Re: [PATCH RFC 08/11] watchdog: sbsa: Handle IRQ probe deferral

[Lorenzo Pieralisi <lpieralisi@kernel.org>]

On Fri, Sep 25, 2026 at 06:46:31AM -0700, Guenter Roeck wrote:
> On Fri, Sep 25, 2026 at 07:57:26AM +0000, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [High] watchdog: sbsa: system reset due to unserviced watchdog on probe defer
> > --
> > 
> > commit 82d6b6d0cf8ddd44758931db5360cd8439795f6f
> > Author: Lorenzo Pieralisi <lpieralisi@kernel.org>
> > 
> > watchdog: sbsa: Handle IRQ probe deferral
> > 
> > This commit handles probe deferral when mapping the IRQ for the SBSA watchdog
> > by returning -EPROBE_DEFER.
> > 
> > > diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
> > > index e04d42cc7774d..f4491409caf5d 100644
> > > --- a/drivers/watchdog/sbsa_gwdt.c
> > > +++ b/drivers/watchdog/sbsa_gwdt.c
> > > @@ -352,6 +352,8 @@ static int sbsa_gwdt_probe(struct platform_device *pdev)
> > >  
> > >  	if (action) {
> > >  		irq = platform_get_irq(pdev, 0);
> > > +		if (irq == -EPROBE_DEFER)
> > > +			return dev_err_probe(dev, irq, "failed to get ws0 interrupt\n");
> > 
> > [Severity: High]
> > Does returning here during probe deferral risk an unintended system reset?
> > 
> > If the bootloader leaves the SBSA hardware watchdog running, the driver
> > correctly detects this via status & SBSA_GWDT_WCS_EN and sets
> > WDOG_HW_RUNNING.
> > 
> > Because we abort probe registration here, the core remains unaware of the
> > device and will not ping it.  If the deferral period exceeds the hardware
> > watchdog timeout, won't it expire and trigger a reset?
> > 
> > Previously, if platform_get_irq() returned -EPROBE_DEFER, the driver fell
> > back to single-stage mode (action = 0), and successfully registered the
> > watchdog, allowing the core to immediately start servicing it.
> > 
> Looks like a valid concern to me.

Right. Just to understand the issue (forgive me the stupid question), isn't
there a time window where this can happen then even without IRQ probe deferral
taken into account ?

What's the best course of action then ? Ignore -EPROBE_DEFER and treat it
as failure (basically, dropping this patch ?) ?

Thanks,
Lorenzo

> 
> Guenter
> 
> > >  		if (irq < 0) {
> > >  			action = 0;
> > >  			dev_warn(dev, "unable to get ws0 interrupt.\n");
> > 
> > -- 
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260925-acpi-static-table-irq-probe-defer-v1-0-2c62125d0085@kernel.org?part=8
> >