This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a similar cleanup like the commit [3db084fd0a: ALSA: fm801:
PCI core handles power state for us].
Since pci_set_power_state(), pci_save_state() and pci_restore_state()
are already done in the PCI core side, so we don't need to it doubly.
Also, pci_enable_device(), pci_disable_device() and pci_set_master()
calls in PM callbacks are superfluous nowadays, too, so get rid of
them as well.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add the missing SoC and revision ID for the Armada 370 and 38x SoCs.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
The A388-GP is a board produced by Marvell that holds
- 1 PCIe slot
- 2 mini PCIe slot (one of them is multiplexed with the PCIe slot,
muxing is selected through the GPIO expander)
- 1 16MB SPI-NOR
- 2 Gigabit Ethernet ports
- 4 SATA ports (2 of them are multiplexed with the mini PCIe slots,
muxing is selected through the GPIO expander)
- 1 SDIO slot
- 1 USB3 port
- 2 USB2 port
- 2 GPIO/interrupts expander on I2C
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
This SoC belongs to the Armada 38x family. The main difference with
the Armada 385 is that the 388 can handle two more SATA
ports. Currently the consequence is the use of a different compatible
string for the pinctrl node, in order to be able to use the pins
associated to this 2 new SATA ports. The second SATA controller has
also been moved from the armada38x.dtsi as it it specific to the
Armada388 version.
In the same time the Armada385 DB and Armada 385 RD board have been
renamed in the 388 one and now include the armada-388.dtsi file. AS
both of them have 4 SATA ports the SoC used on them were wrongly
described.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Update the binding documentation of the Armada 38x Soc family with
the Armada 388.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
The pintcrl label was missing. Adding it allowed referring it from the
root of the device tree. Also add the uart0 label used by the
bootloader.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
With the Armada 385 GP board more pinctrl functions depending of the
SoC are needed. Add them to the DTSI to avoid duplication.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
The A385-AP is a board produced by Marvell that holds 3 mPCIe slot, a 16MB
SPI-NOR, 3 Gigabit Ethernet ports, USB3 and NAND flash storage.
[gregory.clement@free-electrons.com: switch the license to the dual
X11/GPL with the agreement of the author]
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Some pinctrl functions can be shared with all DTS out there, since they are
generic, SoC-wide muxing options. Add a number of these to the DTSI to avoid
duplication.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
The compatible set in the armada-38x DTSI is always overridden, and the reg
defined in there is duplicated in the armada-380 and armada-385 DTSIs.
Remove these useless items.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Some nodes in the DTs have a reg property but no unit name in their node name.
This contradicts the way the ePAPR defines the node names. Fix this.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Tegra132 uses the same GPU as Tegra124 and therefore requires the same
method to remove clamps. However Tegra132 has a separate chip ID, so in
order to avoid having to extend the list of chip IDs for the special
case, add a feature flag to the SoC data.
Reviewed-by: Paul Walmsley <pwalmsley@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Tegra132 is very similar to Tegra124 from a peripheral point of view and
uses the same fuse controller.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Some mvebu boards have the UART1 more easily accessible than the other UARTs
found on the system.
Add a debug_ll option for this case.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
The mvebu SoCs actually have more UARTs than just the one exposed in DEBUG_LL
yet.
In order to differentiate them, Add the index in the configuration options and
their help.
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Acked-by: Jason Cooper <jason@lakedaemon.net>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
struct fusion_context *fusion is already memset to '0', so remove a
redundant call to memmset "fusion->load_balance_info" to '0'.
Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
1) For fusion adapters, limit reserved frames for non SCSI commands to 8
(3 for parallel IOCTLs + 5 for driver's internal DCMDs).
Earlier reserved commands for non SCSI IO frames was set to 32, so with
this implementation, increased per controller "can_queue".
Behavior of MFI controllers will remain unchanged.
2) Optimize the code related to per controller's 'can_queue' setting.
Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Driver calls megasas_complete_cmd() to call wake_up() for each MFI frame
that was issued through the ioctl() interface prior to the kill adapter.
This ensures userspace ioctl() system calls issued just before a kill
adapter don't get stuck in wait state and IOCTLs are returned to
the application.
Cc: <stable@vger.kernel.org>
Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Update driver "mask_interrupts" before enable/disable hardware interrupt
in order to avoid missing interrupts because of "mask_interrupts" still
set to 1 and hardware interrupts are enabled.
Cc: <stable@vger.kernel.org>
Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This patch will address the issue of SCSI device created at OS level for
non existing VD. ldTgtIdtoLd[] array has size 256 for Extended VD firmware
and 128 for legacy firmware. Accessing indices beyond array size (OS will
send TUR, INQUIRY.. commands upto device index 255), may return valid LD
value and that particular SCSI command will be SUCCESS and creating SCSI
device for non existing target(VD).
For legacy firmware (64 VD firmware), invalidates LD (by setting LD value
to 0xff) in LdTgtIdtoLd[] array for device index beyond 127, so that
invalid LD(0xff) value should be returned beyond device index beyond 127.
Cc: <stable@vger.kernel.org>
Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This patch adds support for Secure Encrypting Drives (SED) in JBOD mode:
1) If the firmware supports SED JBOD, all non read/write commands to JBODs
will be sent via firmware path, and read/write commands to JBODs will
be sent via fastpath.
2) If the firmware does not support SED JBOD, driver will fall back to the
old design, i.e. send all JBOD I/O via fastpath.
Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
This patch addresses below issues:
1) Few endianness bug fixes.
2) Break the iteration after (MAX_LOGICAL_DRIVES_EXT - 1)),
instead of MAX_LOGICAL_DRIVES_EXT.
3) Optimization in MFI INIT frame before firing.
4) MFI IO frame should be 256bytes aligned. Code is optimized to reduce
the size of frame for fusion adapters and make the MFI frame size
calculation a bit transparent and readable.
Cc: <stable@vger.kernel.org>
Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com>
Signed-off-by: Sumit Saxena <sumit.saxena@avagotech.com>
Signed-off-by: Chaitra Basappa <chaitra.basappa@avagotech.com>
Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
It is not good practice to display the kernel pointer in any message logs,
and it doesn't display any additional information. And as we know have
block-layer assigned tags we can use them to differentiate the messages.
So remove any pointer references from the displayed messages.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
scsi_log_send() would display buffer pointer for higher logging levels.
This is not only of questionable value but also exposes kernel pointer to
userspace, which is discouraged in some setups. So drop this message
altogether.
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Instead of having constants.c littered with ifdef statements we should
be moving dummy functions into the header and condintionally compile in
constants.c if selected. And update the Kconfig description to reflect
the actual size difference.
Suggested-by: Christoph Hellwig <hch@infradead.org>
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Convert scsi_print_result() to use the per-cpu buffer for decoding the
command result and disposition.
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Convert sense buffer logging to use the per-cpu buffer to avoid line
breakup.
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
libata already uses an internal buffer, so we should be using
__scsi_format_command() here.
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Use an external buffer for __scsi_print_command() and move command
logging over to use the per-cpu logging buffer. With that we can
guarantee the command always will always be formatted in one line.
So we can even print out a variable length command correctly across
several lines. Finally rename __scsi_print_command() to
__scsi_format_comment() to better reflect the functionality.
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
The request tag provides a concise identification of a SCSI
command, so we should be printing that out for scmd_printk().
Suggested-by: Christoph Hellwig <hch@lst.de>
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Implement a per-cpu buffer for formatting messages to avoid line breaks
up under high load. This patch implements scmd_printk() and
sdev_prefix_printk() using the per-cpu buffer and makes sdev_printk() a
wrapper for sdev_prefix_printk().
Tested-by: Robert Elliott <elliott@hp.com>
Reviewed-by: Robert Elliott <elliott@hp.com>
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
On win8 and win8 r2 hosts force SPC-3 compliance for MSFT virtual disks.
Ubuntu has been carrying a similar patch outside the tree for a while now.
Starting with win10, the host will support SPC-3 compliance. Based on all
the testing that has been done on win8 and win8 r2 hosts, we are comfortable
claiming SPC-3 compliance on these hosts as well. This will enable TRIM
support on these hosts.
Suggested by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Commit 4cd83ecdac changed the limits to
reflect the values on the host. It turns out that WS2008R2 cannot
correctly handle these new limits. Fix this bug by setting the limits
based on the host.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Reviewed-by: Long Li <longli@microsoft.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
