April 2024 - Alsa-devel - mailman.alsa-project.org

Re:Re:Re:Re: [PATCH] cpufreq: exit() callback is optional
by lizhe 13 Apr '24

13 Apr '24

HI I urge you to pay close attention to this incident once again. thanks Please don't let the Linux kernel community be filled with robbers and thieves! On April 12th, 2024, at 00:57, I sent the vulnerability and explained the situation to the maintainer at rafael(a)kernel.org and viresh.kumar(a)linaro.org. At 02:11 on April 12th, 2024, Rafael replied to me, asking me to submit it to the main branch. At 07:18 on April 12th, 2024, I submitted the vulnerability to the main branch. At 11:24 on April 12th, 2024, Viresh Kumar replied to me, confirming that the vulnerability was legitimate. At 13:49 on April 12th, 2024, Viresh Kumar released the patch to the main list. Viresh Kumar, are you not a robber and thief? As a maintainer, do you really not care about the healthy development of the community and only defend your own interests? It was me who first released the patch and publicly disclosed the vulnerability to the main branch. Viresh Kumar only understood the principle of the vulnerability after seeing my submitted patch. Even if my patch was not of high quality, I could immediately improve it. Moreover, I communicated with you later and requested to add my signature to the patch, but you refused to communicate. Your behavior fully demonstrates that you are a selfish person. I don't understand why there can be such a selfish person in a country where Buddhism was born, and this person is even a maintainer! At 2024-04-12 22:41:27, "lizhe" <sensor1010(a)163.com> wrote: Let's both take a step back and add my signature to the patch, since I was the one who discovered and reported the vulnerability. HI i will review how it all started. 1. i reported the vulnerability to the maintainer. 2. manitaner replay me 3. i report to main line 4. you reply me 5 . you report to main line You submitted the patch to the mainline after you learned about the vulnerability from the patch I submitted At 2024-04-12 21:54:00, "lizhe" <sensor1010(a)163.com> wrote: Hi Viresh Kumar please add my name to the signature. because i discovered this vulnerability. please reply me. thanks At 2024-04-12 18:28:56, "Greg KH" <gregkh(a)linuxfoundation.org> wrote: >On Fri, Apr 12, 2024 at 02:51:08PM +0530, Viresh Kumar wrote: >> On 12-04-24, 17:05, lizhe wrote: >> > I found it first and submitted it to the main line first. Please be fair and just. Let him withdraw his patch. >> >> Well, I decided not to reply to your emails anymore but this needs to >> be clarified a bit now. >> >> You sent a lot of patches, over and over again and it was a mess. I >> saw the this [1] series first and went over to read the code and fixed >> an issue which I found (by the $subject patch). >> >> Later I read your other patch [2], which I Acked roughly two hours >> back and yes you did send a patch that fixed the problem partially. I >> never saw it earlier, which is okay and it happens. Despite me giving >> an Ack to your patch, you have sent half-a-dozen more emails.. >> >> Then I posted a newer version of my patch some time back, removing the >> bits you already fixed [3]. >> >> That is all one side of the story. But all the noise you have created >> here has really demotivated people to review your stuff now. >> >> -- >> Viresh >> >> [1] https://lore.kernel.org/all/20240410132132.3526-1-sensor1010@163.com/ >> [2] https://lore.kernel.org/all/20240411231818.2471-1-sensor1010@163.com/ >> [3] https://lore.kernel.org/all/68294ce534668c6ab3b71a1b3e6650227c6e1f20.171291… > >Thanks for the links, I don't see that you did anything wrong here at >all. > >Lizhe, you seem to be confused as to how kernel development works. I >suggest you take some time off and read up on how this all is supposed >to happen and then work with some local people, in person, to get this >figured out first, before submitting changes again. > >thanks, > >greg k-h

1 0

qcom: sdm845: MM1: fixes
by GitHub pull_request - opened 13 Apr '24

13 Apr '24

alsa-project/alsa-ucm-conf pull request #408 was opened from jenneron: I'm testing it on a device which is not in upstream yet, but it uses this configuration It seems that the only device in upstream using it is Lenovo Yoga C630 laptop and we got it tested as well https://oftc.irclog.whitequark.org/aarch64-laptops/2024-04-06#33084827 The changes are pretty straightforward, check commit messages of each commit Request URL : https://github.com/alsa-project/alsa-ucm-conf/pull/408 Patch URL : https://github.com/alsa-project/alsa-ucm-conf/pull/408.patch Repository URL: https://github.com/alsa-project/alsa-ucm-conf

1 0

[PATCH v2] dt-bindings: omap-mcpdm: Convert to DT schema
by Mighty 12 Apr '24

