- 15 Jul, 2016 6 commits
-
-
Dan Carpenter authored
My static checker complains that we need to unlock on this path. Seems true. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Brian King <brking@linux.vnet.ibm.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Hans de Goede authored
Oliver Neukum is taking over uas maintainership from me and Gerd Hoffmann. Cc: Oliver Neukum <oneukum@suse.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Oliver Neukum <oneukum@suse.com> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
We've had scsi-mq for 2.5 years now, so we can remove the unused flag to disable the code on a per-host basis that was put in for unexpected emergencies during bringup. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Manjunath M B authored
The code was checking on PA_CONNECTEDRXLANES and PA_CONNECTEDTXLANES attributes to program the Lane#1 attributes. The correct attributes are PA_AVAILRXDATALANES and PA_AVAILTXDATALANES respectively. Signed-off-by:
Manjunath M B <manjumb@synopsys.com> Tested-by:
Joao Pinto <jpinto@synopsys.com> Signed-off-by:
-
Kefeng Wang authored
The _scsih_pci_mmio_enabled called if scsih_pci_error_detected returns PCI_ERS_RESULT_CAN_RECOVER, at this point, read/write to the device still works, no need to reset slot. Or the mpt3sas_base_map_resources in scsih_pci_slot_reset will fail, and iounamp ioc->chip, then we will meet issue when read ioc->chip in mpt3sas_base_get_iocstate from _base_fault_reset_work. Cc: Sathya Prakash <sathya.prakash@broadcom.com> Cc: Chaitra P B <chaitra.basappa@broadcom.com> Cc: Suganath Prabu Subramani <suganath-prabu.subramani@broadcom.com> Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Acked-by:
Chaitra P B <chaitra.basappa@broadcom.com> Signed-off-by:
-
Johannes Thumshirn authored
qla2xxx first calls request_irq() and then does the setup of the queue entry data needed in the interrupt handlers in when using MSI-X. This could lead to a NULL pointer dereference when an IRQ fires between the request_irq() call and the assignment of the qentry data structure to the rsp->msix field. A possible case for such a race would be in the kdump case when the HBA's IRQs are still enabled but the driver is undergoing a new initialisation and thus is not aware of already activated IRQs in the HBA. Signed-off-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Himanshu Madhani <himanshu.madhani@qlogic.com> Signed-off-by:
-
- 14 Jul, 2016 10 commits
-
-
Wen Xiong authored
Increase MSIX vectors from 2 to 16 by default. Signed-off-by:
Wen Xiong <wenxiong@linux.vnet.ibm.com> Reviewed-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Acked-by:
-
Wen Xiong authored
Add the appropriate definitions and table entries for new adapters support. Signed-off-by:
-
Christoph Hellwig authored
The field is only used by the 53c700 driver, so move it into the driver-private device data instead of having it in the common structure. Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Reviewed-by:
-
Sumit Saxena authored
There was an issue reported by Lucz Geza on Dell Perc 6i. As per issue reported, megaraid_sas driver goes into an infinite error reporting loop as soon as there is a change in the status of one of the arrays (degrade, resync online etc ). Below are the error logs reported continuously- Jun 25 08:49:30 ns8 kernel: [ 757.757017] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.778017] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.799017] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.820018] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 Jun 25 08:49:30 ns8 kernel: [ 757.841018] megaraid_sas 0000:02:00.0: DCMD failed/not supported by firmware: megasas_get_pd_list 4115 This issue is very much specific to controllers which do not support DCMD- MR_DCMD_PD_LIST_QUERY. In case of any hotplugging/rescanning of drives, AEN thread will be scheduled by driver and fire DCMD- MR_DCMD_PD_LIST_QUERY and if this DCMD is failed then driver will fail this event processing and will not go ahead for further events. This will cause infinite loop of same event getting retried infinitely and causing above mentioned logs. Fix for this problem is: not to fire DCMD MR_DCMD_PD_LIST_QUERY for controllers which do not support it and send DCMD SUCCESS status to AEN function so that it can go ahead with other event processing. Reported-by:
Lucz Geza <geza@lucz.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Reviewed-by:
-
Johannes Thumshirn authored
Use defines from ethtool for 20Gbit and 40Gbit speeds instead of magic numbers. Signed-off-by:
Laurence Oberman <loberman@redhat.com> Signed-off-by:
-
Hannes Reinecke authored
When the FIP mode is changed we need to update the multicast addresses to ensure we get the correct frames. Signed-off-by:
Johannes Thumshirn <jth@kernel.org> Signed-off-by:
-
Hannes Reinecke authored
'->realdev' is always set, so this check is pointless. Signed-off-by:
-
Hannes Reinecke authored
The FIP mode is independent on the FIP state machine, so use a separate enum for that instead of overloading it with state machine values. Signed-off-by:
-
Hannes Reinecke authored
Update to latest FC-BB-6 draft to include FIP VN2VN VLAN notifications and additional flags. Signed-off-by:
-
Chris Leech authored
In the receive path libfc extracts a cpu number from the ox_id in the fiber channel header and uses that to do a per_cpu_ptr conversion. If, for some reason, a frame is received with an invalid ox_id, per_cpu_ptr will return an invalid pointer and the libfc receive path will panic the system trying to use it. I'm currently looking at such a case, and I don't yet know why a cpu number > nr_cpu_ids is appearing in an exchange id. But adding a sanity check in libfc prevents a system panic, and seems like good idea when dealing with frames coming in from the network. Signed-off-by:
Chris Leech <cleech@redhat.com> Acked-by:
-
- 13 Jul, 2016 24 commits
-
-
Sebastian Andrzej Siewior authored
The driver creates its own per-CPU threads which are updated based on CPU hotplug events. It is also possible to use kworkers and remove some of the kthread infrastrucure. The code checked ->thread to decide if there is an active per-CPU thread. By using the kworker infrastructure this is no longer possible (or required). The thread pointer is saved in `kthread' instead of `thread' so anything trying to use thread is caught by the compiler. Currently only the bnx2fc driver is using struct fcoe_percpu_s and the kthread member. After a CPU went offline, we may still enqueue items on the "offline" CPU. This isn't much of a problem. The work will be done on a random CPU. The allocated crc_eof_page page won't be cleaned up. It is probably expected that the CPU comes up at some point so it should not be a problem. The crc_eof_page memory is released of course once the module is removed. This patch was only compile-tested due to -ENODEV. Cc: Vasu Dev <vasu.dev@intel.com> Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Christoph Hellwig <hch@lst.de> Cc: fcoe-devel@open-fcoe.org Cc: linux-scsi@vger.kernel.org Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by:
-
Johannes Thumshirn authored
Vasu is going to resign from his maintainer role and I'll take over. Signed-off-by:
Vasu Dev <vasu.dev@intel.com> Signed-off-by:
-
Johannes Thumshirn authored
If there is a dma mapping error snic kfree()s buf right before printing it. Change the order to not accidently trip on memory that's not owned by us anymore. Signed-off-by:
Narsimhulu Musini <nmusini@cisco.com> Reviewed-by:
-
Arnd Bergmann authored
Enabling format checking in dprintk() shows that wd7000_biosparam uses an incorrect format string for sector_t: drivers/scsi/wd7000.c: In function 'wd7000_biosparam': drivers/scsi/wd7000.c:1594:21: error: format '%d' expects argument of type 'int', but argument 3 has type 'sector_t {aka long long unsigned int}' [-Werror=format=] As sector_t can be 32-bit wide, this adds a cast to 'u64' and prints that with the correct format. The change to use no_printk() generally helps with finding this kind of hidden format string bug, and I found that when building with "-Wextra", which warned about an empty else clause in } else dprintk("ok!\n"); Signed-off-by:Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Arnd Bergmann authored
The fc_get_host_stats() function contains a complex conversion from jiffies to timespec to seconds. As we try to get rid of uses of struct timespec, we can clean this up and replace it with a simpler computation. Simply dividing the difference in jiffies by HZ is not only much more efficient, it also avoids a problem that causes the seconds_since_last_reset value to be incorrect if jiffies has overrun since the 'boot_time' value was recorded. Signed-off-by:
-
Helge Deller authored
When enabling the debug options NCR_700_DEBUG and NCR_700_TAG_DEBUG various printk format warnings can be seen like: drivers/scsi/53c700.c:357:2: warning: format %p expects argument of type void * , but argument 4 has type dma_addr_t [-Wformat=] script_patch_32(hostdata->dev, script, MessageLocation, Fix them by using the right printk format specifiers. Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Jim Gill authored
[mkp: Updated MAINTAINERS] Signed-off-by:
Jim Gill <jgill@vmware.com> Acked-by:
Arvind Kumar <arvindkumar@vmware.com> Signed-off-by:
-
Uma Krishnan authored
Some CXL Flash cards need notification of device shutdown in order to flush pending I/Os. A PCI notification hook for shutdown has been added where the driver notifies the card and returns. When the device is removed in the PCI remove path, notification code will wait for shutdown processing to complete. Signed-off-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Acked-by:
Manoj N. Kumar <manoj@linux.vnet.ibm.com> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
-
Uma Krishnan authored
Device dependent flags are needed to support functions that are specific to a particular device. One such case is - some CXL Flash cards need to be notified of device shutdown. For other CXL devices, this feature does not prove to be useful yet. Such distinct features need to be identified in the driver to bypass or invoke specific functionality. In this patch, a member 'flags' has been added to device dependent values. These flags will be used and expanded in the future to support various device specific functions. Signed-off-by:
-
Manoj N. Kumar authored
While running 'sg_reset -H' in a loop with a user-space application active, hit the following exception: cpu 0x2: Vector: 300 (Data Access) pc: : afu_attach+0x50/0x240 [cxlflash] lr: : cxlflash_afu_recover+0x3dc/0x7d0 [cxlflash] pid = 20365, comm = run_block_fvt Linux version 4.5.0-491-26f710d+ cxlflash_afu_recover+0x3dc/0x7d0 [cxlflash] cxlflash_ioctl+0x5a8/0x6f0 [cxlflash] scsi_ioctl+0x3b0/0x4c0 sd_ioctl+0x110/0x190 blkdev_ioctl+0x28c/0xc20 block_ioctl+0xa4/0xd0 do_vfs_ioctl+0xd8/0x8c0 SyS_ioctl+0xd4/0xf0 system_call+0x38/0xb4 The problem here is that the problem space area is unmapped while the application issues the DK_CXLFLASH_RECOVER_AFU ioctl. This is the order I observe: proc1 proc2 1) sg_reset 2) ioctl(DK_CXLFLASH_RECOVER_AFU) 3) sg_reset again causing a PSA unmap 4) continues RECOVER_AFU processing The resolution to this problem is to have the reset handler drain all outstanding user space initiated ioctls before proceeding. It is safe to drain after the state has been changed to STATE_RESET. Also since drain_ioctls() was static, it had to be moved up a bit to be before cxlflash_eh_host_reset_handler(). Signed-off-by: -
Dave Carroll authored
Update the email address for aacraid from Adaptec to Microsemi. Signed-off-by:
Dave Carroll <david.carroll@microsemi.com> Signed-off-by:
-
Douglas Gilbert authored
In this post: http://www.spinics.net/lists/linux-scsi/msg97124.html the author shows some kernel infrastructure complaining about a sleep in an invalid context. Remove offending call to vmalloc(). Instead of using kzalloc() which reviewers didn't like, use a bucket system (64 bytes on the stack) and potentially multiple calls to sg_pcopy_from_buffer() to construct the 'data-in' buffer for the SCSI REPORT LUNS command. Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Acked-by:
-
Hannes Reinecke authored
Originally libfc would just be initializing the refcount to '1', and using the disc_mutex to synchronize if and when the final put should be happening. This has a race condition as the mutex might be delayed, causing other threads to access an invalid structure. This patch updates the rport reference counting to increase the reference every time 'rport_lookup' is called, and decreases the reference correspondingly. This removes the need to hold 'disc_mutex' when removing the structure, and avoids the above race condition. Signed-off-by:
-
Randy Dunlap authored
Fix build when CONFIG_ISA_DMA_API is not enabled. Fixes these build errors (on x86_64): ../drivers/scsi/ultrastor.c: In function 'ultrastor_14f_detect': ../drivers/scsi/ultrastor.c:519:5: error: implicit declaration of function 'request_dma' [-Werror=implicit-function-declaration] if (config.dma_channel && request_dma(config.dma_channel,"Ultrastor")) { ^ ../drivers/scsi/ultrastor.c: In function 'ultrastor_release': ../drivers/scsi/ultrastor.c:658:3: error: implicit declaration of function 'free_dma' [-Werror=implicit-function-declaration] free_dma(shost->dma_channel); ^ Signed-off-by:Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Colin Ian King authored
Trivial fix to spelling mistake in printk message. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
John Garry authored
Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
John Garry authored
It is not necessary to surround call to notify_port_event(, PORTE_BROADCAST_RCVD) by spin_lock_irqsave(), so remove. This was causing a warn, as below: ================================= [ INFO: inconsistent lock state ] 4.4.8+ #12 Not tainted --------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. kworker/u64:1/168 [HC0[0]:SC0[0]:HE1:SE1] takes: (&(&hisi_hba->lock)->rlock){?.....}, at: [<ffffffc00052c708>] alloc_dev_quirk_v2_hw+0x48/0xec {IN-HARDIRQ-W} state was registered at: [<ffffffc0000fc764>] mark_lock+0x19c/0x6a0 [<ffffffc0000fdc14>] __lock_acquire+0xa2c/0x1d00 [<ffffffc0000ff654>] lock_acquire+0x58/0x7c [<ffffffc0008b609c>] _raw_spin_lock_irqsave+0x54/0x6c [<ffffffc00052d3c0>] int_chnl_int_v2_hw+0x1c4/0x248 [<ffffffc0001098e8>] handle_irq_event_percpu+0x9c/0x144 [<ffffffc0001099d4>] handle_irq_event+0x44/0x74 [<ffffffc00010cd68>] handle_fasteoi_irq+0xb4/0x188 [<ffffffc000108ea8>] generic_handle_irq+0x24/0x38 [<ffffffc0001091fc>] __handle_domain_irq+0x60/0xac [<ffffffc00008261c>] gic_handle_irq+0xcc/0x168 [<ffffffc0000855ac>] el1_irq+0x6c/0xe0 [<ffffffc0000f7414>] default_idle_call+0x1c/0x34 [<ffffffc0000f7654>] cpu_startup_entry+0x1d4/0x228 [<ffffffc0008aecd8>] rest_init+0x150/0x160 [<ffffffc000c4b95c>] start_kernel+0x3a4/0x3b8 [<00000000008bb000>] 0x8bb000 irq event stamp: 32661 hardirqs last enabled at (32661): [<ffffffc0008b41a8>] __mutex_unlock_slowpath+0x108/0x18c hardirqs last disabled at (32660): [<ffffffc0008b40e4>] __mutex_unlock_slowpath+0x44/0x18c softirqs last enabled at (25114): [<ffffffc0000bde68>] __do_softirq+0x210/0x27c softirqs last disabled at (25095): [<ffffffc0000be224>] irq_exit+0x9c/0xe8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(&hisi_hba->lock)->rlock); <Interrupt> lock(&(&hisi_hba->lock)->rlock); *** DEADLOCK *** 2 locks held by kworker/u64:1/168: #0: ("%s"shost->work_q_name){++++.+}, at: [<ffffffc0000d2980>] process_one_work+0x134/0x3cc #1: ((&sw->work)#2){+.+.+.}, at: [<ffffffc0000d2980>] process_one_work+0x134/0x3cc stack backtrace: CPU: 4 PID: 168 Comm: kworker/u64:1 Not tainted 4.4.8+ #12 Hardware name: Huawei Technologies Co., Ltd. D03/D03, BIOS 1.12 01/01/1900 Workqueue: scsi_wq_1 sas_discover_domain Call trace: [<ffffffc000089988>] dump_backtrace+0x0/0x114 [<ffffffc000089ab0>] show_stack+0x14/0x1c [<ffffffc00035ac50>] dump_stack+0xb4/0xf0 [<ffffffc0000fc524>] print_usage_bug+0x210/0x2b4 [<ffffffc0000fcbc4>] mark_lock+0x5fc/0x6a0 [<ffffffc0000fd9e8>] __lock_acquire+0x800/0x1d00 [<ffffffc0000ff654>] lock_acquire+0x58/0x7c [<ffffffc0008b5edc>] _raw_spin_lock+0x44/0x58 [<ffffffc00052c708>] alloc_dev_quirk_v2_hw+0x48/0xec [<ffffffc000528214>] hisi_sas_dev_found+0x48/0x1b8 [<ffffffc00051a9b8>] sas_notify_lldd_dev_found+0x34/0xe0 [<ffffffc00051e5e8>] sas_discover_root_expander+0x58/0x128 [<ffffffc00051b38c>] sas_discover_domain+0x4bc/0x564 [<ffffffc0000d29ec>] process_one_work+0x1a0/0x3cc [<ffffffc0000d2d50>] worker_thread+0x138/0x438 [<ffffffc0000d9494>] kthread+0xdc/0xf0 [<ffffffc000085c50>] ret_from_fork+0x10/0x40 Signed-off-by:Wei Xu <xuwei5@hisilicon.com> Signed-off-by:
Zhangfei Gao <zhangfei.gao@linaro.org> Signed-off-by:
-
John Garry authored
Add support in v2 hw driver for ACPI. A check on whether an ACPI handle is available for the device is used to decide on whether to use ACPI reset handler or syscon for hw reset. Signed-off-by:
-
Cathy Avery authored
When a virtual scsi DVD device is present with no image file attached the storvsc driver logs all resulting unnecessary sense errors whenever IO is issued to the device. [storvsc] Sense Key : Not Ready [current] [storvsc] Add. Sense: Medium not present - tray closed [mkp: Fixed whitespace] Signed-off-by:
Cathy Avery <cavery@redhat.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
-
Maurizio Lombardi authored
The "fcp_rsp_code = %d" message isn't an error, it's meant to be informative only. This patch prevents a flood of such messages in some situations. Signed-off-by:
Maurizio Lombardi <mlombard@redhat.com> Tested-by:
Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by:
-
Joe Lawrence authored
If _scsih_sas_host_add's call to mpt3sas_config_get_sas_iounit_pg0 fails, ioc->sas_hba.parent_dev may be left uninitialized. A later device probe could invoke mpt3sas_transport_port_add which will call sas_port_alloc_num [scsi_transport_sas] with a NULL parent_dev pointer. Signed-off-by:
Joe Lawrence <joe.lawrence@stratus.com> Acked-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Signed-off-by:
-
Joe Lawrence authored
In _scsih_sas_host_add, the number of HBA phys are determined and then later used to allocate an array of struct _sas_phy's. If the routine sets ioc->sas_hba.num_phys, but then fails to allocate the ioc->sas_hba.phy array (by kcalloc error or other intermediate error/exit path), ioc->sas_hba is left in a dangerous state: all readers of ioc->sas_hba.phy[] do so by indexing it from 0..ioc->sas_hba.num_phys without checking that the space was ever allocated. Modify _scsih_sas_host_add to set ioc->sas_hba.num_phys only after successfully allocating ioc->sas_hba.phy[]. Signed-off-by:
-
Joao Pinto authored
This patch adds license info to the tc-dwc-g210 and ufshcd-dwc files in order for them to have access to some ufshcd symbols when all are built as modules. Signed-off-by:
-
Geert Uytterhoeven authored
Submitters of device tree binding documentation may forget to CC the subsystem maintainer if this is missing. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: James E.J. Bottomley <jejb@linux.vnet.ibm.com> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Signed-off-by:
-
