<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/drivers/ata, branch v4.4.197</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.197</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.197'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2019-09-06T08:18:08Z</updated>
<entry>
<title>libata: add SG safety checks in SFF pio transfers</title>
<updated>2019-09-06T08:18:08Z</updated>
<author>
<name>Jens Axboe</name>
<email>axboe@kernel.dk</email>
</author>
<published>2019-08-07T18:23:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d2b2a7dd72c6c6cb5bac6b96d8b6bb31ca227825'/>
<id>urn:sha1:d2b2a7dd72c6c6cb5bac6b96d8b6bb31ca227825</id>
<content type='text'>
[ Upstream commit 752ead44491e8c91e14d7079625c5916b30921c5 ]

Abort processing of a command if we run out of mapped data in the
SG list. This should never happen, but a previous bug caused it to
be possible. Play it safe and attempt to abort nicely if we don't
have more SG segments left.

Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ata: libahci: do not complain in case of deferred probe</title>
<updated>2019-08-25T08:53:00Z</updated>
<author>
<name>Miquel Raynal</name>
<email>miquel.raynal@bootlin.com</email>
</author>
<published>2019-07-31T12:26:51Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7b31030dacc653d21b4ebd0a8d04495b5af7804e'/>
<id>urn:sha1:7b31030dacc653d21b4ebd0a8d04495b5af7804e</id>
<content type='text'>
[ Upstream commit 090bb803708198e5ab6b0046398c7ed9f4d12d6b ]

Retrieving PHYs can defer the probe, do not spawn an error when
-EPROBE_DEFER is returned, it is normal behavior.

Fixes: b1a9edbda040 ("ata: libahci: allow to use multiple PHYs")
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Miquel Raynal &lt;miquel.raynal@bootlin.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>libata: zpodd: Fix small read overflow in zpodd_get_mech_type()</title>
<updated>2019-08-25T08:53:00Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2019-07-29T21:47:22Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1ea16aaf4691a7297dea47b6dd33900a3912af10'/>
<id>urn:sha1:1ea16aaf4691a7297dea47b6dd33900a3912af10</id>
<content type='text'>
[ Upstream commit 71d6c505b4d9e6f76586350450e785e3d452b346 ]

Jeffrin reported a KASAN issue:

  BUG: KASAN: global-out-of-bounds in ata_exec_internal_sg+0x50f/0xc70
  Read of size 16 at addr ffffffff91f41f80 by task scsi_eh_1/149
  ...
  The buggy address belongs to the variable:
    cdb.48319+0x0/0x40

