- Nov 09, 2016
-
-
Kashyap Desai authored
Signed-off-by:
Sumit Saxena <sumit.saxena@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Kashyap Desai authored
scsi: megaraid_sas: Do not set MPI2_TYPE_CUDA for JBOD FP path for FW which does not support JBOD sequence map CC: stable@vger.kernel.org Signed-off-by:
Tomas Henzl <thenzl@redhat.com> Signed-off-by:
-
Kashyap Desai authored
Update MEGARAID drivers maintainers list. Signed-off-by:
-
Kashyap Desai authored
Until now the megaraid_sas driver has reported successful completion on SYNCHRONIZE_CACHE commands without sending them down to the controller. The controller firmware has been responsible for taking care of flushing disk caches for all drives that belong to a Virtual Disk at the time of system reboot/shutdown. There may have been a reason to avoid sending SYNCHRONIZE_CACHE to a VD in the past but that no longer appears to be valid. Older versions of MegaRaid firmware (Gen2 and Gen2.5) set the WCE bit for Virtual Disks but the firmware does not report correct completion status for a SYNCHRONIZE_CACHE command. As a result, we must use another method to identify whether it is safe to send the command to the controller. We use the canHandleSyncCache firmware flag in the scratch pad register at offset 0xB4. New SYNCHRONIZE_CACHE behavior: IF 'JBOD' Driver sends SYNCHRONIZE_CACHE command to the firmware Firmware sends SYNCHRONIZE_CACHE to drive Firmware obtains status from drive and returns same status back to driver ELSEIF 'VirtualDisk' IF firmware supports new API bit called canHandleSyncCache Driver sends SYNCHRONIZE_CACHE command to the firmware Firmware does not send SYNCHRONIZE_CACHE to drives Firmware returns SUCCESS ELSE Driver does not send SYNCHRONIZE_CACHE command to the firmware Driver return SUCCESS for that command ENDIF ENDIF [mkp: edited patch description] Signed-off-by:
Kashyap Desai <kashyap.desai@broadcom.com> Signed-off-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Christoph Hellwig authored
Which cleans up a lot of the MSI-X handling, and allows us to use the PCI IRQ layer provided vector mapping, which we can then expose to blk-mq. Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Acked-by:
Don Brace <don.brace@microsemi.com> Tested-by:
-
Christoph Hellwig authored
Just hand through the blk-mq map_queues method in the host template. Signed-off-by:
-
Christoph Hellwig authored
This will allow SCSI to have a single blk_mq_ops structure that either lets the LLDD map the queues to PCIe MSIx vectors or use the default. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Subhash Jadavani authored
When we are resuming the UFS device rails in HPM mode, we are first powering on the VCC rail while VCCQ and VCCQ2 rails still being in LPM mode. Some UFS devices may take VCC on event as hint that host wants UFS device to be resumed and may start drawing more power from the VCCQ/VCCQ2 rails (while they are still in LPM mode) causing voltage drop on these rails. This change fixes this issue by bringing VCCQ & VCCQ2 rails out of LPM before powering on VCC rail. Reviewed-by:
Venkat Gopalakrishnan <venkatg@codeaurora.org> Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
Subhash Jadavani authored
Currently clock scaling is suspended only after the host and device are put in low power mode but we should avoid clock scaling running after UFS link is put in low power mode (hibern8). This change suspends clock scaling before putting host/device in low power mode. Reviewed-by:
Sahitya Tummala <stummala@codeaurora.org> Signed-off-by:
-
Subhash Jadavani authored
If ufshcd pltfrm/pci driver's probe fails for some reason then ensure that scsi host is released to avoid memory leak but managed memory allocations (via devm_* calls) need not to be freed explicitly on probe failure as memory allocated with these functions is automatically freed on driver detach. Reviewed-by:
-
Subhash Jadavani authored
UFS devfreq clock scaling work may require clocks to be ON if it need to execute some UFS commands hence it may request for clock hold before issuing the command. But if UFS clock gating work is already running in parallel, ungate work would end up waiting for the clock gating work to finish and as clock gating work would also wait for the clock scaling work to finish, we would enter in deadlock state. Here is the call trace during this deadlock state: Workqueue: devfreq_wq devfreq_monitor __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work ufshcd_hold ufshcd_send_uic_cmd ufshcd_dme_get_attr ufs_qcom_set_dme_vs_core_clk_ctrl_clear_div ufs_qcom_clk_scale_notify ufshcd_scale_clks ufshcd_devfreq_target update_devfreq devfreq_monitor process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_gate_work __switch_to __schedule schedule schedule_preempt_disabled __mutex_lock_slowpath mutex_lock devfreq_monitor_suspend devfreq_simple_ondemand_handler devfreq_suspend_device ufshcd_gate_work process_one_work worker_thread kthread ret_from_fork Workqueue: events ufshcd_ungate_work __switch_to __schedule schedule schedule_timeout wait_for_common wait_for_completion flush_work __cancel_work_timer cancel_delayed_work_sync ufshcd_ungate_work process_one_work worker_thread kthread ret_from_fork This change fixes this deadlock by doing this in devfreq work (devfreq_wq): Try cancelling clock gating work. If we are able to cancel gating work or it wasn't scheduled, hold the clock reference count until scaling is in progress. If gate work is already running in parallel, let's skip the frequecy scaling at this time and it will be retried once next scaling window expires. Reviewed-by:
-
Suganath Prabu Subramani authored
Signed-off-by:
Chaitra P B <chaitra.basappa@broadcom.com> Signed-off-by:
Sathya Prakash <sathya.prakash@broadcom.com> Signed-off-by:
Suganath Prabu S <suganath-prabu.subramani@broadcom.com> Signed-off-by:
-
Suganath Prabu Subramani authored
Use le16_to_cpu only for accessing two byte data provided by controller. Signed-off-by:
-
Suganath Prabu Subramani authored
Support Atomic Request Descriptors for Ventura/SAS35 devices. Signed-off-by:
-
Suganath Prabu Subramani authored
An UNMAP command on a PI formatted device will leave the Logical Block Application Tag and Logical Block Reference Tag as all F's (for those LBAs that are unmapped). To avoid IO errors if those LBAs are subsequently read before they are written with valid tag fields, the MPI SCSI IO requests need to set the EEDPFlags element EEDP Escape Mode field, Bits [7:6] appropriately. A value of 2 should be set to disable all PI checks if the Logical Block Application Tag is 0xFFFF for PI types 1 and 2. A value of 3 should be set to disable all PI checks if the Logical Block Application Tag is 0xFFFF and the Logical Block Reference Tag is 0xFFFFFFFF for PI type 3. Signed-off-by:
-
Suganath Prabu Subramani authored
For SAS35 devices MSIX vectors are inceased to 128 from 96. To support this Reply post host index register count is increased to 16. Also variable msix96_vector is replaced with combined_reply_queue and variable combined_reply_index_count is added to set different values for SAS3 and SAS35 devices. Signed-off-by:
-
Suganath Prabu Subramani authored
Added Device ID's for SAS35 devices (Ventura, Crusader, Harpoon & Tomcat) and updated mpi header file for the same. Also added "is_gen35_ioc" to MPT3SAS_ADAPTER structure for identifying SAS35 adapters. Signed-off-by:
-
Suganath Prabu Subramani authored
Signed-off-by:
-
Suganath Prabu Subramani authored
Removing macro "MPT_DEVICE_TLR_ON" defined in header file as its unused Signed-off-by:
-
Suganath Prabu Subramani authored
When device missing event arrives, device_remove_in_progress bit will be set and hence driver has to stop sending IOCTL commands.Now the check has been added in IOCTL path to test device_remove_in_progress bit is set, if so then IOCTL will be failed printing failure message. Signed-off-by:
-
Suganath Prabu Subramani authored
scsi: mpt3sas: Fix for incorrect numbers for MSIX vectors enabled when non RDPQ card is enumerated first. No. of MSIX vectors supported = min (Total no. of CPU cores, MSIX vectors supported by card) when RDPQ is disabled "max_msix_vectors" module parameter which was declared as global was set to '8' and hence if there are more than one card in system among which if RDPQ disabled card is enumerated first then only 8 MSIX vectors was getting enabled for all the cards(including RDPQ enabled card,which can support more than 8 MSIX vectors). Used local variable instead of global variable ,if RDPQ is disabled this local variable is set to '8' else it is set to "max_msix_vectors" (by default this is set to -1, whose value can be set by user during driver load time).So now regardless of whether RDPQ disabled card is enumerated first or RDPQ enabled card is enumerated first , MSIX vectors enabled depends on the cards capability. Signed-off-by:
-
Suganath Prabu Subramani authored
Return value and Device_handle Arguments passed in correct order to match with its format string. Signed-off-by:
-
Arnd Bergmann authored
The advansys probe function tries to handle both ISA and PCI cases, each hidden in an #ifdef when unused. This leads to a warning indicating that when PCI is disabled we could be using uninitialized data: drivers/scsi/advansys.c: In function advansys_board_found : drivers/scsi/advansys.c:11036:5: error: ret may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:28: note: ret was declared here drivers/scsi/advansys.c:11309:8: error: share_irq may be used uninitialized in this function [-Werror=maybe-uninitialized] drivers/scsi/advansys.c:10928:6: note: share_irq was declared here This cannot happen in practice because the hardware in question only exists for PCI, but changing the code to just error out here is better for consistency and avoids the warning. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
-
Chris Leech authored
With the error message I added in "libfc: sanity check cpu number extracted from xid" I didn't account for the fact that fc_exch_find is called with FC_XID_UNKNOWN at the start of a new exchange if we are the responder. It doesn't come up with the initiator much, but that's basically every exchange for a target. By checking the xid for FC_XID_UNKNOWN first, we not only prevent the erroneous error message, but skip the unnecessary lookup attempt as well. [mkp: applied by hand due to conflict with Hannes' libfc patch series] Signed-off-by:
Chris Leech <cleech@redhat.com> Reviewed-by:
-
Venkat Gopalakrishnan authored
In a case where gate work is called as part of cancel work from ungate path the clk state would be marked as REQ_CLKS_ON. There is no point gating the clocks and then end up turning them ON immediately in ungate work, save time by skipping the gate work and change the clk state to CLKS_ON as they are not turned off yet. Signed-off-by:
-
Venkat Gopalakrishnan authored
The ungate work turns on the clock before it exits hibern8, if the link was put in hibern8 during clock gating work. There occurs a race condition when clock scaling work calls ufshcd_hold() to make sure low power states cannot be entered, but that returns by checking only whether the clocks are on. This causes the clock scaling work to issue UIC commands when the link is in hibern8 causing failures. Make sure we exit hibern8 state before returning from ufshcd_hold(). Callstacks for race condition: ufshcd_scale_gear ufshcd_devfreq_scale ufshcd_devfreq_target update_devfreq devfreq_monitor process_one_work worker_thread kthread ret_from_fork ufshcd_uic_hibern8_exit ufshcd_ungate_work process_one_work worker_thread kthread ret_from_fork Signed-off-by:
-
Dov Levenglick authored
In case the power configuration fails, skip further processing of the probing function and return immediately. This has 2 reasons: 1. Don't allow the UFS to continue running in PWM 2. Avoid multiple calls to pm_runtime_put_sync() when not in error handling or power management contexts Signed-off-by:
Dov Levenglick <dovl@codeaurora.org> Signed-off-by:
-
Gilad Broner authored
During runtime resume operation, clock scaling may get indirectly resumed via call to ufshcd_set_dev_pwr_mode(): Start/Stop Unit command times out and SCSI error handling ultimately calls the host reset handler to recover, during which clock scaling is resumed. Error case exit path of runtime resume will disable clocks. As clock scaling was already resumed, it will get scheduled later on and try to access UFS registers while clocks are disabled, resulting in unclocked register access. Signed-off-by:
Gilad Broner <gbroner@codeaurora.org> Signed-off-by:
-
Gilad Broner authored
According to UFS device specification, sense data can be only 18 bytes long, this change makes the changes accordingly. Signed-off-by:
-
Gilad Broner authored
Add a write memory barrier to make sure descriptors prepared are actually written to memory before ringing the doorbell. We have also added the write memory barrier after ringing the doorbell register so that controller sees the new request immediately. Signed-off-by:
-
Yaniv Gardi authored
In this change there are a few fixes of possible NULL pointer access and possible access to index that exceeds array boundaries. Signed-off-by:
Yaniv Gardi <ygardi@codeaurora.org> Signed-off-by:
-
Andy Shevchenko authored
For small buffers we may use %*ph[N] specifier, for the bigger blocks print_hex_dump() call. Cc: Don Brace <don.brace@microsemi.com> Cc: esc.storagedev@microsemi.com Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Andy Shevchenko authored
In kernel we have defined specifier (%*ph[C]) to dump small buffers in a hex format. Replace custom approach by a generic one. Cc: Jon Mason <jonmason@broadcom.com> Signed-off-by:
-
Andy Shevchenko authored
We have table of the HEX characters in the kernel. Replace custom by a generic one. Cc: Adaptec OEM Raid Solutions <aacraid@adaptec.com> Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by:
-
Oleksandr Khoshaba authored
In the kernel we have nice specifier to print MAC by given pointer to the address in a binary form. Signed-off-by:
Oleksandr Khoshaba <Oleksandr.Khoshaba@gmail.com> Acked-by:
Vikas Chaudhary <vikas.chaudhary@qlogic.com> Cc: QLogic-Storage-Upstream@qlogic.com Signed-off-by:
-
Andy Shevchenko authored
LAN MAC addresses can be printed directly using %pMR specifier. 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:
-
Andy Shevchenko authored
Instead of supplying each byte through stack let's use %pM specifier. Cc: Hiral Patel <hiralpat@cisco.com> Cc: Suma Ramars <sramars@cisco.com> Acked-by:
Tom Tucker <tom@opengridcomputing.com> Signed-off-by:
-
Kashyap Desai authored
This patch addresses the issue of driver firing DCMDs in PCI shutdown/detach path irrespective of firmware state. Driver will now check whether firmware is in operational state or not before firing DCMDs. If firmware is in unrecoverable state or does not become operational within specfied time, driver will skip firing DCMDs. [mkp: fixed typos] Signed-off-by:
Shivasharan Srikanteshwara <shivasharan.srikanteshwara@broadcom.com> Reviewed-by:
-
Kashyap Desai authored
This patch fixes the issue of wrong PhysArm was sent to firmware for R1 VD downgrade. Signed-off-by:
Kiran Kumar Kasturi <kiran-kumar.kasturi@broadcom.com> Signed-off-by:
-
Kashyap Desai authored
For SRIOV enabled firmware, if there is a OCR(online controller reset) possibility driver set the convert flag to 1, which is not happening if there are outstanding commands even after 180 seconds. As driver does not set convert flag to 1 and still making the OCR to run, VF(Virtual function) driver is directly writing on to the register instead of waiting for 30 seconds. Setting convert flag to 1 will cause VF driver will wait for 30 secs before going for reset. CC: stable@vger.kernel.org Signed-off-by:
-
