Many systems do not use ACPI and hence do not provide a DMI table. On
non-ACPI systems a warning, such as the following, is printed on boot.
WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
The variable 'dmi_available' is not exported and so currently cannot be
used by kernel modules without adding an accessor. However, it is
possible to use the function is_acpi_device_node() to determine if the
sound card is an ACPI device and hence indicate if we expect a DMI table
to be present. Therefore, call is_acpi_device_node() to see if we are
using ACPI and only parse the DMI table if we are booting with ACPI.
Signed-off-by: Jon Hunter <[email protected]>
---
Changes since V1:
- Use is_acpi_device_node() to determine if we expect the DMI table to
be present.
sound/soc/soc-core.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index f6d4e99b590c..0cffc9527e28 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -31,6 +31,7 @@
#include <linux/of.h>
#include <linux/of_graph.h>
#include <linux/dmi.h>
+#include <linux/acpi.h>
#include <sound/core.h>
#include <sound/pcm.h>
#include <sound/pcm_params.h>
@@ -1573,6 +1574,9 @@ int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour)
if (card->long_name)
return 0; /* long name already set by driver or from DMI */
+ if (!is_acpi_device_node(card->dev->fwnode))
+ return 0;
+
/* make up dmi long name as: vendor-product-version-board */
vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
if (!vendor || !is_dmi_valid(vendor)) {
--
2.25.1
On 3/3/21 5:55 AM, Jon Hunter wrote:
> Many systems do not use ACPI and hence do not provide a DMI table. On
> non-ACPI systems a warning, such as the following, is printed on boot.
>
> WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
>
> The variable 'dmi_available' is not exported and so currently cannot be
> used by kernel modules without adding an accessor. However, it is
> possible to use the function is_acpi_device_node() to determine if the
> sound card is an ACPI device and hence indicate if we expect a DMI table
> to be present. Therefore, call is_acpi_device_node() to see if we are
> using ACPI and only parse the DMI table if we are booting with ACPI.
That change introduces a regression on all our tests: the names are not
correctly set, which will prevent UCM from loading the relevant profiles
based on the long name.
Before:
0 [sofhdadsp ]: sof-hda-dsp - sof-hda-dsp
AAEON-UP_WHL01-V1.0
After:
root@plb-UP-WHL01:/proc/asound# more cards
0 [sofhdadsp ]: sof-hda-dsp - sof-hda-dsp
sof-hda-dsp
The problem is that the cards are platform devices created by the parent
(which itself may be a PCI or ACPI device) and have nothing to do with ACPI.
Could we flip the logic and instead explicitly detect OF devices? That
restores functionality for us.
Jon, would this work for you?
Thanks!
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 16ba54eb8164..5c40b4548413 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1574,7 +1574,7 @@ int snd_soc_set_dmi_name(struct snd_soc_card
*card, const char *flavour)
if (card->long_name)
return 0; /* long name already set by driver or from DMI */
- if (!is_acpi_device_node(card->dev->fwnode))
+ if (is_of_node(card->dev->fwnode))
return 0;
/* make up dmi long name as: vendor-product-version-board */
>
> Signed-off-by: Jon Hunter <[email protected]>
> ---
> Changes since V1:
> - Use is_acpi_device_node() to determine if we expect the DMI table to
> be present.
>
> sound/soc/soc-core.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index f6d4e99b590c..0cffc9527e28 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -31,6 +31,7 @@
> #include <linux/of.h>
> #include <linux/of_graph.h>
> #include <linux/dmi.h>
> +#include <linux/acpi.h>
> #include <sound/core.h>
> #include <sound/pcm.h>
> #include <sound/pcm_params.h>
> @@ -1573,6 +1574,9 @@ int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour)
> if (card->long_name)
> return 0; /* long name already set by driver or from DMI */
>
> + if (!is_acpi_device_node(card->dev->fwnode))
> + return 0;
> +
> /* make up dmi long name as: vendor-product-version-board */
> vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
> if (!vendor || !is_dmi_valid(vendor)) {
>
On Tue, Mar 09, 2021 at 01:41:45PM -0600, Pierre-Louis Bossart wrote:
> The problem is that the cards are platform devices created by the parent
> (which itself may be a PCI or ACPI device) and have nothing to do with ACPI.
> Could we flip the logic and instead explicitly detect OF devices? That
> restores functionality for us.
Just change it to a system level check for ACPI, checking for OF would
leave problems for board files or any other alternative firmware
interfaces.
On 3/10/21 7:35 AM, Mark Brown wrote:
> On Tue, Mar 09, 2021 at 01:41:45PM -0600, Pierre-Louis Bossart wrote:
>
>> The problem is that the cards are platform devices created by the parent
>> (which itself may be a PCI or ACPI device) and have nothing to do with ACPI.
>
>> Could we flip the logic and instead explicitly detect OF devices? That
>> restores functionality for us.
>
> Just change it to a system level check for ACPI, checking for OF would
> leave problems for board files or any other alternative firmware
> interfaces.
did you mean if (!IS_ENABLED(CONFIG_ACPI)) ?
On Wed, Mar 10, 2021 at 09:44:07AM -0600, Pierre-Louis Bossart wrote:
> On 3/10/21 7:35 AM, Mark Brown wrote:
> > Just change it to a system level check for ACPI, checking for OF would
> > leave problems for board files or any other alternative firmware
> > interfaces.
> did you mean if (!IS_ENABLED(CONFIG_ACPI)) ?
Is there a runtime check?
On Wed, 10 Mar 2021 17:18:14 +0100,
Mark Brown wrote:
>
> On Wed, Mar 10, 2021 at 09:44:07AM -0600, Pierre-Louis Bossart wrote:
> > On 3/10/21 7:35 AM, Mark Brown wrote:
>
> > > Just change it to a system level check for ACPI, checking for OF would
> > > leave problems for board files or any other alternative firmware
> > > interfaces.
>
> > did you mean if (!IS_ENABLED(CONFIG_ACPI)) ?
>
> Is there a runtime check?
Well, basically both DMI and ACPI are completely different things, so
I don't think it's right to check the availability of ACPI as a signal
of the availability of DMI.
Takashi
On 3/10/21 10:37 AM, Takashi Iwai wrote:
> On Wed, 10 Mar 2021 17:18:14 +0100,
> Mark Brown wrote:
>>
>> On Wed, Mar 10, 2021 at 09:44:07AM -0600, Pierre-Louis Bossart wrote:
>>> On 3/10/21 7:35 AM, Mark Brown wrote:
>>
>>>> Just change it to a system level check for ACPI, checking for OF would
>>>> leave problems for board files or any other alternative firmware
>>>> interfaces.
>>
>>> did you mean if (!IS_ENABLED(CONFIG_ACPI)) ?
>>
>> Is there a runtime check?
>
> Well, basically both DMI and ACPI are completely different things, so
> I don't think it's right to check the availability of ACPI as a signal
> of the availability of DMI.
would this work?
if (!IS_ENABLED(CONFIG_DMI))
return 0;
On Wed, Mar 10, 2021 at 05:37:25PM +0100, Takashi Iwai wrote:
> Mark Brown wrote:
> > > did you mean if (!IS_ENABLED(CONFIG_ACPI)) ?
> > Is there a runtime check?
> Well, basically both DMI and ACPI are completely different things, so
> I don't think it's right to check the availability of ACPI as a signal
> of the availability of DMI.
In theory they are only somewhat related, but in practice they're both
part of a holistic system model - ACPI users complain if their system
does not also provide DMI information.
On Wed, Mar 10, 2021 at 10:41:18AM -0600, Pierre-Louis Bossart wrote:
> would this work?
> if (!IS_ENABLED(CONFIG_DMI))
> return 0;
Build time dependencies aren't going to help anything, arm64 (and to my
understanding some future x86 systems, LynxPoint IIRC) supports both DT
and ACPI and so you have kernels built with support for both.
On 3/10/21 10:52 AM, Mark Brown wrote:
> On Wed, Mar 10, 2021 at 10:41:18AM -0600, Pierre-Louis Bossart wrote:
>
>> would this work?
>
>> if (!IS_ENABLED(CONFIG_DMI))
>> return 0;
>
> Build time dependencies aren't going to help anything, arm64 (and to my
> understanding some future x86 systems, LynxPoint IIRC) supports both DT
> and ACPI and so you have kernels built with support for both.
well, that's what I suggested initially:
if (is_of_node(card->dev->fwnode))
I used the of_node test as a proxy for 'no DMI' since I am not aware of
any means to detect if DMI is enabled at run-time.
On Wed, Mar 10, 2021 at 11:50:13AM -0600, Pierre-Louis Bossart wrote:
> On 3/10/21 10:52 AM, Mark Brown wrote:
> > Build time dependencies aren't going to help anything, arm64 (and to my
> > understanding some future x86 systems, LynxPoint IIRC) supports both DT
> > and ACPI and so you have kernels built with support for both.
> well, that's what I suggested initially:
> if (is_of_node(card->dev->fwnode))
> I used the of_node test as a proxy for 'no DMI' since I am not aware of any
> means to detect if DMI is enabled at run-time.
Can we not fix the DMI code so it lets us check dmi_available either
directly or with an accessor? I don't understand why all the proposals
are dancing around local bodges here.
>>> Build time dependencies aren't going to help anything, arm64 (and to my
>>> understanding some future x86 systems, LynxPoint IIRC) supports both DT
>>> and ACPI and so you have kernels built with support for both.
>
>> well, that's what I suggested initially:
>> if (is_of_node(card->dev->fwnode))
>
>> I used the of_node test as a proxy for 'no DMI' since I am not aware of any
>> means to detect if DMI is enabled at run-time.
>
> Can we not fix the DMI code so it lets us check dmi_available either
> directly or with an accessor? I don't understand why all the proposals
> are dancing around local bodges here.
something like this then (compile-tested only)?
diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index d51ca0428bb8..f191a1f901ac 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -166,6 +166,7 @@ static int __init dmi_checksum(const u8 *buf, u8 len)
static const char *dmi_ident[DMI_STRING_MAX];
static LIST_HEAD(dmi_devices);
int dmi_available;
+EXPORT_SYMBOL_GPL(dmi_available);
/*
* Save a DMI string
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index 16ba54eb8164..c7e4600b2dd4 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1574,7 +1574,7 @@ int snd_soc_set_dmi_name(struct snd_soc_card
*card, const char *flavour)
if (card->long_name)
return 0; /* long name already set by driver or from DMI */
- if (!is_acpi_device_node(card->dev->fwnode))
+ if (!dmi_available)
return 0;
/* make up dmi long name as: vendor-product-version-board */
On 10/03/2021 18:37, Pierre-Louis Bossart wrote:
>
>>>> Build time dependencies aren't going to help anything, arm64 (and to my
>>>> understanding some future x86 systems, LynxPoint IIRC) supports both DT
>>>> and ACPI and so you have kernels built with support for both.
>>
>>> well, that's what I suggested initially:
>>> ??????? if (is_of_node(card->dev->fwnode))
>>
>>> I used the of_node test as a proxy for 'no DMI' since I am not aware
>>> of any
>>> means to detect if DMI is enabled at run-time.
>>
>> Can we not fix the DMI code so it lets us check dmi_available either
>> directly or with an accessor?? I don't understand why all the proposals
>> are dancing around local bodges here.
>
> something like this then (compile-tested only)?
>
> diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
> index d51ca0428bb8..f191a1f901ac 100644
> --- a/drivers/firmware/dmi_scan.c
> +++ b/drivers/firmware/dmi_scan.c
> @@ -166,6 +166,7 @@ static int __init dmi_checksum(const u8 *buf, u8 len)
> ?static const char *dmi_ident[DMI_STRING_MAX];
> ?static LIST_HEAD(dmi_devices);
> ?int dmi_available;
> +EXPORT_SYMBOL_GPL(dmi_available);
>
> ?/*
> ? *???? Save a DMI string
> diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
> index 16ba54eb8164..c7e4600b2dd4 100644
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -1574,7 +1574,7 @@ int snd_soc_set_dmi_name(struct snd_soc_card
> *card, const char *flavour)
> ??????? if (card->long_name)
> ??????????????? return 0; /* long name already set by driver or from DMI */
>
> -?????? if (!is_acpi_device_node(card->dev->fwnode))
> +?????? if (!dmi_available)
> ??????????????? return 0;
>
> ??????? /* make up dmi long name as: vendor-product-version-board */
Sounds good to me. I would have done the same if I had known that the
current solution would have caused this regression.
Cheers
Jon
--
nvpublic
On Wed, Mar 10, 2021 at 07:17:13PM +0000, Jon Hunter wrote:
> On 10/03/2021 18:37, Pierre-Louis Bossart wrote:
> > +EXPORT_SYMBOL_GPL(dmi_available);
> > -?????? if (!is_acpi_device_node(card->dev->fwnode))
> > +?????? if (!dmi_available)
> Sounds good to me. I would have done the same if I had known that the
> current solution would have caused this regression.
Yes, this looks good.