On Thu, Nov 26, 2020 at 02:29:46PM +0100, Sebastian Andrzej Siewior wrote: > From: "Ahmed S. Darwish" <a.darwish@xxxxxxxxxxxxx> > > qla4_82xx_rom_lock() spins on a certain hardware state until it is > updated. At the end of each spin, if in_interrupt() is true, it does 20 > loops of cpu_relax(). Otherwise, it yields the CPU. > > While in_interrupt() is ill-defined and does not provide what the name > suggests, it is not needed here: qla4_82xx_rom_lock() is always called > from process context. Below is an analysis of its callers: > > - ql4_nx.c: qla4_82xx_rom_fast_read(), all process context callers: > => ql4_nx.c: qla4_82xx_pinit_from_rom(), GFP_KERNEL allocation > => ql4_nx.c: qla4_82xx_load_from_flash(), msleep() in a loop > > - ql4_nx.c: qla4_82xx_pinit_from_rom(), earlier discussed > > - ql4_nx.c: qla4_82xx_rom_lock_recovery(), bound to "isp_operations" > ->rom_lock_recovery() hook, which has one process context caller, > qla4_8xxx_device_bootstrap(), with callers: > => ql4_83xx.c: qla4_83xx_need_reset_handler(), process, msleep() > => ql4_nx.c: qla4_8xxx_device_state_handler(), multiple msleep()s > > - ql4_nx.c: qla4_82xx_read_flash_data(), has cond_resched() > > Remove the in_interrupt() check. Mark, qla4_82xx_rom_lock(), and the > ->rom_lock_recovery() hook, with "Context: task, can sleep". > > Change qla4_82xx_rom_lock() implementation to sleep 20ms, instead of a > schedule(), for each spin. This is more deterministic, and it matches > the other implementations bound to ->rom_lock_recovery(). > > Signed-off-by: Ahmed S. Darwish <a.darwish@xxxxxxxxxxxxx> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx> > Cc: Nilesh Javali <njavali@xxxxxxxxxxx> > Cc: Manish Rangankar <mrangankar@xxxxxxxxxxx> > Cc: <GR-QLogic-Storage-Upstream@xxxxxxxxxxx> Reviewed-by: Daniel Wagner <dwagner@xxxxxxx>
