| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by
explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Link: https://lore.kernel.org/r/e9fc10eb7d843e6f31e50400d428bd7a217684ac.1605896060.git.gustavoars@kernel.org
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by
explicitly adding a break statement instead of letting the code fall
through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Link: https://lore.kernel.org/r/e4e25e57964a69f7173f868ff93df9d6d08f360f.1605896060.git.gustavoars@kernel.org
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple break statements and replacing /*
fall through */ comments with the new pseudo-keyword macro fallthrough;
instead of just letting the code fall through to the next case.
Notice that Clang doesn't recognize /* fall through */ comments as implicit
fall-through markings.
Link: https://github.com/KSPP/linux/issues/115
Link: https://lore.kernel.org/r/2ae1cafd858238b85fc5e7fe5cc183843e21ec9f.1605896059.git.gustavoars@kernel.org
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding a couple of break and fallthrough statements
instead of just letting the code fall through to the next case.
Link: https://github.com/KSPP/linux/issues/115
Link: https://lore.kernel.org/r/9b58459045d303bbea0160f2e349f5799402a2bf.1605896059.git.gustavoars@kernel.org
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple
warnings by explicitly adding multiple break statements instead of just
letting the code fall through to the next case, and by adding fallthrough
statements in places where the code is intended to fall through, and
finally by replacing /* FALLTHROUGH */ comments with the new pseudo-keyword
macro fallthrough.
Link: https://github.com/KSPP/linux/issues/115
Link: https://lore.kernel.org/r/1a7cd2f77623e6ab46bbec0b6103b18491419206.1605896059.git.gustavoars@kernel.org
Signed-off-by: Gustavo A. R. Silva <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
smatch correctly called out a logic error with accessing a pointer after
checking it for null:
drivers/scsi/lpfc/lpfc_els.c:2043 lpfc_cmpl_els_plogi()
error: we previously assumed 'ndlp' could be null (see line 1942)
Adjust the exit point to avoid the trace printf ndlp reference. A trace
entry was already generated when the ndlp was checked for null.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 4430f7fd09ec ("scsi: lpfc: Rework locations of ndlp reference taking")
Reported-by: Dan Carpenter <[email protected]>
Signed-off-by: James Smart <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Instead of hardcoding the scale down gear, make it a member of
the ufs_clk_scaling struct.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Stanley Chu <[email protected]>
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Can Guo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
If we want to disable clocks to save power but still keep the link active,
core_clk_unipro, like ref_clk, should not be the one being disabled.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hongwu Su <[email protected]>
Reviewed-by: Asutosh Das <[email protected]>
Signed-off-by: Can Guo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Remove the param skip_ref_clk from __ufshcd_setup_clocks(), but keep a flag
in struct ufs_clk_info to tell whether a clock can be disabled or not while
the link is active.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Hongwu Su <[email protected]>
Reviewed-by: Bean Huo <[email protected]>
Reviewed-by: Stanley Chu <[email protected]>
Signed-off-by: Can Guo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
mptsas_cleanup_fw_event_q()
mptsas_cleanup_fw_event_q() uses in_interrupt() to determine if it is safe
to cancel a worker item.
Aside of that in_interrupt() is deprecated as it does not provide what the
name suggests. It covers more than hard/soft interrupt servicing context
and is semantically ill defined.
Looking closer there are a few problems with the current construct:
- It could be invoked from an interrupt handler / non-blocking context
because cancel_delayed_work() has no such restriction. Also,
mptsas_free_fw_event() has no such restriction.
- The list is accessed unlocked. It may dequeue a valid work-item but at
the time of invoking cancel_delayed_work() the memory may be released or
reused because the worker has already run.
mptsas_cleanup_fw_event_q() is invoked via mptsas_shutdown() which is
always invoked from preemtible context on device shutdown. It is also
invoked via mptsas_ioc_reset(, MPT_IOC_POST_RESET) which is a
MptResetHandlers callback. The only caller here are mpt_SoftResetHandler(),
mpt_HardResetHandler() and mpt_Soft_Hard_ResetHandler(). All these
functions have a `sleepFlag' argument and each caller uses caller uses
`CAN_SLEEP' here and according to current documentation: | @sleepFlag:
Indicates if sleep or schedule must be called
So it is safe to sleep.
Add mptsas_hotplug_event::users member. Initialize it to one by default so
mptsas_free_fw_event() will free the memory. mptsas_cleanup_fw_event_q()
will increment its value for items it dequeues and then it may keep a
pointer after dropping the lock. Invoke cancel_delayed_work_sync() to
cancel the work item and wait if the worker is currently busy. Free the
memory afterwards since it owns the last reference to it.
Link: https://lore.kernel.org/r/[email protected]
Cc: Sathya Prakash <[email protected]>
Cc: Sreekanth Reddy <[email protected]>
Cc: Suganath Prabu Subramani <[email protected]>
Cc: [email protected]
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
in_interrupt() is referenced all over the place in these drivers. Most of
these references are comments which are outdated and wrong.
Aside of that in_interrupt() is deprecated as it does not provide what the
name suggests. It covers more than hard/soft interrupt servicing context
and is semantically ill defined.
>From reading the mpt_config() code and the history this is clearly a debug
mechanism and should probably be replaced by might_sleep() or completely
removed because such checks are already in the subsequent functions.
Remove the in_interrupt() references and replace the usage in mpt_config()
with might_sleep().
Link: https://lore.kernel.org/r/[email protected]
Cc: Sathya Prakash <[email protected]>
Cc: Sreekanth Reddy <[email protected]>
Cc: Suganath Prabu Subramani <[email protected]>
Cc: [email protected]
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The in_interrupt() macro is ill-defined and does not provide what the name
suggests. The usage especially in driver code is deprecated and a tree-wide
effort to clean up and consolidate the (ab)usage of in_interrupt() and
related checks is happening.
In this case the check covers only parts of the contexts in which these
functions cannot be called. It fails to detect preemption or interrupt
disabled invocations.
As wait_for_completion() already contains a broad variety of checks (always
enabled or debug option dependent) which cover all invalid conditions
already, there is no point in having extra inconsistent warnings in
drivers.
Just remove it.
Link: https://lore.kernel.org/r/[email protected]
Cc: Hannes Reinecke <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The in_interrupt() macro is ill-defined and does not provide what the name
suggests. The usage especially in driver code is deprecated and a tree-wide
effort to clean up and consolidate the (ab)usage of in_interrupt() and
related checks is happening.
In this case the check covers only parts of the contexts in which these
functions cannot be called. It fails to detect preemption or interrupt
disabled invocations.
As wait_for_completion() already contains a broad variety of checks (always
enabled or debug option dependent) which cover all invalid conditions
already, there is no point in having extra inconsistent warnings in
drivers.
Just remove it.
Link: https://lore.kernel.org/r/[email protected]
Cc: Hannes Reinecke <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
_scsih_fw_event_cleanup_queue() waits for all outstanding firmware events
wokrqueue handlers to finish. If in_interrupt() is true, it cancels itself
and return early.
That in_interrupt() check is ill-defined and does not provide what the name
suggests: it does not cover all states in which it is safe to block and
call functions like cancel_work_sync().
That check is also not needed: _scsih_fw_event_cleanup_queue() is always
invoked from process context. Below is an analysis of its callers:
- scsih_remove(), bound to PCI ->remove(), process context
- scsih_shutdown(), bound to PCI ->shutdown(), process context
- mpt3sas_scsih_clear_outstanding_scsi_tm_commands(), called by
=> _base_clear_outstanding_commands(), called by
=>_base_fault_reset_work(), workqueue
=> mpt3sas_base_hard_reset_handler(), locks mutex
Remove the in_interrupt() check. Change _scsih_fw_event_cleanup_queue()
specification to a purely process-context function and mark it with
"Context: task, can sleep".
Link: https://lore.kernel.org/r/[email protected]
Cc: Sathya Prakash <[email protected]>
Cc: Sreekanth Reddy <[email protected]>
Cc: Suganath Prabu Subramani <[email protected]>
Cc: <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
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/[email protected]
Cc: Nilesh Javali <[email protected]>
Cc: Manish Rangankar <[email protected]>
Cc: <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
qla4_82xx_idc_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_idc_lock() is always called from
process context. Below is an analysis of its callers:
- ql4_nx.c: qla4_82xx_need_reset_handler(), 1-second msleep() in a
loop.
- ql4_nx.c: qla4_82xx_isp_reset(), calls
qla4_8xxx_device_state_handler(), which has multiple msleep()s.
Beside direct calls, qla4_82xx_idc_lock() is also bound to isp_operations
->idc_lock() hook. Other functions which are bound to the same hook,
e.g. qla4_83xx_drv_lock(), also have an msleep(). For completeness, below
is an analysis of all callers of that hook:
- ql4_83xx.c: qla4_83xx_need_reset_handler(), has an msleep()
- ql4_83xx.c: qla4_83xx_isp_reset(), calls
qla4_8xxx_device_state_handler(), which has multiple msleep()s.
- ql4_83xx.c: qla4_83xx_disable_pause(), all process context callers:
=> ql4_mbx.c: qla4xxx_mailbox_command(), msleep(), mutex_lock()
=> ql4_os.c: qla4xxx_recover_adapter(), schedule_timeout() in loop
=> ql4_os.c: qla4xxx_do_dpc(), workqueue context
- ql4_attr.c: qla4_8xxx_sysfs_write_fw_dump(), sysfs bin_attribute
->write() hook, process context
- ql4_mbx.c: qla4xxx_mailbox_command(), earlier discussed
- ql4_nx.c: qla4_8xxx_device_bootstrap(), callers:
=> ql4_83xx.c: qla4_83xx_need_reset_handler(), process, msleep()
=> ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed
- ql4_nx.c: qla4_8xxx_need_qsnt_handler(), callers:
=> ql4_nx.c: qla4_8xxx_device_state_handler(), multiple msleep()s
=> ql4_os.c: qla4xxx_do_dpc(), workqueue context
- ql4_nx.c: qla4_8xxx_update_idc_reg(), callers:
=> ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed
=> ql4_os.c: qla4_8xxx_error_recovery(), only called by
qla4xxx_pci_slot_reset(), which is bound to PCI ->slot_reset()
process-context hook
- ql4_nx.c: qla4_8xxx_device_state_handler(), earlier discussed
- ql4_os.c: qla4xxx_recover_adapter(), earlier discussed
- ql4_os.c: qla4xxx_do_dpc(), earlier discussed
Remove the in_interrupt() check. Mark, qla4_82xx_idc_lock(), and the
->idc_lock() hook itself, with "Context: task, can sleep".
Change qla4_82xx_idc_lock() implementation to sleep 100ms, instead of a
schedule(), for each spin. This is more deterministic, and it matches other
PCI HW locking functions in the driver.
Link: https://lore.kernel.org/r/[email protected]
Cc: Nilesh Javali <[email protected]>
Cc: Manish Rangankar <[email protected]>
Cc: <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
qla83xx_wait_logic() is used to control the frequency of device IDC lock
retries. If in_interrupt() is true, it does 20 loops of cpu_relax().
Otherwise, it sleeps for 100ms and yields the CPU.
While in_interrupt() is ill-defined and does not provide what the name
suggests, it is not needed here: that qla83xx_wait_logic() is exclusively
called by qla83xx_idc_lock() / unlock(), and they always run from process
context. Below is an analysis of all the idc lock/unlock callers, in order
of appearance:
- qla_os.c:
qla83xx_nic_core_unrecoverable_work(),
qla83xx_idc_state_handler_work(),
qla83xx_nic_core_reset_work(),
qla83xx_service_idc_aen(), all workqueue context
- qla_os.c: qla83xx_check_nic_core_fw_alive(), has msleep()
- qla_os.c: qla83xx_set_drv_presence(), called once from
qla2x00_abort_isp(), which is bound to process-context ->abort_isp()
hook. It also invokes wait_for_completion_timeout() through the chain
qla2x00_configure_hba() => qla24xx_link_initialize() =>
qla2x00_mailbox_command().
- qla_os.c: qla83xx_clear_drv_presence(), which is called from
qla2x00_abort_isp() discussed above, and from qla2x00_remove_one()
which is PCI process-context ->remove() hook.
- qla_os.c: qla83xx_need_reset_handler(), has a one second msleep() in
a loop.
- qla_os.c: qla83xx_device_bootstrap(), called only by
qla83xx_idc_state_handler(), which has multiple msleep()
invocations.
- qla_os.c: qla83xx_idc_state_handler(), multiple msleep()
invocations.
- qla_attr.c: qla2x00_sysfs_write_reset(), sysfs bin_attribute
->write() hook, process context
- qla_init.c: qla83xx_nic_core_fw_load()
=> qla_init.c: qla2x00_initialize_adapter()
=> bound to isp_operations ->initialize_adapter() hook
** => qla_os.c: qla2x00_probe_one(), PCI ->probe() process ctx
- qla_init.c: qla83xx_initiating_reset(), msleep() in a loop.
- qla_init.c: qla83xx_nic_core_reset(), called by
qla83xx_nic_core_reset_work(), workqueue context.
Remove the in_interrupt() check, and thus replace the entirety of
qla83xx_wait_logic() with an msleep(QLA83XX_WAIT_LOGIC_MS).
Mark qla83xx_idc_lock() / unlock() with "Context: task, can sleep".
Link: https://lore.kernel.org/r/[email protected]
Cc: Nilesh Javali <[email protected]>
Cc: [email protected]
Reviewed-by: Himanshu Madhani <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
tcm_qla2xxx_free_session() has a BUG_ON(in_interrupt()).
While in_interrupt() is ill-defined and does not provide what the name
suggests, it is not needed here: the function is always invoked from
workqueue context through "struct qla_tgt_func_tmpl" ->free_session() hook
it is bound to.
The function also calls wait_event_timeout() down the chain, which already
has a might_sleep().
Remove the in_interrupt() check.
Link: https://lore.kernel.org/r/[email protected]
Cc: Nilesh Javali <[email protected]>
Cc: <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
qla82xx_idc_lock() spins on a certain hardware state until it's 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: qla82xx_idc_lock() is always called from
process context. Below is an analysis of its callers, in order of
appearance:
- qla_nx.c: qla82xx_device_bootstrap(), only called by
qla82xx_device_state_handler(), has multiple msleep()s.
- qla_nx.c: qla82xx_need_qsnt_handler(), has one second msleep()
- qla_nx.c: qla82xx_wait_for_state_change(), one second msleep()
- qla_nx.c: qla82xx_need_reset_handler(), can sleep up to 10 seconds
- qla_nx.c: qla82xx_device_state_handler(), has multiple msleep()s
- qla_nx.c: qla82xx_abort_isp(), if it's a qla82xx controller, calls
qla82xx_device_state_handler(), which sleeps. It's also bound to
isp_operations ->abort_isp() hook, where all the callers are in process
context.
- qla_nx.c: qla82xx_beacon_on(), bound to isp_operations ->beacon_on()
hook. That hook is only called once, in a mutex locked context, from
qla2x00_beacon_store().
- qla_nx.c: qla82xx_beacon_off(), bound to isp_operations ->beacon_off()
hook. Like ->beacon_on(), it's only called once, in a mutex locked
context, from qla2x00_beacon_store().
- qla_nx.c: qla82xx_fw_dump(), calls qla2x00_wait_for_chip_reset(), which
has msleep() in a loop. It is bound to isp_operations ->fw_dump()
hook. That hook *is* called from atomic context at qla_isr.c by
multiple interrupt handlers. Nonetheless, it's other controllers
interrupt handlers, and not the qla82xx.
- qla82xx_msix_default() and qla82xx_msix_rsp_q() call
qla24xx_process_response_queue() which doesn't implement the firmware
dumping.
- qla_attr.c: qla2x00_sysfs_write_fw_dump(), and
qla2x00_sysfs_write_reset(), process-context sysfs ->write() hooks.
- qla_os.c: qla2x00_probe_one(). PCI ->probe(), process context.
- qla_os.c: qla2x00_clear_drv_active(), called solely from
qla2x00_remove_one(), which is PCI ->remove() hook, process context.
- qla_os.c: qla2x00_do_dpc(), kthread function, process context.
Remove the in_interrupt() check. Change qla82xx_idc_lock() specification to
a purely process-context function. Mark it with "Context: task, might
sleep".
Change qla82xx_idc_lock() implementation to sleep 100ms, instead of a
schedule(), for each spin. This is more deterministic, and it matches the
other qla models idc_lock() functions.
Link: https://lore.kernel.org/r/[email protected]
Cc: Nilesh Javali <[email protected]>
Cc: <[email protected]>
Reviewed-by: Himanshu Madhani <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
qla4_82xx_crb_win_lock() spins on a certain hardware state until it's
updated. At the end of each spin, if in_interrupt() is true, it does 20
loops of cpu_relax(). Otherwise, it yields the CPU.
The in_interrupt() macro is ill-defined as it does not provide what the
name suggests, and it does not catch the intended use-case here.
qla4_82xx_crb_win_lock() is always invoked with scsi_qla_host::hw_lock
acquired, with disabled interrupts. If the caller is in process context, as
in qla4_82xx_need_reset_handler(), then in_interrupt() will return false
even though it is not allowed to call schedule().
Remove the in_interrupt() check.
Change qla4_82xx_crb_win_lock() specification to a purely atomic
function. Mark it as static, remove its forward declaration, and move it
above its callers. To avoid hammering the PCI bus while spinning, use a 10
micro-second delay instead of cpu_relax().
Link: https://lore.kernel.org/r/[email protected]
Fixes: f4f5df23bf72 ("[SCSI] qla4xxx: Added support for ISP82XX")
Cc: Nilesh Javali <[email protected]>
Cc: Manish Rangankar <[email protected]>
Cc: <[email protected]>
Reviewed-by: Daniel Wagner <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
hisi_sas_task_exec() uses preemptible() to see if it's safe to block. This
does not work for CONFIG_PREEMPT_COUNT=n kernels in which preemptible()
always returns 0.
The problem is masked when enabling some of the common Kconfig.debug
options (like CONFIG_DEBUG_ATOMIC_SLEEP), as they implicitly enable the
preemption counter.
In general, driver leaf functions should not make logic decisions based on
the context they're called from. The caller should be the entity
responsible for explicitly indicating context.
Since hisi_sas_task_exec() already has a gfp_t flags parameter, use it as
the explicit context marker.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 214e702d4b70 ("scsi: hisi_sas: Adjust task reject period during host reset")
Fixes: 550c0d89d52d ("scsi: hisi_sas: Replace in_softirq() check in hisi_sas_task_exec()")
Cc: Xiaofei Tan <[email protected]>
Cc: Xiang Chen <[email protected]>
Cc: John Garry <[email protected]>
Acked-by: John Garry <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
hw_event_sas_phy_up() is used in hardirq/softirq context:
pm8001_interrupt_handler_msix() || pm8001_interrupt_handler_intx() || pm8001_tasklet
=> PM8001_CHIP_DISP->isr() = pm80xx_chip_isr()
=> process_oq() [spin_lock_irqsave(&pm8001_ha->lock,)]
=> process_one_iomb()
=> mpi_hw_event()
=> hw_event_sas_phy_up()
=> msleep(200)
Revert the msleep() back to an mdelay() to avoid sleeping in atomic
context.
Link: https://lore.kernel.org/r/[email protected]
Fixes: 4daf1ef3c681 ("scsi: pm80xx: Convert 'long' mdelay to msleep")
Cc: Vikram Auradkar <[email protected]>
Cc: Jack Wang <[email protected]>
Acked-by: Jack Wang <[email protected]>
Signed-off-by: Ahmed S. Darwish <[email protected]>
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
In the case that auto_bkops_enable is false, which means auto bkops has
been disabled, there is no need to call ufshcd_disable_auto_bkops().
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Stanley Chu <[email protected]>
Reviewed-by: Can Guo <[email protected]>
Signed-off-by: Bean Huo <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Relocate all the debugfs code for DFX to v3 hw since no other versions
support it.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Luo Jiaxing <[email protected]>
Signed-off-by: John Garry <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Fix some rollbacks in function hisi_sas_v3_probe() and
interrupt_init_v3_hw().
Link: https://lore.kernel.org/r/[email protected]
Fixes: 8d98416a55eb ("scsi: hisi_sas: Switch v3 hw to MQ")
Signed-off-by: Xiang Chen <[email protected]>
Signed-off-by: John Garry <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Sometimes local functions are called indirectly from the hw driver, which
only makes the code harder to follow. Remove these.
Method .hw_init is only called from platform driver probe, which is not
relevant, so don't set this either.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: John Garry <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
There are two words that need separating with a space in a pm8001_dbg()
message. Fix it.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Ewan D. Milne <[email protected]>
Acked-by: Jack Wang <[email protected]>
Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
kernel robot reported a misindentation of a goto.
Fix it.
At the same time, use a temporary for a repeated entry in the same block to
reduce visual noise.
Link: https://lore.kernel.org/r/9542a8be9954c1dca744f93f53bb1af6dd1436e8.1606192458.git.joe@perches.com
Reported-by: kernel test robot <[email protected]>
Acked-by: Jack Wang <[email protected]>
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Use the more common logging style.
[mkp: fixed a few conflicts]
Link: https://lore.kernel.org/r/69dc34ff63adfa60b3f203ed2d58143b5692af57.1606192458.git.joe@perches.com
Acked-by: Jack Wang <[email protected]>
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in pmcraid_resume(), and
there is no corresponding pci_enable_wake(...., true) in pmcraid_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
pmcraid_resume().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
There is no "device" parameter in mvumi_shutdown(). Instead there is "pdev"
which is not described.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in mvumi_resume(), and there
is no corresponding pci_enable_wake(...., true) in mvumi_suspend(). Either
it should do enable-wake the device in .suspend() or should not invoke
pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
mvumi_resume().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in twl_resume(), and there is
no corresponding pci_enable_wake(...., true) in twl_suspend(). Either it
should do enable-wake the device in .suspend() or should not invoke
pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
twl_resume().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in twa_resume(), and there is
no corresponding pci_enable_wake(...., true) in twa_suspend(). Either it
should do enable-wake the device in .suspend() or should not invoke
pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
twa_resume().
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Don Brace <[email protected]>
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Don Brace <[email protected]>
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in pm8001_pci_resume(), and
there is no corresponding pci_enable_wake(...., true) in
pm8001_pci_suspend(). Either it should do enable-wake the device in
.suspend() or should not invoke pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
pm8001_pci__resume().
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Jack Wang <[email protected]>
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in scsih_resume(), and there
is no corresponding pci_enable_wake(...., true) in scsih_suspend(). Either
it should do enable-wake the device in .suspend() or should not invoke
pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
scsih_resume().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Both runtime_suspend_v3_hw() and runtime_resume_v3_hw() do nothing else but
invoke suspend_v3_hw() and resume_v3_hw() respectively. This is the case of
unnecessary function calls. To use those functions for runtime pm as well,
simply use UNIVERSAL_DEV_PM_OPS.
make -j$(nproc) W=1, with CONFIG_PM disabled, throws '-Wunused-function'
warning for runtime_suspend_v3_hw() and runtime_resume_v3_hw(). After
dropping those function definitions, the warning was thrown for
suspend_v3_hw() and resume_v3_hw(). Hence, mark them as '__maybe_unused'.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers using new-framework/generic-framework should not handle standard
power management operations. These operations were performed by legacy
framework through PCI helper functions like pci_save/restore_state(),
pci_set_power_state(), etc.
Drivers should not use them now.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in hisi_sas_v3_resume(), and
there is no corresponding pci_enable_wake(...., true) in
hisi_sas_v3_suspend(). Either it should do enable-wake the device in
.suspend() or should not invoke pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
hisi_sas_v3_resume().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
The driver calls pci_enable_wake(...., false) in esas2r_resume(), and there
is no corresponding pci_enable_wake(...., true) in esas2r_suspend().
Either it should do enable-wake the device in .suspend() or should not
invoke pci_enable_wake() at all.
Concluding that this driver doesn't support enable-wake and PCI core calls
pci_enable_wake(pci_dev, PCI_D0, false) during resume, drop it from
esas2r_resume().
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
Drivers should do only device-specific jobs. But in general, drivers using
legacy PCI PM framework for .suspend()/.resume() have to manage many PCI
PM-related tasks themselves which can be done by PCI Core itself. This
brings extra load on the driver and it directly calls PCI helper functions
to handle them.
Switch to the new generic framework by updating function signatures and
define a "struct dev_pm_ops" variable to bind PM callbacks. Also, remove
unnecessary calls to the PCI Helper functions along with the legacy
.suspend & .resume bindings.
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vaibhav Gupta <[email protected]>
Signed-off-by: Martin K. Petersen <[email protected]>
|