[0/2] mfd: twlx030: i2c remove callback cleanup

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.

Best regards
Uwe

Uwe Kleine-König (2):
  mfd: twl6030: Make twl6030_exit_irq() return void
  mfd: twl4030: Make twl4030_exit_irq() return void

 drivers/mfd/twl-core.c    | 8 ++------
 drivers/mfd/twl-core.h    | 4 ++--
 drivers/mfd/twl4030-irq.c | 7 ++-----
 drivers/mfd/twl6030-irq.c | 3 +--
 4 files changed, 7 insertions(+), 15 deletions(-)

base-commit: 455e73a07f6e288b0061dfcf4fcf54fa9fe06458

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.