Currently this driver only works with a DesignWare DMA engine which it
registers manually using the second "reg" address range and interrupt
number from the DT node.

This patch makes the driver instead use the "dmas" property if present,
otherwise optionally falling back on the old way so existing device
trees can continue to work.

With this change, there is no longer any reason to depend on the 460EX
machine type so drop that from Kconfig.
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NMans Rullgard <mans@mansr.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

ata_sff_qc_issue() can't handle DMA commands and thus we have to avoid it for
them. Do call ata_bmdma_qc_issue() instead for this case. Note that the former
one distinguishes PIO and DMA mode and behaves accordingly.
Suggested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Calling dmaengine_prep_slave_sg() for non-dma ATA commands is
unnecessary at best and could be harmful if the dma driver reacts
badly to this.  It also causes this driver to print a bogus error
message in these cases.

This patch changes sata_dwc_qc_issue() to only do the dma setup
for dma commands and also reports an error to libata if if fails.
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NMans Rullgard <mans@mansr.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

There is no need to have a platform driver compiled since the DMA driver is
used as a library.
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

In the original code the DMA is always a flow controller. Set this accordingly
in updated code.
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The burst size as defined by DMAengine API is in items of address width. Derive
burst size from AHB_DMA_BRST_DFLT (64 bytes) by dividing it to
DMA_SLAVE_BUSWIDTH_4_BYTES (4 bytes) that gives us 16 items.
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The original code states:

	Make sure a LLI block is not created that will span 8K max FIS
	boundary. If the block spans such a FIS boundary, there is a chance
	that a DMA burst will cross that boundary -- this results in an error
	in the host controller.

Since we have switched to generic DMAengine API we satisfy above by setting
dma_boundary value to 0x1fff.
Suggested-by: NMans Rullgard <mans@mansr.com>
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch fixes Machine Check "Data Write PLB Error" which happens
when libata-sff's ata_sff_dev_select is trying to write into the
device_addr in order to select a drive. However, SATA has no master
or slave devices like the old ATA Bus, therefore selecting a
different drive is kind of pointless.

