- 11 Jan, 2018 21 commits
-
-
Douglas Gilbert authored
Various cdb masks incorrectly assumed the GROUP NUMBER field was 5 bits long. It is actually 6 bits long. Correct. Also fix mask failure (in same byte) to allow DLD0 in READ(16) and WRITE(16). Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Reviewed-by:
Bart Van Assche <bart.vanassche@wdc.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Douglas Gilbert authored
Some of my development tools tend to add spaces (my preference) rather than tabs (kernel convention). Running unexpand to clean these spaces up found more of them than checkpatch.pl did. Then checkpatch.pl complained about other style violations in those newly tabbed lines. Signed-off-by:
-
Suganath Prabu Subramani authored
Performance improvement using block layer tag. Curent driver gets scsiio tracker and free smid from link list and array based tracking managed by driver. Accessing list in main io path is performance pentaly because of protection using spinlock "scsi_lookup_lock". In this patch: 1. Driver removes all link list access from main io path and use scmd->request->tag to get free smid. 2. Instead of holding 'struct scsiio_tracker' in its own pool driver can embed it into the scsi command. Driver provides cmd_size in scsi_host_template, so that struct scsiio_tracker is preallocated by scsi mid layer for each scsi command. Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Hannes Reinecke authored
Use 'host_busy' instead of counting outstanding commands by hand. Signed-off-by:
-
Hannes Reinecke authored
Move the check for outstanding commands out of the function allowing us to simplify the overall code. Signed-off-by:
-
Hannes Reinecke authored
No functional change. Code optimization. One can simply check 'target_busy' or 'device_busy' when figuring out if there are outstanding commands; no need to painstakingly count them by hand. [mkp: tweaked patch description] Signed-off-by:
-
Hannes Reinecke authored
ioctl passthrough commands require a SCSIIO smid, but cannot easily integrate with the block layer. But the driver already has reserved some SCSIIO smids and we're only ever allowing one ioctl command at a time we can use the first reserved smid for ioctl commands. Signed-off-by:
-
Hannes Reinecke authored
When attempting a command abort we should check the command status prior to sending the abort; the command might've been completed already. Signed-off-by:
-
Hannes Reinecke authored
Abstract accesses to the scsi_lookup array by introducing mpt3sas_get_st_from_smid(). Signed-off-by:
-
Hannes Reinecke authored
Just a wrapper around the scsi lookup array and only used in one place, so open-code it. Signed-off-by:
-
Hannes Reinecke authored
No functional change. Signed-off-by:
-
Hannes Reinecke authored
Use 'list_splice_init()' instead of hand-crafted function. No functional change. Signed-off-by:
-
Hannes Reinecke authored
No functional change Signed-off-by:
-
Matthew R. Ochs authored
As staging to support future accelerator transports, add a shim layer such that the underlying services the cxlflash driver requires can be conditional upon the accelerator infrastructure. Signed-off-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
-
Uma Krishnan authored
Adapter context creation can return either NULL or an error pointer. Updating the check condition to reflect this. Signed-off-by:
-
Matthew R. Ochs authored
The CXL-specific work structure used to request the number of interrupts currently resides as a nested member of both the context information and hardware queue structures. It is used to cache values (specifically the number of interrupts) required by the CXL layer when starting a context. To facilitate staging that will ultimately allow the cxlflash core to become agnostic of the underlying accelerator transport, remove these embedded work structures. Signed-off-by:
-
Matthew R. Ochs authored
The number of interrupts a user requests during a context attach is presently stored within the CXL work ioctl structure that is nested alongside the per context metadata. Keeping this data in a structure that is tied to a particular hardware implementation (CXL) will only complicate matters when supporting newer accelerator transports. Instead of relying upon the number of interrupts being cached within a CXL-specific structure, explicitly cache the value within the context information structure. Signed-off-by:
-
Uma Krishnan authored
Convert cxl-specific pointers to generic cookies to facilitate future enhancements. Signed-off-by:
-
Uma Krishnan authored
In the event of a command failure, cxlflash returns the failure to the upper layers to process. After processing the error, when the command is queued again, the private command structure will not be zeroed and the ioasc could be stale. Per the SISLite specification, the AFU only sets the ioasc in the presence of a failure. Thus, even though the original command succeeds the second time, the command is considered a failure due to stale ioasc. This cycle repeats indefinitely and can cause a hang or IO failure. To fix the issue, clear the ioasc before queuing any command. [mkp: added Cc: stable per request] Fixes: 479ad8e9 ("scsi: cxlflash: Remove zeroing of private command data") Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jason Yan authored
There are two places queuing the disco event DISCE_REVALIDATE_DOMAIN. One is in sas_porte_broadcast_rcvd() and uses sas_chain_event() to queue the event. The other is in sas_enable_revalidation() and uses sas_queue_event() to queue the event. We have diffrent work queues for event and discovery now, so the DISCE_REVALIDATE_DOMAIN event may be processed in both event queue and discovery queue. Now since we do synchronous event handling, we cannot do it in discovery queue, so have to trigger a fake broadcast event to re-trigger the revalidation from event queue. Signed-off-by:
Jason Yan <yanaijie@huawei.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> Reviewed-by:
-
Jason Yan authored
In commit 87c8331f ("[SCSI] libsas: prevent domain rediscovery competing with ata error handling") introduced disco mutex to prevent rediscovery competing with ata error handling and put the whole revalidation in the mutex. But the rphy add/remove needs to wait for the error handling which also grabs the disco mutex. This may leads to dead lock.So the probe and destruct event were introduce to do the rphy add/remove asynchronously and out of the lock. The asynchronously processed workers makes the whole discovery process not atomic, the other events may interrupt the process. For example, if a loss of signal event inserted before the probe event, the sas_deform_port() is called and the port will be deleted. And sas_port_delete() may run before the destruct event, but the port-x:x is the top parent of end device or expander. This leads to a kernel WARNING such as: [ 82.042979] sysfs group 'power' not found for kobject 'phy-1:0:22' [ 82.042983] ------------[ cut here ]------------ [ 82.042986] WARNING: CPU: 54 PID: 1714 at fs/sysfs/group.c:237 sysfs_remove_group+0x94/0xa0 [ 82.043059] Call trace: [ 82.043082] [<ffff0000082e7624>] sysfs_remove_group+0x94/0xa0 [ 82.043085] [<ffff00000864e320>] dpm_sysfs_remove+0x60/0x70 [ 82.043086] [<ffff00000863ee10>] device_del+0x138/0x308 [ 82.043089] [<ffff00000869a2d0>] sas_phy_delete+0x38/0x60 [ 82.043091] [<ffff00000869a86c>] do_sas_phy_delete+0x6c/0x80 [ 82.043093] [<ffff00000863dc20>] device_for_each_child+0x58/0xa0 [ 82.043095] [<ffff000008696f80>] sas_remove_children+0x40/0x50 [ 82.043100] [<ffff00000869d1bc>] sas_destruct_devices+0x64/0xa0 [ 82.043102] [<ffff0000080e93bc>] process_one_work+0x1fc/0x4b0 [ 82.043104] [<ffff0000080e96c0>] worker_thread+0x50/0x490 [ 82.043105] [<ffff0000080f0364>] kthread+0xfc/0x128 [ 82.043107] [<ffff0000080836c0>] ret_from_fork+0x10/0x50 Make probe and destruct a direct call in the disco and revalidate function, but put them outside the lock. The whole discovery or revalidate won't be interrupted by other events. And the DISCE_PROBE and DISCE_DESTRUCT event are deleted as a result of the direct call. Introduce a new list to destruct the sas_port and put the port delete after the destruct. This makes sure the right order of destroying the sysfs kobject and fix the warning above. In sas_ex_revalidate_domain() have a loop to find all broadcasted device, and sometimes we have a chance to find the same expander twice. Because the sas_port will be deleted at the end of the whole revalidate process, sas_port with the same name cannot be added before this. Otherwise the sysfs will complain of creating duplicate filename. Since the LLDD will send broadcast for every device change, we can only process one expander's revalidation. [mkp: kbuild test robot warning] Signed-off-by:
-
- 09 Jan, 2018 11 commits
-
-
Jason Yan authored
Now we are processing sas event and discover event in different workqueues. It's safe to wait the discover event done in the sas event work. Use flush_workqueue() to insure the disco and revalidate events processed synchronously so that the whole discover and revalidate process will not be interrupted by other events. Signed-off-by:
-
Jason Yan authored
Now all libsas works are queued to scsi host workqueue, include sas event work post by LLDD and sas discovery work, and a sas hotplug flow may be divided into several works, e.g libsas receive a PORTE_BYTES_DMAED event, currently we process it as following steps: sas_form_port --- run in work in shost workq sas_discover_domain --- run in another work in shost workq ... sas_probe_devices --- run in new work in shost workq We found during hot-add a device, libsas may need run several works in same workqueue to add device in system, the process is not atomic, it may interrupt by other sas event works, like PHYE_LOSS_OF_SIGNAL. This patch is preparation of execute libsas sas event in sync. We need to use different workqueue to run sas event and disco event. Otherwise the work will be blocked for waiting another chained work in the same workqueue. Signed-off-by:
Yijing Wang <wangyijing@huawei.com> CC: John Garry <john.garry@huawei.com> CC: Johannes Thumshirn <jthumshirn@suse.de> CC: Ewan Milne <emilne@redhat.com> CC: Christoph Hellwig <hch@lst.de> CC: Tomas Henzl <thenzl@redhat.com> CC: Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Jason Yan authored
Add a sysfs attr that LLDD can configure it for every host. We made an example in hisi_sas. Other LLDDs using libsas can implement it if they want. Suggested-by:
-
Jason Yan authored
If the PHY burst too many events, we will alloc a lot of events for the worker. This may leads to memory exhaustion. Dan Williams suggested to shut down the PHY if the events reached the threshold, because in this case the PHY may have gone into some erroneous state. Users can re-enable the PHY by sysfs if they want. We cannot use the fixed memory pool because if we run out of events, the shut down event and loss of signal event will lost too. The events still need to be allocated and processed in this case. Suggested-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Jason Yan authored
Now libsas hotplug work is static, every sas event type has its own static work, LLDD driver queues the hotplug work into shost->work_q. If LLDD driver burst posts lots hotplug events to libsas, the hotplug events may pending in the workqueue like shost->work_q new work[PORTE_BYTES_DMAED] --> |[PHYE_LOSS_OF_SIGNAL][PORTE_BYTES_DMAED] -> processing |<-------wait worker to process-------->| In this case, a new PORTE_BYTES_DMAED event coming, libsas try to queue it to shost->work_q, but this work is already pending, so it would be lost. Finally, libsas delete the related sas port and sas devices, but LLDD driver expect libsas add the sas port and devices(last sas event). This patch use dynamic allocated work to avoid this issue. Signed-off-by: -
Xiongfeng Wang authored
gcc-8 reports drivers/message/fusion/mptbase.c: In function 'mpt_display_event_info': ./include/linux/string.h:245:9: warning: '__builtin_strncpy' specified bound 100 equals destination size [-Wstringop-truncation] We need to use strlcpy() to make sure the dest string is nul-terminated. Signed-off-by:
Xiongfeng Wang <xiongfeng.wang@linaro.org> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Colin Ian King authored
A previous commit no longer stores the contents of c, so we now have a situation where c is being updated but the value is never read. Clean up the code by removing the now redundant setting of variable c. Cleans up clang warning: drivers/scsi/aacraid/aachba.c:943:3: warning: Value stored to 'c' is never read Fixes: f4e8708d ("scsi: aacraid: Fix udev inquiry race condition") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
-
Varun Prakash authored
For mgmt cmds ->alloc_pdu() can be called from atomic context so use GFP_ATOMIC instead of GFP_KERNEL. Signed-off-by:
Varun Prakash <varun@chelsio.com> Signed-off-by:
-
chenxiang authored
The status of SAS PHY is in sas_phy->enabled. There is an issue that the status of a remote SAS PHY may be initialized incorrectly: if disable remote SAS PHY through sysfs interface (such as echo 0 > /sys/class/sas_phy/phy-1:0:0/enable), then reboot the system, and we will find the status of remote SAS PHY which is disabled before is 1 (cat /sys/class/sas_phy/phy-1:0:0/enable). But actually the status of remote SAS PHY is disabled and the device attached is not found. In SAS protocol, NEGOTIATED LOGICAL LINK RATE field of DISCOVER response is 0x1 when remote SAS PHY is disabled. So initialize sas_phy->enabled according to the value of NEGOTIATED LOGICAL LINK RATE field. Signed-off-by:
chenxiang <chenxiang66@hisilicon.com> Reviewed-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
-
Jason Yan authored
The intend purpose here was to goto out if smp_execute_task() returned error. Obviously something got screwed up. We will never get these link error statistics below: ~:/sys/class/sas_phy/phy-1:0:12 # cat invalid_dword_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat running_disparity_error_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat loss_of_dword_sync_count 0 ~:/sys/class/sas_phy/phy-1:0:12 # cat phy_reset_problem_count 0 Obviously we should goto error handler if smp_execute_task() returns non-zero. Fixes: 2908d778 ("[SCSI] aic94xx: new driver") Signed-off-by:
-
Jason Yan authored
We've got a memory leak with the following producer: while true; do cat /sys/class/sas_phy/phy-1:0:12/invalid_dword_count >/dev/null; done The buffer req is allocated and not freed after we return. Fix it. Fixes: 2908d778 ("[SCSI] aic94xx: new driver") Signed-off-by:
-
- 08 Jan, 2018 1 commit
-
-
Andy Shevchenko authored
Using this extension reduces the object size. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
- 04 Jan, 2018 7 commits
-
-
Himanshu Jha authored
Use dma_zalloc_coherent instead of dma_alloc_coherent followed by memset 0. Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci Suggested-by:
Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by:
Himanshu Jha <himanshujha199640@gmail.com> Acked-by:
Manish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by:
-
Himanshu Jha authored
Use vzalloc instead of vmalloc followed by memset 0. Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci Suggested-by:
Anil Gurumurthy <anil.gurumurthy@cavium.com> Signed-off-by:
-
Himanshu Jha authored
Use dma_zalloc_coherent and vzalloc instead of dma_alloc_coherent and vmalloc respectively, followed by memset 0. Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci Suggested-by:
Himanshu Madhani <himanshu.madhani@cavium.com> Signed-off-by:
-
Himanshu Jha authored
Use dma_zalloc_coherent instead of dma_alloc_coherent followed by memset 0. Generated-by: scripts/coccinelle/api/alloc/kzalloc-simple.cocci Suggested-by:
-
Meelis Roos authored
The battery in my HP NetRAID-4M died of old age, and the aacraid driver started oopsing with NULL pointer dereference on startup after that. Fix it by reordering the init sequence to fill in function pointers before ioremapping memory, or dev->a_ops.adapter_ioremap pointer will be NULL. Other subtypes of aacraid seem to have the order already correct. This was the call trace: ? aac_probe_one+0x7a5/0xb30 [aacraid] pci_device_probe+0xc0/0x1a0 driver_probe_device+0x1df/0x3b0 __driver_attach+0xa9/0xe0 ? driver_probe_device+0x3b0/0x3b0 bus_for_each_dev+0x4c/0x90 driver_attach+0x1d/0x40 ? driver_probe_device+0x3b0/0x3b0 bus_add_driver+0x1a7/0x2a0 driver_register+0x6e/0x130 __pci_register_driver+0x54/0x90 ? 0xf81f4000 aac_init+0x2b/0x1000 [aacraid] do_one_initcall+0x45/0x1e0 ? kfree_skbmem+0x74/0xa0 ? kfree+0x16d/0x240 ? kvfree+0x45/0x50 ? kvfree+0x45/0x50 ? __vunmap+0x99/0x120 ? do_init_module+0x1a/0x245 do_init_module+0x83/0x245 load_module+0x2764/0x34a0 ? kernel_read_file+0x150/0x320 SyS_finit_module+0x82/0xa0 do_fast_syscall_32+0xba/0x340 Signed-off-by:
Meelis Roos <mroos@linux.ee> Reviewed-by:
-
himanshu.madhani@cavium.com authored
Signed-off-by:
-
Quinn Tran authored
Add free_pending flag to serialize queueing of free_work element onto the work queue Signed-off-by:
Quinn Tran <quinn.tran@cavium.com> Signed-off-by:
-
