On Wed, Jun 02, 2021 at 11:13:40PM -0700, Stephen Boyd wrote: > Quoting Dmitry Torokhov (2021-06-02 21:33:41) > > On Wed, Jun 02, 2021 at 06:33:49PM -0700, Stephen Boyd wrote: > > > Quoting Dmitry Torokhov (2021-06-02 18:18:17) > > > > > > > > I do not think keeping counter balanced would be important here, as we > > > > are shutting down, and upon reboot everything will be reinitialized from > > > > scratch. Also, we are lucky in that there is just a handful of I2C > > > > drivers defining shutdown() methods. > > > > > > > > > Please don't make me shave this yak. > > > > > > > > I'm afraid someone has to... I'm adding Wolfram to CC to get his take on > > > > this. > > > > > > > > > > I suppose another option would be to introduce some common function that > > > i2c drivers can use for their shutdown op, like i2c_generic_shutdown() > > > that would disable the irq? I would guess that it isn't a great idea to > > > blanket disable the irq in case some i2c driver wants to do something > > > that may require that irq to come in once more during shutdown to signal > > > that things are off or something like that. > > > > > > Would having this common function that this driver opts into work for > > > you? > > > > Opting in in this fashion will still require changes in the majority > > of drivers (any I2C touchscreen or touchpad may be touched while system > > is being shut down, so all of them will need to have interrupt freed or > > disabled, or they may initiate I2C transfer). How about something like > > this; > > Yes, this approach should work. I assume a device that doesn't have a > shutdown function will be happy to let the i2c core disable the irq for > it so it looks low risk. > > Will you send a proper patch to Wolfram or would you like me to wrap it > up and resend? If you could do that I'd be more than happy. Thanks. -- Dmitry
