02 Nov, 2018
1 commit
-
Add one parameter to distinguish the different ref_clk
source, internal pll or the external osc.
NOTE: The value of the ext_osc should be aligned to the one
of the pcie's, since both of them share one ref_clk source.Signed-off-by: Richard Zhu
29 Oct, 2018
6 commits
-
In order to do SATA compliance tests, add the bist mode
sysfile callback to generate kinds of test patterns.
- Add the "ahci-imx.bist=1" into kernel command line to
register the bist mode enable callback.
- Use "echo /sys/devices/.../ahci_bist_pattern"
to generate the responding test pattern.
- Use "cat /sys/devices/.../ahci_bist_pattern" to check
the current pattern configuration.
NOTE:
LBP 0, LFTP 1, MFTP 2, HFTP 3.
- Adjust the TX-DEEMP and COMINT to pass the compliance tests.BuildInfo:
- SCFW 685bd659, SECO-FW 00000000, IMX-MKIMAGE 53974947, ATF 625d9ed
- U-Boot 2017.03-01018-g6045484Signed-off-by: Richard Zhu
Reviewed-by: Frank Li -
- To save power consumption, PHY related CLKs can be
gated off after the configurations are done.
- The impedance ratio should be configured refer to
differnet REXT values.
0x6c REXT valuse is 85Ohms
Default values 0x80 REXT value is 100Ohms.
- IMX8QM_HSIO_PHY_X1_APB_CLK is mandatory required when
access SATA PHY registers. Change the power domain to SATA.Signed-off-by: Richard Zhu
-
enable sata on imx8qm.
sata function is relied on the usage of pcie ports.BuildInfo:
- SCFW 9559d5ec, IMX-MKIMAGE 06bc2767, ATF
- U-Boot 2017.03-imx_v2017.03_4.9.51_imx8_beta1+g6dc7b0fReviewed-by: Frank Li
Signed-off-by: Richard Zhu -
Since the version of the imx6qp's ahci controller
is same to the version of imx6q ahci controller.
So, this work-around should be applied to imx6qp
ahci too.Signed-off-by: Richard Zhu
(cherry picked from commit 31a7eab5be9843263535306dbaa08592b66714e5) -
- add the sata phy power down and phy reset for 6qp
sataSigned-off-by: Richard Zhu
(cherry picked from commit b1270554354d46cf7676e354e63ec4f11766e6f6) -
errata:
When a read command returns less data than specified in the PRDs (for
example, there are two PRDs for this command, but the device returns a
number of bytes which is less than in the first PRD), the second PRD of
this command is not read out of the PRD FIFO, causing the next command
to use this PRD erroneously.workaround
- forces sg_tablesize = 1
- modified the sg_io function in block/scsi_ioctl.c to use a 64k buffer
allocated with dma_alloc_coherent during the probe in ahci_imx
- In order to fix the scsi/sata hang, when CD_ROM and HDD are
accessed simultaneously after the workaround is applied.
Do not go to sleep in scsi_eh_handler, when there is host failed.Signed-off-by: Richard Zhu
04 Oct, 2018
1 commit
-
[ Upstream commit 46cb52ad414ac829680d0bb8cc7090ac2b577ca7 ]
The DMA is broken on this specific device for some unknown
reason (probably badly designed or plain broken interface
electronics) and will only work with PIO. Other users of
the same hardware does not have this problem.Add a specific quirk so that this Gemini device gets
DMA turned off. Also fix up some code around passing the
port information around in probe while we're at it.Signed-off-by: Linus Walleij
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
20 Sep, 2018
2 commits
-
[ Upstream commit 2dbb3ec29a6c069035857a2fc4c24e80e5dfe3cc ]
We have seen that on some platforms, SATA device never show any DEVSLP
residency. This prevent power gating of SATA IP, which prevent system
to transition to low power mode in systems with SLP_S0 aka modern
standby systems. The PHY logic is off only in DEVSLP not in slumber.
Reference:
https://www.intel.com/content/dam/www/public/us/en/documents/datasheets
/332995-skylake-i-o-platform-datasheet-volume-1.pdf
Section 28.7.6.1Here driver is trying to do read-modify-write the devslp register. But
not resetting the bits for which this driver will modify values (DITO,
MDAT and DETO). So simply reset those bits before updating to new values.Signed-off-by: Srinivas Pandruvada
Reviewed-by: Rafael J. Wysocki
Reviewed-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 11c291461b6ea8d1195a96d6bba6673a94aacebc ]
There are two modes in which DEVSLP can be entered. The OS initiated or
hardware autonomous.In hardware autonomous mode, BIOS configures the AHCI controller and the
device to enable DEVSLP. But they may not be ideal for all cases. So in
this case, OS should be able to reconfigure DEVSLP register.Currently if the DEVSLP is already enabled, we can't set again as it will
simply return. There are some systems where the firmware is setting high
DITO by default, in this case we can't modify here to correct settings.
With the default in several seconds, we are not able to transition to
DEVSLP.This change will allow reconfiguration of devslp register if DITO is
different.Signed-off-by: Srinivas Pandruvada
Reviewed-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
24 Aug, 2018
1 commit
-
[ Upstream commit fae2a63737e5973f1426bc139935a0f42e232844 ]
Currently smatch warns of possible Spectre-V1 issue in ahci_led_store():
drivers/ata/libahci.c:1150 ahci_led_store() warn: potential spectre issue 'pp->em_priv' (local cap)Userspace controls @pmp from following callchain:
em_message->store()
->ata_scsi_em_message_store()
-->ap->ops->em_store()
--->ahci_led_store()After the mask+shift @pmp is effectively an 8b value, which is used to
index into an array of length 8, so sanitize the array index.Signed-off-by: John Garry
Signed-off-by: Tejun HeoSigned-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
03 Aug, 2018
1 commit
-
[ Upstream commit 804689ad2d9b66d0d3920b48cf05881049d44589 ]
For failed commands with valid sense data (e.g. NCQ commands),
scsi_check_sense() is used in ata_analyze_tf() to determine if the
command can be retried. In such case, rely on this decision and ignore
the command error mask based decision done in ata_worth_retry().This fixes useless retries of commands such as unaligned writes on zoned
disks (TYPE_ZAC).Signed-off-by: Damien Le Moal
Reviewed-by: Hannes Reinecke
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
17 Jul, 2018
3 commits
-
commit 240630e61870e62e39a97225048f9945848fa5f5 upstream.
There have been several reports of LPM related hard freezes about once
a day on multiple Lenovo 50 series models. Strange enough these reports
where not disk model specific as LPM issues usually are and some users
with the exact same disk + laptop where seeing them while other users
where not seeing these issues.It turns out that enabling LPM triggers a firmware bug somewhere, which
has been fixed in later BIOS versions.This commit adds a new ahci_broken_lpm() function and a new ATA_FLAG_NO_LPM
for dealing with this.The ahci_broken_lpm() function contains DMI match info for the 4 models
which are known to be affected by this and the DMI BIOS date field for
known good BIOS versions. If the BIOS date is older then the one in the
table LPM will be disabled and a warning will be printed.Note the BIOS dates are for known good versions, some older versions may
work too, but we don't know for sure, the table is using dates from BIOS
versions for which users have confirmed that upgrading to that version
makes the problem go away.Unfortunately I've been unable to get hold of the reporter who reported
that BIOS version 2.35 fixed the problems on the W541 for him. I've been
able to verify the DMI_SYS_VENDOR and DMI_PRODUCT_VERSION from an older
dmidecode, but I don't know the exact BIOS date as reported in the DMI.
Lenovo keeps a changelog with dates in their release notes, but the
dates there are the release dates not the build dates which are in DMI.
So I've chosen to set the date to which we compare to one day past the
release date of the 2.34 BIOS. I plan to fix this with a follow up
commit once I've the necessary info.Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 6edf1d4cb0acde3a0a5dac849f33031bd7abb7b1 upstream.
If the ALL bit is set in the ZBC_OUT command, the command zone ID field
(block) should be ignored.Reported-by: David Butterfield
Signed-off-by: Damien Le Moal
Cc: stable@vger.kernel.org
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit b320a0a9f23c98f21631eb27bcbbca91c79b1c6e upstream.
The block (LBA) specified must not exceed the last addressable LBA,
which is dev->nr_sectors - 1. So fix the correct check is
"if (block >= dev->n_sectors)" and not "if (block > dev->n_sectords)".Additionally, the asc/ascq to return for an LBA that is not a zone start
LBA should be ILLEGAL REQUEST, regardless if the bad LBA is out of
range.Reported-by: David Butterfield
Signed-off-by: Damien Le Moal
Cc: stable@vger.kernel.org
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman
26 Jun, 2018
2 commits
-
commit 2cfce3a86b64b53f0a70e92a6a659c720c319b45 upstream.
Commit 184add2ca23c ("libata: Apply NOLPM quirk for SanDisk
SD7UB3Q*G1001 SSDs") disabled LPM for SanDisk SD7UB3Q*G1001 SSDs.This has lead to several reports of users of that SSD where LPM
was working fine and who know have a significantly increased idle
power consumption on their laptops.Likely there is another problem on the T450s from the original
reporter which gets exposed by the uncore reaching deeper sleep
states (higher PC-states) due to LPM being enabled. The problem as
reported, a hardfreeze about once a day, already did not sound like
it would be caused by LPM and the reports of the SSD working fine
confirm this. The original reporter is ok with dropping the quirk.A X250 user has reported the same hard freeze problem and for him
the problem went away after unrelated updates, I suspect some GPU
driver stack changes fixed things.TL;DR: The original reporters problem were triggered by LPM but not
an LPM issue, so drop the quirk for the SSD in question.BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1583207
Cc: stable@vger.kernel.org
Cc: Richard W.M. Jones
Cc: Lorenzo Dalrio
Reported-by: Lorenzo Dalrio
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Acked-by: "Richard W.M. Jones"
Signed-off-by: Greg Kroah-Hartman -
commit 18c9a99bce2a57dfd7e881658703b5d7469cc7b9 upstream.
We read from the cdb[] buffer in ata_exec_internal_sg(). It has to be
ATAPI_CDB_LEN (16) bytes long, but this buffer is only 12 bytes.Fixes: 213342053db5 ("libata: handle power transition of ODD")
Signed-off-by: Dan Carpenter
Signed-off-by: Tejun Heo
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
21 Jun, 2018
3 commits
-
[ Upstream commit 0d74d872c3f8b9cb3d096fb932a063b43b37f188 ]
__printf is useful to verify format and arguments. Remove the following
warning (with W=1):drivers/ata/libata-eh.c:183:10: warning: function might be possible candidate for ‘gnu_printf’ format attribute [-Wsuggest-attribute=format]
Signed-off-by: Mathieu Malaterre
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit daa2e3bdbb0b3e691cf20a042350817310cb8cb5 ]
There is an issue(Errata Ref#226) that the SATA can not be
detected via SATA Port-MultiPlayer(PMP) with following
error log:
ata1.15: PMP product ID mismatch
ata1.15: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1.15: Port Multiplier vendor mismatch '0x1b4b'!='0x0'
ata1.15: PMP revalidation failed (errno=-19)After debugging, the reason is found that the value Port-x
FIS-based Switching Control(PxFBS@0x40) become wrong.
According to design, the bits[11:8, 0] of register PxFBS
are cleared when Port Command and Status (0x18) bit[0]
changes its value from 1 to 0, i.e. falling edge of Port
Command and Status bit[0] sends PULSE that resets PxFBS
bits[11:8; 0].
So it needs a mvebu SATA WA to save the port PxFBS register
before PxCMD ST write and restore it afterwards.This patch implements the WA in a separate function of
ahci_mvebu_stop_engine to override ahci_stop_gngine.Signed-off-by: Evan Wang
Cc: Ofer Heifetz
Cc: Tejun Heo
Cc: Thomas Petazzoni
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit fa89f53bd7288d6aa7a982841119e7123faf5a53 ]
Marvell armada37xx, armada7k and armada8k share the same
AHCI sata controller IP, and currently there is an issue
(Errata Ref#226)that the SATA can not be detected via SATA
Port-MultiPlayer(PMP). After debugging, the reason is
found that the value of Port-x FIS-based Switching Control
(PxFBS@0x40) became wrong.
According to design, the bits[11:8, 0] of register PxFBS
are cleared when Port Command and Status (0x18) bit[0]
changes its value from 1 to 0, i.e. falling edge of Port
Command and Status bit[0] sends PULSE that resets PxFBS
bits[11:8; 0].
So it needs save the port PxFBS register before PxCMD
ST write and restore the port PxFBS register afterwards
in ahci_stop_engine().This commit allows drivers to override ahci_stop_engine
behavior for use by the Marvell AHCI driver(and potentially
other drivers in the future).Signed-off-by: Evan Wang
Cc: Ofer Heifetz
Cc: Tejun Heo
Cc: Thomas Petazzoni
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
30 May, 2018
3 commits
-
[ Upstream commit 0d3e45bc6507bd1f8728bf586ebd16c2d9e40613 ]
This fixs the following comile warnings with ATA_DEBUG enabled,
which detected by Linaro GCC 5.2-2015.11:drivers/ata/libata-scsi.c: In function 'ata_scsi_dump_cdb':
./include/linux/kern_levels.h:5:18: warning: format '%d' expects
argument of type 'int', but argument 6 has type 'u64 {aka long
long unsigned int}' [-Wformat=]tj: Patch hand-applied and description trimmed.
Signed-off-by: Dong Bo
Signed-off-by: Tejun Heo
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
commit 136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream.
While whitelisting Micron M500DC drives, the tweaked blacklist entry
enabled queued TRIM from M500IT variants also. But these do not support
queued TRIM. And while using those SSDs with the latest kernel we have
seen errors and even the partition table getting corrupted.Some part from the dmesg:
[ 6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133
[ 6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
[ 6.741026] ata1.00: supports DRM functions and may not be fully accessible
[ 6.759887] ata1.00: configured for UDMA/133
[ 6.762256] scsi 0:0:0:0: Direct-Access ATA Micron_M500IT_MT MU01 PQ: 0 ANSI: 5and then for the error:
[ 120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen
[ 120.860338] ata1.00: irq_stat 0x40000008
[ 120.860342] ata1.00: failed command: SEND FPDMA QUEUED
[ 120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)
[ 120.860353] ata1.00: status: { DRDY }
[ 120.860543] ata1: hard resetting link
[ 121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 121.166376] ata1.00: supports DRM functions and may not be fully accessible
[ 121.186238] ata1.00: supports DRM functions and may not be fully accessible
[ 121.204445] ata1.00: configured for UDMA/133
[ 121.204454] ata1.00: device reported invalid CHS sector 0
[ 121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
[ 121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]
[ 121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4
[ 121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00
[ 121.204559] print_req_error: I/O error, dev sda, sector 272512After few reboots with these errors, and the SSD is corrupted.
After blacklisting it, the errors are not seen and the SSD does not get
corrupted any more.Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC")
Cc: Martin K. Petersen
Cc: stable@vger.kernel.org
Signed-off-by: Sudip Mukherjee
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 322579dcc865b94b47345ad1b6002ad167f85405 upstream.
Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up
regularly under sustained moderate load with NCQ enabled. Blacklist
for now.Signed-off-by: Tejun Heo
Reported-by: Dave Jones
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
16 May, 2018
1 commit
-
commit 184add2ca23ce5edcac0ab9c3b9be13f91e7b567 upstream.
Richard Jones has reported that using med_power_with_dipm on a T450s
with a Sandisk SD7UB3Q256G1001 SSD (firmware version X2180501) is
causing the machine to hang.Switching the LPM to max_performance fixes this, so it seems that
this Sandisk SSD does not handle LPM well.Note in the past there have been bug-reports about the following
Sandisk models not working with min_power, so we may need to extend
the quirk list in the future: name - firmware
Sandisk SD6SB2M512G1022I - X210400
Sandisk SD6PP4M-256G-1006 - A200906Cc: stable@vger.kernel.org
Cc: Richard W.M. Jones
Reported-and-tested-by: Richard W.M. Jones
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman
29 Mar, 2018
10 commits
-
commit d418ff56b8f2d2b296daafa8da151fe27689b757 upstream.
When commit 9c7be59fc519af ("libata: Apply NOLPM quirk to Crucial MX100
512GB SSDs") was added it inherited the ATA_HORKAGE_NO_NCQ_TRIM quirk
from the existing "Crucial_CT*MX100*" entry, but that entry sets model_rev
to "MU01", where as the entry adding the NOLPM quirk sets it to NULL.This means that after this commit we no apply the NO_NCQ_TRIM quirk to
all "Crucial_CT512MX100*" SSDs even if they have the fixed "MU02"
firmware. This commit splits the "Crucial_CT512MX100*" quirk into 2
quirks, one for the "MU01" firmware and one for all other firmware
versions, so that we once again only apply the NO_NCQ_TRIM quirk to the
"MU01" firmware version.Fixes: 9c7be59fc519af ("libata: Apply NOLPM quirk to ... MX100 512GB SSDs")
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 3bf7b5d6d017c27e0d3b160aafb35a8e7cfeda1f upstream.
Commit b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB
drive"), introduced a ATA_HORKAGE_NOLPM quirk for Crucial BX100 500GB SSDs
but limited this to the MU02 firmware version, according to:
http://www.crucial.com/usa/en/support-ssd-firmwareMU02 is the last version, so there are no newer possibly fixed versions
and if the MU02 version has broken LPM then the MU01 almost certainly
also has broken LPM, so this commit changes the quirk to apply to all
firmware versions.Fixes: b17e5729a630 ("libata: disable LPM for Crucial BX100 SSD 500GB...")
Cc: stable@vger.kernel.org
Cc: Kai-Heng Feng
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 62ac3f7305470e3f52f159de448bc1a771717e88 upstream.
There have been reports of the Crucial M500 480GB model not working
with LPM set to min_power / med_power_with_dipm level.It has not been tested with medium_power, but that typically has no
measurable power-savings.Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03
and there is a MU05 update available, but that update does not mention any
LPM fixes in its changelog, so the quirk matches all firmware versions.In my experience the LPM problems with (older) Crucial SSDs seem to be
limited to higher capacity versions of the SSDs (different firmware?),
so this commit adds a NOLPM quirk for the 480 and 960GB versions of the
M500, to avoid LPM causing issues with these SSDs.Cc: stable@vger.kernel.org
Reported-and-tested-by: Martin Steigerwald
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit ca6bfcb2f6d9deab3924bf901e73622a94900473 upstream.
Samsung explicitly states that queued TRIM is supported for Linux with
860 PRO and 860 EVO.Make the previous blacklist to cover only 840 and 850 series.
Signed-off-by: Park Ju Hyung
Reviewed-by: Martin K. Petersen
Signed-off-by: Tejun Heo
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit b17e5729a630d8326a48ec34ef02e6b4464a6aef upstream.
After Laptop Mode Tools starts to use min_power for LPM, a user found
out Crucial BX100 SSD can't get mounted.Crucial BX100 SSD 500GB drive don't work well with min_power. This also
happens to med_power_with_dipm.So let's disable LPM for Crucial BX100 SSD 500GB drive.
BugLink: https://bugs.launchpad.net/bugs/1726930
Signed-off-by: Kai-Heng Feng
Signed-off-by: Tejun Heo
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman -
commit 9c7be59fc519af9081c46c48f06f2b8fadf55ad8 upstream.
Various people have reported the Crucial MX100 512GB model not working
with LPM set to min_power. I've now received a report that it also does
not work with the new med_power_with_dipm level.It does work with medium_power, but that has no measurable power-savings
and given the amount of people being bitten by the other levels not
working, this commit just disables LPM altogether.Note all reporters of this have either the 512GB model (max capacity), or
are not specifying their SSD's size. So for now this quirk assumes this is
a problem with the 512GB model only.Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=89261
Buglink: https://github.com/linrunner/TLP/issues/84
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 2c1ec6fda2d07044cda922ee25337cf5d4b429b3 upstream.
syzkaller hit a WARN() in ata_bmdma_qc_issue() when writing to /dev/sg0.
This happened because it issued an ATA pass-through command (ATA_16)
where the protocol field indicated that NCQ should be used -- but the
device did not support NCQ.We could just remove the WARN() from libata-sff.c, but the real problem
seems to be that the SCSI -> ATA translation code passes through NCQ
commands without verifying that the device actually supports NCQ.Fix this by adding the appropriate check to ata_scsi_pass_thru().
Here's reproducer that works in QEMU when /dev/sg0 refers to a disk of
the default type ("82371SB PIIX3 IDE"):#include
#includeint main()
{
char buf[53] = { 0 };buf[36] = 0x85; /* ATA_16 */
buf[37] = (12 << 1); /* FPDMA */
buf[38] = 0x1; /* Has data */
buf[51] = 0xC8; /* ATA_CMD_READ */
write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
}Fixes: ee7fb331c3ac ("libata: add support for NCQ commands for SG interface")
Reported-by: syzbot+2f69ca28df61bdfc77cd36af2e789850355a221e@syzkaller.appspotmail.com
Cc: # v4.4+
Signed-off-by: Eric Biggers
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 9173e5e80729c8434b8d27531527c5245f4a5594 upstream.
syzkaller hit a WARN() in ata_qc_issue() when writing to /dev/sg0. This
happened because it issued a READ_6 command with no data buffer.Just remove the WARN(), as it doesn't appear indicate a kernel bug. The
expected behavior is to fail the command, which the code does.Here's a reproducer that works in QEMU when /dev/sg0 refers to a disk of
the default type ("82371SB PIIX3 IDE"):#include
#includeint main()
{
char buf[42] = { [36] = 0x8 /* READ_6 */ };write(open("/dev/sg0", O_RDWR), buf, sizeof(buf));
}Fixes: f92a26365a72 ("libata: change ATA_QCFLAG_DMAMAP semantics")
Reported-by: syzbot+f7b556d1766502a69d85071d2ff08bd87be53d0f@syzkaller.appspotmail.com
Cc: # v2.6.25+
Signed-off-by: Eric Biggers
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 058f58e235cbe03e923b30ea7c49995a46a8725f upstream.
syzkaller reported a crash in ata_bmdma_fill_sg() when writing to
/dev/sg1. The immediate cause was that the ATA command's scatterlist
was not DMA-mapped, which causes 'pi - 1' to underflow, resulting in a
write to 'qc->ap->bmdma_prd[0xffffffff]'.Strangely though, the flag ATA_QCFLAG_DMAMAP was set in qc->flags. The
root cause is that when __ata_scsi_queuecmd() is preparing to relay a
SCSI command to an ATAPI device, it doesn't correctly validate the CDB
length before copying it into the 16-byte buffer 'cdb' in 'struct
ata_queued_cmd'. Namely, it validates the fixed CDB length expected
based on the SCSI opcode but not the actual CDB length, which can be
larger due to the use of the SG_NEXT_CMD_LEN ioctl. Since 'flags' is
the next member in ata_queued_cmd, a buffer overflow corrupts it.Fix it by requiring that the actual CDB length be cdb_len,
but the current behavior seems to have been intentionally introduced by
commit 607126c2a21c ("libata-scsi: be tolerant of 12-byte ATAPI commands
in 16-byte CDBs") to work around a userspace bug in mplayer. Probably
the workaround is no longer needed (mplayer was fixed in 2007), but
continuing to allow lengths to up 16 appears harmless for now.]Here's a reproducer that works in QEMU when /dev/sg1 refers to the
CD-ROM drive that qemu-system-x86_64 creates by default:#include
#include
#include#define SG_NEXT_CMD_LEN 0x2283
int main()
{
char buf[53] = { [36] = 0x7e, [52] = 0x02 };
int fd = open("/dev/sg1", O_RDWR);
ioctl(fd, SG_NEXT_CMD_LEN, &(int){ 17 });
write(fd, buf, sizeof(buf));
}The crash was:
BUG: unable to handle kernel paging request at ffff8cb97db37ffc
IP: ata_bmdma_fill_sg drivers/ata/libata-sff.c:2623 [inline]
IP: ata_bmdma_qc_prep+0xa4/0xc0 drivers/ata/libata-sff.c:2727
PGD fb6c067 P4D fb6c067 PUD 0
Oops: 0002 [#1] SMP
CPU: 1 PID: 150 Comm: syz_ata_bmdma_q Not tainted 4.15.0-next-20180202 #99
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[...]
Call Trace:
ata_qc_issue+0x100/0x1d0 drivers/ata/libata-core.c:5421
ata_scsi_translate+0xc9/0x1a0 drivers/ata/libata-scsi.c:2024
__ata_scsi_queuecmd drivers/ata/libata-scsi.c:4326 [inline]
ata_scsi_queuecmd+0x8c/0x210 drivers/ata/libata-scsi.c:4375
scsi_dispatch_cmd+0xa2/0xe0 drivers/scsi/scsi_lib.c:1727
scsi_request_fn+0x24c/0x530 drivers/scsi/scsi_lib.c:1865
__blk_run_queue_uncond block/blk-core.c:412 [inline]
__blk_run_queue+0x3a/0x60 block/blk-core.c:432
blk_execute_rq_nowait+0x93/0xc0 block/blk-exec.c:78
sg_common_write.isra.7+0x272/0x5a0 drivers/scsi/sg.c:806
sg_write+0x1ef/0x340 drivers/scsi/sg.c:677
__vfs_write+0x31/0x160 fs/read_write.c:480
vfs_write+0xa7/0x160 fs/read_write.c:544
SYSC_write fs/read_write.c:589 [inline]
SyS_write+0x4d/0xc0 fs/read_write.c:581
do_syscall_64+0x5e/0x110 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x21/0x86Fixes: 607126c2a21c ("libata-scsi: be tolerant of 12-byte ATAPI commands in 16-byte CDBs")
Reported-by: syzbot+1ff6f9fcc3c35f1c72a95e26528c8e7e3276e4da@syzkaller.appspotmail.com
Cc: # v2.6.24+
Signed-off-by: Eric Biggers
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 28b2182dad43f6f8fcbd167539a26714fd12bd64 upstream.
Like the Highpoint Rocketraid 642L and cards using a Marvel 88SE9235
controller in general, this RAID card also supports AHCI mode and short
of a custom driver, this is the only way to make it work under Linux.Note that even though the card is called to 644L, it has a product-id
of 0x0645.Cc: stable@vger.kernel.org
BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1534106
Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Acked-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman
17 Feb, 2018
3 commits
-
commit f919dde0772a894c693a1eeabc77df69d6a9b937 upstream.
Add Intel Cannon Lake PCH-H PCI ID to the list of supported controllers.
Signed-off-by: Mika Westerberg
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 998008b779e424bd7513c434d0ab9c1268459009 upstream.
Add PCI ids for Intel Bay Trail, Cherry Trail and Apollo Lake AHCI
SATA controllers. This commit is a preparation patch for allowing a
different default sata link powermanagement policy for mobile chipsets.Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit ca1b4974bd237f2373b0e980b11957aac3499b56 upstream.
Intel uses different SATA PCI ids for the Desktop and Mobile SKUs of their
chipsets. For older models the comment describing which chipset the PCI id
is for, aksi indicates when we're dealing with a mobile SKU. Extend the
comments for recent chipsets to also indicate mobile SKUs.The information this commit adds comes from Intel's chipset datasheets.
This commit is a preparation patch for allowing a different default
sata link powermanagement policy for mobile chipsets.Signed-off-by: Hans de Goede
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman
24 Jan, 2018
1 commit
-
commit db5ff909798ef0099004ad50a0ff5fde92426fd1 upstream.
LITEON EP1 has the same timeout issues as CX1 series devices.
Revert max_sectors to the value of 1024.
Fixes: e0edc8c54646 ("libata: apply MAX_SEC_1024 to all CX1-JB*-HP devices")
Signed-off-by: Xinyu Lin
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman
30 Nov, 2017
1 commit
-
commit f1601113ddc0339a745e702f4fb1ca37d4875e65 upstream.
When tracing ata link error event, the kernel crashes when the disk is
removed due to NULL pointer access by trace_ata_eh_link_autopsy API.
This occurs as the dev is NULL when the disk disappeared. This patch
fixes this crash by calling trace_ata_eh_link_autopsy only if "dev"
is not NULL.v2 changes:
Removed direct passing "link" pointer instead of "dev" in trace API.Signed-off-by: Rameshwar Prasad Sahu
Signed-off-by: Tejun Heo
Fixes: 255c03d15a29 ("libata: Add tracepoints")
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
