- 08 Nov, 2016 36 commits
-
-
Joao Pinto authored
I am going to leave Synopsys and so this patch changes the Maintainer for UFS Synopsys' specific drivers to my colleagues Manjunath and Prabu. Signed-off-by:
Joao Pinto <jpinto@synopsys.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Javier Martinez Canillas authored
It appears that the mailing list email address doesn't exist anymore: <iss_storagedev@hp.com>: host smtp.hp.com[15.73.96.116] said: 550 5.1.1 <iss_storagedev@hp.com>: Recipient address rejected: User unknown in virtual alias table (in reply to RCPT TO command) Signed-off-by:Javier Martinez Canillas <javier@osg.samsung.com> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
Javier Martinez Canillas authored
It's not necessary to cast the result of kmalloc, since void pointers are promoted to any other type. This also fixes following coccinelle warning: casting value returned by memory allocation function to (BIG_IOCTL_Command_struct *) is useless. Signed-off-by:
-
Christoph Hellwig authored
Having an I/O priority does not mean we should send all requests as HEAD OF QUEUE tags. Reported-by:
Adam Manzanares <adam.manzanares@wdc.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Hannes Reinicke <hare@suse.de> Signed-off-by:
-
Finn Thain authored
If a NCR5380 host instance ends up on a shared interrupt line then this printk will be a problem. It is already a problem on some Mac models: when testing mac_scsi on a PowerBook 180 I found that PDMA transfers (but not PIO transfers) cause the message to be logged. These spurious interrupts don't appear to come from the DRQ signal from the 5380. And they don't happen at all on the Mac LC III. A comment in the NetBSD source code mentions this mystery. Testing seems to show that we can safely ignore these interrupts. Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Reviewed-by:
Hannes Reinecke <hare@suse.com> Tested-by:
Ondrej Zary <linux@rainbow-software.org> Tested-by:
Michael Schmitz <schmitzmic@gmail.com> Signed-off-by:
-
Finn Thain authored
Apply prototypes to get consistent function signatures for the DMA functions implemented in the board-specific drivers. To avoid using macros to alter actual parameters, some of those functions are reworked slightly. This is a step toward the goal of passing the board-specific routines to the core driver using an ops struct (as in a platform driver or library module). This also helps fix some inconsistent types: where the core driver uses ints (cmd->SCp.this_residual and hostdata->dma_len) for keeping track of transfers, certain board-specific routines used unsigned long. While we are fixing these function signatures, pass the hostdata pointer to DMA routines instead of a Scsi_Host pointer, for shorter and faster code. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Finn Thain authored
Avoid the call to NCR5380_poll_politely2() when possible. The call is easily short-circuited on the PIO fast path, using the inline wrapper. This requires that the NCR5380_read macro be made available before any #include "NCR5380.h" so a few declarations have to be moved too. Signed-off-by:
-
Finn Thain authored
Pass a NCR5380_hostdata struct pointer to the board-specific routines instead of a Scsi_Host struct pointer. This reduces pointer chasing in the PIO and PDMA fast paths. The old way was a mistake because it is slow and the board-specific code is not concerned with the mid-layer. Signed-off-by:
-
Finn Thain authored
For timeout values adopt unsigned long, which is the type of jiffies etc. For chip register values and bit masks pass u8, which is the return type of readb, inb etc. For device register offsets adopt unsigned int, as it is suitable for adding to base addresses. Pass the NCR5380_hostdata pointer to the board-specific routines instead of the Scsi_Host pointer. The board-specific code is concerned with hardware and not with SCSI protocol or the mid-layer. Signed-off-by:
-
Finn Thain authored
The various 5380 drivers inconsistently store register pointers either in the Scsi_Host struct "legacy crap" area or in special, board-specific members of the NCR5380_hostdata struct. Uniform use of the latter struct makes for simpler and faster code (see the following patches) and helps to reduce use of the NCR5380_implementation_fields macro. Signed-off-by:
-
Finn Thain authored
Re-order struct members so that hot data lies at the beginning of the struct and cold data at the end. Improve the comments while we're here. Signed-off-by:
-
Finn Thain authored
If NCR5380_poll_politely() is called under irq lock, the polling time limit is clamped to avoid a spike in interrupt latency. When not under irq lock, the same polling time limit acts as the worst case delay between schedule() calls. During PDMA (under irq lock) I've found that the 10 ms time limit is sometimes too short, and leads to the error message, sd 0:0:0:0: [sda] tag#1 macscsi_pread: !REQ and !ACK This particular target identifies itself as a QUANTUM DAYTONA514S. It seems to be slower to assert ACK than the other targets I've tested. This patch solves the problem by increasing the polling timeout. Signed-off-by:
-
Finn Thain authored
When polling a device register under irq lock the polling loop terminates after a given number of jiffies. Make this timeout independent of the HZ setting. All 5380 drivers benefit from this patch, which optimizes the PIO fast path, because they all use PIO transfers (for phases other than DATA IN and DATA OUT). Some cards support only PIO transfers (even for DATA phases). CPU cycles are scarce on some of these systems, so a small improvement here makes a big difference. Signed-off-by:
-
Finn Thain authored
This patch fixes an old bug: accesses to device registers from the interrupt handler (after reselection, DMA completion etc.) could mess up a device register access elsewhere, if the latter takes place outside of an irq lock (during selection etc.). Signed-off-by:
-
Finn Thain authored
Signed-off-by:
-
Ondrej Zary authored
Merge the port-mapped IO and memory-mapped IO support (with the help of ioport_map) into the g_NCR5380 module and delete g_NCR5380_mmio. Signed-off-by:
-
Subhash Jadavani authored
Vendor specific setup_clocks callback may require the clocks managed by ufshcd driver to be ON. So if the vendor specific setup_clocks callback is called while the required clocks are turned off, it could result into unclocked register access. To prevent possible unclock register access, this change adds one more argument to setup_clocks callback to let it know whether it is called pre/post the clock changes by core driver. Signed-off-by:
Subhash Jadavani <subhashj@codeaurora.org> Reviewed-by:
Kiwoong Kim <kwmad.kim@samsung.com> Signed-off-by:
-
Chad Dupuis authored
If we haven't logged into the fabric yet we want to be a little more nuanced with our CVL handling than what we've been: - If the FCF has been selected, check the source MAC to make sure the frame is from the FCF we've selected. - If a FCF is selected and the CVL is from the FCF but we have not logged in yet, then reset everything and go back to solicitation. Signed-off-by:
Chad Dupuis <chad.dupuis@cavium.com> Reviewed-by:
Johannes Thumshirn <jth@kernel.org> Signed-off-by:
-
Hannes Reinecke authored
When we receive an FLOGI but have already sent our own we should not advance the state machine but rather wait for our FLOGI to return before continuing with PLOGI. Signed-off-by:
-
Hannes Reinecke authored
When the port is already started we don't need to login; that will only confuse the state machine. Signed-off-by:
-
Hannes Reinecke authored
When fc_rport_login() is called while the rport is not in RPORT_ST_INIT, RPORT_ST_READY, or RPORT_ST_DELETE login is already in progress and there's no need to drop down to FLOGI; doing so will only confuse the other side. Signed-off-by:
-
Chad Dupuis authored
When an ELS response handler receives a -FC_EX_CLOSED, the rdata->rp_mutex is already held which can lead to a deadlock condition like the following stack trace: [<ffffffffa04d8f18>] fc_rport_plogi_resp+0x28/0x200 [libfc] [<ffffffffa04cfa1a>] fc_invoke_resp+0x6a/0xe0 [libfc] [<ffffffffa04d0c08>] fc_exch_mgr_reset+0x1b8/0x280 [libfc] [<ffffffffa04d87b3>] fc_rport_logoff+0x43/0xd0 [libfc] [<ffffffffa04ce73d>] fc_disc_stop+0x6d/0xf0 [libfc] [<ffffffffa04ce7ce>] fc_disc_stop_final+0xe/0x20 [libfc] [<ffffffffa04d55f7>] fc_fabric_logoff+0x17/0x70 [libfc] The other ELS handlers need to follow the FLOGI response handler and simply do a kref_put against the fc_rport_priv struct and exit when receving a -FC_EX_CLOSED response. Signed-off-by:
-
Hannes Reinecke authored
The list of attached 'rdata' remote port structures is RCU protected, so there is no need to take the 'disc_mutex' when traversing it. Rather we should be using rcu_read_lock() and kref_get_unless_zero() to validate the entries. We need, however, take the disc_mutex when deleting an entry; otherwise we risk clashes with list_add. Signed-off-by:
-
Hannes Reinecke authored
The kref handling in fc_rport is a mess. This patch updates the kref handling according to the following rules: - Take a reference whenever scheduling a workqueue - Take a reference whenever an ELS command is send - Drop the reference at the end of the workqueue function - Drop the reference at the end of handling ELS replies - Take a reference when allocating an rport - Drop the reference when removing an rport Signed-off-by:
-
John Garry authored
The hip06 D03 and hip07 D05 boards have different reference clock frequencies for the SAS controller. Register PHY_CTRL needs to be programmed differently according to this frequency, so add support for this. The default register setting in PHY_CTRL is for 50MHz, so only update this register when the refclk frequency is 66MHz. For ACPI we expect the _RST handler to set the correct value for PHY_CTRL (we're forced to take different approach for DT and ACPI as ACPI does not support fixed-clock device). Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by:
-
John Garry authored
Chipset hip07 incorporates v2 hw. Signed-off-by:
-
John Garry authored
Add support for hip07 chipset to hisi_sas controller. Chipset hip07 has v2 hw. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Deepa Dinamani authored
Trace timestamps use struct timespec and CURRENT_TIME which are not y2038 safe. These timestamps are only part of the trace log on the machine and are not shared with the fnic. Replace then with y2038 safe struct timespec64 and ktime_get_real_ts64(), respectively. Signed-off-by:
Deepa Dinamani <deepa.kernel@gmail.com> Reviewed-by:
Arnd Bergmann <arnd@arndb.de> Cc: Hiral Patel <hiralpat@cisco.com> Cc: Suma Ramars <sramars@cisco.com> Cc: Brian Uchino <buchino@cisco.com> Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: linux-scsi@vger.kernel.org Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Christoph Hellwig authored
Switch the ipr driver to use pci_alloc_irq_vectors. We need to two calls to pci_alloc_irq_vectors as ipr only supports multiple MSI-X vectors, but not multiple MSI vectors. Otherwise this cleans up a lot of cruft and allows to use a common request_irq loop for irq types, which happens to only iterate over a single line in the non MSI-X case. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Signed-off-by:
-
Christoph Hellwig authored
Switch the arcmsr driver to use pci_alloc_irq_vectors. We need to two calls to pci_alloc_irq_vectors as arcmsr only supports multiple MSI-X vectors, but not multiple MSI vectors. Otherwise this cleans up a lot of cruft and allows to use a common request_irq loop for irq types, which happens to only iterate over a single line in the non MSI-X case. Signed-off-by:
Ching Huang <ching2048@areca.com.tw> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommuLinus Torvalds authored
Pull IOMMU fixes from Joerg Roedel: - Four patches from Robin Murphy fix several issues with the recently merged generic DT-bindings support for arm-smmu drivers - A fix for a dead-lock issue in the VT-d driver, which shows up on iommu hotplug * tag 'iommu-fixes-v4.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu: iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path iommu/arm-smmu: Fix out-of-bounds dereference iommu/arm-smmu: Check that iommu_fwspecs are ours iommu/arm-smmu: Don't inadvertently reject multiple SMMUv3s iommu/arm-smmu: Work around ARM DMA configuration
-
Joerg Roedel authored
It turns out that the disable_dmar_iommu() code-path tried to get the device_domain_lock recursivly, which will dead-lock when this code runs on dmar removal. Fix both code-paths that could lead to the dead-lock. Fixes: 55d94043 ('iommu/vt-d: Get rid of domain->iommu_lock') Signed-off-by:
Joerg Roedel <jroedel@suse.de>
-
Robin Murphy authored
When we iterate a master's config entries, what we generally care about is the entry's stream map index, rather than the entry index itself, so it's nice to have the iterator automatically assign the former from the latter. Unfortunately, booting with KASAN reveals the oversight that using a simple comma operator results in the entry index being dereferenced before being checked for validity, so we always access one element past the end of the fwspec array. Flip things around so that the check always happens before the index may be dereferenced. Fixes: adfec2e7 ("iommu/arm-smmu: Convert to iommu_fwspec") Reported-by:
Mark Rutland <mark.rutland@arm.com> Signed-off-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Robin Murphy authored
We seem to have forgotten to check that iommu_fwspecs actually belong to us before we go ahead and dereference their private data. Oops. Fixes: 021bb842 ("iommu/arm-smmu: Wire up generic configuration support") Signed-off-by:
-
Robin Murphy authored
We now delay installing our per-bus iommu_ops until we know an SMMU has successfully probed, as they don't serve much purpose beforehand, and doing so also avoids fights between multiple IOMMU drivers in a single kernel. However, the upshot of passing the return value of bus_set_iommu() back from our probe function is that if there happens to be more than one SMMUv3 device in a system, the second and subsequent probes will wind up returning -EBUSY to the driver core and getting torn down again. Avoid re-setting ops if ours are already installed, so that any genuine failures stand out. Fixes: 08d4ca2a ("iommu/arm-smmu: Support non-PCI devices with SMMUv3") CC: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> CC: Hanjun Guo <hanjun.guo@linaro.org> Signed-off-by:
-
Robin Murphy authored
The 32-bit ARM DMA configuration code predates the IOMMU core's default domain functionality, and instead relies on allocating its own domains and attaching any devices using the generic IOMMU binding to them. Unfortunately, it does this relatively early on in the creation of the device, before we've seen our add_device callback, which leads us to attempt to operate on a half-configured master. To avoid a crash, check for this situation on attach, but refuse to play, as there's nothing we can do. This at least allows VFIO to keep working for people who update their 32-bit DTs to the generic binding, albeit with a few (innocuous) warnings from the DMA layer on boot. Signed-off-by:
-
- 07 Nov, 2016 4 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds authored
Pull arm64 fix from Will Deacon: "It's been pretty quiet on the fixes side of things for us, but Artem reported a build failure introduced during the merge window that appears with older GCCs that do not support asm goto. The fix is bigger than I'd like, but it's a mechnical move of some constants to break an include dependency between atomic.h and jump_label.h when !HAVE_JUMP_LABEL. Summary: - Fix build failure on compilers without asm goto" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: Fix circular include of asm/lse.h through linux/jump_label.h
-
Linus Torvalds authored
Merge tag 'openrisc-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull openrisc fix from Guenter Roeck: "Fix openrisc crash caused by ro_init changes" * tag 'openrisc-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: openrisc: Define __ro_after_init to avoid crash
-
Linus Torvalds authored
Merge tag 'hwmon-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging Pull hwmon fix from Guenter Roeck: "Fix resource leak on devm_kcalloc failure" * tag 'hwmon-for-linus-v4.9-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: hwmon: (core) fix resource leak on devm_kcalloc failure
-
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hidLinus Torvalds authored
Pull HID fixes from Jiri Kosina: - modprobe-after-rmmod load failure bugfix for intel-ish, from Even Xu - IRQ probing bugfix for intel-ish, from Srinivas Pandruvada - attribute parsing fix in hid-sensor, from Ooi, Joyce - other small misc fixes / quirky device additions * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: sensor: fix attributes in HID sensor interface HID: intel-ish-hid: request_irq failure HID: intel-ish-hid: Fix driver reinit failure HID: intel-ish-hid: Move DMA disable code to new function HID: intel-ish-hid: consolidate ish wake up operation HID: usbhid: add ATEN CS962 to list of quirky devices HID: intel-ish-hid: Fix !CONFIG_PM build warning HID: sensor-hub: Fix packing of result buffer for feature report
-
