- 23 Jan, 2021 33 commits
-
-
Hannes Reinecke authored
Add the missing 'set_status_byte()' accessor function. Link: https://lore.kernel.org/r/20210113090500.129644-28-hare@suse.deReviewed-by:
Benjamin Block <bblock@linux.ibm.com> Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hannes Reinecke authored
Change the error code for an invalid SCSI opcode to DID_ERROR. INITIATOR_ERROR is a scsi parallel message which doesn't apply for RAID HBAs. Link: https://lore.kernel.org/r/20210113090500.129644-27-hare@suse.deReviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Hannes Reinecke authored
CMD_ACCEPT_MSG is an internal definition and most certainly not a SCSI status. As the latter gets set during command completion we can drop the assignment here. Link: https://lore.kernel.org/r/20210113090500.129644-26-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Use standard definitions for SCSI commands and return status instead of the hardcoded values. Link: https://lore.kernel.org/r/20210113090500.129644-25-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
COMMAND_COMPLETE is defined as '0', so setting it is quite pointless. Link: https://lore.kernel.org/r/20210113090500.129644-24-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
COMMAND_COMPLETE is defined as '0', so setting it is quite pointless. Link: https://lore.kernel.org/r/20210113090500.129644-23-hare@suse.deReviewed-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Hannes Reinecke authored
Use the standard SCSI message definitions instead of the driver-internal ones. Link: https://lore.kernel.org/r/20210113090500.129644-22-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Drop the internal SCSI message definitions and use the functions provided by the SPI transport class. Link: https://lore.kernel.org/r/20210113090500.129644-21-hare@suse.deReported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
-
Hannes Reinecke authored
Use the standard SCSI message definitions instead of the driver-internal ones. Link: https://lore.kernel.org/r/20210113090500.129644-20-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Use the standard SCSI message definitions instead of the driver-internal ones. Link: https://lore.kernel.org/r/20210113090500.129644-19-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
COMMAND_COMPLETE is defined as '0', so setting it is quite pointless. Link: https://lore.kernel.org/r/20210113090500.129644-18-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
COMMAND_COMPLETE is defined as '0', and it is a SCSI parallel message to boot. Drop the call to set_msg_byte(). Link: https://lore.kernel.org/r/20210113090500.129644-17-hare@suse.deReviewed-by:
Don Brace <don.brace@microchip.com> Signed-off-by:
-
Hannes Reinecke authored
The aacraid controller is a RAID controller and the driver will never see any SCSI messages. Plus it's quite pointless to set the message byte if the host byte is already set, as the latter takes precedence during error recovery. Drop the message byte values for the final result. Link: https://lore.kernel.org/r/20210113090500.129644-16-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
COMMAND_COMPLETE is defined as '0', and it is a SCSI parallel message to boot. So drop the call to set_msg_byte(). Link: https://lore.kernel.org/r/20210113090500.129644-15-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Use standard SAM status definitions and drop the driver-defined ones. Link: https://lore.kernel.org/r/20210113090500.129644-14-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
We don't need to duplicate definitions from the common include files. Link: https://lore.kernel.org/r/20210113090500.129644-13-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
SCp.status is always the SAM-defined status value, not the Linux ones. Fixup the one wrong definition. Link: https://lore.kernel.org/r/20210113090500.129644-12-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Use midlayer-defined values and drop the non-existing QUEUE_FULL case; we are checking the SCSI messages in the switch statement, and QUEUE_FULL is a SCSI status hence it can never occur here. Link: https://lore.kernel.org/r/20210113090500.129644-11-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Drop the driver-defined SCSI status codes and use the generic ones instead. Link: https://lore.kernel.org/r/20210113090500.129644-10-hare@suse.deReviewed-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
-
Hannes Reinecke authored
Replace the driver-defined SAM status definitions with the standard mid-layer defined ones. Link: https://lore.kernel.org/r/20210113090500.129644-9-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Link: https://lore.kernel.org/r/20210113090500.129644-8-hare@suse.deReviewed-by:
-
Hannes Reinecke authored
Link: https://lore.kernel.org/r/20210113090500.129644-7-hare@suse.deSigned-off-by:
-
Hannes Reinecke authored
Link: https://lore.kernel.org/r/20210113090500.129644-6-hare@suse.deSigned-off-by:
-
Hannes Reinecke authored
Link: https://lore.kernel.org/r/20210113090500.129644-5-hare@suse.deSigned-off-by:
-
Hannes Reinecke authored
Link: https://lore.kernel.org/r/20210113090500.129644-4-hare@suse.deSigned-off-by:
-
Hannes Reinecke authored
Link: https://lore.kernel.org/r/20210113090500.129644-3-hare@suse.deSigned-off-by:
-
Hannes Reinecke authored
The gdth driver refers to a SCSI parallel, PCI-only HBA RAID adapter which was manufactured by the now-defunct ICP Vortex company, later acquired by Adaptec and superseded by the aacraid series of controllers. The driver itself would require a major overhaul before any modifications can be attempted, but seeing that it's unlikely to have any users left it should rather be removed completely. Link: https://lore.kernel.org/r/20210113090500.129644-2-hare@suse.deCautiously-Acked-by:
-
Ahmed S. Darwish authored
transport_handle_cdb_direct() uses in_interrupt() to detect if it is safe to sleep. It produces a stack trace and returns with an error which is clearly for debugging. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. transport_handle_cdb_direct() has a comment saying that it may only be invoked from process context. It invokes transport_generic_new_cmd() which performs GFP_KERNEL memory allocations. in_interrupt() does not detect all the contexts where it is invalid to sleep (for the blocking GFP_KERNEL allocation) as it fails to detect sections with disabled preemption. Replace the in_interrupt() based check with a might_sleep() annotation. Link: https://lore.kernel.org/r/20201220203638.43615-7-bigeasy@linutronix.deSigned-off-by:
Ahmed S. Darwish <a.darwish@linutronix.de> Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
Sebastian Andrzej Siewior authored
target_submit_cmd_map_sgls() uses in_interrupt() to crash if it returns true. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. The usage of in_interrupt() is clearly for debugging. might_sleep() is better at this because it also detects other contexts in which it is not allowed to sleep, like preempt-disabled section. Replace BUG_ON(in_interrupt) with might_sleep(). Link: https://lore.kernel.org/r/20201220203638.43615-6-bigeasy@linutronix.deSigned-off-by:
-
Sebastian Andrzej Siewior authored
core_alua_check_nonop_delay() uses in_interrupt() to decide if it is safe to sleep. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. core_alua_check_nonop_delay() has two callers: - target_submit_cmd_map_sgls() Kernel doc says it that it must be called from process context. Also has a BUG_ON(in_interrupt()). - iscsit_setup_scsi_cmd() Invokes iscsit_add_reject_cmd() which does GFP_KERNEL allocation and target_cmd_init_cdb() which may do GFP_KERNEL allocations. Remove the in_interrupt() check because all callers are from preemptible context. Link: https://lore.kernel.org/r/20201220203638.43615-5-bigeasy@linutronix.deSigned-off-by:
-
Sebastian Andrzej Siewior authored
The return value of iscsit_check_session_usage_count() is only checked if it was not allowed to sleep. If it returns `2' then a timer is prepared. If it returns something else or if it was allowed to sleep then it is ignored. Let iscsit_check_session_usage_count() return true if it needs to arm the timer - otherwise false. This simplifies the code flow of the only caller. Link: https://lore.kernel.org/r/20201220203638.43615-4-bigeasy@linutronix.deSigned-off-by:
-
Sebastian Andrzej Siewior authored
iscsit_check_session_usage_count() uses in_interrupt() to find out if it is safe to invoke wait_for_completion(). The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. There is only one caller of iscsit_check_session_usage_count() which already has an argument indicating if it is safe to sleep. Extend iscsit_check_session_usage_count() by an argument indicating if it may sleep. Link: https://lore.kernel.org/r/20201220203638.43615-3-bigeasy@linutronix.deSigned-off-by:
-
Sebastian Andrzej Siewior authored
iscsit_close_session() uses in_interrupt() to decide if it needs to check the return value of iscsit_check_session_usage_count() if it was not able to sleep. The usage of in_interrupt() in drivers is phased out and Linus clearly requested that code which changes behaviour depending on context should either be separated or the context be conveyed in an argument passed by the caller, which usually knows the context. iscsit_close_session() has two callers: - iscsit_handle_time2retain_timeout() A timer_list callback. - iscsit_close_connection() Runs in preemptible context, acquires a mutex. Add an argument to iscsit_close_session() indicating if sleeping is possible. Link: https://lore.kernel.org/r/20201220203638.43615-2-bigeasy@linutronix.deSigned-off-by:
-
- 21 Jan, 2021 7 commits
-
-
Stanley Chu authored
Manipulate clock scaling related stuff only if the host capability supports clock scaling feature to avoid redundant code execution. Link: https://lore.kernel.org/r/20210120150142.5049-4-stanley.chu@mediatek.comReviewed-by:
Can Guo <cang@codeaurora.org> Signed-off-by:
Stanley Chu <stanley.chu@mediatek.com> Signed-off-by:
-
Stanley Chu authored
hba->devfreq is zero-initialized thus it is not required to check its existence in ufshcd_add_lus() function which is invoked during initialization only. Link: https://lore.kernel.org/r/20210120150142.5049-3-stanley.chu@mediatek.comReviewed-by:
-
Stanley Chu authored
Cancelling suspend_work and resume_work is only required while suspending clk-scaling. Move these two invocations into ufshcd_suspend_clkscaling() function. Link: https://lore.kernel.org/r/20210120150142.5049-2-stanley.chu@mediatek.comReviewed-by:
-
Can Guo authored
Commit 73cc291c ("scsi: ufs: Make sure clk scaling happens only when HBA is runtime ACTIVE") is no longer needed since commit 0e9d4ca4 ("scsi: ufs: Protect some contexts from unexpected clock scaling") is a more mature fix to protect UFS LLD stability from clock scaling invoked through sysfs nodes by users. Link: https://lore.kernel.org/r/1611137065-14266-4-git-send-email-cang@codeaurora.orgReviewed-by:
-
Can Guo authored
ufshcd_hba_exit() is always called after ufshcd_exit_clk_scaling() and ufshcd_exit_clk_gating(). Move ufshcd_exit_clk_scaling/gating() to ufshcd_hba_exit(). Meanwhile, add dedicated functions to initialize and remove sysfs nodes of clock scaling/gating to make the code more readable. Overall functionality remains same. Link: https://lore.kernel.org/r/1611137065-14266-3-git-send-email-cang@codeaurora.orgReviewed-by:
-
Can Guo authored
In contexts like suspend, shutdown, and error handling we need to suspend devfreq to make sure these contexts won't be disturbed by clock scaling. However, suspending devfreq is not enough since users can still trigger a clock scaling by manipulating the devfreq sysfs nodes like min/max_freq and governor even after devfreq is suspended. Moreover, mere suspending devfreq cannot synchroinze a clock scaling which has already been invoked through these sysfs nodes. Add one more flag in struct clk_scaling and wrap the entire func ufshcd_devfreq_scale() with the clk_scaling_lock, so that we can use this flag and clk_scaling_lock to control and synchronize clock scaling invoked through devfreq sysfs nodes. Link: https://lore.kernel.org/r/1611137065-14266-2-git-send-email-cang@codeaurora.orgReviewed-by:
-
Bean Huo authored
UFS device-related flags should be grouped in ufs_dev_info. Move wb_enabled and wb_buf_flush_enabled out from struct ufs_hba, group them in struct ufs_dev_info, and align the names of the structure members vertically. Link: https://lore.kernel.org/r/20210119163847.20165-6-huobean@gmail.comReviewed-by:
Bean Huo <beanhuo@micron.com> Signed-off-by:
-
