Re: [PATCH v4 6/7] gpiolib: cdev: don't report a failed line read as an edge

[Bartosz Golaszewski]

On Fri, Oct 30, 2026 at 09:46:39PM +0800, Kent Gibson wrote:
> On Fri, Oct 30, 2026 at 02:31:10PM +0200, Adrian Ambrozewicz wrote:
> > On Fri, Oct 30, 2026 at 07:14:35PM +0800, Kent Gibson wrote:
> > > > Fixes: 61f922db7221 ("gpio: userspace ABI for reading GPIO line events")
> > > > Fixes: 73e0341992b6 ("gpiolib: cdev: support edge detection for uAPI v2")
> > > > Fixes: 2068339a6c35 ("gpiolib: cdev: Add hardware timestamp clock type")
> > >
> > > How did you determine that?  Those commits are where the associated blocks
> > > of code were first added - not where the problem first exhibited.
> > 
> > From the hot-plug case in the message: a driver's ->get() error has
> > reached these checks since each was added. Removal is newer, as you
> > say.
> > 
> > > The failure mode you are addressing was added by
> > > commit d83cee3d ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU").
> > > Prior to that gpiod_get_raw_value_commit(), and gpiod_get_value_cansleep()
> > > and gpiod_get_raw_value_cansleep() that wrap it, wouldn't return the error
> > > that you are handling.
> > >
> > > Could you bisect to confirm?
> > 
> > Confirmed: with gpio-sim and delayed IRQ threads, a falling edge
> > during removal reads as falling on the parent of commit d83cee3d2bb1
> > ("gpio: protect the pointer to gpio_chip in gpio_device with SRCU")
> > and as rising on it, 10 of 10 each.
> > 
> > A test chip whose ->get() returns -EIO gives a rising edge on that
> > parent and on gpio/for-current, none with this patch. pcf857x and dln2
> > already returned such errors at commit 61f922db7221
> > ("gpio: userspace ABI for reading GPIO line events").
> > 
> 
> Ok, so the driver ->get() itself may return an error if the physical chip
> has gone away.  Hadn't considered that path.
> 
> Could you update the commit message to better describe that case?
> 
> > I would use Fixes: 61f922db7221 for ->get() errors and d83cee3d2bb1
> > for removal. Is that OK?
> 
> Not sure - I'll defer to Bart on that.
>

Rule of thumb is: the Fixes tag should point to the commit until which
backporting of this patch makes sense. I'd say your proposal is fine.

Bart