Much like commit 18c9a99bce2a ("libata: zpodd: small read overflow in
eject_tray()"), this fixes a cdb[] buffer length, this time in
zpodd_get_mech_type():

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.

Reported-by: Jeffrin Jose T &lt;jeffrin@rajagiritech.edu.in&gt;
Fixes: afe759511808c ("libata: identify and init ZPODD devices")
Link: https://lore.kernel.org/lkml/201907181423.E808958@keescook/
Tested-by: Jeffrin Jose T &lt;jeffrin@rajagiritech.edu.in&gt;
Reviewed-by: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Signed-off-by: Kees Cook &lt;keescook@chromium.org&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>libata: Extend quirks for the ST1000LM024 drives with NOLPM quirk</title>
<updated>2019-06-22T06:18:22Z</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2019-06-11T14:32:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=be499b84c3bd1dcfd2c5aa80171ae9c43e7060e8'/>
<id>urn:sha1:be499b84c3bd1dcfd2c5aa80171ae9c43e7060e8</id>
<content type='text'>
commit 31f6264e225fb92cf6f4b63031424f20797c297d upstream.

We've received a bugreport that using LPM with ST1000LM024 drives leads
to system lockups. So it seems that these models are buggy in more then
1 way. Add NOLPM quirk to the existing quirks entry for BROKEN_FPDMA_AA.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330
Cc: stable@vger.kernel.org
Reviewed-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>libata: fix using DMA buffers on stack</title>
<updated>2019-05-16T17:44:59Z</updated>
<author>
<name>raymond pang</name>
<email>raymondpangxd@gmail.com</email>
</author>
<published>2019-03-28T12:19:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8c2bbe210936f22ea5796d97431f61de439cd7ce'/>
<id>urn:sha1:8c2bbe210936f22ea5796d97431f61de439cd7ce</id>
<content type='text'>
[ Upstream commit dd08a8d9a66de4b54575c294a92630299f7e0fe7 ]

When CONFIG_VMAP_STACK=y, __pa() returns incorrect physical address for
a stack virtual address. Stack DMA buffers must be avoided.

Signed-off-by: raymond pang &lt;raymondpangxd@gmail.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin (Microsoft) &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>sata_rcar: fix deferred probing</title>
<updated>2019-02-20T09:13:08Z</updated>
<author>
<name>Sergei Shtylyov</name>
<email>sergei.shtylyov@cogentembedded.com</email>
</author>
<published>2018-11-24T18:14:16Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c90636fda3d6f1db1d33d2e3d41f35c43eff456e'/>
<id>urn:sha1:c90636fda3d6f1db1d33d2e3d41f35c43eff456e</id>
<content type='text'>
[ Upstream commit 9f83cfdb1ace3ef268ecc6fda50058d2ec37d603 ]

The driver overrides the error codes returned by platform_get_irq() to
-EINVAL, so if it returns -EPROBE_DEFER, the driver would fail the probe
permanently instead of the deferred probing. Switch to propagating the
error code upstream, still checking/overriding IRQ0 as libata regards it
as "no IRQ" (thus polling) anyway...

Fixes: 9ec36cafe43b ("of/irq: do irq resolution in platform_get_irq")
Reviewed-by: Simon Horman &lt;horms+renesas@verge.net.au&gt;
Reviewed-by: Geert Uytterhoeven &lt;geert+renesas@glider.be&gt;
Signed-off-by: Sergei Shtylyov &lt;sergei.shtylyov@cogentembedded.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>libata: whitelist all SAMSUNG MZ7KM* solid-state disks</title>
<updated>2018-12-21T13:09:53Z</updated>
<author>
<name>Juha-Matti Tilli</name>
<email>juha-matti.tilli@iki.fi</email>
</author>
<published>2018-12-02T10:47:08Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=08349ed6ea70f26ce279059521d329e850bc8fdf'/>
<id>urn:sha1:08349ed6ea70f26ce279059521d329e850bc8fdf</id>
<content type='text'>
[ Upstream commit fd6f32f78645db32b6b95a42e45da2ddd6de0e67 ]

These devices support read zero after trim (RZAT), as they advertise to
the OS. However, the OS doesn't believe the SSDs unless they are
explicitly whitelisted.

Acked-by: Martin K. Petersen &lt;martin.petersen@oracle.com&gt;
Signed-off-by: Juha-Matti Tilli &lt;juha-matti.tilli@iki.fi&gt;
Signed-off-by: Jens Axboe &lt;axboe@kernel.dk&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ahci: don't ignore result code of ahci_reset_controller()</title>
<updated>2018-11-10T15:41:42Z</updated>
<author>
<name>Ard Biesheuvel</name>
<email>ard.biesheuvel@linaro.org</email>
</author>
<published>2017-10-02T18:31:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=f2adb1f6f9d691f8d518b6b44ea20618e636ffee'/>
<id>urn:sha1:f2adb1f6f9d691f8d518b6b44ea20618e636ffee</id>
<content type='text'>
[ Upstream commit d312fefea8387503375f728855c9a62de20c9665 ]

ahci_pci_reset_controller() calls ahci_reset_controller(), which may
fail, but ignores the result code and always returns success. This
may result in failures like below

  ahci 0000:02:00.0: version 3.0
  ahci 0000:02:00.0: enabling device (0000 -&gt; 0003)
  ahci 0000:02:00.0: SSS flag set, parallel bus scan disabled
  ahci 0000:02:00.0: controller reset failed (0xffffffff)
  ahci 0000:02:00.0: failed to stop engine (-5)
    ... repeated many times ...
  ahci 0000:02:00.0: failed to stop engine (-5)
  Unable to handle kernel paging request at virtual address ffff0000093f9018
    ...
  PC is at ahci_stop_engine+0x5c/0xd8 [libahci]
  LR is at ahci_deinit_port.constprop.12+0x1c/0xc0 [libahci]
    ...
  [&lt;ffff000000a17014&gt;] ahci_stop_engine+0x5c/0xd8 [libahci]
  [&lt;ffff000000a196b4&gt;] ahci_deinit_port.constprop.12+0x1c/0xc0 [libahci]
  [&lt;ffff000000a197d8&gt;] ahci_init_controller+0x80/0x168 [libahci]
  [&lt;ffff000000a260f8&gt;] ahci_pci_init_controller+0x60/0x68 [ahci]
  [&lt;ffff000000a26f94&gt;] ahci_init_one+0x75c/0xd88 [ahci]
  [&lt;ffff000008430324&gt;] local_pci_probe+0x3c/0xb8
  [&lt;ffff000008431728&gt;] pci_device_probe+0x138/0x170
  [&lt;ffff000008585e54&gt;] driver_probe_device+0x2dc/0x458
  [&lt;ffff0000085860e4&gt;] __driver_attach+0x114/0x118
  [&lt;ffff000008583ca8&gt;] bus_for_each_dev+0x60/0xa0
  [&lt;ffff000008585638&gt;] driver_attach+0x20/0x28
  [&lt;ffff0000085850b0&gt;] bus_add_driver+0x1f0/0x2a8
  [&lt;ffff000008586ae0&gt;] driver_register+0x60/0xf8
  [&lt;ffff00000842f9b4&gt;] __pci_register_driver+0x3c/0x48
  [&lt;ffff000000a3001c&gt;] ahci_pci_driver_init+0x1c/0x1000 [ahci]
  [&lt;ffff000008083918&gt;] do_one_initcall+0x38/0x120

where an obvious hardware level failure results in an unnecessary 15 second
delay and a subsequent crash.

So record the result code of ahci_reset_controller() and relay it, rather
than ignoring it.

Signed-off-by: Ard Biesheuvel &lt;ard.biesheuvel@linaro.org&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>ata: libahci: Correct setting of DEVSLP register</title>
<updated>2018-09-19T20:48:58Z</updated>
<author>
<name>Srinivas Pandruvada</name>
<email>srinivas.pandruvada@linux.intel.com</email>
</author>
<published>2018-07-02T19:01:53Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=58e91e96fdb2cacd96d89baba3ec9d8e1b937896'/>
<id>urn:sha1:58e91e96fdb2cacd96d89baba3ec9d8e1b937896</id>
<content type='text'>
[ 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.1

Here 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 &lt;srinivas.pandruvada@linux.intel.com&gt;
Reviewed-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Reviewed-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>libata: Fix command retry decision</title>
<updated>2018-08-06T14:24:36Z</updated>
<author>
<name>Damien Le Moal</name>
<email>damien.lemoal@wdc.com</email>
</author>
<published>2018-05-09T00:28:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=cdebef38f64805a1802452acadd33e690bd7c503'/>
<id>urn:sha1:cdebef38f64805a1802452acadd33e690bd7c503</id>
<content type='text'>
[ 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 &lt;damien.lemoal@wdc.com&gt;
Reviewed-by: Hannes Reinecke &lt;hare@suse.com&gt;
Signed-off-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
