Message ID | 20220113101430.12869-1-u.kleine-koenig@pengutronix.de |
---|---|
Headers | show |
Series | mfd: twlx030: i2c remove callback cleanup | expand |
On Thu, Jan 13, 2022 at 11:14:28AM +0100, Uwe Kleine-König wrote: > Hello, > > the remove paths of the twl4030 chip can fail and then returns an error > code in twl_remove() early. This isn't a good thing, because the device > will still go away with some resources not freed. > For the twl6030 this cannot happen, and the first patch is just a small > cleanup. For the twl4030 the situation is improved a bit: When the > failure happens, the dummy slave devices are removed now. > > Note that twl4030_exit_irq() is incomplete. The irq isn't freed and > maybe some more cleanup is missing which might boom if an irq triggers > after the device is removed. Not sure that twl6030_exit_irq() is better > in this regard. > > I noticed this issue because I work on making i2c_driver::remove return > void as returning a value != 0 there is almost always an error attached > to wrong expectations. It's one merge window ago now that I sent these two patches and didn't get any feedback. Did this series fell through the cracks? Best regards Uwe
On Thu, 31 Mar 2022, Uwe Kleine-König wrote: > On Thu, Jan 13, 2022 at 11:14:28AM +0100, Uwe Kleine-König wrote: > > Hello, > > > > the remove paths of the twl4030 chip can fail and then returns an error > > code in twl_remove() early. This isn't a good thing, because the device > > will still go away with some resources not freed. > > For the twl6030 this cannot happen, and the first patch is just a small > > cleanup. For the twl4030 the situation is improved a bit: When the > > failure happens, the dummy slave devices are removed now. > > > > Note that twl4030_exit_irq() is incomplete. The irq isn't freed and > > maybe some more cleanup is missing which might boom if an irq triggers > > after the device is removed. Not sure that twl6030_exit_irq() is better > > in this regard. > > > > I noticed this issue because I work on making i2c_driver::remove return > > void as returning a value != 0 there is almost always an error attached > > to wrong expectations. > > It's one merge window ago now that I sent these two patches and didn't > get any feedback. Did this series fell through the cracks? Yes they did. Feel free to submit [RESEND]s any time after 2 weeks with no reply. They are now on my TODO list.