Searched hist:"014 aced1" (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/drivers/scsi/qla4xxx/ |
H A D | ql4_def.h | 014aced1 Thu Nov 26 07:29:46 CST 2020 Ahmed S. Darwish <a.darwish@linutronix.de> scsi: qla4xxx: Remove in_interrupt() from qla4_82xx_rom_lock()
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().
Link: https://lore.kernel.org/r/20201126132952.2287996-9-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: Manish Rangankar <mrangankar@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
H A D | ql4_nx.c | 014aced1 Thu Nov 26 07:29:46 CST 2020 Ahmed S. Darwish <a.darwish@linutronix.de> scsi: qla4xxx: Remove in_interrupt() from qla4_82xx_rom_lock()
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().
Link: https://lore.kernel.org/r/20201126132952.2287996-9-bigeasy@linutronix.de Cc: Nilesh Javali <njavali@marvell.com> Cc: Manish Rangankar <mrangankar@marvell.com> Cc: <GR-QLogic-Storage-Upstream@marvell.com> Reviewed-by: Daniel Wagner <dwagner@suse.de> Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|