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

[PATCH AUTOSEL 5.10 16/33] soundwire: cadence: Don't overwrite msg->buf during write commands
by Sasha Levin 13 Oct '22

13 Oct '22

From: Richard Fitzgerald <rf(a)opensource.cirrus.com> [ Upstream commit ba05b39d265bdd16913f7684600d9d41e2796745 ] The buf passed in struct sdw_msg must only be written for a READ, in that case the RDATA part of the response is the data value of the register. For a write command there is no RDATA, and buf should be assumed to be const and unmodifable. The original caller should not expect its data buffer to be corrupted by an sdw_nwrite(). Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20220916103505.1562210-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soundwire/cadence_master.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index c6d421a4b91b..a3247692ddc0 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -501,9 +501,12 @@ cdns_fill_msg_resp(struct sdw_cdns *cdns, return SDW_CMD_IGNORED; } - /* fill response */ - for (i = 0; i < count; i++) - msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, cdns->response_buf[i]); + if (msg->flags == SDW_MSG_FLAG_READ) { + /* fill response */ + for (i = 0; i < count; i++) + msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, + cdns->response_buf[i]); + } return SDW_CMD_OK; } -- 2.35.1

1 0

[PATCH AUTOSEL 5.15 22/47] soundwire: intel: fix error handling on dai registration issues
by Sasha Levin 13 Oct '22

13 Oct '22

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit c6867cda906aadbce5e71efde9c78a26108b2bad ] The call to intel_register_dai() may fail because of memory allocation issues or problems reported by the ASoC core. In all cases, when a error is thrown the component is not registered, it's invalid to unregister it. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Link: https://lore.kernel.org/r/20220919175721.354679-2-yung-chuan.liao@linux.int… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soundwire/intel.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 38e7f1a2bb97..89ee033f0c35 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1407,7 +1407,6 @@ int intel_link_startup(struct auxiliary_device *auxdev) ret = intel_register_dai(sdw); if (ret) { dev_err(dev, "DAI registration failed: %d\n", ret); - snd_soc_unregister_component(dev); goto err_interrupt; } -- 2.35.1

1 0

[PATCH AUTOSEL 5.15 21/47] soundwire: cadence: Don't overwrite msg->buf during write commands
by Sasha Levin 13 Oct '22

13 Oct '22

From: Richard Fitzgerald <rf(a)opensource.cirrus.com> [ Upstream commit ba05b39d265bdd16913f7684600d9d41e2796745 ] The buf passed in struct sdw_msg must only be written for a READ, in that case the RDATA part of the response is the data value of the register. For a write command there is no RDATA, and buf should be assumed to be const and unmodifable. The original caller should not expect its data buffer to be corrupted by an sdw_nwrite(). Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20220916103505.1562210-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soundwire/cadence_master.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index 4fcc3ba93004..18d2f9b3e201 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -545,9 +545,12 @@ cdns_fill_msg_resp(struct sdw_cdns *cdns, return SDW_CMD_IGNORED; } - /* fill response */ - for (i = 0; i < count; i++) - msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, cdns->response_buf[i]); + if (msg->flags == SDW_MSG_FLAG_READ) { + /* fill response */ + for (i = 0; i < count; i++) + msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, + cdns->response_buf[i]); + } return SDW_CMD_OK; } -- 2.35.1

1 0

[PATCH AUTOSEL 5.19 28/63] soundwire: intel: fix error handling on dai registration issues
by Sasha Levin 13 Oct '22

13 Oct '22

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit c6867cda906aadbce5e71efde9c78a26108b2bad ] The call to intel_register_dai() may fail because of memory allocation issues or problems reported by the ASoC core. In all cases, when a error is thrown the component is not registered, it's invalid to unregister it. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Link: https://lore.kernel.org/r/20220919175721.354679-2-yung-chuan.liao@linux.int… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soundwire/intel.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 505c5ef061e3..865d91ecb862 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1401,7 +1401,6 @@ int intel_link_startup(struct auxiliary_device *auxdev) ret = intel_register_dai(sdw); if (ret) { dev_err(dev, "DAI registration failed: %d\n", ret); - snd_soc_unregister_component(dev); goto err_interrupt; } -- 2.35.1

1 0

[PATCH AUTOSEL 5.19 27/63] soundwire: cadence: Don't overwrite msg->buf during write commands
by Sasha Levin 13 Oct '22

13 Oct '22

