Hello Andy, On Mon, Jun 20, 2022 at 06:13:21PM +0200, Andy Shevchenko wrote: > On Mon, Jun 20, 2022 at 2:33 PM Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > > > If a platform device's remove callback returns non-zero, the device core > > emits a warning and still removes the device and calls the devm cleanup > > callbacks. > > > > So it's not save to not unregister the gpiochip because on the next request > > safe > > > to a gpio the driver accesses kfree()'d memory. Also if an irq triggers, > > GPIO > IRQ > > > the freed memory is accessed. > > > > Instead rely on the gpio framework to ensure that after gpiochip_remove() > > GPIO > > > all gpios are freed and so the corresponding irqs unmapped. (I'm think the > > GPIOs > IRQs > are unmapped > > I think > > > gpio framework doesn't guarantee that, but that's a bug there and out of > > GPIO > > > scope for this gpio driver to fix that.) > > GPIO > > > This is a preparation for making platform remove callbacks return void. > > > ... > > What a bug are you seeing in the GPIO library? IIRC for IRQ over GPIO > the GPIO holds the module reference count as well as GPIO device > reference count. Am I wrong? I don't see a bug, I just looked into gpiochip_remove() to check if it ensures that all gpios go away and at one point is issues dev_crit(&gdev->dev, "REMOVING GPIOCHIP WITH GPIOS STILL REQUESTED\n"); and so I assumed that there is an issue, but maybe this isn't reachable in practise?! Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | https://www.pengutronix.de/ |
Attachment:
signature.asc
Description: PGP signature
