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

[Adrian Ambrozewicz]

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").

I would use Fixes: 61f922db7221 for ->get() errors and d83cee3d2bb1
for removal. Is that OK?