diff mbox series

[V2] ASoC: soc-core: Prevent warning if no DMI table is present

Message ID 20210303115526.419458-1-jonathanh@nvidia.com
State Accepted
Commit 7de14d581dbed57c2b3c6afffa2c3fdc6955a3cd
Headers show
Series [V2] ASoC: soc-core: Prevent warning if no DMI table is present | expand

Commit Message

Jon Hunter March 3, 2021, 11:55 a.m. UTC 
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 <jonathanh@nvidia.com>
---
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(+)

Comments

Pierre-Louis Bossart March 9, 2021, 7:41 p.m. UTC | #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 <jonathanh@nvidia.com>
> ---
> 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)) {
>
Mark Brown March 10, 2021, 1:35 p.m. UTC | #2 
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.
Pierre-Louis Bossart March 10, 2021, 3:44 p.m. UTC | #3 
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)) ?
Mark Brown March 10, 2021, 4:18 p.m. UTC | #4 
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?
Takashi Iwai March 10, 2021, 4:37 p.m. UTC | #5 
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
Pierre-Louis Bossart March 10, 2021, 4:41 p.m. UTC | #6 
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;
Mark Brown March 10, 2021, 4:50 p.m. UTC | #7 
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.
Mark Brown March 10, 2021, 4:52 p.m. UTC | #8 
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.
Pierre-Louis Bossart March 10, 2021, 5:50 p.m. UTC | #9 
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.
Mark Brown March 10, 2021, 6:16 p.m. UTC | #10 
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.
Pierre-Louis Bossart March 10, 2021, 6:37 p.m. UTC | #11 
>>> 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 */
Jon Hunter March 10, 2021, 7:17 p.m. UTC | #12 
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
diff mbox series

Patch

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)) {