Re: [RESEND PATCH 2/2] rtc: cmos: Honor explicit use_acpi_alarm parameter value

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] rtc: cmos: unused-but-set variable use_acpi_alarm_explicit on non-x86
--

commit db7f65d5eb781cb5e973c2ace56bd5a4865e78bb
Author: Gregory Price <gourry@gourry.net>

rtc: cmos: Honor explicit use_acpi_alarm parameter value

An explicit rtc_cmos.use_acpi_alarm=0 command-line argument is ignored on
systems where use_acpi_alarm_quirks() enables ACPI RTC alarms. This patch uses
a custom setter to record whether parsing occurred and skips automatic
selection when it did.

> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index fe514b1aa3433..209aa4ec732c8 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -57,7 +57,28 @@
>   */
>  
>  static bool use_acpi_alarm;
> -module_param(use_acpi_alarm, bool, 0444);
> +static bool use_acpi_alarm_explicit;
> +
> +static int set_use_acpi_alarm(const char *val, const struct kernel_param *kp)
> +{
> +	int ret;
> +
> +	ret = param_set_bool(val, kp);
> +	if (!ret)
> +		use_acpi_alarm_explicit = true;

[Severity: Low]
Will this trigger a -Wunused-but-set-variable compiler warning on non-x86
architectures?

The file-scoped variable use_acpi_alarm_explicit is declared and unconditionally
assigned here, but it appears to only be read inside use_acpi_alarm_quirks(),
which is wrapped in an #ifdef CONFIG_X86 block.

On architectures like ARM64 or PowerPC, the variable is written to but never
read.

> +
> +	return ret;
> +}

[ ... ]

> @@ -822,6 +843,9 @@ static void rtc_wake_off(struct device *dev)
>  #ifdef CONFIG_X86
>  static void use_acpi_alarm_quirks(void)
>  {
> +	if (use_acpi_alarm_explicit)
> +		return;
> +
>  	if (acpi_gbl_FADT.flags & ACPI_FADT_FIXED_RTC)
>  		return;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261015173029.3091872-1-gourry@gourry.net?part=2