12 Apr '24

From: Mithil Bavishi <bavishimithil(a)gmail.com> Convert the OMAP4+ McPDM bindings to DT schema. Signed-off-by: Mighty <bavishimithil(a)gmail.com> --- .../devicetree/bindings/sound/omap-mcpdm.txt | 30 ---------- .../bindings/sound/ti,omap-mcpdm.yaml | 59 +++++++++++++++++++ 2 files changed, 59 insertions(+), 30 deletions(-) delete mode 100644 Documentation/devicetree/bindings/sound/omap-mcpdm.txt create mode 100644 Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml diff --git a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt b/Documentation/devicetree/bindings/sound/omap-mcpdm.txt deleted file mode 100644 index ff98a0cb5..000000000 --- a/Documentation/devicetree/bindings/sound/omap-mcpdm.txt +++ /dev/null @@ -1,30 +0,0 @@ -* Texas Instruments OMAP4+ McPDM - -Required properties: -- compatible: "ti,omap4-mcpdm" -- reg: Register location and size as an array: - <MPU access base address, size>, - <L3 interconnect address, size>; -- interrupts: Interrupt number for McPDM -- ti,hwmods: Name of the hwmod associated to the McPDM -- clocks: phandle for the pdmclk provider, likely <&twl6040> -- clock-names: Must be "pdmclk" - -Example: - -mcpdm: mcpdm@40132000 { - compatible = "ti,omap4-mcpdm"; - reg = <0x40132000 0x7f>, /* MPU private access */ - <0x49032000 0x7f>; /* L3 Interconnect */ - interrupts = <0 112 0x4>; - interrupt-parent = <&gic>; - ti,hwmods = "mcpdm"; -}; - -In board DTS file the pdmclk needs to be added: - -&mcpdm { - clocks = <&twl6040>; - clock-names = "pdmclk"; - status = "okay"; -}; diff --git a/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml b/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml new file mode 100644 index 000000000..4d5d37e98 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/ti,omap-mcpdm.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/ti,omap-mcpdm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OMAP McPDM + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> + +description: + OMAP ALSA SoC DAI driver using McPDM port used by TWL6040 + +properties: + compatible: + const: ti,omap4-mcpdm + + reg: + description: + Register location and size as an array + <MPU access base address, size>, + <L3 interconnect address, size>; + + interrupts: + maxItems: 1 + + ti,hwmods: + maxItems: 1 + + clocks: + description: phandle for the pdmclk provider, likely <&twl6040> + + clock-names: + description: Must be "pdmclk" + + +required: + - compatible + - reg + - interrupts + - ti,hwmods + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + mcpdm@0 { + compatible = "ti,omap4-mcpdm"; + reg = <0x40132000 0x7f>, /* MPU private access */ + <0x49032000 0x7f>; /* L3 Interconnect */ + interrupts = <0 112 0x4>; + interrupt-parent = <&gic>; + ti,hwmods = "mcpdm"; + clocks = <&twl6040>; + clock-names = "pdmclk"; + }; -- 2.34.1

3 9

UCM vs SOF vs HDMI passthrough
by Péter Ujfalusi 12 Apr '24

12 Apr '24

Hi, afaik for HDMI passthrough there should be a usable PCM mapping present for user space: aplay -L | grep hdmi hdmi:CARD=PCH,DEV=0 hdmi:CARD=PCH,DEV=1 hdmi:CARD=PCH,DEV=2 or similar. SOF with IPC4 (Meteor Lake and newer or some TGL/ADL setups with 2024.03 release) it is possible to use passthrough via HDMI technically but we are lacking the "hdmi:..." PCMs, so in reality it is not usable for applications. Afaik. So far I managed to cook up two ways of doing this, but neither one is good enough as they will create the "hdmi:..." for both IPC3 and IPC4 setups and IPC3 firmware cannot support passthrough. Setups: sof-hda-dsp cards have HDMI PCMs: pcm3-5 sof-soundwire cards have HDMI PCMs: pcm5-7 [A] use card profile Add these to /usr/share/alsa/cards/aliases.conf: sof-hda-dsp cards.sof-hda-dsp sof-soundwire cards.sof-soundwire Create the minimal sof-hda-ds.conf and sof-soundwire.conf to handle the two types of HDMI PCM numbering. [B] Using UCM https://github.com/ujfalusi/alsa-ucm-conf/tree/topic/sof-hdmi It is using the BootSequence[] to create three files: [1] /var/lib/alsa/conf.d/42-sof-hdmi.conf [2] /var/lib/alsa/card[card_number].conf.d/30-sof-hdmi-common.conf [3] /var/lib/alsa/card[card_number].conf.d/31-sof-hdmi.conf [1] includes the pcm/iec958.conf and pcm/hdmi.conf to global space of alsaconf to be used by the card macros [2] Card specific macros for hdmi PCM definition, ampping [3] Card specific definitions of the three HDMI port In both case I have the needed PCMs: aplay -L | grep hdmi hdmi:CARD=sofhdadsp,DEV=0 hdmi:CARD=sofhdadsp,DEV=1 hdmi:CARD=sofhdadsp,DEV=2 or hdmi:CARD=sofsoundwire,DEV=0 hdmi:CARD=sofsoundwire,DEV=1 hdmi:CARD=sofsoundwire,DEV=2 But it is unconditional and they will be created for all sof-hda-dsp and sof-soundwire cards. I would really appreciate some guidance on how we can achieve this correctly (the code for the UCM way leaves much to be desired, I know). How can this be done conditionally? We can set the HDMI PCMs to advertise IEC958_SUBFRAME_LE for IPC4 only, but how can we use that? Should we add some parameter to 'amixer -c0 info', like ipc_version:4/3, so if the ipc_version is 3 or missing we assume that passthrough is not supported? Thanks for the help, Péter

