[PATCH] ASoC: soc-core: Prevent warning if no DMI table is present
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; }
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.
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
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
participants (3)
-
Jon Hunter -
Mark Brown -
Takashi Iwai