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

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

[Jon Hunter]

Many systems do not provide a DMI table and on these systems a warning,
such as the following, is printed on boot ...

 WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!

If DMI support is enabled in the kernel, there is no simple way to
detect if a DMI table is table or not. Note that the variable
'dmi_available' is not exported and so cannot be used by kernel modules.
It could be possible to have every ASoC sound card driver set the long
name to avoid the above message, but it might be intentional for the
long name, that we fall back to using the sound card name. Therefore,
make this a debug print by default to avoid the warning.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
 sound/soc/soc-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index f6d4e99b590c..f1189e7c1fcc 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1576,7 +1576,7 @@ int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour)
 	/* make up dmi long name as: vendor-product-version-board */
 	vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
 	if (!vendor || !is_dmi_valid(vendor)) {
-		dev_warn(card->dev, "ASoC: no DMI vendor name!\n");
+		dev_dbg(card->dev, "ASoC: no DMI vendor name!\n");
 		return 0;
 	}
 
-- 
2.25.1

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

[Jon Hunter]

Many systems do not provide a DMI table and on these systems a warning,
such as the following, is printed on boot ...

 WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!

If DMI support is enabled in the kernel, there is no simple way to
detect if a DMI table is table or not. Note that the variable
'dmi_available' is not exported and so cannot be used by kernel modules.
It could be possible to have every ASoC sound card driver set the long
name to avoid the above message, but it might be intentional for the
long name, that we fall back to using the sound card name. Therefore,
make this a debug print by default to avoid the warning.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
---
 sound/soc/soc-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index f6d4e99b590c..f1189e7c1fcc 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -1576,7 +1576,7 @@ int snd_soc_set_dmi_name(struct snd_soc_card *card, const char *flavour)
 	/* make up dmi long name as: vendor-product-version-board */
 	vendor = dmi_get_system_info(DMI_BOARD_VENDOR);
 	if (!vendor || !is_dmi_valid(vendor)) {
-		dev_warn(card->dev, "ASoC: no DMI vendor name!\n");
+		dev_dbg(card->dev, "ASoC: no DMI vendor name!\n");
 		return 0;
 	}
 
-- 
2.25.1

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Tue, Mar 02, 2021 at 09:27:12AM +0000, Jon Hunter wrote:
> Many systems do not provide a DMI table and on these systems a warning,
> such as the following, is printed on boot ...
> 
>  WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
> 
> If DMI support is enabled in the kernel, there is no simple way to
> detect if a DMI table is table or not. Note that the variable
> 'dmi_available' is not exported and so cannot be used by kernel modules.

We could fix that, or provide an accessor function?  Or only warn if
we're on an ACPI system (which we can check from a module).  This really
does feel like something we should be warning about on systems that are
supposed to have DMI information available as standard.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 753 bytes --]

On Tue, Mar 02, 2021 at 09:27:12AM +0000, Jon Hunter wrote:
> Many systems do not provide a DMI table and on these systems a warning,
> such as the following, is printed on boot ...
> 
>  WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
> 
> If DMI support is enabled in the kernel, there is no simple way to
> detect if a DMI table is table or not. Note that the variable
> 'dmi_available' is not exported and so cannot be used by kernel modules.

We could fix that, or provide an accessor function?  Or only warn if
we're on an ACPI system (which we can check from a module).  This really
does feel like something we should be warning about on systems that are
supposed to have DMI information available as standard.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Takashi Iwai]

On Tue, 02 Mar 2021 13:49:13 +0100,
Mark Brown wrote:
> 
> On Tue, Mar 02, 2021 at 09:27:12AM +0000, Jon Hunter wrote:
> > Many systems do not provide a DMI table and on these systems a warning,
> > such as the following, is printed on boot ...
> > 
> >  WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
> > 
> > If DMI support is enabled in the kernel, there is no simple way to
> > detect if a DMI table is table or not. Note that the variable
> > 'dmi_available' is not exported and so cannot be used by kernel modules.
> 
> We could fix that, or provide an accessor function?  Or only warn if
> we're on an ACPI system (which we can check from a module).  This really
> does feel like something we should be warning about on systems that are
> supposed to have DMI information available as standard.

I had the same feeling when I took a look at the patch, but later
changed mind, since the error will pop up also if a system has an
unmatured BIOS with some bogus vendor DMI string, too.  That is, users
of such a machine gets always an error message although this isn't any
serious problem unless you need a dedicated UCM profile (which can't
be used on such a system in anyway).