From: Richard Fitzgerald <rf(a)opensource.cirrus.com> [ Upstream commit ba05b39d265bdd16913f7684600d9d41e2796745 ] The buf passed in struct sdw_msg must only be written for a READ, in that case the RDATA part of the response is the data value of the register. For a write command there is no RDATA, and buf should be assumed to be const and unmodifable. The original caller should not expect its data buffer to be corrupted by an sdw_nwrite(). Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20220916103505.1562210-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soundwire/cadence_master.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index 4fbb19557f5e..42c5fae80efb 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -544,9 +544,12 @@ cdns_fill_msg_resp(struct sdw_cdns *cdns, return SDW_CMD_IGNORED; } - /* fill response */ - for (i = 0; i < count; i++) - msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, cdns->response_buf[i]); + if (msg->flags == SDW_MSG_FLAG_READ) { + /* fill response */ + for (i = 0; i < count; i++) + msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, + cdns->response_buf[i]); + } return SDW_CMD_OK; } -- 2.35.1

1 0

[PATCH AUTOSEL 6.0 29/67] soundwire: intel: fix error handling on dai registration issues
by Sasha Levin 13 Oct '22

13 Oct '22

From: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> [ Upstream commit c6867cda906aadbce5e71efde9c78a26108b2bad ] The call to intel_register_dai() may fail because of memory allocation issues or problems reported by the ASoC core. In all cases, when a error is thrown the component is not registered, it's invalid to unregister it. Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Reviewed-by: Rander Wang <rander.wang(a)intel.com> Signed-off-by: Bard Liao <yung-chuan.liao(a)linux.intel.com> Link: https://lore.kernel.org/r/20220919175721.354679-2-yung-chuan.liao@linux.int… Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soundwire/intel.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/soundwire/intel.c b/drivers/soundwire/intel.c index 89d1d0d021fc..af6c1a93372d 100644 --- a/drivers/soundwire/intel.c +++ b/drivers/soundwire/intel.c @@ -1429,7 +1429,6 @@ int intel_link_startup(struct auxiliary_device *auxdev) ret = intel_register_dai(sdw); if (ret) { dev_err(dev, "DAI registration failed: %d\n", ret); - snd_soc_unregister_component(dev); goto err_interrupt; } -- 2.35.1

1 0

[PATCH AUTOSEL 6.0 28/67] soundwire: cadence: Don't overwrite msg->buf during write commands
by Sasha Levin 13 Oct '22

13 Oct '22

From: Richard Fitzgerald <rf(a)opensource.cirrus.com> [ Upstream commit ba05b39d265bdd16913f7684600d9d41e2796745 ] The buf passed in struct sdw_msg must only be written for a READ, in that case the RDATA part of the response is the data value of the register. For a write command there is no RDATA, and buf should be assumed to be const and unmodifable. The original caller should not expect its data buffer to be corrupted by an sdw_nwrite(). Signed-off-by: Richard Fitzgerald <rf(a)opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> Link: https://lore.kernel.org/r/20220916103505.1562210-1-rf@opensource.cirrus.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/soundwire/cadence_master.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/soundwire/cadence_master.c b/drivers/soundwire/cadence_master.c index 4fbb19557f5e..42c5fae80efb 100644 --- a/drivers/soundwire/cadence_master.c +++ b/drivers/soundwire/cadence_master.c @@ -544,9 +544,12 @@ cdns_fill_msg_resp(struct sdw_cdns *cdns, return SDW_CMD_IGNORED; } - /* fill response */ - for (i = 0; i < count; i++) - msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, cdns->response_buf[i]); + if (msg->flags == SDW_MSG_FLAG_READ) { + /* fill response */ + for (i = 0; i < count; i++) + msg->buf[i + offset] = FIELD_GET(CDNS_MCP_RESP_RDATA, + cdns->response_buf[i]); + } return SDW_CMD_OK; } -- 2.35.1

1 0

[PATCH v1 0/5] Support System Suspend and Resume for CS35L41 HDA
by Stefan Binding 12 Oct '22

12 Oct '22

The CS35L41 HDA driver currently only supports runtime suspend and resume. Add support for system suspend and resume into the CS35L41 HDA driver. The driver will put the parts into a state where they can be powered down during suspend, and on system resume, it will restore the part. If firmware was previously loaded, during system suspend, the firmware will be unloaded, and during system resume, it will be loaded again. Note: System suspend is only supported for models which use Internal Boost, or models which use External Boost with a Boost Enable GPIO. The chain also contains minor bug fixes for the CS35L41 HDA driver, and associated hda_cs_dsp_ctl driver. Richard Fitzgerald (1): ALSA: hda/cs_dsp_ctl: Fix mutex inversion when creating controls Stefan Binding (4): ALSA: hda: hda_cs_dsp_ctl: Minor clean and redundant code removal ALSA: hda: hda_cs_dsp_ctl: Ensure pwr_lock is held before reading/writing controls ALSA: hda: cs35l41: Remove suspend/resume hda hooks ALSA: hda: cs35l41: Support System Suspend sound/pci/hda/cs35l41_hda.c | 197 +++++++++++++++++++++++++-------- sound/pci/hda/hda_component.h | 2 - sound/pci/hda/hda_cs_dsp_ctl.c | 79 +++++++------ sound/pci/hda/hda_cs_dsp_ctl.h | 2 +- sound/pci/hda/patch_realtek.c | 19 +--- 5 files changed, 198 insertions(+), 101 deletions(-) -- 2.34.1

