Crucial M550 may cause data corruption on queued trims and is
blacklisted. The pattern used for it fails to match 1TB one as the
capacity section will be four chars instead of three. Widen the
pattern.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Charles Reiss <woggling@gmail.com>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=81071
Cc: stable@vger.kernel.org
The function may be useful for other drivers, so export it. (Suggested
by Tejun Heo.)
Note that I inverted the return value of glob_match; returning true on
match seemed to make more sense.
Signed-off-by: George Spelvin <linux@horizon.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The sata on fsl mpc8315e is broken after the commit 8a4aeec8d2
("libata/ahci: accommodate tag ordered controllers"). The reason is
that the ata controller on this SoC only implement a queue depth of
16. When issuing the commands in tag order, all the commands in tag
16 ~ 31 are mapped to tag 0 unconditionally and then causes the sata
malfunction. It makes no senses to use a 32 queue in software while
the hardware has less queue depth. So consider the queue depth
implemented by the hardware when requesting a command tag.
Fixes: 8a4aeec8d2 ("libata/ahci: accommodate tag ordered controllers")
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Queued trim only works for some users with MU05 firmware. Revert to
blacklisting all firmware versions.
Introduced by commit d121f7d0cb ("libata: Update queued trim blacklist
for M5x0 drives") which this effectively reverts, while retaining the
blacklisting of M550.
See
https://bugzilla.kernel.org/show_bug.cgi?id=71371
for reports of trouble with MU05 firmware.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull libata fixes from Tejun Heo:
"Mostly device-specific fixes. The only thing which isn't is the fix
for zpodd oops-on-detach bug"
* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
ahci: imx: PLL clock needs 100us to settle down
ata: pata_at91 only works on sam9
libata: clean up ZPODD when a port is detached
ahci: imx: software workaround for phy reset issue in resume
ahci: imx: add namespace for register enums
ahci: disable DEVSLP for Intel Valleyview
When a ZPODD device is unbound via sysfs, the ACPI notify handler
is not removed. This causes panics as observed in Bug #74601. The
panic only happens when the wake happens from outside the kernel
(i.e. inserting a media or pressing a button). Add a loop to
ata_port_detach which loops through the port's devices and checks
if zpodd is enabled, if so call zpodd_exit.
Cc: stable@vger.kernel.org
Reviewed-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Levente Kurusa <levex@linux.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Pull libata fixes from Tejun Heo:
"Dan updated tag allocation to accomodate devices which choke when tags
jump back and forth. Quite a few ahci MSI related fixes. A couple
config dependency fixes and other misc fixes"
* 'for-3.15-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
libata/ahci: accommodate tag ordered controllers
ahci: Do not receive interrupts sent by dummy ports
ahci: Use pci_enable_msi_exact() instead of pci_enable_msi_range()
ahci: Ensure "MSI Revert to Single Message" mode is not enforced
ahci: do not request irq for dummy port
pata_samsung_cf: fix ata_host_activate() failure handling
pata_arasan_cf: fix ata_host_activate() failure handling
ata: fix i.MX AHCI driver dependencies
pata_at91: fix ata_host_activate() failure handling
libata: Update queued trim blacklist for M5x0 drives
libata: make AHCI_XGENE depend on PHY_XGENE
The AHCI spec allows implementations to issue commands in tag order
rather than FIFO order:
5.3.2.12 P:SelectCmd
HBA sets pSlotLoc = (pSlotLoc + 1) mod (CAP.NCS + 1)
or HBA selects the command to issue that has had the
PxCI bit set to '1' longer than any other command
pending to be issued.
The result is that commands posted sequentially (time-wise) may play out
of sequence when issued by hardware.
This behavior has likely been hidden by drives that arrange for commands
to complete in issue order. However, it appears recent drives (two from
different vendors that we have found so far) inflict out-of-order
completions as a matter of course. So, we need to take care to maintain
ordered submission, otherwise we risk triggering a drive to fall out of
sequential-io automation and back to random-io processing, which incurs
large latency and degrades throughput.
This issue was found in simple benchmarks where QD=2 seq-write
performance was 30-50% *greater* than QD=32 seq-write performance.
Tagging for -stable and making the change globally since it has a low
risk-to-reward ratio. Also, word is that recent versions of an unnamed
OS also does it this way now. So, drives in the field are already
experienced with this tag ordering scheme.
Cc: <stable@vger.kernel.org>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: Ed Ciechanowski <ed.ciechanowski@intel.com>
Reviewed-by: Matthew Wilcox <matthew.r.wilcox@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Crucial/Micron M500 drives properly support queued DSM TRIM starting
with firmware MU05. Update the blacklist so we only disable queued trim
for older firmware releases.
Early M550 series drives suffer from the same issue as M500. A bugfix
firmware is in the pipeline but not ready yet. Until then, blacklist
queued trim for M550.
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Cc: Chris Samuel <chris@csamuel.org>
Cc: Marc MERLIN <marc@merlins.org>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Pull libata updates from Tejun Heo:
"A lot of activities on libata side this time.
- A lot of changes around ahci. Various embedded platforms are
implementing ahci controllers. Some were built atop ahci_platform,
others were doing their own things. Hans made some structural
changes to libahci and librarized ahci_platform so that ahci
platform drivers can share more common code. A couple platform
drivers are added on top of that and several are added to replace
older drivers which were doing their own things (older ones are
scheduled to be removed).
- Dan finishes the patchset to make libata PM operations
asynchronous. Combined with one patch being routed through scsi,
this should speed resume measurably.
- Various fixes and cleanups from Bartlomiej and others"
* 'for-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: (61 commits)
ata: fix Marvell SATA driver dependencies
ata: fix ARASAN CompactFlash PATA driver dependencies
ata: remove superfluous casts
ata: sata_highbank: remove superfluous cast
ata: fix Calxeda Highbank SATA driver dependencies
ata: fix R-Car SATA driver dependencies
ARM: davinci: da850: update SATA AHCI support
ata: add new-style AHCI platform driver for DaVinci DA850 AHCI controller
ata: move library code from ahci_platform.c to libahci_platform.c
ata: ahci_platform: fix ahci_platform_data->suspend method handling
libata: remove unused ata_sas_port_async_resume() stub
libata.h: add stub for ata_sas_port_resume
libata: async resume
libata, libsas: kill pm_result and related cleanup
ata: Fix compiler warning with APM X-Gene host controller driver
arm64: Add APM X-Gene SoC AHCI SATA host controller DTS entries
ata: Add APM X-Gene SoC AHCI SATA host controller driver
Documentation: Add documentation for the APM X-Gene SoC SATA host controller DTS binding
arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries
ata: ahci_sunxi: fix code formatting
...
Improve overall system resume time by making libata link recovery
actions asynchronous relative to other resume events.
Link resume operations are performed using the scsi_eh thread, so
commands, particularly the sd resume start/stop command, will be held
off until the device exits error handling. Libata already flushes eh
with ata_port_wait_eh() in the port teardown paths, so there are no
concerns with async operation colliding with the end-of-life of the
ata_port object. Also, libata-core is already careful to flush
in-flight pm operations before another round of pm starts on the given
ata_port.
Reference: https://01.org/suspendresume/blogs/tebrandt/2013/hard-disk-resume-optimization-simpler-approach
Cc: Len Brown <len.brown@intel.com>
Cc: Phillip Susi <psusi@ubuntu.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Todd Brandt <todd.e.brandt@linux.intel.com>
[djbw: rebase on cleanup patch, changelog wordsmithing]
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Tejun says:
"At least for libata, worrying about suspend/resume failures don't make
whole lot of sense. If suspend failed, just proceed with suspend. If
the device can't be woken up afterwards, that's that. There isn't
anything we could have done differently anyway. The same for resume, if
spinup fails, the device is dud and the following commands will invoke
EH actions and will eventually fail. Again, there really isn't any
*choice* to make. Just making sure the errors are handled gracefully
(ie. don't crash) and the following commands are handled correctly
should be enough."
The only libata user that actually cares about the result from a suspend
operation is libsas. However, it only cares about whether queuing a new
operation collides with an in-flight one. All libsas does with the
error is retry, but we can just let libata wait for the previous
operation before continuing.
Other cleanups include:
1/ Unifying all ata port pm operations on an ata_port_pm_ prefix
2/ Marking all ata port pm helper routines as returning void, only
ata_port_pm_ entry points need to fake a 0 return value.
3/ Killing ata_port_{suspend|resume}_common() in favor of calling
ata_port_request_pm() directly
4/ Killing the wrappers that just do a to_ata_port() conversion
5/ Clearly marking the entry points that do async operations with an
_async suffix.
Reference: http://marc.info/?l=linux-scsi&m=138995409532286&w=2
Cc: Phillip Susi <psusi@ubuntu.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Suggested-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Todd Brandt <todd.e.brandt@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
We're now blacklisting "Crucial_CT???M500SSD1" and
"Crucial_CT???M500SSD3". Also, "Micron_M500*" is blacklisted which is
about the same devices as the crucial branded ones. Let's merge the
two Crucial M500 entries and widen the match to
"Crucial_CT???M500SSD*" so that we don't have to fiddle with new
entries for similar devices.
Signed-off-by: Tejun Heo <tj@kernel.org>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: stable@vger.kernel.org
Via commit 87809942d3 "libata: add ATA_HORKAGE_BROKEN_FPDMA_AA quirk
for Seagate Momentus SpinPoint M8" we added a quirk for disks named
"ST1000LM024 HN-M101MBB" with firmware revision "2AR10001".
As reported on https://bugzilla.redhat.com/show_bug.cgi?id=1073901,
we need to also add firmware revision 2BA30001 as it is broken as well.
Reported-by: Nicholas <arealityfarbetween@googlemail.com>
Signed-off-by: Michele Baldessari <michele@acksyn.org>
Tested-by: Guilherme Amadio <guilherme.amadio@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
Queued TRIM commands cause problems and silent file system corruption
on Crucial M500 SSDs. This patch disables them for the mSATA model of
the drive.
Signed-off-by: Marios Andreopoulos <opensource@andmarios.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org # 3.12+
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=71371
This patch fix spelling typo in Documentation/DocBook.
It is because .html and .xml files are generated by make htmldocs,
I have to fix a typo within the source files.
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
For some reason, some early WD drives spin up and down drives
erratically when the link is put into slumber mode which can reduce
the life expectancy of the device significantly. Unfortunately, we
don't have full list of devices and given the nature of the issue it'd
be better to err on the side of false positives than the other way
around. Let's disable LPM on all WD devices which match one of the
known problematic model prefixes and are SATA-I.
As horkage list doesn't support matching SATA capabilities, this is
implemented as two horkages - WD_BROKEN_LPM and NOLPM. The former is
set for the known prefixes and sets the latter if the matched device
is SATA-I.
Note that this isn't optimal as this disables all LPM operations and
partial link power state reportedly works fine on these; however, the
way LPM is implemented in libata makes it difficult to precisely map
libata LPM setting to specific link power state. Well, these devices
are already fairly outdated. Let's just disable whole LPM for now.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Nikos Barkas <levelwol@gmail.com>
Reported-and-tested-by: Ioannis Barkas <risc4all@yahoo.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=57211
Cc: stable@vger.kernel.org
Certain drives cannot handle queued TRIM commands properly, even
though support is indicated in the IDENTIFY DEVICE buffer. This patch
allows for disabling the commands for the affected drives and apply it
to the Micron/Crucial M500 SSDs which exhibit incorrect protocol
behavior when issued queued TRIM commands, which could lead to silent
data corruption.
tj: Merged two unnecessarily split patches and made minor edits
including shortening horkage name.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Link: http://lkml.kernel.org/g/1387246554-7311-1-git-send-email-marc.ceeeee@gmail.com
Cc: stable@vger.kernel.org # 3.12+
We've received multiple reports in Fedora via (BZ 907193)
that the Seagate Momentus SpinPoint M8 errors out when enabling AA:
[ 2.555905] ata2.00: failed to enable AA (error_mask=0x1)
[ 2.568482] ata2.00: failed to enable AA (error_mask=0x1)
Add the ATA_HORKAGE_BROKEN_FPDMA_AA for this specific harddisk.
Reported-by: Nicholas <arealityfarbetween@googlemail.com>
Signed-off-by: Michele Baldessari <michele@acksyn.org>
Tested-by: Nicholas <arealityfarbetween@googlemail.com>
Acked-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
After commit bcdde7e221 (sysfs: make __sysfs_remove_dir() recursive)
Mika Westerberg sees traces analogous to the one below in Thunderbolt
hot-remove testing:
WARNING: CPU: 0 PID: 4 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()
sysfs group ffffffff81c6f1e0 not found for kobject 'host7'
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.12.0+ #13
Hardware name: /D33217CK, BIOS GKPPT10H.86A.0042.2013.0422.1439 04/22/2013
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
0000000000000009 ffff8801002459b0 ffffffff817daab1 ffff8801002459f8
ffff8801002459e8 ffffffff810436b8 0000000000000000 ffffffff81c6f1e0
ffff88006d440358 ffff88006d440188 ffff88006e8b4c28 ffff880100245a48
Call Trace:
[<ffffffff817daab1>] dump_stack+0x45/0x56
[<ffffffff810436b8>] warn_slowpath_common+0x78/0xa0
[<ffffffff81043727>] warn_slowpath_fmt+0x47/0x50
[<ffffffff811ad319>] ? sysfs_get_dirent_ns+0x49/0x70
[<ffffffff811ae526>] sysfs_remove_group+0xc6/0xd0
[<ffffffff81432f7e>] dpm_sysfs_remove+0x3e/0x50
[<ffffffff8142a0d0>] device_del+0x40/0x1b0
[<ffffffff8142a24d>] device_unregister+0xd/0x20
[<ffffffff8144131a>] scsi_remove_host+0xba/0x110
[<ffffffff8145f526>] ata_host_detach+0xc6/0x100
[<ffffffff8145f578>] ata_pci_remove_one+0x18/0x20
[<ffffffff812e8f48>] pci_device_remove+0x28/0x60
[<ffffffff8142d854>] __device_release_driver+0x64/0xd0
[<ffffffff8142d8de>] device_release_driver+0x1e/0x30
[<ffffffff8142d257>] bus_remove_device+0xf7/0x140
[<ffffffff8142a1b1>] device_del+0x121/0x1b0
[<ffffffff812e43d4>] pci_stop_bus_device+0x94/0xa0
[<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
[<ffffffff812e437b>] pci_stop_bus_device+0x3b/0xa0
[<ffffffff812e44dd>] pci_stop_and_remove_bus_device+0xd/0x20
[<ffffffff812fc743>] trim_stale_devices+0x73/0xe0
[<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
[<ffffffff812fc78b>] trim_stale_devices+0xbb/0xe0
[<ffffffff812fcb6e>] acpiphp_check_bridge+0x7e/0xd0
[<ffffffff812fd90d>] hotplug_event+0xcd/0x160
[<ffffffff812fd9c5>] hotplug_event_work+0x25/0x60
[<ffffffff81316749>] acpi_hotplug_work_fn+0x17/0x22
[<ffffffff8105cf3a>] process_one_work+0x17a/0x430
[<ffffffff8105db29>] worker_thread+0x119/0x390
[<ffffffff8105da10>] ? manage_workers.isra.25+0x2a0/0x2a0
[<ffffffff81063a5d>] kthread+0xcd/0xf0
[<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180
[<ffffffff817eb33c>] ret_from_fork+0x7c/0xb0
[<ffffffff81063990>] ? kthread_create_on_node+0x180/0x180
The source of this problem is that SCSI hosts are removed from
ATA ports after calling ata_tport_delete() which removes the
port's sysfs directory, among other things. Now, after commit
bcdde7e221, the sysfs directory is removed along with all of
its subdirectories that include the SCSI host's sysfs directory
and its subdirectories at this point. Consequently, when
device_del() is finally called for any child device of the SCSI
host and tries to remove its "power" group (which is already
gone then), it triggers the above warning.
To make the warnings go away, change the removal ordering in
ata_port_detach() so that the SCSI host is removed from the
port before ata_tport_delete() is called.
References: https://bugzilla.kernel.org/show_bug.cgi?id=65281
Reported-and-tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Tested-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
The endianness attribute on the 'aux' local variable is wrong, and can
lead to wrong endianness on big-endian machines,
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Add support for the following ATA opcodes, which are present
in SATA 3.1 and T13 ATA ACS-3:
SEND FPDMA QUEUED
RECEIVE FPDMA QUEUED
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
SATA 3.1 added an "auxiliary" field to the host-to-device FIS.
Populate the host-to-device FIS with the new field via the
taskfile struct.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Binding ACPI handle to SCSI device has several drawbacks, namely:
1 During ATA device initialization time, ACPI handle will be needed
while SCSI devices are not created yet. So each time ACPI handle is
needed, instead of retrieving the handle by ACPI_HANDLE macro,
a namespace scan is performed to find the handle for the corresponding
ATA device. This is inefficient, and also expose a restriction on
calling path not holding any lock.
2 The binding to SCSI device tree makes code complex, while at the same
time doesn't bring us any benefit. All ACPI handlings are still done
in ATA module, not in SCSI.
Rework the ATA ACPI binding code to bind ACPI handle to ATA transport
devices(ATA port and ATA device). The binding needs to be done only once,
since the ATA transport devices do not go away with hotplug. And due to
this, the flush_work call in hotplug handler for ATA bay is no longer
needed.
Tested on an Intel test platform for binding and runtime power off for
ODD(ZPODD) and hard disk; on an ASUS S400C for binding and normal boot
and S3, where its SATA port node has _SDD and _GTF control methods when
configured as an AHCI controller and its PATA device node has _GTF
control method when configured as an IDE controller. SATA PMP binding
and ATA hotplug is not tested.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Tested-by: Dirk Griesbach <spamthis@freenet.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Pull libata updates from Tejun Heo:
"Overview of changes:
- The rest of maintainer email address updates.
- Some core updates - more robust default behavior for port
multipliers, better error reporting for SG_IO commands, and a way
to better work around now ancient and probably pretty rare PATA ->
SATA bridges with ATAPI devices.
- sata_rcar stabilization.
- Some hardware PCI ID additions and one-off low level driver
updates."
* 'for-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata: (22 commits)
AHCI: use ATA_BUSY
libata-zpodd: must use ata_tf_init()
ahci: AHCI-mode SATA patch for Intel Coleto Creek DeviceIDs
ata_piix: IDE-mode SATA patch for Intel Coleto Creek DeviceIDs
libata: cleanup SAT error translation
ahci: sata: add support for exynos5440 sata
libata: skip SRST for all SIMG [34]7x port-multipliers
ahci: remove pmp link online check in FBS EH
sata highbank: add bit-banged SGPIO driver support
ahci: make ahci_transmit_led_message into a function pointer
sata_rcar: fix compilation warning in sata_rcar_thaw()
sata_highbank: increase retry count but shorten duration for Calxeda controller
ata: use pci_get_drvdata()
ipr: qc_fill_rtf() method should not store alternate status register
sata_rcar: add 'base' local variable to some functions
sata_rcar: correct 'sata_rcar_sht'
sata_rcar: kill superfluous code in sata_rcar_bmdma_fill_sg()
libata: do not limit R-Car SATA driver to shmobile
ata: use platform_{get,set}_drvdata()
AHCI: Make distinct names for ports in /proc/interrupts
...
libata/for-3.10-fixes never got submitted during v3.10 cycle. Merge
it into for-3.11 so that it can be routed together with other changes
scheduled for v3.11.
Three trivial conflicts in drivers/ata/sata_rcar.c. All are caused by
1b20f6a9ad ("sata_rcar: add 'base' local variable to some functions")
conflicting with logic updates in for-3.10-fixes. The offending
commit simply adds local variable @base on functions which
dereferences sata_rcar_priv->base multiple times. The resolutions are
trivial - applying s/priv->base/base/ in the conflicting logic
updates.
Signed-off-by: Tejun Heo <tj@kernel.org>
Commit 30dcf76acc "libata: migrate ACPI code over to new bindings"
mistakenly dropped the code to register hotplug notificaion handler
for ATA port/devices, causing regression for people using ATA bay,
as kernel bug #59871 shows.
Fix this by adding back the hotplug notification handler registration
code. Since this code has to be run once and notification needs to
be installed on every ATA port/devices handle no matter if there is
actual device attached, we can't do this in binding time for ATA
device ACPI handle, as the binding only occurs when a SCSI device is
created, i.e. there is device attached. So introduce the
ata_acpi_hotplug_init() function to loop scan all ATA ACPI handles
and if it is available, install the notificaion handler for it during
ATA init time.
With the ATA ACPI handle binding to SCSI device tree, it is possible
now that when the SCSI hotplug work removes the SCSI device, the ACPI
unbind function will find that the corresponding ACPI device has
already been deleted by dock driver, causing a scaring message like:
[ 128.263966] scsi 4:0:0:0: Oops, 'acpi_handle' corrupt
Fix this by waiting for SCSI hotplug task finish in our notificaion
handler, so that the removal of ACPI device done in ACPI unbind
function triggered by the removal of SCSI device is run earlier when
ACPI device is still available.
[rjw: Rebased]
References: https://bugzilla.kernel.org/show_bug.cgi?id=59871
Reported-bisected-and-tested-by: Dirk Griesbach <spamthis@freenet.de>
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: 3.6+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The "runtime idle" helper routine, rpm_idle(), currently ignores
return values from .runtime_idle() callbacks executed by it.
However, it turns out that many subsystems use
pm_generic_runtime_idle() which checks the return value of the
driver's callback and executes pm_runtime_suspend() for the device
unless that value is not 0. If that logic is moved to rpm_idle()
instead, pm_generic_runtime_idle() can be dropped and its users
will not need any .runtime_idle() callbacks any more.
Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
ata_port_runtime_idle(), respectively, as well as a few drivers'
ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
been returned by the .runtime_idle() callback executed by it.
To reduce overall code bloat, make the changes described above.
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Kevin Hilman <khilman@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Kevin Hilman <khilman@linaro.org>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Some device require DMADIR to be enabled, but are not detected as such
by atapi_id_dmadir. One such example is "Asus Serillel 2"
SATA-host-to-PATA-device bridge: the bridge itself requires DMADIR,
even if the bridged device does not.
As atapi_dmadir module parameter can cause problems with some devices
(as per Tejun Heo's memory), enabling it globally may not be possible
depending on the hardware.
This patch adds atapi_dmadir in the form of a "force" horkage value,
allowing global, per-bus and per-device control.
Signed-off-by: Vincent Pelletier <plr.vincent@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
While registering host controller track port number based upon number
of ports available on the controller, export port_no attribute through
/sys. This patch is needed by udev for composing persistent links in
/dev/disk/by-path.
/sys/devices/pci0000:00/0000:00:1f.2/ata8/ata_port/ata8
total 0
lrwxrwxrwx. 1 root root 0 Mar 6 12:43 device -> ../../../ata8
-r--r--r--. 1 root root 4096 Mar 6 12:43 idle_irq
-r--r--r--. 1 root root 4096 Mar 6 12:43 nr_pmp_links
-r--r--r--. 1 root root 4096 Mar 6 12:43 port_no
drwxr-xr-x. 2 root root 0 Mar 6 12:42 power
lrwxrwxrwx. 1 root root 0 Mar 6 12:41 subsystem -> ../../../../../../class/ata_port
-rw-r--r--. 1 root root 4096 Mar 6 12:40 uevent
1
Signed-off-by: David Milburn <dmilburn@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Jeff moved on to a greener pasture.
s/Maintained by: Jeff Garzik/Maintained by: Tejun Heo/g
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Jeff Garzik <jgarzik@pobox.com>
Commit 803739d25c ("[libata] replace
sata_settings with devslp_timing"), which was also Cc: stable, used a
stack buffer to receive data from ata_read_log_page(), which triggers
the following warning:
ahci 0000:00:1f.2: DMA-API: device driver maps memory fromstack [addr=ffff880140469948]
Fix this by using ap->sector_buf instead of a stack buffer.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Cc: stable@kernel.org
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
For system freeze, if the port is already runtime suspended, leave it
alone and just return. The port will be resumed on thaw before it will
be used.
And since we will call get_noresume for every device during prepare
phase, and the port is resumed during thaw phase, it can't be in runtime
suspended state during the poweroff phase. So remove the
runtime_suspended check in poweroff callback.
And for all suspend(freeze/suspend/poweroff/etc.), there is no need to
touch the device, so set no_autopsy and no_recovery for them all.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
We need to do different things for system PM and runtime PM, e.g. we do
not need to enable runtime wake for ZPODD when we are doing system
suspend, etc.
Currently, we use PMSG_SUSPEND for both system suspend and runtime
suspend and PMSG_ON for both system resume and runtime resume. Change
this by using PMSG_AUTO_SUSPEND for runtime suspend and PMSG_AUTO_RESUME
for runtime resume. And since PMSG_ON means no transition, it is changed
to PMSG_RESUME for ata port's system resume.
The ata_acpi_set_state is modified accordingly, and the sata case and
pata case is seperated for easy reading.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
For ODDs, the upper layer will poll for media change every few
seconds, which will make it enter and leave suspend state very
often. And as each suspend will also cause a hard/soft reset,
the gain of runtime suspend is very little while the ODD may
malfunction after constantly being reset. So the idle callback
here will not proceed to suspend if a non-ZPODD capable ODD is
attached to the port.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
The ODD can be enabled for ZPODD if the following three conditions are
satisfied:
1 The ODD supports device attention;
2 The platform can runtime power off the ODD through ACPI;
3 The ODD is either slot type or drawer type.
For such ODDs, zpodd_init is called and a new structure is allocated for
it to store ZPODD related stuffs.
And the zpodd_dev_enabled function is used to test if ZPODD is currently
enabled for this ODD.
A new config CONFIG_SATA_ZPODD is added to selectively build ZPODD code.
Signed-off-by: Aaron Lu <aaron.lu@intel.com>
Acked-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
NCQ capability was used to check availability of SATA Settings page
from Identify Device Data Log, which contains DevSlp timing variables.
It does not work on some HDDs and leads to error messages.
IDENTIFY word 78 bit 5(Hardware Feature Control) can't work either
because it is only the sufficient condition of Identify Device data
log, not the necessary condition.
This patch replaced ata_device->sata_settings with ->devslp_timing
to only save DevSlp timing variables(8 bytes), instead of the whole
SATA Settings page(512 bytes).
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=51881
Reported-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Shane Huang <shane.huang@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This reverts commit de90cd71f6.
Shane Huang writes:
Please suspend this patch because I just received two new
DevSlp drives but found word 78 bit 5 is _not_ set.
I'm checking with the drive vendor whether he gave me
the wrong information. If bit 5 is not the necessary and
sufficient condition, I will implement another patch to
replace ata_device->sata_settings into ->devslp_timing.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
This relatively simple boiler-plate code is repeated in several platform
drivers. We should implement a common version in libata.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Tejun Heo