Data Write PLB Error
Oops: Machine check, sig: 7 [#1]
PowerPC 44x Platform
Modules linked in:
CPU: 0 PID: 508 Comm: scsi_eh_0 Not tainted 4.6.0-rc3-next-20160412+ #10
[...]
NIP [c027e820] ata_sff_dev_select+0x3c/0x44
LR [c027e810] ata_sff_dev_select+0x2c/0x44
Call Trace:
[cec31cd0] [c027da00] ata_sff_postreset+0x40/0xb4 (unreliable)
[cec31ce0] [c027a03c] ata_eh_reset+0x5cc/0x928
[cec31d60] [c027a840] ata_eh_recover+0x330/0x10bc
[cec31df0] [c027bae0] ata_do_eh+0x4c/0xa4
[...]
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

This lock is already taken in ata_scsi_queuecmd() a few levels up the
call stack so attempting to take it here is an error.  Moreover, it is
pointless in the first place since it only protects a single, atomic
assignment.

Enabling lock debugging gives the following output:

=============================================
[ INFO: possible recursive locking detected ]
4.4.0-rc5+ #189 Not tainted
---------------------------------------------
kworker/u2:3/37 is trying to acquire lock:
 (&(&host->lock)->rlock){-.-...}, at: [<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c

but task is already holding lock:
 (&(&host->lock)->rlock){-.-...}, at: [<902761ac>] ata_scsi_queuecmd+0x2c/0x330

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&(&host->lock)->rlock);
  lock(&(&host->lock)->rlock);

 *** DEADLOCK ***
 May be due to missing lock nesting notation

4 locks held by kworker/u2:3/37:
 #0:  ("events_unbound"){.+.+.+}, at: [<9003a0a4>] process_one_work+0x12c/0x430
 #1:  ((&entry->work)){+.+.+.}, at: [<9003a0a4>] process_one_work+0x12c/0x430
 #2:  (&bdev->bd_mutex){+.+.+.}, at: [<9011fd54>] __blkdev_get+0x50/0x380
 #3:  (&(&host->lock)->rlock){-.-...}, at: [<902761ac>] ata_scsi_queuecmd+0x2c/0x330

stack backtrace:
CPU: 0 PID: 37 Comm: kworker/u2:3 Not tainted 4.4.0-rc5+ #189
Workqueue: events_unbound async_run_entry_fn
Stack : 90b38e30 00000021 00000003 9b2a6040 00000000 9005f3f0 904fc8dc 00000025
        906b96e4 00000000 90528648 9b3336c4 904fc8dc 9009bf18 00000002 00000004
        00000000 00000000 9b3336c4 9b3336e4 904fc8dc 9003d074 00000000 90500000
        9005e738 00000000 00000000 00000000 00000000 00000000 00000000 00000000
        6e657665 755f7374 756f626e 0000646e 00000000 00000000 9b00ca00 9b025000
          ...
Call Trace:
[<90009d6c>] show_stack+0x88/0xa4
[<90057744>] __lock_acquire+0x1ce8/0x2154
[<900583e4>] lock_acquire+0x64/0x8c
[<9045ff10>] _raw_spin_lock_irqsave+0x54/0x78
[<90283294>] sata_dwc_exec_command_by_tag.constprop.14+0x44/0x8c
[<90283484>] sata_dwc_qc_issue+0x1a8/0x24c
[<9026b39c>] ata_qc_issue+0x1f0/0x410
[<90273c6c>] ata_scsi_translate+0xb4/0x200
[<90276234>] ata_scsi_queuecmd+0xb4/0x330
[<9025800c>] scsi_dispatch_cmd+0xd0/0x128
[<90259934>] scsi_request_fn+0x58c/0x638
[<901a3e50>] __blk_run_queue+0x40/0x5c
[<901a83d4>] blk_queue_bio+0x27c/0x28c
[<901a5914>] generic_make_request+0xf0/0x188
[<901a5a54>] submit_bio+0xa8/0x194
[<9011adcc>] submit_bh_wbc.isra.23+0x15c/0x17c
[<9011c908>] block_read_full_page+0x3e4/0x428
[<9009e2e0>] do_read_cache_page+0xac/0x210
[<9009fd90>] read_cache_page+0x18/0x24
[<901bbd18>] read_dev_sector+0x38/0xb0
[<901bd174>] msdos_partition+0xb4/0x5c0
[<901bcb8c>] check_partition+0x140/0x274
[<901bba60>] rescan_partitions+0xa0/0x2b0
[<9011ff68>] __blkdev_get+0x264/0x380
[<901201ac>] blkdev_get+0x128/0x36c
[<901b9378>] add_disk+0x3c0/0x4bc
[<90268268>] sd_probe_async+0x100/0x224
[<90043a44>] async_run_entry_fn+0x50/0x124
[<9003a11c>] process_one_work+0x1a4/0x430
[<9003a4f4>] worker_thread+0x14c/0x4fc
[<900408f4>] kthread+0xd0/0xe8
[<90004338>] ret_from_kernel_thread+0x14/0x1c

Fixes: 62936009 ("[libata] Add 460EX on-chip SATA driver, sata_dwc_460ex")
Tested-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NMans Rullgard <mans@mansr.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

We pass struct dw_dma_chip to dw_dma_probe() anyway, thus we may use it to
pass a platform data as well.

While here, constify the source of the platform data.
Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The source and destination masters are reflecting buses or their layers to
where the different devices can be connected. The patch changes the master
names to reflect which one is related to which independently on the transfer
direction.

The outcome of the change is that the memory data width is now always limited
by a data width of the master which is dedicated to communicate to memory.

The patch will not break anything since all current users have the same data
width for all masters. Though it would be nice to revisit avr32 platforms to
check what is the actual hardware topology in use there. It seems that it has
one bus and two masters on it as stated by Table 8-2, that's why everything
works independently on the master in use. The purpose of the sequential patch
is to fix the driver for configuration of more than one bus.

The change is done in the assumption that src_master and dst_master are
reflecting a connection to the memory and peripheral correspondently on avr32
and otherwise on the rest.
Acked-by: NHans-Christian Egtvedt <egtvedt@samfundet.no>
Acked-by: NMark Brown <broonie@kernel.org>
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NVinod Koul <vinod.koul@intel.com>

The new helper returns index of the mathing string in an array.  We
would use it here.
Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: NTejun Heo <tj@kernel.org>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If the call to acpi_get_object_info() fails then "info" hasn't been
initialized.  In that situation, we already know that "version" should
be XGENE_AHCI_V1 so we don't actually need to dereference "info".

Fixes: c9802a4b ('ata: ahci_xgene: Add AHCI Support for 2nd HW version of APM X-Gene SoC AHCI SATA Host controller.')
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

These PCI device IDs have been removed from the Intel Lewisburg design
specification. They are no longer needed.
Signed-off-by: NScott Lawson <scott.lawson@intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.

This is part of an ongoing process to migrate from ARCH_SHMOBILE to
ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>
Signed-off-by: NTejun Heo <tj@kernel.org>
Acked-by: NGeert Uytterhoeven <geert+renesas@glider.be>

The HPCP bit is set by bioses for on-board sata ports either because
they think sata is hotplug capable in general or to allow Windows
to display a "device eject" icon on ports which are routed to an
external connector bracket.

However in Redhat Bugzilla #1310682, users report that with kernel 4.4,
where this bit test first appeared, a lot of partitions on sata drives
are now mounted automatically.

This patch should fix redhat and a lot of other distros which
unconditionally automount all devices which have the "removable"
bit set.
Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Fixes: 8a3e33cf ("ata: ahci: find eSATA ports and flag them as removable" changes userspace behavior)
Link: http://lkml.kernel.org/g/56CF35FA.1070500@redhat.com
Cc: stable@vger.kernel.org #v4.4+

Due to Errata in ThunderX, HOST_IRQ_STAT should be
cleared before leaving the interrupt handler.
The patch attempts to satisfy the need.

Changes from V2:
	- removed newfile
	- code is now under CONFIG_ARM64

Changes from V1:
	- Rebased on top of libata/for-4.6
        - Moved ThunderX intr handler to new file

tj: Minor adjustments to comments.
Signed-off-by: NTirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Enable IRQ on hotplug and add an interrupt handler to handle it.

This allows hotplug to work:
ata5: exception Emask 0x10 SAct 0x0 SErr 0x70000 action 0xe frozen
ata5: SError: { PHYRdyChg PHYInt CommWake }
ata5: hard resetting link
ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata5.00: LPM support broken, forcing max_power
ata5.00: ATA-7: WDC WD800JD-75MSA3, 10.01E04, max UDMA/133
ata5.00: 156250000 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata5.00: LPM support broken, forcing max_power
ata5.00: configured for UDMA/133
ata5: EH complete
scsi 4:0:0:0: Direct-Access     ATA      WDC WD800JD-75MS 1E04 PQ: 0 ANSI: 5
sd 4:0:0:0: [sdb] 156250000 512-byte logical blocks: (80.0 GB/74.5 GiB)
sd 4:0:0:0: [sdb] Write Protect is off
sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 4:0:0:0: Attached scsi generic sg1 type 0
sd 4:0:0:0: [sdb] Attached SCSI disk

And also hot unplug:
ata5: exception Emask 0x10 SAct 0x0 SErr 0x1b0000 action 0xe frozen
ata5: SError: { PHYRdyChg PHYInt 10B8B Dispar }
ata5: hard resetting link
ata5: SATA link down (SStatus 0 SControl 310)
ata5: hard resetting link
ata5: SATA link down (SStatus 0 SControl 310)
ata5: hard resetting link
ata5: SATA link down (SStatus 0 SControl 310)
ata5.00: disabled
ata5: EH complete
ata5.00: detaching (SCSI 4:0:0:0)
sd 4:0:0:0: [sdb] Synchronizing SCSI cache
sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
sd 4:0:0:0: [sdb] Stopping disk
sd 4:0:0:0: [sdb] Start/Stop Unit failed: Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

Currently, workaround for broken WD drives is applied always, slowing
down all drives. And it has a bug - it's not applied after resume.

Apply the workaround only if the error really appears
(SErr == 0x1000500). This allows unaffected drives to run at full speed
(provided that no affected drive is connected to the controller).
Also make sure the workaround is re-applied on resume.

Tested on VT6421.
As SCR registers access is known to cause problems on VT6420 (and I
don't have it to test), keep the workaround applied always on VT6420.

Unaffected drive (Hitachi HDS721680PLA380):
Before:
$ hdparm -t --direct /dev/sdb
/dev/sdb:
 Timing O_DIRECT disk reads: 160 MB in  3.01 seconds =  53.16 MB/sec

After:
$ hdparm -t --direct /dev/sdb
/dev/sdb:
 Timing O_DIRECT disk reads: 200 MB in  3.01 seconds =  66.47 MB/sec

Affected drive (WDC WD5003ABYX-18WERA0):
Before:
$ hdparm -t --direct /dev/sda

/dev/sda:
 Timing O_DIRECT disk reads: 180 MB in  3.02 seconds =  59.51 MB/sec

After:
$ hdparm -t --direct /dev/sdb
/dev/sdb:
 Timing O_DIRECT disk reads: 156 MB in  3.03 seconds =  51.48 MB/sec
$ hdparm -t --direct /dev/sdb
/dev/sdb:
 Timing O_DIRECT disk reads: 180 MB in  3.02 seconds =  59.64 MB/sec

The first hdparm is slower because of the error:
[   50.408042] ata5: Incompatible drive: enabling workaround. This slows down transfer rate to ~60 MB/s
[   50.728052] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[   50.744834] ata5.00: configured for UDMA/133
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

This patch adds runtime PM support for the AHCI host controller driver so
that the host controller is powered down when all SATA ports are runtime
suspended. Powering down the AHCI host controller can reduce power
consumption and possibly allow the CPU to enter lower power idle states
(S0ix) during runtime.

Runtime PM is blocked by default and needs to be unblocked from userspace
as needed (via power/* sysfs nodes).
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Add new functions ahci_rpm_get_port()/ahci_rpm_put_port() that change
runtime PM status of AHCI ports. Depending if the AHCI host has runtime PM
enabled or disabled calling these may trigger runtime suspend/resume of the
host controller.

We also call these functions in appropriate places to make sure host
controller registers are available before using them.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

In order to add support for runtime PM to the ahci driver we first need to
convert the driver to use modern non-legacy system suspend hooks. There
should be no functional changes.

tj: Updated .driver.pm init for older compilers as suggested by Andy
    and Chrsitoph.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

This allows sysfs nodes to read the cached value directly instead of
powering up possibly runtime suspended controller.
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The main difference in the new Armada 3700 is that no address
decoding needs to take place in the driver probe.

[gregory.clement@free-electrons.com: reformulate the commit log]
Signed-off-by: NLior Amsalem <alior@marvell.com>
Reviewed-by: NNadav Haklai <nadavh@marvell.com>
Tested-by: NNadav Haklai <nadavh@marvell.com>
Signed-off-by: NGregory CLEMENT <gregory.clement@free-electrons.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

ata_scsi_park_show() was pairing spin_lock_irqsave() with
spin_unlock_irq().  As the function is always called with irq enabled,
it didn't actually break anything.  Use spin_lock_irq() instead.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Elias Oltmanns <eo@nebensachen.de>

This patch complements the list of device IDs previously
added for lewisburg sata.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

The RB532 platform specific irq_to_gpio() implementation has been
removed with commit 832f5dac ("MIPS: Remove all the uses of
custom gpio.h"). Now the platform uses the generic stub which causes
the following error:

  pata-rb532-cf pata-rb532-cf: no GPIO found for irq149
  pata-rb532-cf: probe of pata-rb532-cf failed with error -2

Drop the irq_to_gpio() call and get the GPIO number from platform
data instead. After this change, the driver works again:

  scsi host0: pata-rb532-cf
  ata1: PATA max PIO4 irq 149
  ata1.00: CFA: CF 1GB, 20080820, max MWDMA4
  ata1.00: 1989792 sectors, multi 0: LBA
  ata1.00: configured for PIO4
  scsi 0:0:0:0: Direct-Access     ATA      CF 1GB           0820 PQ: 0\
  ANSI: 5
  sd 0:0:0:0: [sda] 1989792 512-byte logical blocks: (1.01 GB/971 MiB)
  sd 0:0:0:0: [sda] Write Protect is off
  sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't\
  support DPO or FUA
   sda: sda1 sda2
  sd 0:0:0:0: [sda] Attached SCSI disk

Fixes: 832f5dac ("MIPS: Remove all the uses of custom gpio.h")
Cc: Alban Bedel <albeu@free.fr>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: <stable@vger.kernel.org> #v4.3+
Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
Signed-off-by: NTejun Heo <tj@kernel.org>

Most arches have an asm/gpio.h that merely includes linux/gpio.h.  The
others select ARCH_HAVE_CUSTOM_GPIO_H, and when that's selected,
linux/gpio.h includes asm/gpio.h.

Therefore, code should include linux/gpio.h instead of including asm/gpio.h
directly.

Remove includes of asm/gpio.h, adding an include of linux/gpio.h when
necessary.

This is a follow-on to 7563bbf8 ("gpiolib/arches: Centralise
bolierplate asm/gpio.h").
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

The OCTEON SATA controller is currently found on cn71XX devices.
Acked-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid Daney <david.daney@cavium.com>
Signed-off-by: NVinita Gupta <vgupta@caviumnetworks.com>
Signed-off-by: NAleksey Makarov <aleksey.makarov@auriga.com>
Signed-off-by: NZubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

As reported by Soohoon Lee, the HDIO_GET_32BIT ioctl does not
work correctly in compat mode with libata.

I have investigated the issue further and found multiple problems
that all appeared with the same commit that originally introduced
HDIO_GET_32BIT handling in libata back in linux-2.6.8 and presumably
also linux-2.4, as the code uses "copy_to_user(arg, &val, 1)" to copy
a 'long' variable containing either 0 or 1 to user space.

The problems with this are:

* On big-endian machines, this will always write a zero because it
  stores the wrong byte into user space.

* In compat mode, the upper three bytes of the variable are updated
  by the compat_hdio_ioctl() function, but they now contain
  uninitialized stack data.

* The hdparm tool calling this ioctl uses a 'static long' variable
  to store the result. This means at least the upper bytes are
  initialized to zero, but calling another ioctl like HDIO_GET_MULTCOUNT
  would fill them with data that remains stale when the low byte
  is overwritten. Fortunately libata doesn't implement any of the
  affected ioctl commands, so this would only happen when we query
  both an IDE and an ATA device in the same command such as
  "hdparm -N -c /dev/hda /dev/sda"

* The libata code for unknown reasons started using ATA_IOC_GET_IO32
  and ATA_IOC_SET_IO32 as aliases for HDIO_GET_32BIT and HDIO_SET_32BIT,
  while the ioctl commands that were added later use the normal
  HDIO_* names. This is harmless but rather confusing.

This addresses all four issues by changing the code to use put_user()
on an 'unsigned long' variable in HDIO_GET_32BIT, like the IDE subsystem
does, and by clarifying the names of the ioctl commands.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Reported-by: NSoohoon Lee <Soohoon.Lee@f5.com>
Tested-by: NSoohoon Lee <Soohoon.Lee@f5.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTejun Heo <tj@kernel.org>

ahci_xgene: Implement the workaround to fix the missing of the edge interrupt for the HOST_IRQ_STAT.

Due to H/W errata, the HOST_IRQ_STAT register misses the edge interrupt
when clearing the HOST_IRQ_STAT register and hardware reporting the
PORT_IRQ_STAT register happens to be at the same clock cycle.
Signed-off-by: NSuman Tripathi <stripathi@apm.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The flexibility to override the irq handles in the LLD's are already
present, so controllers implementing a edge trigger latch can
implement their own interrupt handler inside the driver.  This patch
removes the AHCI_HFLAG_EDGE_IRQ support from libahci and moves edge
irq handling to ahci_xgene.

tj: Minor update to description.
Signed-off-by: NSuman Tripathi <stripathi@apm.com>
Signed-off-by: NTejun Heo <tj@kenrel.org>

This patch implements the capability to override the generic AHCI
interrupt handler so that specific ahci drivers can implement their
own custom interrupt handler routines.  It also exports
ahci_handle_port_intr so that custom irq_handler implementations can
use it.

tj: s/ahci_irq_handler/irq_handler/ and updated description.
Signed-off-by: NSuman Tripathi <stripathi@apm.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

Adding Intel codename DNV platform device IDs for SATA.
Signed-off-by: NAlexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org

Drivers should include asm/pci-bridge.h only when they need the arch-
specific things provided there.  Outside of the arch/ directories, the only
drivers that actually need things provided by asm/pci-bridge.h are the
powerpc RPA hotplug drivers in drivers/pci/hotplug/rpa*.

Remove the includes of asm/pci-bridge.h from the other drivers, adding an
include of linux/pci.h if necessary.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>

The bulk of ATA host state machine is implemented by
ata_sff_hsm_move().  The function is called from either the interrupt
handler or, if polling, a work item.  Unlike from the interrupt path,
the polling path calls the function without holding the host lock and
ata_sff_hsm_move() selectively grabs the lock.

This is completely broken.  If an IRQ triggers while polling is in
progress, the two can easily race and end up accessing the hardware
and updating state machine state at the same time.  This can put the
state machine in an illegal state and lead to a crash like the
following.

  kernel BUG at drivers/ata/libata-sff.c:1302!
  invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
  Modules linked in:
  CPU: 1 PID: 10679 Comm: syz-executor Not tainted 4.5.0-rc1+ #300
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  task: ffff88002bd00000 ti: ffff88002e048000 task.ti: ffff88002e048000
  RIP: 0010:[<ffffffff83a83409>]  [<ffffffff83a83409>] ata_sff_hsm_move+0x619/0x1c60
  ...
  Call Trace:
   <IRQ>
   [<ffffffff83a84c31>] __ata_sff_port_intr+0x1e1/0x3a0 drivers/ata/libata-sff.c:1584
   [<ffffffff83a85611>] ata_bmdma_port_intr+0x71/0x400 drivers/ata/libata-sff.c:2877
   [<     inline     >] __ata_sff_interrupt drivers/ata/libata-sff.c:1629
   [<ffffffff83a85bf3>] ata_bmdma_interrupt+0x253/0x580 drivers/ata/libata-sff.c:2902
   [<ffffffff81479f98>] handle_irq_event_percpu+0x108/0x7e0 kernel/irq/handle.c:157
   [<ffffffff8147a717>] handle_irq_event+0xa7/0x140 kernel/irq/handle.c:205
   [<ffffffff81484573>] handle_edge_irq+0x1e3/0x8d0 kernel/irq/chip.c:623
   [<     inline     >] generic_handle_irq_desc include/linux/irqdesc.h:146
   [<ffffffff811a92bc>] handle_irq+0x10c/0x2a0 arch/x86/kernel/irq_64.c:78
   [<ffffffff811a7e4d>] do_IRQ+0x7d/0x1a0 arch/x86/kernel/irq.c:240
   [<ffffffff86653d4c>] common_interrupt+0x8c/0x8c arch/x86/entry/entry_64.S:520
   <EOI>
   [<     inline     >] rcu_lock_acquire include/linux/rcupdate.h:490
   [<     inline     >] rcu_read_lock include/linux/rcupdate.h:874
   [<ffffffff8164b4a1>] filemap_map_pages+0x131/0xba0 mm/filemap.c:2145
   [<     inline     >] do_fault_around mm/memory.c:2943
   [<     inline     >] do_read_fault mm/memory.c:2962
   [<     inline     >] do_fault mm/memory.c:3133
   [<     inline     >] handle_pte_fault mm/memory.c:3308
   [<     inline     >] __handle_mm_fault mm/memory.c:3418
   [<ffffffff816efb16>] handle_mm_fault+0x2516/0x49a0 mm/memory.c:3447
   [<ffffffff8127dc16>] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
   [<ffffffff8127e358>] trace_do_page_fault+0xe8/0x420 arch/x86/mm/fault.c:1331
   [<ffffffff8126f514>] do_async_page_fault+0x14/0xd0 arch/x86/kernel/kvm.c:264
   [<ffffffff86655578>] async_page_fault+0x28/0x30 arch/x86/entry/entry_64.S:986

Fix it by ensuring that the polling path is holding the host lock
before entering ata_sff_hsm_move() so that all hardware accesses and
state updates are performed under the host lock.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-and-tested-by: NDmitry Vyukov <dvyukov@google.com>
Link: http://lkml.kernel.org/g/CACT4Y+b_JsOxJu2EZyEf+mOXORc_zid5V1-pLZSroJVxyWdSpw@mail.gmail.com
Cc: stable@vger.kernel.org

ata_sff_hsm_move() triggers BUG if it sees a host state machine state
that it dind't expect.  The risk for data corruption when the
condition occurs is low as it's highly unlikely that it would lead to
spurious completion of commands.  The BUG occasionally triggered for
subtle race conditions in the driver.  Let's downgrade it to WARN so
that it doesn't kill the machine unnecessarily.
Signed-off-by: NTejun Heo <tj@kernel.org>
Cc: Dmitry Vyukov <dvyukov@google.com>

Some early controllers incorrectly reported zero ports in PORTS_IMPL
register and the ahci driver fabricates PORTS_IMPL from the number of
ports in those cases.  This hasn't mattered but with the new nvme
controllers there are cases where zero PORTS_IMPL is valid and should
be honored.

Disable the workaround for >= AHCI 1.3.
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NAndy Lutomirski <luto@amacapital.net>
Link: http://lkml.kernel.org/g/CALCETrU7yMvXEDhjAUShoHEhDwifJGapdw--BKxsP0jmjKGmRw@mail.gmail.com
Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: stable@vger.kernel.org

Viking flash model VRFDFC22048UCHC-TE causes data corruption in MWDMA mode.

Cc: xe-kernel@external.cisco.com
Signed-off-by: NShikha Jain <shikjain@cisco.com>
Signed-off-by: NAnil Veliyankara Madam <aveliyan@cisco.com>
Signed-off-by: NTejun Heo <tj@kernel.org>

The AHCI driver code stops and starts port DMA engines at will
without considering the power state of the particular port. The
AHCI specification isn't very clear on how to handle this scenario,
leaving implementation open to interpretation.

Broadcom's STB SATA host controller is unable to handle port DMA
controller restarts when the port in question is in low power mode.
When a port enters partial or slumber mode, its PHY is powered down.
When a controller restart is requested, the controller's internal
state machine expects the PHY to be brought back up by software which
never happens in this case, resulting in failures.

To avoid this situation, logic is added to manually wake up the port
just before its DMA engine is stopped, if the port happens to be in
a low power state. HBA initiated power management ensures that the port
eventually returns to its configured low power state, when the link is
idle (as per the conditions listed in the spec). A new host flag is also
added to ensure this logic is only exercised for hosts with the above
limitation.

tj: Formatting changes.
Signed-off-by: NDanesh Petigara <dpetigara@broadcom.com>
Reviewed-by: NMarkus Mayer <mmayer@broadcom.com>
Signed-off-by: NTejun Heo <tj@kernel.org>