Message ID | 20230327-tegra-pmic-reboot-v4-0-b24af219fb47@skidata.com |
---|---|
Headers | show |
Series | mfd: tps6586x: register restart handler | expand |
On Thu, Apr 13, 2023 at 09:46:40AM +0200, Benjamin Bara wrote: > From: Benjamin Bara <benjamin.bara@skidata.com> > > Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is > disabled. However, non-atomic i2c transfers require preemption (e.g. in > wait_for_completion() while waiting for the DMA). > > panic() calls preempt_disable_notrace() before calling > emergency_restart(). Therefore, if an i2c device is used for the > restart, the xfer should be atomic. This avoids warnings like: > > [ 12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0 > [ 12.676926] Voluntary context switch within RCU read-side critical section! > ... > [ 12.742376] schedule_timeout from wait_for_completion_timeout+0x90/0x114 > [ 12.749179] wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70 > ... > [ 12.994527] atomic_notifier_call_chain from machine_restart+0x34/0x58 > [ 13.001050] machine_restart from panic+0x2a8/0x32c > > Use !preemptible() instead, which is basically the same check as > pre-v5.2. > > Fixes: bae1d3a05a8b ("i2c: core: remove use of in_atomic()") > Cc: stable@vger.kernel.org # v5.2+ > Suggested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> > Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com> So, with Peter's input and me checking again: Acked-by: Wolfram Sang <wsa@kernel.org> I assume this shall go in via the mfd-tree. Let me know if I should pick it instead.
On 4/13/23 10:46, Benjamin Bara wrote: > +static int tps6586x_power_off_handler(struct sys_off_data *data) > { > - if (tps6586x_clr_bits(tps6586x_dev, TPS6586X_SUPPLYENE, EXITSLREQ_BIT)) > - return; > + struct device *tps6586x_dev = data->cb_data; > + int ret; > + > + ret = tps6586x_clr_bits(tps6586x_dev, TPS6586X_SUPPLYENE, EXITSLREQ_BIT); > + if (ret) > + return ret; > > - tps6586x_set_bits(tps6586x_dev, TPS6586X_SUPPLYENE, SLEEP_MODE_BIT); > + return tps6586x_set_bits(tps6586x_dev, TPS6586X_SUPPLYENE, SLEEP_MODE_BIT); Handlers must return NOTIFY_DONE or notifier_from_errno(). Sorry for missing this previously.
On Thu, 13 Apr 2023, 22:37 Dmitry Osipenko, <dmitry.osipenko@collabora.com> wrote: > Handlers must return NOTIFY_DONE or notifier_from_errno(). Sorry for > missing this previously. Thanks! AFAIU, notifier_from_errno() sets NOTIFY_STOP_MASK, which stops atomic_notifier_call_chain() immediately. So I think NOTIFY_DONE is the only valid return value for sys_off handlers, to not skip others. So I think letting sys_off_notify() [1] always return NOTIFY_DONE might be a good idea. If so, we could return a "notify return errno" (or also a "normal errno") from the handler, which is checked, but then replaced to NOTIFY_DONE, in [1]. This would enable us to have a common place to check for failed handlers. Handlers then should only return NOTIFY_DONE when they are skipped (e.g. when the requested reboot mode is not supported by the handler). Otherwise, I think ETIME, ENOSYS or ENOTSUPP might fit when the communication was successful, a possible delay awaited, but the return was still reached. What do you think? Thanks and best regards, Benjamin [1] https://elixir.bootlin.com/linux/v6.3-rc6/source/kernel/reboot.c#L327
On 4/14/23 09:15, Benjamin Bara wrote: > On Thu, 13 Apr 2023, 22:37 Dmitry Osipenko, > <dmitry.osipenko@collabora.com> wrote: >> Handlers must return NOTIFY_DONE or notifier_from_errno(). Sorry for >> missing this previously. > > Thanks! > > AFAIU, notifier_from_errno() sets NOTIFY_STOP_MASK, which stops > atomic_notifier_call_chain() immediately. So I think NOTIFY_DONE is the > only valid return value for sys_off handlers, to not skip others. So I > think letting sys_off_notify() [1] always return NOTIFY_DONE might be a > good idea. > > If so, we could return a "notify return errno" (or also a "normal > errno") from the handler, which is checked, but then replaced to > NOTIFY_DONE, in [1]. This would enable us to have a common place to > check for failed handlers. > > Handlers then should only return NOTIFY_DONE when they are skipped (e.g. > when the requested reboot mode is not supported by the handler). > Otherwise, I think ETIME, ENOSYS or ENOTSUPP might fit when the > communication was successful, a possible delay awaited, but the return > was still reached. What do you think? The behaviour may depend on a particular platform and driver. In general and in case of this driver, it should be more reliable and cleaner to abort the reboot on a error that shall never happen.
On Mon, 24 Apr 2023 at 12:42, Dmitry Osipenko <dmitry.osipenko@collabora.com> wrote: > In general and in case of this driver, it should be more reliable and > cleaner to abort the reboot on a error that shall never happen. Thanks! Then I will drop my 4/6 of v5 [1]. [1] https://lore.kernel.org/all/20230327-tegra-pmic-reboot-v5-4-ab090e03284d@skidata.com/