Re: drivers/platform/x86/amd/pmc/pmc.c:717:37: warning: '%s' directive argument is null

[Daniel Gibson]

Hi,

On 25.06.26 09:22, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   ab9de95c9cf952332ab79453b4b5d1bfca8e514f
> commit: 428b9fd2dce50b4dc5cd9ade10b92efcf57ce7aa platform/x86/amd/pmc: Add delay_suspend module parameter
> date:   2 weeks ago
> config: x86_64-buildonly-randconfig-006-20260625 (https://download.01.org/0day-ci/archive/20260625/202606251540.Nr2BtaNu-lkp@xxxxxxxxx/config)
> compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260625/202606251540.Nr2BtaNu-lkp@xxxxxxxxx/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Fixes: 428b9fd2dce5 ("platform/x86/amd/pmc: Add delay_suspend module parameter")
> | Reported-by: kernel test robot <lkp@xxxxxxxxx>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202606251540.Nr2BtaNu-lkp@xxxxxxxxx/
> 
> All warnings (new ones prefixed by >>):
> 
>    In file included from include/linux/device.h:15,
>                     from include/linux/acpi.h:15,
>                     from drivers/platform/x86/amd/pmc/pmc.c:13:
>    In function 'amd_pmc_want_suspend_delay',
>        inlined from 'amd_pmc_s2idle_check' at drivers/platform/x86/amd/pmc/pmc.c:763:6:
>>> drivers/platform/x86/amd/pmc/pmc.c:717:37: warning: '%s' directive argument is null [-Wformat-overflow=]
>      717 |                 dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@xxxxxxxxxxxxxxx so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
>          |                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>    include/linux/dev_printk.h:110:30: note: in definition of macro 'dev_printk_index_wrap'
>      110 |                 _p_func(dev, fmt, ##__VA_ARGS__);                       \
>          |                              ^~~
>    include/linux/dev_printk.h:160:58: note: in expansion of macro 'dev_fmt'
>      160 |         dev_printk_index_wrap(_dev_info, KERN_INFO, dev, dev_fmt(fmt), ##__VA_ARGS__)
>          |                                                          ^~~~~~~
>    drivers/platform/x86/amd/pmc/pmc.c:717:17: note: in expansion of macro 'dev_info'
>      717 |                 dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@xxxxxxxxxxxxxxx so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
>          |                 ^~~~~~~~
>    drivers/platform/x86/amd/pmc/pmc.c: In function 'amd_pmc_s2idle_check':
>    drivers/platform/x86/amd/pmc/pmc.c:717:279: note: format string is defined here
>      717 |                 dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@xxxxxxxxxxxxxxx so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
>          |                                                                                                                                                                                                                                                                                       ^~
> 
> 
> vim +717 drivers/platform/x86/amd/pmc/pmc.c
> 
>    691	
>    692	static bool amd_pmc_want_suspend_delay(struct amd_pmc_dev *pdev)
>    693	{
>    694		/*
>    695		 * Some Lenovo Laptops (like different IdeaPad 3 Slims) need some
>    696		 * me-time before sleeping or they get uncooperative after waking
>    697		 * up and don't send events for keyboard and lid switch anymore.
>    698		 *
>    699		 * Unfortunately this doesn't entirely fix the problem: It can still
>    700		 * happen when resuming with a timer (wakealarm), but at least the
>    701		 * more common usecases (wakeup by opening lid or pressing a key)
>    702		 * work fine with this workaround.
>    703		 *
>    704		 * See https://bugzilla.kernel.org/show_bug.cgi?id=221383
>    705		 */
>    706		if (amd_pmc_quirk_need_suspend_delay(pdev)) {
>    707			/*
>    708			 * delay_suspend=1 force-enables this, otherwise it can be
>    709			 * disabled with disable_workarounds or delay_suspend=0
>    710			 */
>    711			if (delay_suspend == 1 || (delay_suspend == -1 && !disable_workarounds)) {
>    712				dev_info(pdev->dev, "Delaying suspend by 2.5s to avoid platform bug\n");
>    713				return true;
>    714			}
>    715			dev_info(pdev->dev, "Not delaying suspend because of module parameter, even though your device is assumed to need it!\n");
>    716		} else if (delay_suspend == 1) {
>  > 717			dev_info(pdev->dev, "Delaying suspend by 2.5s because delay_suspend=1. If this solves problems on your machine, please report this whole line to: platform-driver-x86@xxxxxxxxxxxxxxx so it can be automatically detected as affected in the future. System Vendor: \"%s\" Product Name: \"%s\" Product Family: \"%s\" Board Vendor: \"%s\" Board Name: \"%s\"\n",
>    718				 dmi_get_system_info(DMI_SYS_VENDOR),
>    719				 dmi_get_system_info(DMI_PRODUCT_NAME),
>    720				 dmi_get_system_info(DMI_PRODUCT_FAMILY),
>    721				 dmi_get_system_info(DMI_BOARD_VENDOR),
>    722				 dmi_get_system_info(DMI_BOARD_NAME));
>    723			return true;
>    724		}
>    725		return false;
>    726	}
>    727	
> 

Ok, so dmi_get_system_info(DMI_*) can return NULL (not sure if this is
more of a theoretical possibility or if it actually happens).

Is this a problem?

As far as I know printk() will just print "(null)" or similar then,
which IMHO is fine for this usecase.

Cheers,
Daniel