[PATCH 0/2] ASoC: cs35l56: Update ACPI HID and property
These two patches add an ACPI HID and update the way the platform- specific firmware identifier is extracted from the ACPI.
Maciej Strozek (1): ASoC: cs35l56: Read firmware uuid from a device property instead of _SUB
Simon Trimmer (1): ASoC: cs35l56: Add an ACPI match table
sound/soc/codecs/cs35l56-i2c.c | 9 +++++++++ sound/soc/codecs/cs35l56-spi.c | 9 +++++++++ sound/soc/codecs/cs35l56.c | 31 ++++++++++++++----------------- 3 files changed, 32 insertions(+), 17 deletions(-)
From: Simon Trimmer simont@opensource.cirrus.com
An ACPI ID has been allocated for CS35L56 ASoC devices so that they can be instantiated from ACPI Device entries.
Signed-off-by: Simon Trimmer simont@opensource.cirrus.com Signed-off-by: Richard Fitzgerald rf@opensource.cirrus.com --- sound/soc/codecs/cs35l56-i2c.c | 9 +++++++++ sound/soc/codecs/cs35l56-spi.c | 9 +++++++++ 2 files changed, 18 insertions(+)
diff --git a/sound/soc/codecs/cs35l56-i2c.c b/sound/soc/codecs/cs35l56-i2c.c index 888fdfa5f5db..9f4f2f4f23f5 100644 --- a/sound/soc/codecs/cs35l56-i2c.c +++ b/sound/soc/codecs/cs35l56-i2c.c @@ -62,10 +62,19 @@ static const struct i2c_device_id cs35l56_id_i2c[] = { }; MODULE_DEVICE_TABLE(i2c, cs35l56_id_i2c);
+#ifdef CONFIG_ACPI +static const struct acpi_device_id cs35l56_asoc_acpi_match[] = { + { "CSC355C", 0 }, + {}, +}; +MODULE_DEVICE_TABLE(acpi, cs35l56_asoc_acpi_match); +#endif + static struct i2c_driver cs35l56_i2c_driver = { .driver = { .name = "cs35l56", .pm = &cs35l56_pm_ops_i2c_spi, + .acpi_match_table = ACPI_PTR(cs35l56_asoc_acpi_match), }, .id_table = cs35l56_id_i2c, .probe = cs35l56_i2c_probe, diff --git a/sound/soc/codecs/cs35l56-spi.c b/sound/soc/codecs/cs35l56-spi.c index 2057fce435be..9962703915e1 100644 --- a/sound/soc/codecs/cs35l56-spi.c +++ b/sound/soc/codecs/cs35l56-spi.c @@ -59,10 +59,19 @@ static const struct spi_device_id cs35l56_id_spi[] = { }; MODULE_DEVICE_TABLE(spi, cs35l56_id_spi);
+#ifdef CONFIG_ACPI +static const struct acpi_device_id cs35l56_asoc_acpi_match[] = { + { "CSC355C", 0 }, + {}, +}; +MODULE_DEVICE_TABLE(acpi, cs35l56_asoc_acpi_match); +#endif + static struct spi_driver cs35l56_spi_driver = { .driver = { .name = "cs35l56", .pm = &cs35l56_pm_ops_i2c_spi, + .acpi_match_table = ACPI_PTR(cs35l56_asoc_acpi_match), }, .id_table = cs35l56_id_spi, .probe = cs35l56_spi_probe,
From: Maciej Strozek mstrozek@opensource.cirrus.com
Use a device property "cirrus,firmware-uid" to get the unique firmware identifier instead of using ACPI _SUB.
There will not usually be a _SUB in Soundwire nodes. The ACPI can use a _DSD section for custom properties.
There is also a need to support instantiating this driver using software nodes. This is for systems where the CS35L56 is a back-end device and the ACPI refers only to the front-end audio device - there will not be any ACPI references to CS35L56.
Signed-off-by: Maciej Strozek mstrozek@opensource.cirrus.com Signed-off-by: Richard Fitzgerald rf@opensource.cirrus.com --- sound/soc/codecs/cs35l56.c | 31 ++++++++++++++----------------- 1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/sound/soc/codecs/cs35l56.c b/sound/soc/codecs/cs35l56.c index 3a9ec8724cc1..1f4cee097119 100644 --- a/sound/soc/codecs/cs35l56.c +++ b/sound/soc/codecs/cs35l56.c @@ -5,7 +5,6 @@ // Copyright (C) 2023 Cirrus Logic, Inc. and // Cirrus Logic International Semiconductor Ltd.
-#include <linux/acpi.h> #include <linux/completion.h> #include <linux/debugfs.h> #include <linux/delay.h> @@ -1029,26 +1028,24 @@ static int cs35l56_dsp_init(struct cs35l56_private *cs35l56) return 0; }
-static int cs35l56_acpi_get_name(struct cs35l56_private *cs35l56) +static int cs35l56_get_firmware_uid(struct cs35l56_private *cs35l56) { - acpi_handle handle = ACPI_HANDLE(cs35l56->base.dev); - const char *sub; + const char *prop; + int ret;
- /* If there is no ACPI_HANDLE, there is no ACPI for this system, return 0 */ - if (!handle) + ret = device_property_read_string(cs35l56->base.dev, "cirrus,firmware-uid", + &prop); + /* + * If bad sw node property, return 0 and fallback to legacy firmware path + */ + if (ret < 0) return 0;
- sub = acpi_get_subsystem_id(handle); - if (IS_ERR(sub)) { - /* If bad ACPI, return 0 and fallback to legacy firmware path, otherwise fail */ - if (PTR_ERR(sub) == -ENODATA) - return 0; - else - return PTR_ERR(sub); - } + cs35l56->dsp.system_name = kstrdup(prop, GFP_KERNEL); + if (cs35l56->dsp.system_name == NULL) + return -ENOMEM;
- cs35l56->dsp.system_name = sub; - dev_dbg(cs35l56->base.dev, "Subsystem ID: %s\n", cs35l56->dsp.system_name); + dev_dbg(cs35l56->base.dev, "Firmware UID: %s\n", cs35l56->dsp.system_name);
return 0; } @@ -1095,7 +1092,7 @@ int cs35l56_common_probe(struct cs35l56_private *cs35l56) gpiod_set_value_cansleep(cs35l56->base.reset_gpio, 1); }
- ret = cs35l56_acpi_get_name(cs35l56); + ret = cs35l56_get_firmware_uid(cs35l56); if (ret != 0) goto err;
On Wed, Aug 16, 2023 at 05:49:06PM +0100, Richard Fitzgerald wrote:
From: Maciej Strozek mstrozek@opensource.cirrus.com
Use a device property "cirrus,firmware-uid" to get the unique firmware identifier instead of using ACPI _SUB.
There will not usually be a _SUB in Soundwire nodes. The ACPI can use a _DSD section for custom properties.
There is also a need to support instantiating this driver using software nodes. This is for systems where the CS35L56 is a back-end device and the ACPI refers only to the front-end audio device - there will not be any ACPI references to CS35L56.
Are there any existing systems (or might there be given that the driver is in released kernels already) which rely on _SUB?
On 16/8/23 18:03, Mark Brown wrote:
On Wed, Aug 16, 2023 at 05:49:06PM +0100, Richard Fitzgerald wrote:
From: Maciej Strozek mstrozek@opensource.cirrus.com
Use a device property "cirrus,firmware-uid" to get the unique firmware identifier instead of using ACPI _SUB.
There will not usually be a _SUB in Soundwire nodes. The ACPI can use a _DSD section for custom properties.
There is also a need to support instantiating this driver using software nodes. This is for systems where the CS35L56 is a back-end device and the ACPI refers only to the front-end audio device - there will not be any ACPI references to CS35L56.
Are there any existing systems (or might there be given that the driver is in released kernels already) which rely on _SUB?
No. Nothing has been released with CS35L56.
On Wed, Aug 16, 2023 at 06:09:52PM +0100, Richard Fitzgerald wrote:
On 16/8/23 18:03, Mark Brown wrote:
On Wed, Aug 16, 2023 at 05:49:06PM +0100, Richard Fitzgerald wrote:
There is also a need to support instantiating this driver using software nodes. This is for systems where the CS35L56 is a back-end device and the ACPI refers only to the front-end audio device - there will not be any ACPI references to CS35L56.
Are there any existing systems (or might there be given that the driver is in released kernels already) which rely on _SUB?
No. Nothing has been released with CS35L56.
And nobody's going to pick up a kernel with the old binding when they're putting together a product? If we're going to make this change it should be sent as a fix in order to minimise the risk of that happening but this patch doesn't apply against for-6.5, could you rebase please?
On Wed, 16 Aug 2023 17:49:04 +0100, Richard Fitzgerald wrote:
These two patches add an ACPI HID and update the way the platform- specific firmware identifier is extracted from the ACPI.
Maciej Strozek (1): ASoC: cs35l56: Read firmware uuid from a device property instead of _SUB
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: cs35l56: Add an ACPI match table commit: e8500a70270334b9abad72fea504ef38a2952274 [2/2] ASoC: cs35l56: Read firmware uuid from a device property instead of _SUB commit: 897a6b5a030e62c21566551c870d81740f82ca13
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
participants (2)
-
Mark Brown -
Richard Fitzgerald