2 2

[PATCH RESEND] soundwire: qcom: allow multi-link on newer devices
by Krzysztof Kozlowski 12 Apr '24

12 Apr '24

Newer Qualcomm SoCs like X1E80100 might come with four speakers spread over two Soundwire controllers, thus they need a multi-link Soundwire stream runtime. Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Almost four months, so let's resend this one. Add Rb tag. --- drivers/soundwire/qcom.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index 82b3ca5a405a..a97412c8671e 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -920,6 +920,18 @@ static int qcom_swrm_init(struct qcom_swrm_ctrl *ctrl) return 0; } +static int qcom_swrm_read_prop(struct sdw_bus *bus) +{ + struct qcom_swrm_ctrl *ctrl = to_qcom_sdw(bus); + + if (ctrl->version >= SWRM_VERSION_2_0_0) { + bus->multi_link = true; + bus->hw_sync_min_links = 3; + } + + return 0; +} + static enum sdw_command_response qcom_swrm_xfer_msg(struct sdw_bus *bus, struct sdw_msg *msg) { @@ -1078,6 +1090,7 @@ static const struct sdw_master_port_ops qcom_swrm_port_ops = { }; static const struct sdw_master_ops qcom_swrm_ops = { + .read_prop = qcom_swrm_read_prop, .xfer_msg = qcom_swrm_xfer_msg, .pre_bank_switch = qcom_swrm_pre_bank_switch, .post_bank_switch = qcom_swrm_post_bank_switch, @@ -1196,6 +1209,15 @@ static int qcom_swrm_stream_alloc_ports(struct qcom_swrm_ctrl *ctrl, mutex_lock(&ctrl->port_lock); list_for_each_entry(m_rt, &stream->master_list, stream_node) { + /* + * For streams with multiple masters: + * Allocate ports only for devices connected to this master. + * Such devices will have ports allocated by their own master + * and its qcom_swrm_stream_alloc_ports() call. + */ + if (ctrl->bus.id != m_rt->bus->id) + continue; + if (m_rt->direction == SDW_DATA_DIR_RX) { maxport = ctrl->num_dout_ports; port_mask = &ctrl->dout_port_mask; -- 2.34.1

2 5

[PATCH v1] ASoC: cs35l41: Update DSP1RX5/6 Sources for DSP config
by Stefan Binding 12 Apr '24

12 Apr '24