So, I agree that exporting dmi_avilable could improve the situation a
bit, but the error level needs still reconsideration.


Takashi

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

[Takashi Iwai]

On Tue, 02 Mar 2021 13:49:13 +0100,
Mark Brown wrote:
> 
> On Tue, Mar 02, 2021 at 09:27:12AM +0000, Jon Hunter wrote:
> > Many systems do not provide a DMI table and on these systems a warning,
> > such as the following, is printed on boot ...
> > 
> >  WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
> > 
> > If DMI support is enabled in the kernel, there is no simple way to
> > detect if a DMI table is table or not. Note that the variable
> > 'dmi_available' is not exported and so cannot be used by kernel modules.
> 
> We could fix that, or provide an accessor function?  Or only warn if
> we're on an ACPI system (which we can check from a module).  This really
> does feel like something we should be warning about on systems that are
> supposed to have DMI information available as standard.

I had the same feeling when I took a look at the patch, but later
changed mind, since the error will pop up also if a system has an
unmatured BIOS with some bogus vendor DMI string, too.  That is, users
of such a machine gets always an error message although this isn't any
serious problem unless you need a dedicated UCM profile (which can't
be used on such a system in anyway).

So, I agree that exporting dmi_avilable could improve the situation a
bit, but the error level needs still reconsideration.


Takashi

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

[Jon Hunter]

On 02/03/2021 17:23, Takashi Iwai wrote:
> On Tue, 02 Mar 2021 13:49:13 +0100,
> Mark Brown wrote:
>>
>> On Tue, Mar 02, 2021 at 09:27:12AM +0000, Jon Hunter wrote:
>>> Many systems do not provide a DMI table and on these systems a warning,
>>> such as the following, is printed on boot ...
>>>
>>>  WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
>>>
>>> If DMI support is enabled in the kernel, there is no simple way to
>>> detect if a DMI table is table or not. Note that the variable
>>> 'dmi_available' is not exported and so cannot be used by kernel modules.
>>
>> We could fix that, or provide an accessor function?  Or only warn if
>> we're on an ACPI system (which we can check from a module).  This really
>> does feel like something we should be warning about on systems that are
>> supposed to have DMI information available as standard.
> 
> I had the same feeling when I took a look at the patch, but later
> changed mind, since the error will pop up also if a system has an
> unmatured BIOS with some bogus vendor DMI string, too.  That is, users
> of such a machine gets always an error message although this isn't any
> serious problem unless you need a dedicated UCM profile (which can't
> be used on such a system in anyway).
> 
> So, I agree that exporting dmi_avilable could improve the situation a
> bit, but the error level needs still reconsideration.


Thanks for the feedback. Yes it is probably better if we have a specific
test. I will send out a V2 for review.

Thanks
Jon

-- 
nvpublic

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

[Jon Hunter]

On 02/03/2021 17:23, Takashi Iwai wrote:
> On Tue, 02 Mar 2021 13:49:13 +0100,
> Mark Brown wrote:
>>
>> On Tue, Mar 02, 2021 at 09:27:12AM +0000, Jon Hunter wrote:
>>> Many systems do not provide a DMI table and on these systems a warning,
>>> such as the following, is printed on boot ...
>>>
>>>  WARNING KERN tegra-audio-graph-card sound: ASoC: no DMI vendor name!
>>>
>>> If DMI support is enabled in the kernel, there is no simple way to
>>> detect if a DMI table is table or not. Note that the variable
>>> 'dmi_available' is not exported and so cannot be used by kernel modules.
>>
>> We could fix that, or provide an accessor function?  Or only warn if
>> we're on an ACPI system (which we can check from a module).  This really
>> does feel like something we should be warning about on systems that are
>> supposed to have DMI information available as standard.
> 
> I had the same feeling when I took a look at the patch, but later
> changed mind, since the error will pop up also if a system has an
> unmatured BIOS with some bogus vendor DMI string, too.  That is, users
> of such a machine gets always an error message although this isn't any
> serious problem unless you need a dedicated UCM profile (which can't
> be used on such a system in anyway).
> 
> So, I agree that exporting dmi_avilable could improve the situation a
> bit, but the error level needs still reconsideration.


Thanks for the feedback. Yes it is probably better if we have a specific
test. I will send out a V2 for review.

Thanks
Jon

-- 
nvpublic