diff mbox series

[2/2] rtc: cmos: Propagate errors from optional IRQ lookup

Message ID 20260810051504.26912-2-phucduc.bui@gmail.com
State New
Headers show
Series [1/2] rtc: m48t59: Propagate errors from optional IRQ lookup | expand

Commit Message

Bui Duc Phuc Aug. 10, 2026, 5:15 a.m. UTC 
From: bui duc phuc <phucduc.bui@gmail.com>

platform_get_irq_optional() returns a positive IRQ number on success or
a negative error code on failure. For an optional IRQ, -ENXIO indicates
that no optional IRQ is available, while other errors should be propagated.

Propagate all error codes returned by platform_get_irq_optional() other
than -ENXIO, while preserving -1 for the case where no optional IRQ is
available.

Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
 drivers/rtc/rtc-cmos.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Comments

sashiko-bot@kernel.org Aug. 10, 2026, 5:30 a.m. UTC | #1 
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Propagating -EPROBE_DEFER from platform_get_irq_optional() causes a permanent device probe failure because rtc-cmos is registered using platform_driver_probe(), which explicitly forbids deferred probing.
- [High] Propagating parsing errors like -EINVAL bypasses the x86 legacy IRQ fallback, breaking RTC probing on systems with malformed ACPI tables.
--

--- Patch [2]: [PATCH 2/2] rtc: cmos: Propagate errors from optional IRQ lookup ---
commit bf54cacd6dce9cc731cd51fdbcbf8b84af0b1e7f
Author: bui duc phuc <phucduc.bui@gmail.com>

rtc: cmos: Propagate errors from optional IRQ lookup

The commit updates the RTC CMOS driver to propagate error codes returned by
platform_get_irq_optional() other than -ENXIO, while preserving -1 for the
case where no optional IRQ is available.

> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index fa04ece151b8b..0a2c7383c8cd4 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -1436,7 +1436,9 @@ static int __init cmos_platform_probe(struct platform_device *pdev)
>  	else
>  		resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>  	irq = platform_get_irq_optional(pdev, 0);
> -	if (irq < 0) {
> +	if (irq < 0 && irq != -ENXIO)
> +		return irq;

[Severity: High]
Does propagating -EPROBE_DEFER from platform_get_irq_optional() cause a
permanent device probe failure?

Since rtc-cmos is registered using platform_driver_probe(), which explicitly
forbids deferred probing, returning -EPROBE_DEFER here might cause the driver
core to convert it to -ENXIO and permanently fail the probe instead of
proceeding without an optional IRQ.

[Severity: High]
Does propagating parsing errors like -EINVAL bypass the x86 legacy IRQ
fallback?

On x86 systems with malformed ACPI tables (e.g., specifying IRQ 0, which
platform_get_irq_optional() rejects with -EINVAL), propagating the error
bypasses the fallback logic below that successfully hardcodes the IRQ to
RTC_IRQ if legacy PIC IRQs are supported, potentially breaking RTC probing
on those systems.

> +	if (irq == -ENXIO) {
>  		irq = -1;
>  #ifdef CONFIG_X86
>  		/*
diff mbox series

Patch

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index fa04ece151b8..0a2c7383c8cd 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -1436,7 +1436,9 @@  static int __init cmos_platform_probe(struct platform_device *pdev)
 	else
 		resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	irq = platform_get_irq_optional(pdev, 0);
-	if (irq < 0) {
+	if (irq < 0 && irq != -ENXIO)
+		return irq;
+	if (irq == -ENXIO) {
 		irq = -1;
 #ifdef CONFIG_X86
 		/*