From: Stephen Boyd <hidden> Date: 2021-05-10 22:00:18
Touching an elan trackpad while shutting down the system sometimes leads
to the following warning from i2c core. This is because the irq is still
active and working, but the i2c bus for the device has been shutdown
already. If the bus has been taken down then we shouldn't expect
transfers to work. Disable the irq on shutdown so that this driver
doesn't try to get the report in the irq handler after the i2c bus is
shutdown.
i2c i2c-7: Transfer while suspended
WARNING: CPU: 0 PID: 196 at drivers/i2c/i2c-core.h:54 __i2c_transfer+0xb8/0x38c
Modules linked in: rfcomm algif_hash algif_skcipher af_alg uinput xt_cgroup
CPU: 0 PID: 196 Comm: irq/166-ekth300 Not tainted 5.4.115 #96
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
pstate: 60c00009 (nZCv daif +PAN +UAO)
pc : __i2c_transfer+0xb8/0x38c
lr : __i2c_transfer+0xb8/0x38c
sp : ffffffc011793c20
x29: ffffffc011793c20 x28: 0000000000000000
x27: ffffff85efd60348 x26: ffffff85efdb8040
x25: ffffffec39d579cc x24: ffffffec39d57bac
x23: ffffffec3aab17b9 x22: ffffff85f02d6400
x21: 0000000000000001 x20: ffffff85f02aa190
x19: ffffff85f02aa100 x18: 00000000ffff0a10
x17: 0000000000000044 x16: 00000000000000ec
x15: ffffffec3a0b9174 x14: 0000000000000006
x13: 00000000003fe680 x12: 0000000000000000
x11: 0000000000000000 x10: 00000000ffffffff
x9 : 806da3cb9f8c1d00 x8 : 806da3cb9f8c1d00
x7 : 0000000000000000 x6 : ffffffec3afd3bef
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : fffffffffffffcc7
x1 : 0000000000000000 x0 : 0000000000000023
Call trace:
__i2c_transfer+0xb8/0x38c
i2c_transfer+0xa0/0xf4
i2c_transfer_buffer_flags+0x64/0x98
elan_i2c_get_report+0x2c/0x88
elan_isr+0x68/0x3e4
irq_thread_fn+0x2c/0x70
irq_thread+0xf8/0x148
kthread+0x140/0x17c
ret_from_fork+0x10/0x18
Cc: Jingle Wu <redacted>
Signed-off-by: Stephen Boyd <redacted>
---
drivers/input/mouse/elan_i2c_core.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Hi Stephen,
On Mon, May 10, 2021 at 03:00:12PM -0700, Stephen Boyd wrote:
Touching an elan trackpad while shutting down the system sometimes leads
to the following warning from i2c core. This is because the irq is still
active and working, but the i2c bus for the device has been shutdown
already. If the bus has been taken down then we shouldn't expect
transfers to work. Disable the irq on shutdown so that this driver
doesn't try to get the report in the irq handler after the i2c bus is
shutdown.
i2c i2c-7: Transfer while suspended
WARNING: CPU: 0 PID: 196 at drivers/i2c/i2c-core.h:54 __i2c_transfer+0xb8/0x38c
Modules linked in: rfcomm algif_hash algif_skcipher af_alg uinput xt_cgroup
CPU: 0 PID: 196 Comm: irq/166-ekth300 Not tainted 5.4.115 #96
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
pstate: 60c00009 (nZCv daif +PAN +UAO)
pc : __i2c_transfer+0xb8/0x38c
lr : __i2c_transfer+0xb8/0x38c
sp : ffffffc011793c20
x29: ffffffc011793c20 x28: 0000000000000000
x27: ffffff85efd60348 x26: ffffff85efdb8040
x25: ffffffec39d579cc x24: ffffffec39d57bac
x23: ffffffec3aab17b9 x22: ffffff85f02d6400
x21: 0000000000000001 x20: ffffff85f02aa190
x19: ffffff85f02aa100 x18: 00000000ffff0a10
x17: 0000000000000044 x16: 00000000000000ec
x15: ffffffec3a0b9174 x14: 0000000000000006
x13: 00000000003fe680 x12: 0000000000000000
x11: 0000000000000000 x10: 00000000ffffffff
x9 : 806da3cb9f8c1d00 x8 : 806da3cb9f8c1d00
x7 : 0000000000000000 x6 : ffffffec3afd3bef
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : fffffffffffffcc7
x1 : 0000000000000000 x0 : 0000000000000023
Call trace:
__i2c_transfer+0xb8/0x38c
i2c_transfer+0xa0/0xf4
i2c_transfer_buffer_flags+0x64/0x98
elan_i2c_get_report+0x2c/0x88
elan_isr+0x68/0x3e4
irq_thread_fn+0x2c/0x70
irq_thread+0xf8/0x148
kthread+0x140/0x17c
ret_from_fork+0x10/0x18
This does not seem to me that it is Elan-specific issue. I wonder if
this should be pushed into I2C core to shut off client->irq in shutdown
for everyone.
@@ -1338,6 +1338,22 @@ static int elan_probe(struct i2c_client *client,return0;}+staticvoidelan_shutdown(structi2c_client*client)+{+structelan_tp_data*data=i2c_get_clientdata(client);++/*+*Makesurewedon'taccessi2cbusafteritisshutdown.+*+*Wearetakingthemutextomakesuresysfsoperationsare+*completebeforeweattempttosilencethedevicebydisabling+*theirq.+*/
I do not think important on shutdown as I expect we'll stop/kill
userspace first, and then fully reinitialize device on subsequent boot.
Thanks.
--
Dmitry
From: Stephen Boyd <hidden> Date: 2021-05-11 05:11:25
Quoting Dmitry Torokhov (2021-05-10 19:01:58)
Hi Stephen,
On Mon, May 10, 2021 at 03:00:12PM -0700, Stephen Boyd wrote:
quoted
Touching an elan trackpad while shutting down the system sometimes leads
to the following warning from i2c core. This is because the irq is still
active and working, but the i2c bus for the device has been shutdown
already. If the bus has been taken down then we shouldn't expect
transfers to work. Disable the irq on shutdown so that this driver
doesn't try to get the report in the irq handler after the i2c bus is
shutdown.
i2c i2c-7: Transfer while suspended
WARNING: CPU: 0 PID: 196 at drivers/i2c/i2c-core.h:54 __i2c_transfer+0xb8/0x38c
Modules linked in: rfcomm algif_hash algif_skcipher af_alg uinput xt_cgroup
CPU: 0 PID: 196 Comm: irq/166-ekth300 Not tainted 5.4.115 #96
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
pstate: 60c00009 (nZCv daif +PAN +UAO)
pc : __i2c_transfer+0xb8/0x38c
lr : __i2c_transfer+0xb8/0x38c
sp : ffffffc011793c20
x29: ffffffc011793c20 x28: 0000000000000000
x27: ffffff85efd60348 x26: ffffff85efdb8040
x25: ffffffec39d579cc x24: ffffffec39d57bac
x23: ffffffec3aab17b9 x22: ffffff85f02d6400
x21: 0000000000000001 x20: ffffff85f02aa190
x19: ffffff85f02aa100 x18: 00000000ffff0a10
x17: 0000000000000044 x16: 00000000000000ec
x15: ffffffec3a0b9174 x14: 0000000000000006
x13: 00000000003fe680 x12: 0000000000000000
x11: 0000000000000000 x10: 00000000ffffffff
x9 : 806da3cb9f8c1d00 x8 : 806da3cb9f8c1d00
x7 : 0000000000000000 x6 : ffffffec3afd3bef
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : fffffffffffffcc7
x1 : 0000000000000000 x0 : 0000000000000023
Call trace:
__i2c_transfer+0xb8/0x38c
i2c_transfer+0xa0/0xf4
i2c_transfer_buffer_flags+0x64/0x98
elan_i2c_get_report+0x2c/0x88
elan_isr+0x68/0x3e4
irq_thread_fn+0x2c/0x70
irq_thread+0xf8/0x148
kthread+0x140/0x17c
ret_from_fork+0x10/0x18
This does not seem to me that it is Elan-specific issue. I wonder if
this should be pushed into I2C core to shut off client->irq in shutdown
for everyone.
It sounds nice if we don't have to play whack-a-mole, except for the
part where the irq is requested in this driver via
devm_request_threaded_irq(). The i2c bus code doesn't request the irq,
so it doesn't enable it, hence the responsibility of enabling and
disabling the irq is on the driver. Maybe another option would be to
disable all device irqs, similar to how that is done during suspend, but
then we would need a split shutdown flow where there's irq enabled
shutdown and irq disabled shutdown callbacks. That would be a large
change. Similarly, disabling it in the i2c bus code would be a large
change that would mean auditing each i2c driver shutdown function to
make sure we don't disable the irq more than the number of times it has
been enabled. Please don't make me shave this yak.
@@ -1338,6 +1338,22 @@ static int elan_probe(struct i2c_client *client,return0;}+staticvoidelan_shutdown(structi2c_client*client)+{+structelan_tp_data*data=i2c_get_clientdata(client);++/*+*Makesurewedon'taccessi2cbusafteritisshutdown.+*+*Wearetakingthemutextomakesuresysfsoperationsare+*completebeforeweattempttosilencethedevicebydisabling+*theirq.+*/
I do not think important on shutdown as I expect we'll stop/kill
userspace first, and then fully reinitialize device on subsequent boot.
Alright sure. I was worried about some process that may still be running
given that shutdown/restart doesn't actually stop/freeze all processes
like suspend does. If you're not worried about something like a firmware
update happening in parallel with the restart syscall then OK. Cutting
those things off may mean they don't work properly, but we're already
shutting down so all bets are off.
Hi Stephen,
Sorry for the long delay with the response.
On Mon, May 10, 2021 at 10:11:21PM -0700, Stephen Boyd wrote:
Quoting Dmitry Torokhov (2021-05-10 19:01:58)
quoted
Hi Stephen,
On Mon, May 10, 2021 at 03:00:12PM -0700, Stephen Boyd wrote:
quoted
Touching an elan trackpad while shutting down the system sometimes leads
to the following warning from i2c core. This is because the irq is still
active and working, but the i2c bus for the device has been shutdown
already. If the bus has been taken down then we shouldn't expect
transfers to work. Disable the irq on shutdown so that this driver
doesn't try to get the report in the irq handler after the i2c bus is
shutdown.
i2c i2c-7: Transfer while suspended
WARNING: CPU: 0 PID: 196 at drivers/i2c/i2c-core.h:54 __i2c_transfer+0xb8/0x38c
Modules linked in: rfcomm algif_hash algif_skcipher af_alg uinput xt_cgroup
CPU: 0 PID: 196 Comm: irq/166-ekth300 Not tainted 5.4.115 #96
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
pstate: 60c00009 (nZCv daif +PAN +UAO)
pc : __i2c_transfer+0xb8/0x38c
lr : __i2c_transfer+0xb8/0x38c
sp : ffffffc011793c20
x29: ffffffc011793c20 x28: 0000000000000000
x27: ffffff85efd60348 x26: ffffff85efdb8040
x25: ffffffec39d579cc x24: ffffffec39d57bac
x23: ffffffec3aab17b9 x22: ffffff85f02d6400
x21: 0000000000000001 x20: ffffff85f02aa190
x19: ffffff85f02aa100 x18: 00000000ffff0a10
x17: 0000000000000044 x16: 00000000000000ec
x15: ffffffec3a0b9174 x14: 0000000000000006
x13: 00000000003fe680 x12: 0000000000000000
x11: 0000000000000000 x10: 00000000ffffffff
x9 : 806da3cb9f8c1d00 x8 : 806da3cb9f8c1d00
x7 : 0000000000000000 x6 : ffffffec3afd3bef
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : fffffffffffffcc7
x1 : 0000000000000000 x0 : 0000000000000023
Call trace:
__i2c_transfer+0xb8/0x38c
i2c_transfer+0xa0/0xf4
i2c_transfer_buffer_flags+0x64/0x98
elan_i2c_get_report+0x2c/0x88
elan_isr+0x68/0x3e4
irq_thread_fn+0x2c/0x70
irq_thread+0xf8/0x148
kthread+0x140/0x17c
ret_from_fork+0x10/0x18
This does not seem to me that it is Elan-specific issue. I wonder if
this should be pushed into I2C core to shut off client->irq in shutdown
for everyone.
It sounds nice if we don't have to play whack-a-mole, except for the
part where the irq is requested in this driver via
devm_request_threaded_irq(). The i2c bus code doesn't request the irq,
so it doesn't enable it, hence the responsibility of enabling and
disabling the irq is on the driver.
There is purity, and there is practicality. Drivers normally prepare
device for suspend and waking up from suspend, however I2C core does
handle enabling interrupt as wakeup source because this saves on
boilerplate. I2C core already does a lot of preparing for interrupt
being requested by drivers (parsing ACPI and DT tables, etc).
Maybe another option would be to
disable all device irqs, similar to how that is done during suspend, but
then we would need a split shutdown flow where there's irq enabled
shutdown and irq disabled shutdown callbacks.
Yes, that would be quite large patch, and probably not needed for
devices/buses that do not use out of bound signalling of attention.
That would be a large
change. Similarly, disabling it in the i2c bus code would be a large
change that would mean auditing each i2c driver shutdown function to
make sure we don't disable the irq more than the number of times it has
been enabled.
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.
Thanks.
--
Dmitry
From: Stephen Boyd <hidden> Date: 2021-06-03 01:33:52
Quoting Dmitry Torokhov (2021-06-02 18:18:17)
Hi Stephen,
Sorry for the long delay with the response.
On Mon, May 10, 2021 at 10:11:21PM -0700, Stephen Boyd wrote:
quoted
Quoting Dmitry Torokhov (2021-05-10 19:01:58)
quoted
Hi Stephen,
On Mon, May 10, 2021 at 03:00:12PM -0700, Stephen Boyd wrote:
quoted
Touching an elan trackpad while shutting down the system sometimes leads
to the following warning from i2c core. This is because the irq is still
active and working, but the i2c bus for the device has been shutdown
already. If the bus has been taken down then we shouldn't expect
transfers to work. Disable the irq on shutdown so that this driver
doesn't try to get the report in the irq handler after the i2c bus is
shutdown.
i2c i2c-7: Transfer while suspended
WARNING: CPU: 0 PID: 196 at drivers/i2c/i2c-core.h:54 __i2c_transfer+0xb8/0x38c
Modules linked in: rfcomm algif_hash algif_skcipher af_alg uinput xt_cgroup
CPU: 0 PID: 196 Comm: irq/166-ekth300 Not tainted 5.4.115 #96
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
pstate: 60c00009 (nZCv daif +PAN +UAO)
pc : __i2c_transfer+0xb8/0x38c
lr : __i2c_transfer+0xb8/0x38c
sp : ffffffc011793c20
x29: ffffffc011793c20 x28: 0000000000000000
x27: ffffff85efd60348 x26: ffffff85efdb8040
x25: ffffffec39d579cc x24: ffffffec39d57bac
x23: ffffffec3aab17b9 x22: ffffff85f02d6400
x21: 0000000000000001 x20: ffffff85f02aa190
x19: ffffff85f02aa100 x18: 00000000ffff0a10
x17: 0000000000000044 x16: 00000000000000ec
x15: ffffffec3a0b9174 x14: 0000000000000006
x13: 00000000003fe680 x12: 0000000000000000
x11: 0000000000000000 x10: 00000000ffffffff
x9 : 806da3cb9f8c1d00 x8 : 806da3cb9f8c1d00
x7 : 0000000000000000 x6 : ffffffec3afd3bef
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : fffffffffffffcc7
x1 : 0000000000000000 x0 : 0000000000000023
Call trace:
__i2c_transfer+0xb8/0x38c
i2c_transfer+0xa0/0xf4
i2c_transfer_buffer_flags+0x64/0x98
elan_i2c_get_report+0x2c/0x88
elan_isr+0x68/0x3e4
irq_thread_fn+0x2c/0x70
irq_thread+0xf8/0x148
kthread+0x140/0x17c
ret_from_fork+0x10/0x18
This does not seem to me that it is Elan-specific issue. I wonder if
this should be pushed into I2C core to shut off client->irq in shutdown
for everyone.
It sounds nice if we don't have to play whack-a-mole, except for the
part where the irq is requested in this driver via
devm_request_threaded_irq(). The i2c bus code doesn't request the irq,
so it doesn't enable it, hence the responsibility of enabling and
disabling the irq is on the driver.
There is purity, and there is practicality. Drivers normally prepare
device for suspend and waking up from suspend, however I2C core does
handle enabling interrupt as wakeup source because this saves on
boilerplate. I2C core already does a lot of preparing for interrupt
being requested by drivers (parsing ACPI and DT tables, etc).
quoted
Maybe another option would be to
disable all device irqs, similar to how that is done during suspend, but
then we would need a split shutdown flow where there's irq enabled
shutdown and irq disabled shutdown callbacks.
Yes, that would be quite large patch, and probably not needed for
devices/buses that do not use out of bound signalling of attention.
quoted
That would be a large
change. Similarly, disabling it in the i2c bus code would be a large
change that would mean auditing each i2c driver shutdown function to
make sure we don't disable the irq more than the number of times it has
been enabled.
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.
quoted
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?
On Wed, Jun 02, 2021 at 06:33:49PM -0700, Stephen Boyd wrote:
Quoting Dmitry Torokhov (2021-06-02 18:18:17)
quoted
Hi Stephen,
Sorry for the long delay with the response.
On Mon, May 10, 2021 at 10:11:21PM -0700, Stephen Boyd wrote:
quoted
Quoting Dmitry Torokhov (2021-05-10 19:01:58)
quoted
Hi Stephen,
On Mon, May 10, 2021 at 03:00:12PM -0700, Stephen Boyd wrote:
quoted
Touching an elan trackpad while shutting down the system sometimes leads
to the following warning from i2c core. This is because the irq is still
active and working, but the i2c bus for the device has been shutdown
already. If the bus has been taken down then we shouldn't expect
transfers to work. Disable the irq on shutdown so that this driver
doesn't try to get the report in the irq handler after the i2c bus is
shutdown.
i2c i2c-7: Transfer while suspended
WARNING: CPU: 0 PID: 196 at drivers/i2c/i2c-core.h:54 __i2c_transfer+0xb8/0x38c
Modules linked in: rfcomm algif_hash algif_skcipher af_alg uinput xt_cgroup
CPU: 0 PID: 196 Comm: irq/166-ekth300 Not tainted 5.4.115 #96
Hardware name: Google Lazor (rev3+) with KB Backlight (DT)
pstate: 60c00009 (nZCv daif +PAN +UAO)
pc : __i2c_transfer+0xb8/0x38c
lr : __i2c_transfer+0xb8/0x38c
sp : ffffffc011793c20
x29: ffffffc011793c20 x28: 0000000000000000
x27: ffffff85efd60348 x26: ffffff85efdb8040
x25: ffffffec39d579cc x24: ffffffec39d57bac
x23: ffffffec3aab17b9 x22: ffffff85f02d6400
x21: 0000000000000001 x20: ffffff85f02aa190
x19: ffffff85f02aa100 x18: 00000000ffff0a10
x17: 0000000000000044 x16: 00000000000000ec
x15: ffffffec3a0b9174 x14: 0000000000000006
x13: 00000000003fe680 x12: 0000000000000000
x11: 0000000000000000 x10: 00000000ffffffff
x9 : 806da3cb9f8c1d00 x8 : 806da3cb9f8c1d00
x7 : 0000000000000000 x6 : ffffffec3afd3bef
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : fffffffffffffcc7
x1 : 0000000000000000 x0 : 0000000000000023
Call trace:
__i2c_transfer+0xb8/0x38c
i2c_transfer+0xa0/0xf4
i2c_transfer_buffer_flags+0x64/0x98
elan_i2c_get_report+0x2c/0x88
elan_isr+0x68/0x3e4
irq_thread_fn+0x2c/0x70
irq_thread+0xf8/0x148
kthread+0x140/0x17c
ret_from_fork+0x10/0x18
This does not seem to me that it is Elan-specific issue. I wonder if
this should be pushed into I2C core to shut off client->irq in shutdown
for everyone.
It sounds nice if we don't have to play whack-a-mole, except for the
part where the irq is requested in this driver via
devm_request_threaded_irq(). The i2c bus code doesn't request the irq,
so it doesn't enable it, hence the responsibility of enabling and
disabling the irq is on the driver.
There is purity, and there is practicality. Drivers normally prepare
device for suspend and waking up from suspend, however I2C core does
handle enabling interrupt as wakeup source because this saves on
boilerplate. I2C core already does a lot of preparing for interrupt
being requested by drivers (parsing ACPI and DT tables, etc).
quoted
Maybe another option would be to
disable all device irqs, similar to how that is done during suspend, but
then we would need a split shutdown flow where there's irq enabled
shutdown and irq disabled shutdown callbacks.
Yes, that would be quite large patch, and probably not needed for
devices/buses that do not use out of bound signalling of attention.
quoted
That would be a large
change. Similarly, disabling it in the i2c bus code would be a large
change that would mean auditing each i2c driver shutdown function to
make sure we don't disable the irq more than the number of times it has
been enabled.
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.
quoted
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;
From: Stephen Boyd <hidden> Date: 2021-06-03 06:14:50
Quoting Dmitry Torokhov (2021-06-02 21:33:41)
On Wed, Jun 02, 2021 at 06:33:49PM -0700, Stephen Boyd wrote:
quoted
Quoting Dmitry Torokhov (2021-06-02 18:18:17)
quoted
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.
quoted
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?
On Wed, Jun 02, 2021 at 11:13:40PM -0700, Stephen Boyd wrote:
Quoting Dmitry Torokhov (2021-06-02 21:33:41)
quoted
On Wed, Jun 02, 2021 at 06:33:49PM -0700, Stephen Boyd wrote:
quoted
Quoting Dmitry Torokhov (2021-06-02 18:18:17)
quoted
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.
quoted
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