On 10/4/23 5:00 AM, Bartosz Golaszewski wrote: > On Thu, Sep 7, 2023 at 9:28 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> >> On Tue, Sep 5, 2023 at 8:53 PM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: >> >>> From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >>> >>> Using struct gpio_chip is not safe as it will disappear if the >>> underlying driver is unbound for any reason. Switch to using reference >>> counted struct gpio_device and its dedicated accessors. >>> >>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> >> >> As Andy points out add <linux/cleanup.h>, with that fixed: >> Reviewed-by: Linus Walleij <linus.walleij@xxxxxxxxxx> >> >> I think this can be merged into the gpio tree after leaving some >> slack for the HTE maintainer to look at it, things look so much >> better after this. >> >> Yours, >> Linus Walleij > > Dipen, > > if you could give this patch a test and possibly ack it for me to take > it through the GPIO tree (or go the immutable tag from HTE route) then > it would be great. This is the last user of gpiochip_find() treewide, > so with it we could remove it entirely for v6.7. Progress so far for the RFT... I tried applying the patch series on 6.6-rc1 and it did not apply cleanly, some patches I needed to manually apply and correct. With all this, it failed compilation at some spi/spi-bcm2835 driver. I disabled that and was able to compile. I thought I should let you know this part. Now, I tried to test the hte and it seems to fail finding the gpio device, roughly around this place [1]. I thought it would be your patch series so tried to just use 6.6rc1 without your patches and it still failed at the same place. I have to trace back now from which kernel version it broke. > > Bart
