[alsa-devel] [RFC] ASoC: core: Allow DAI links to be specified by using ACPI names
This patch adds alternative way to specify DAI links by using ACPI names. ACPI name here is considered to be used as an alias for device name during DAI link binding time.
Rationale behind this is that device name especially with bus connected codecs may not be constant enough to be used in machines with dynamic and variable amount of bus controllers due changing bus/adapter number.
One way to solve this problem on ACPI 5 based systems is to use ACPI names of those devices that are enumerated by the ACPI subsystem.
For instance, matchine drivers could specify codec in DAI link by using: .codec_name = "INT33CA:00", instead of .codec_name = "rt5640.0-001c",
Note that ACPI name is used just an alias during bind time and core continues to use device name. In fact, machine drivers could use either names.
Thanks to Mika Westerberg for initial idea to use ACPI handles for binding. Author extended and simplified the idea so that struct snd_soc_dai_link doesn't need a new field, machine drivers don't need any additional code and soc-core.c can handle matching when executing soc_bind_dai_link().
Signed-off-by: Jarkko Nikula jarkko.nikula@linux.intel.com Cc: Mika Westerberg mika.westerberg@linux.intel.com --- linux-acpi@vger.kernel.org cc'd if ACPI folks would like to check API usage here. --- sound/soc/soc-core.c | 38 ++++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 4280c70..5cb440e 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -36,6 +36,7 @@ #include <linux/of.h> #include <linux/gpio.h> #include <linux/of_gpio.h> +#include <linux/acpi.h> #include <sound/ac97_codec.h> #include <sound/core.h> #include <sound/jack.h> @@ -836,6 +837,27 @@ EXPORT_SYMBOL_GPL(snd_soc_resume); static const struct snd_soc_dai_ops null_dai_ops = { };
+static bool soc_match_name(struct device *dev, + const char *comp_name, const char *bind_name) +{ + if (!strcmp(comp_name, bind_name)) + return true; + +#if IS_ENABLED(CONFIG_ACPI) + if (ACPI_HANDLE(dev)) { + struct acpi_device *adev; + if (!acpi_bus_get_device(ACPI_HANDLE(dev), &adev) && + !strcmp(dev_name(&adev->dev), bind_name)) { + dev_dbg(dev, "Matching with ACPI name %s\n", + dev_name(&adev->dev)); + return true; + } + } +#endif + + return false; +} + static int soc_bind_dai_link(struct snd_soc_card *card, int num) { struct snd_soc_dai_link *dai_link = &card->dai_link[num]; @@ -853,10 +875,12 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) (cpu_dai->dev->of_node != dai_link->cpu_of_node)) continue; if (dai_link->cpu_name && - strcmp(dev_name(cpu_dai->dev), dai_link->cpu_name)) + !soc_match_name(cpu_dai->dev, dev_name(cpu_dai->dev), + dai_link->cpu_name)) continue; if (dai_link->cpu_dai_name && - strcmp(cpu_dai->name, dai_link->cpu_dai_name)) + !soc_match_name(cpu_dai->dev, cpu_dai->name, + dai_link->cpu_dai_name)) continue;
rtd->cpu_dai = cpu_dai; @@ -874,7 +898,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) if (codec->dev->of_node != dai_link->codec_of_node) continue; } else { - if (strcmp(codec->name, dai_link->codec_name)) + if (!soc_match_name(codec->dev, codec->name, + dai_link->codec_name)) continue; }
@@ -886,8 +911,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) */ list_for_each_entry(codec_dai, &dai_list, list) { if (codec->dev == codec_dai->dev && - !strcmp(codec_dai->name, - dai_link->codec_dai_name)) { + soc_match_name(codec->dev, codec_dai->name, + dai_link->codec_dai_name)) {
rtd->codec_dai = codec_dai; } @@ -918,7 +943,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) dai_link->platform_of_node) continue; } else { - if (strcmp(platform->name, platform_name)) + if (!soc_match_name(platform->dev, platform->name, + platform_name)) continue; }
On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
For instance, matchine drivers could specify codec in DAI link by using: .codec_name = "INT33CA:00", instead of .codec_name = "rt5640.0-001c",
Note that ACPI name is used just an alias during bind time and core continues to use device name. In fact, machine drivers could use either names.
This is making me wonder if we shouldn't be taking the stable names we get from ACPI as the dev_name() instead of our internal ones on ACPI systems (and possibly something similar on DT) rather than adding custom code like this.
On 10/03/2013 04:37 PM, Mark Brown wrote:
On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
For instance, matchine drivers could specify codec in DAI link by using: .codec_name = "INT33CA:00", instead of .codec_name = "rt5640.0-001c", Note that ACPI name is used just an alias during bind time and core continues to use device name. In fact, machine drivers could use either names.
This is making me wonder if we shouldn't be taking the stable names we get from ACPI as the dev_name() instead of our internal ones on ACPI systems (and possibly something similar on DT) rather than adding custom code like this.
This is actually somewhat confusing issue. I think it's relatively easy to switch using ACPI names within ASoC core (by modifying fmt_single_name or something like that).
Problem is that for ACPI enumerated client devices the dev_name(dev) still comes from those subsystems as before. So for instance dev_ prints in codec driver or ASoC core keeps printing "rt5640 0-001c:" as before and I personally find it a bit more confusing if internal ASoC names don't match as easily with dev_ prints.
But yes, I agree. This alias name in DAI link is not that clear either as it exists only during bind time.
On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
On 10/03/2013 04:37 PM, Mark Brown wrote:
On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
For instance, matchine drivers could specify codec in DAI link by using: .codec_name = "INT33CA:00", instead of .codec_name = "rt5640.0-001c", Note that ACPI name is used just an alias during bind time and core continues to use device name. In fact, machine drivers could use either names.
This is making me wonder if we shouldn't be taking the stable names we get from ACPI as the dev_name() instead of our internal ones on ACPI systems (and possibly something similar on DT) rather than adding custom code like this.
This is actually somewhat confusing issue. I think it's relatively easy to switch using ACPI names within ASoC core (by modifying fmt_single_name or something like that).
Problem is that for ACPI enumerated client devices the dev_name(dev) still comes from those subsystems as before. So for instance dev_ prints in codec driver or ASoC core keeps printing "rt5640 0-001c:" as before and I personally find it a bit more confusing if internal ASoC names don't match as easily with dev_ prints.
But yes, I agree. This alias name in DAI link is not that clear either as it exists only during bind time.
Sorry am very ignorant about ACPI, but cant resist asking why should ACPI allocate some internal name and then we go about figuring the bus, slave and codec. Wouldn't it make sense to just get "rt5640.0-001c" as device from ACPI and use it.
On Thu, 2013-10-03 at 20:59 +0530, Vinod Koul wrote:
On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
On 10/03/2013 04:37 PM, Mark Brown wrote:
On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
For instance, matchine drivers could specify codec in DAI link by using: .codec_name = "INT33CA:00", instead of .codec_name = "rt5640.0-001c", Note that ACPI name is used just an alias during bind time and core continues to use device name. In fact, machine drivers could use either names.
This is making me wonder if we shouldn't be taking the stable names we get from ACPI as the dev_name() instead of our internal ones on ACPI systems (and possibly something similar on DT) rather than adding custom code like this.
This is actually somewhat confusing issue. I think it's relatively easy to switch using ACPI names within ASoC core (by modifying fmt_single_name or something like that).
Problem is that for ACPI enumerated client devices the dev_name(dev) still comes from those subsystems as before. So for instance dev_ prints in codec driver or ASoC core keeps printing "rt5640 0-001c:" as before and I personally find it a bit more confusing if internal ASoC names don't match as easily with dev_ prints.
But yes, I agree. This alias name in DAI link is not that clear either as it exists only during bind time.
Sorry am very ignorant about ACPI, but cant resist asking why should ACPI allocate some internal name and then we go about figuring the bus, slave and codec. Wouldn't it make sense to just get "rt5640.0-001c" as device from ACPI and use it.
We have the situation whereby some BIOS settings can alter the I2C bus number used by the codec. i.e. matching fail on "rt5640.0-001c" but would succeed on "rt5640.7-001c".
Moving this to also support ACPI names would be a bonus since we would only need to match on the static ACPI device name.
Liam
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
On 10/03/2013 04:37 PM, Mark Brown wrote:
This is making me wonder if we shouldn't be taking the stable names we get from ACPI as the dev_name() instead of our internal ones on ACPI systems (and possibly something similar on DT) rather than adding custom code like this.
This is actually somewhat confusing issue. I think it's relatively easy to switch using ACPI names within ASoC core (by modifying fmt_single_name or something like that).
Problem is that for ACPI enumerated client devices the dev_name(dev) still comes from those subsystems as before. So for instance dev_ prints in codec driver or ASoC core keeps printing "rt5640 0-001c:" as before and I personally find it a bit more confusing if internal ASoC names don't match as easily with dev_ prints.
You're misreading my suggestion. What I'm saying is that it seems like it might be useful to have dev_name() return the ACPI name - this would mean that everything, including all the dev_ prints, would use the same name which would then become stable and tied to hardware.
On 10/03/2013 07:19 PM, Mark Brown wrote:
On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
On 10/03/2013 04:37 PM, Mark Brown wrote:
This is making me wonder if we shouldn't be taking the stable names we get from ACPI as the dev_name() instead of our internal ones on ACPI systems (and possibly something similar on DT) rather than adding custom code like this.
This is actually somewhat confusing issue. I think it's relatively easy to switch using ACPI names within ASoC core (by modifying fmt_single_name or something like that). Problem is that for ACPI enumerated client devices the dev_name(dev) still comes from those subsystems as before. So for instance dev_ prints in codec driver or ASoC core keeps printing "rt5640 0-001c:" as before and I personally find it a bit more confusing if internal ASoC names don't match as easily with dev_ prints.
You're misreading my suggestion. What I'm saying is that it seems like it might be useful to have dev_name() return the ACPI name - this would mean that everything, including all the dev_ prints, would use the same name which would then become stable and tied to hardware.
I see. Indeed, this sounds a better idea. At quick look is even more simple.
On Friday, October 04, 2013 09:28:27 AM Jarkko Nikula wrote:
On 10/03/2013 07:19 PM, Mark Brown wrote:
On Thu, Oct 03, 2013 at 05:22:45PM +0300, Jarkko Nikula wrote:
On 10/03/2013 04:37 PM, Mark Brown wrote:
This is making me wonder if we shouldn't be taking the stable names we get from ACPI as the dev_name() instead of our internal ones on ACPI systems (and possibly something similar on DT) rather than adding custom code like this.
This is actually somewhat confusing issue. I think it's relatively easy to switch using ACPI names within ASoC core (by modifying fmt_single_name or something like that). Problem is that for ACPI enumerated client devices the dev_name(dev) still comes from those subsystems as before. So for instance dev_ prints in codec driver or ASoC core keeps printing "rt5640 0-001c:" as before and I personally find it a bit more confusing if internal ASoC names don't match as easily with dev_ prints.
You're misreading my suggestion. What I'm saying is that it seems like it might be useful to have dev_name() return the ACPI name - this would mean that everything, including all the dev_ prints, would use the same name which would then become stable and tied to hardware.
I see. Indeed, this sounds a better idea. At quick look is even more simple.
Well, this is slightly ambiguous. What exactly do you mean by "ACPI names"?
On 10/04/2013 09:55 AM, Rafael J. Wysocki wrote:
You're misreading my suggestion. What I'm saying is that it seems like it might be useful to have dev_name() return the ACPI name - this would mean that everything, including all the dev_ prints, would use the same name which would then become stable and tied to hardware.
I see. Indeed, this sounds a better idea. At quick look is even more simple.
Well, this is slightly ambiguous. What exactly do you mean by "ACPI names"?
Ah, yes. What I meant as ACPI name was the <bus_id:instance> based ACPI device name/object (or what is the correct terminology), not the hardware ID.
On Friday, October 04, 2013 10:38:10 AM Jarkko Nikula wrote:
On 10/04/2013 09:55 AM, Rafael J. Wysocki wrote:
You're misreading my suggestion. What I'm saying is that it seems like it might be useful to have dev_name() return the ACPI name - this would mean that everything, including all the dev_ prints, would use the same name which would then become stable and tied to hardware.
I see. Indeed, this sounds a better idea. At quick look is even more simple.
Well, this is slightly ambiguous. What exactly do you mean by "ACPI names"?
Ah, yes. What I meant as ACPI name was the <bus_id:instance> based ACPI device name/object (or what is the correct terminology), not the hardware ID.
OK
On Thursday, October 03, 2013 03:33:56 PM Jarkko Nikula wrote:
This patch adds alternative way to specify DAI links by using ACPI names. ACPI name here is considered to be used as an alias for device name during DAI link binding time.
What's DAI?
Rationale behind this is that device name especially with bus connected codecs may not be constant enough to be used in machines with dynamic and variable amount of bus controllers due changing bus/adapter number.
One way to solve this problem on ACPI 5 based systems is to use ACPI names of those devices that are enumerated by the ACPI subsystem.
For instance, matchine drivers could specify codec in DAI link by using: .codec_name = "INT33CA:00", instead of .codec_name = "rt5640.0-001c",
Note that ACPI name is used just an alias during bind time and core continues to use device name. In fact, machine drivers could use either names.
Thanks to Mika Westerberg for initial idea to use ACPI handles for binding. Author extended and simplified the idea so that struct snd_soc_dai_link doesn't need a new field, machine drivers don't need any additional code and soc-core.c can handle matching when executing soc_bind_dai_link().
Signed-off-by: Jarkko Nikula jarkko.nikula@linux.intel.com Cc: Mika Westerberg mika.westerberg@linux.intel.com
linux-acpi@vger.kernel.org cc'd if ACPI folks would like to check API usage here.
sound/soc/soc-core.c | 38 ++++++++++++++++++++++++++++++++------ 1 file changed, 32 insertions(+), 6 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c index 4280c70..5cb440e 100644 --- a/sound/soc/soc-core.c +++ b/sound/soc/soc-core.c @@ -36,6 +36,7 @@ #include <linux/of.h> #include <linux/gpio.h> #include <linux/of_gpio.h> +#include <linux/acpi.h> #include <sound/ac97_codec.h> #include <sound/core.h> #include <sound/jack.h> @@ -836,6 +837,27 @@ EXPORT_SYMBOL_GPL(snd_soc_resume); static const struct snd_soc_dai_ops null_dai_ops = { };
+static bool soc_match_name(struct device *dev,
const char *comp_name, const char *bind_name)+{
- if (!strcmp(comp_name, bind_name))
return true;+#if IS_ENABLED(CONFIG_ACPI)
That's not necessary, because ACPI_HANDLE() is defined as false for CONFIG_ACPI unset.
- if (ACPI_HANDLE(dev)) {
struct acpi_device *adev;if (!acpi_bus_get_device(ACPI_HANDLE(dev), &adev) &&!strcmp(dev_name(&adev->dev), bind_name)) {dev_dbg(dev, "Matching with ACPI name %s\n",dev_name(&adev->dev));return true;}- }
+#endif
- return false;
+}
static int soc_bind_dai_link(struct snd_soc_card *card, int num) { struct snd_soc_dai_link *dai_link = &card->dai_link[num]; @@ -853,10 +875,12 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) (cpu_dai->dev->of_node != dai_link->cpu_of_node)) continue; if (dai_link->cpu_name &&
strcmp(dev_name(cpu_dai->dev), dai_link->cpu_name))
!soc_match_name(cpu_dai->dev, dev_name(cpu_dai->dev),dai_link->cpu_name)) continue;
strcmp(cpu_dai->name, dai_link->cpu_dai_name))
!soc_match_name(cpu_dai->dev, cpu_dai->name,dai_link->cpu_dai_name)) continue;rtd->cpu_dai = cpu_dai;
@@ -874,7 +898,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) if (codec->dev->of_node != dai_link->codec_of_node) continue; } else {
if (strcmp(codec->name, dai_link->codec_name))
if (!soc_match_name(codec->dev, codec->name,dai_link->codec_name)) continue;@@ -886,8 +911,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) */ list_for_each_entry(codec_dai, &dai_list, list) { if (codec->dev == codec_dai->dev &&
!strcmp(codec_dai->name,dai_link->codec_dai_name)) {
soc_match_name(codec->dev, codec_dai->name,dai_link->codec_dai_name)) { rtd->codec_dai = codec_dai; }@@ -918,7 +943,8 @@ static int soc_bind_dai_link(struct snd_soc_card *card, int num) dai_link->platform_of_node) continue; } else {
if (strcmp(platform->name, platform_name))
if (!soc_match_name(platform->dev, platform->name,platform_name)) continue;
Thanks!
On 10/04/2013 09:53 AM, Rafael J. Wysocki wrote:
On Thursday, October 03, 2013 03:33:56 PM Jarkko Nikula wrote:
This patch adds alternative way to specify DAI links by using ACPI names. ACPI name here is considered to be used as an alias for device name during DAI link binding time.
What's DAI?
It comes from Digital Audio Interface, and DAI link in ALSA SoC basically ties together platform, DAI and codec devices by name or device tree node.
+#if IS_ENABLED(CONFIG_ACPI) That's not necessary, because ACPI_HANDLE() is defined as false for CONFIG_ACPI unset.
Actually problem acpi_bus_get_device() that is not available if CONFIG_ACPI is not set. Which suggests was it even meant to be used in drivers that are build for non ACPI systems too?
On Friday, October 04, 2013 10:22:43 AM Jarkko Nikula wrote:
On 10/04/2013 09:53 AM, Rafael J. Wysocki wrote:
On Thursday, October 03, 2013 03:33:56 PM Jarkko Nikula wrote:
This patch adds alternative way to specify DAI links by using ACPI names. ACPI name here is considered to be used as an alias for device name during DAI link binding time.
What's DAI?
It comes from Digital Audio Interface, and DAI link in ALSA SoC basically ties together platform, DAI and codec devices by name or device tree node.
+#if IS_ENABLED(CONFIG_ACPI) That's not necessary, because ACPI_HANDLE() is defined as false for CONFIG_ACPI unset.
Actually problem acpi_bus_get_device() that is not available if CONFIG_ACPI is not set. Which suggests was it even meant to be used in drivers that are build for non ACPI systems too?
No, acpi_bus_get_device() shoudn't be used if CONFIG_ACPI is not set.
Thanks!
On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
This patch adds alternative way to specify DAI links by using ACPI names. ACPI name here is considered to be used as an alias for device name during DAI link binding time.
Did anything happen with the idea of making dev_name() use the ACPI name?
On 10/24/2013 12:51 PM, Mark Brown wrote:
On Thu, Oct 03, 2013 at 03:33:56PM +0300, Jarkko Nikula wrote:
This patch adds alternative way to specify DAI links by using ACPI names. ACPI name here is considered to be used as an alias for device name during DAI link binding time.
Did anything happen with the idea of making dev_name() use the ACPI name?
Well, looks like I manage to put it aside. I'll spin it again as next merge window starts to be too near now.
On Fri, Oct 25, 2013 at 09:53:28AM +0300, Jarkko Nikula wrote:
On 10/24/2013 12:51 PM, Mark Brown wrote:
Did anything happen with the idea of making dev_name() use the ACPI name?
Well, looks like I manage to put it aside. I'll spin it again as next merge window starts to be too near now.
OK, I was asking because I was thinking of applying the patch for now; it's not that it's a bad idea it just seems like it's something that might might make sense solved at that level. Equally well I don't know if these systems will work with v3.13 anyway so perhaps it's not so urgent.
On 10/25/2013 01:06 PM, Mark Brown wrote:
OK, I was asking because I was thinking of applying the patch for now; it's not that it's a bad idea it just seems like it's something that might might make sense solved at that level. Equally well I don't know if these systems will work with v3.13 anyway so perhaps it's not so urgent.
Yes, I don't see any urgent reason to push this hack in. Better to check dev_name change first. What I'm going to propose there is "spix.y" to "spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"
On Fri, 2013-10-25 at 13:42 +0300, Jarkko Nikula wrote:
On 10/25/2013 01:06 PM, Mark Brown wrote:
OK, I was asking because I was thinking of applying the patch for now; it's not that it's a bad idea it just seems like it's something that might might make sense solved at that level. Equally well I don't know if these systems will work with v3.13 anyway so perhaps it's not so urgent.
Yes, I don't see any urgent reason to push this hack in. Better to check dev_name change first. What I'm going to propose there is "spix.y" to "spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"
We probably need to be able to match on ACPI name alone as some BIOS settings can change the I2C bus number and break the name match used at bind time. e.g. on Haswell the codec can either be on I2C bus 0 or 7.
Liam
On Mon, Oct 28, 2013 at 11:53:14AM +0000, Liam Girdwood wrote:
On Fri, 2013-10-25 at 13:42 +0300, Jarkko Nikula wrote:
Yes, I don't see any urgent reason to push this hack in. Better to check dev_name change first. What I'm going to propose there is "spix.y" to "spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"
We probably need to be able to match on ACPI name alone as some BIOS settings can change the I2C bus number and break the name match used at bind time. e.g. on Haswell the codec can either be on I2C bus 0 or 7.
Indeed. The way I initially read the suggestion above the idea was to replace the bus number with the ACPI name for the device which seemed sensible but now I reread the bus number is still there.
On 10/28/2013 05:06 PM, Mark Brown wrote:
On Mon, Oct 28, 2013 at 11:53:14AM +0000, Liam Girdwood wrote:
On Fri, 2013-10-25 at 13:42 +0300, Jarkko Nikula wrote:
Yes, I don't see any urgent reason to push this hack in. Better to check dev_name change first. What I'm going to propose there is "spix.y" to "spi-INTABCD:xy" and "x-00yz" to "i2c-INTABCD:xy"
We probably need to be able to match on ACPI name alone as some BIOS settings can change the I2C bus number and break the name match used at bind time. e.g. on Haswell the codec can either be on I2C bus 0 or 7.
Indeed. The way I initially read the suggestion above the idea was to replace the bus number with the ACPI name for the device which seemed sensible but now I reread the bus number is still there.
Sorry, my textual proposal above was confusing and should have used different variables for ACPI name. What I meant was "spix.y" -> "spi-INTABCD:ij" and "x-00yz" to "i2c-INTABCD:ij" where "INTABCD:ij" was the ACPI device name which contains the device instance in "ij".
On Mon, Oct 28, 2013 at 05:23:45PM +0200, Jarkko Nikula wrote:
On 10/28/2013 05:06 PM, Mark Brown wrote:
Indeed. The way I initially read the suggestion above the idea was to replace the bus number with the ACPI name for the device which seemed sensible but now I reread the bus number is still there.
Sorry, my textual proposal above was confusing and should have used different variables for ACPI name. What I meant was "spix.y" -> "spi-INTABCD:ij" and "x-00yz" to "i2c-INTABCD:ij" where "INTABCD:ij" was the ACPI device name which contains the device instance in "ij".
Ah, OK - it's actually what I read it as in the first place then!
participants (6)
-
Jarkko Nikula -
Liam Girdwood -
Liam Girdwood -
Mark Brown -
Rafael J. Wysocki -
Vinod Koul