Currently, all ASoC systems are set to use VPMON for DSP1RX5_SRC, however, this is required only for internal boost systems. External boost systems require VBSTMON instead of VPMON to be the input to DSP1RX5_SRC. Shared Boost Active acts like Internal boost (requires VPMON). Shared Boost Passive acts like External boost (requires VBSTMON) All systems require DSP1RX6_SRC to be set to VBSTMON. Signed-off-by: Stefan Binding <sbinding(a)opensource.cirrus.com> --- sound/soc/codecs/cs35l41.c | 26 ++++++++++++++++++++------ 1 file changed, 20 insertions(+), 6 deletions(-) diff --git a/sound/soc/codecs/cs35l41.c b/sound/soc/codecs/cs35l41.c index dfb4ce53491b..f8e57a2fc3e3 100644 --- a/sound/soc/codecs/cs35l41.c +++ b/sound/soc/codecs/cs35l41.c @@ -1094,6 +1094,7 @@ static int cs35l41_handle_pdata(struct device *dev, struct cs35l41_hw_cfg *hw_cf static int cs35l41_dsp_init(struct cs35l41_private *cs35l41) { struct wm_adsp *dsp; + uint32_t dsp1rx5_src; int ret; dsp = &cs35l41->dsp; @@ -1113,16 +1114,29 @@ static int cs35l41_dsp_init(struct cs35l41_private *cs35l41) return ret; } - ret = regmap_write(cs35l41->regmap, CS35L41_DSP1_RX5_SRC, - CS35L41_INPUT_SRC_VPMON); + switch (cs35l41->hw_cfg.bst_type) { + case CS35L41_INT_BOOST: + case CS35L41_SHD_BOOST_ACTV: + dsp1rx5_src = CS35L41_INPUT_SRC_VPMON; + break; + case CS35L41_EXT_BOOST: + case CS35L41_SHD_BOOST_PASS: + dsp1rx5_src = CS35L41_INPUT_SRC_VBSTMON; + break; + default: + dev_err(cs35l41->dev, "wm_halo_init failed - Invalid Boost Type: %d\n", + cs35l41->hw_cfg.bst_type); + goto err_dsp; + } + + ret = regmap_write(cs35l41->regmap, CS35L41_DSP1_RX5_SRC, dsp1rx5_src); if (ret < 0) { - dev_err(cs35l41->dev, "Write INPUT_SRC_VPMON failed: %d\n", ret); + dev_err(cs35l41->dev, "Write DSP1RX5_SRC: %d failed: %d\n", dsp1rx5_src, ret); goto err_dsp; } - ret = regmap_write(cs35l41->regmap, CS35L41_DSP1_RX6_SRC, - CS35L41_INPUT_SRC_CLASSH); + ret = regmap_write(cs35l41->regmap, CS35L41_DSP1_RX6_SRC, CS35L41_INPUT_SRC_VBSTMON); if (ret < 0) { - dev_err(cs35l41->dev, "Write INPUT_SRC_CLASSH failed: %d\n", ret); + dev_err(cs35l41->dev, "Write CS35L41_INPUT_SRC_VBSTMON failed: %d\n", ret); goto err_dsp; } ret = regmap_write(cs35l41->regmap, CS35L41_DSP1_RX7_SRC, -- 2.34.1

3 2

[PATCH][next] ASoC: codecs: tas2780: remove redundant assignments to variable ret
by Colin Ian King 12 Apr '24

12 Apr '24

Variable ret is being assigned a value that is never read in a couple of places. The variable is being re-assigned later on. The assignments are redundant and can be removed. Cleans up clang scan build warning: sound/soc/codecs/tas2780.c:84:2: warning: Value stored to 'ret' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King <colin.i.king(a)gmail.com> --- sound/soc/codecs/tas2780.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sound/soc/codecs/tas2780.c b/sound/soc/codecs/tas2780.c index 41076be23854..972e8ea5ebde 100644 --- a/sound/soc/codecs/tas2780.c +++ b/sound/soc/codecs/tas2780.c @@ -71,7 +71,7 @@ static int tas2780_codec_resume(struct snd_soc_component *component) { struct tas2780_priv *tas2780 = snd_soc_component_get_drvdata(component); - int ret = 0; + int ret; ret = snd_soc_component_update_bits(component, TAS2780_PWR_CTRL, TAS2780_PWR_CTRL_MASK, TAS2780_PWR_CTRL_ACTIVE); @@ -81,7 +81,6 @@ static int tas2780_codec_resume(struct snd_soc_component *component) __func__, ret); goto err; } - ret = 0; regcache_cache_only(tas2780->regmap, false); ret = regcache_sync(tas2780->regmap); err: -- 2.39.2

2 1

[PATCH] MAINTAINERS: adjust file entry in TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS
by Lukas Bulwahn 12 Apr '24

12 Apr '24

Commit 8167bd1c8a45 ("ASoC: dt-bindings: ti,pcm1681: Convert to dtschema") converts ti,pcm1681.txt to ti,pcm1681.yaml, but misses to adjust the file entry in TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains about a broken reference. Adjust the file entry in TEXAS INSTRUMENTS AUDIO (ASoC/HDA) DRIVERS after this conversion. Signed-off-by: Lukas Bulwahn <lukas.bulwahn(a)redhat.com> --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index e5431f06ab55..d39e0f2556f7 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -21976,7 +21976,7 @@ F: Documentation/devicetree/bindings/sound/tas2552.txt F: Documentation/devicetree/bindings/sound/tas2562.yaml F: Documentation/devicetree/bindings/sound/tas2770.yaml F: Documentation/devicetree/bindings/sound/tas27xx.yaml -F: Documentation/devicetree/bindings/sound/ti,pcm1681.txt +F: Documentation/devicetree/bindings/sound/ti,pcm1681.yaml F: Documentation/devicetree/bindings/sound/ti,pcm3168a.yaml F: Documentation/devicetree/bindings/sound/ti,tlv320*.yaml F: Documentation/devicetree/bindings/sound/tlv320adcx140.yaml -- 2.44.0

1 0

[PATCH v2] soundwire: qcom: allow multi-link on newer devices
by Krzysztof Kozlowski 11 Apr '24

11 Apr '24

Newer Qualcomm SoCs like X1E80100 might come with four speakers spread over two Soundwire controllers, thus they need a multi-link Soundwire stream runtime. Cc: Mark Brown <broonie(a)kernel.org> Cc: alsa-devel(a)alsa-project.org Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Changes in v2: 1. Only rebase (slightly different context) --- drivers/soundwire/qcom.c | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c index fb70afe64fcc..ce5cf3ecceb5 100644 --- a/drivers/soundwire/qcom.c +++ b/drivers/soundwire/qcom.c @@ -905,6 +905,18 @@ static int qcom_swrm_init(struct qcom_swrm_ctrl *ctrl) return 0; } +static int qcom_swrm_read_prop(struct sdw_bus *bus) +{ + struct qcom_swrm_ctrl *ctrl = to_qcom_sdw(bus); + + if (ctrl->version >= SWRM_VERSION_2_0_0) { + bus->multi_link = true; + bus->hw_sync_min_links = 3; + } + + return 0; +} + static enum sdw_command_response qcom_swrm_xfer_msg(struct sdw_bus *bus, struct sdw_msg *msg) { @@ -1056,6 +1068,7 @@ static const struct sdw_master_port_ops qcom_swrm_port_ops = { }; static const struct sdw_master_ops qcom_swrm_ops = { + .read_prop = qcom_swrm_read_prop, .xfer_msg = qcom_swrm_xfer_msg, .pre_bank_switch = qcom_swrm_pre_bank_switch, }; @@ -1173,6 +1186,15 @@ static int qcom_swrm_stream_alloc_ports(struct qcom_swrm_ctrl *ctrl, mutex_lock(&ctrl->port_lock); list_for_each_entry(m_rt, &stream->master_list, stream_node) { + /* + * For streams with multiple masters: + * Allocate ports only for devices connected to this master. + * Such devices will have ports allocated by their own master + * and its qcom_swrm_stream_alloc_ports() call. + */ + if (ctrl->bus.id != m_rt->bus->id) + continue; + if (m_rt->direction == SDW_DATA_DIR_RX) { maxport = ctrl->num_dout_ports; port_mask = &ctrl->dout_port_mask; -- 2.34.1

2 4

[PATCH v2] slimbus: qcom-ngd-ctrl: Add timeout for wait operation
by Viken Dadhaniya 11 Apr '24

11 Apr '24

In current driver qcom_slim_ngd_up_worker() indefinitely waiting for ctrl->qmi_up completion object. This is resulting in workqueue lockup on Kthread. Added wait_for_completion_interruptible_timeout to allow the thread to wait for specific timeout period and bail out instead waiting infinitely. Fixes: a899d324863a ("slimbus: qcom-ngd-ctrl: add Sub System Restart support") Cc: stable(a)vger.kernel.org Reviewed-by: Konrad Dybcio <konrad.dybcio(a)linaro.org> Signed-off-by: Viken Dadhaniya <quic_vdadhani(a)quicinc.com> --- v1 -> v2: - Remove macro and add value inline. - add fix, cc and review tag. --- --- drivers/slimbus/qcom-ngd-ctrl.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c index efeba8275a66..a09a26bf4988 100644 --- a/drivers/slimbus/qcom-ngd-ctrl.c +++ b/drivers/slimbus/qcom-ngd-ctrl.c @@ -1451,7 +1451,11 @@ static void qcom_slim_ngd_up_worker(struct work_struct *work) ctrl = container_of(work, struct qcom_slim_ngd_ctrl, ngd_up_work); /* Make sure qmi service is up before continuing */ - wait_for_completion_interruptible(&ctrl->qmi_up); + if (!wait_for_completion_interruptible_timeout(&ctrl->qmi_up, + msecs_to_jiffies(MSEC_PER_SEC))) { + dev_err(ctrl->dev, "QMI wait timeout\n"); + return; + } mutex_lock(&ctrl->ssr_lock); qcom_slim_ngd_enable(ctrl, true); -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

2 1