2 6

Re: Fw: [External] RE: [PATCH -next] ASoC: amd: yc: Adding Lenovo ThinkBook 14 Gen 4+ ARA and Lenovo ThinkBook 16 Gen 4+ ARA to the Quirks List
by Mark Pearson 11 Oct '22

11 Oct '22

<moved to my more open-source friendly email account> Thanks Mario On 2022-10-11 13:14, Mark Pearson wrote: > > -------------------------------------------------------------------------------- > *From:* Limonciello, Mario <Mario.Limonciello(a)amd.com> > *Sent:* October 11, 2022 13:08 > *Subject:* [External] RE: [PATCH -next] ASoC: amd: yc: Adding Lenovo ThinkBook > 14 Gen 4+ ARA and Lenovo ThinkBook 16 Gen 4+ ARA to the Quirks List > [Public] > > Cc: > Mark Pearson > Vijendar > Syed > Renjith > >> -----Original Message----- >> From: linkt <xazrael(a)hotmail.com> >> Sent: Monday, October 10, 2022 21:52 >> To: lgirdwood(a)gmail.com; broonie(a)kernel.org; perex(a)perex.cz; >> tiwai(a)suse.com; Limonciello, Mario <Mario.Limonciello(a)amd.com> >> Cc: alsa-devel(a)alsa-project.org; linux-kernel(a)vger.kernel.org; linkt >> <xazrael(a)hotmail.com> >> Subject: [PATCH -next] ASoC: amd: yc: Adding Lenovo ThinkBook 14 Gen 4+ >> ARA and Lenovo ThinkBook 16 Gen 4+ ARA to the Quirks List >> >> Lenovo ThinkBook 14 Gen 4+ ARA and ThinkBook 16 Gen 4+ ARA >> need to be added to the list of quirks for the microphone to work properly. >> >> Signed-off-by: linkt <xazrael(a)hotmail.com> > > This patch alone makes sense to me. > > Cc: stable(a)vger.kernel.org > Reviewed-by: Mario Limonciello <mario.limonciello(a)amd.com> > > I think it should go in as is, but it prompts another idea to me I want to run by > Mark specifically.. > > Should we just drop this whole file down to a much simpler DMI match prefix like > this: > >> + { >> + .driver_data = &acp6x_card, >> + .matches = { >> + DMI_MATCH(DMI_BOARD_VENDOR, "LENOVO"), >> + DMI_MATCH(DMI_PRODUCT_NAME, "21"), >> + } >> + }, > > That would allow it to match all the Lenovo Rembrandt systems presumably and > can stop touching the file. This only makes sense if every single Lenovo > Rembrandt design > uses a DMIC from ACP. I don't know if that's a valid assumption and I think we > need Mark > to confirm it. > > The DMI match "technically" would match some of the Intel systems from this > generation > but this driver is only "loaded" on AMD Rembrandt systems, so I don't think it's > a problem. > I love the idea but I'm a little hesitant as I don't know if I'll be able to confirm it authoritatively - I don't have particularly great levers to pull on for platforms outside the Linux program. I'll try - but I think chances of being able to reply yes or no with confidence are limited. I think it's relatively low risk for breaking anything on this years platforms - but may get more interesting for next years. If needed can we then just quirk any platforms that come up that need the logic reversing or does that get really messy. I can confirm the "21" match is going to be match a ton of Intel platforms. For the AMD platforms - will this be limited to Rembrandt only or will it affect any past/future generations? Short answer - I'll see what I can find...but no promises Mark

2 1

Re: [PATCH v2 02/36] gpiolib: cdev: Add missed header(s)
by Andy Shevchenko 11 Oct '22

11 Oct '22

On Tue, Oct 11, 2022 at 11:05:42AM +0300, Andy Shevchenko wrote: > On Tue, Oct 11, 2022 at 3:02 AM Kent Gibson <warthog618(a)gmail.com> wrote: > > On Mon, Oct 10, 2022 at 11:14:18PM +0300, Andy Shevchenko wrote: ... > > > -#include <linux/gpio.h> > > > #include <linux/gpio/driver.h> > > > +#include <linux/gpio.h> > > > +#include <linux/hte.h> > > > > Ok with the hte re-order. > > > > But moving the gpio subsystem header after the gpio/driver is not > > alphabetical ('.' precedes '/') and it read better and made more sense > > to me the way it was. > > I see, I guess this is vim sort vs shell sort. Strange, they should > follow the locale settings... I have checked, the shell and vim sort gave the same result as in this patch. -- With Best Regards, Andy Shevchenko

3 5