* Re: [GIT PULL] libata changes for v4.14-rc1
From: Tejun Heo @ 2017-09-06 14:46 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ide, Bartlomiej Zolnierkiewicz, Hans de Goede, linux-kernel
In-Reply-To: <20170905142959.GG1774378@devbig577.frc2.facebook.com>
Hello, Linus.
I added the following two patches to the branch. The ahci patch fixes
a boot issue, so it needs some prioritizing and I applied the zpodd
one while at it.
795ef78 libata: zpodd: make arrays cdb static, reduces object code size
f723fa4 ahci: don't use MSI for devices with the silly Intel NVMe remapping scheme
Except for the ahci fix, nothing major in this pull request. Some new
platform controller support and device specific changes.
Thanks.
The following changes since commit 74cbd96bc2e00f5daa805e2ebf49e998f7045062:
Merge tag 'md/4.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md (2017-07-18 11:51:08 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.14
for you to fetch changes up to 795ef788145ed2fa023efdf11e8d5d7bedc21462:
libata: zpodd: make arrays cdb static, reduces object code size (2017-09-06 07:40:28 -0700)
----------------------------------------------------------------
Andrey Korolyov (1):
cs5536: add support for IDE controller variant
Christoph Hellwig (1):
ahci: don't use MSI for devices with the silly Intel NVMe remapping scheme
Colin Ian King (1):
libata: zpodd: make arrays cdb static, reduces object code size
Julia Lawall (1):
ata: Drop unnecessary static
Linus Walleij (2):
ata: sata_gemini: Retire custom pin control
ata: sata_gemini: Introduce explicit IDE pin control
Nate Watterson (1):
ata: ahci_platform: Add shutdown handler
Philipp Zabel (1):
ata: sata_gemini: explicitly request exclusive reset control
Rob Herring (1):
ata: Convert to using %pOF instead of full_name
Ryder Lee (2):
ata: mediatek: add support for MediaTek SATA controller
dt-bindings: ata: add DT bindings for MediaTek SATA controller
Sergei Shtylyov (1):
pata_octeon_cf: use of_property_read_{bool|u32}()
Documentation/devicetree/bindings/ata/ahci-mtk.txt | 51 ++++++
drivers/ata/Kconfig | 10 ++
drivers/ata/Makefile | 1 +
drivers/ata/ahci.c | 9 +-
drivers/ata/ahci_mtk.c | 196 +++++++++++++++++++++
drivers/ata/ahci_platform.c | 1 +
drivers/ata/libahci_platform.c | 34 ++++
drivers/ata/libata-zpodd.c | 4 +-
drivers/ata/pata_amd.c | 1 +
drivers/ata/pata_cs5536.c | 1 +
drivers/ata/pata_octeon_cf.c | 10 +-
drivers/ata/sata_gemini.c | 67 +++----
drivers/ata/sata_svw.c | 2 +-
include/linux/ahci_platform.h | 2 +
include/linux/pci_ids.h | 1 +
15 files changed, 347 insertions(+), 43 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt
create mode 100644 drivers/ata/ahci_mtk.c
--
tejun
^ permalink raw reply
* Re: [PATCH] libata: zpodd: make arrays cdb static, reduces object code size
From: Tejun Heo @ 2017-09-06 14:40 UTC (permalink / raw)
To: Colin King; +Cc: linux-ide, kernel-janitors, linux-kernel
In-Reply-To: <20170906085629.23938-1-colin.king@canonical.com>
On Wed, Sep 06, 2017 at 09:56:29AM +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> Don't populate the arrays cdb on the stack, instead make them static.
> Makes the object code smaller by 230 bytes:
>
> Before:
> text data bss dec hex filename
> 3797 240 0 4037 fc5 drivers/ata/libata-zpodd.o
>
> After:
> text data bss dec hex filename
> 3407 400 0 3807 edf drivers/ata/libata-zpodd.o
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied to libata/for-4.14.
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH] ahci: don't use MSI for devices with the braindead Intel NVMe remapping scheme
From: Tejun Heo @ 2017-09-06 14:40 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: dan.j.williams, john.robert.loy, linux-ide, stable
In-Reply-To: <20170905164647.24101-1-hch@lst.de>
Hello,
On Tue, Sep 05, 2017 at 06:46:47PM +0200, Christoph Hellwig wrote:
> Intel AHCI controllers that also hide NVMe devices in their bar
> can't use MSI interrupts, so disable them.
>
> Reported-by: John Loy <john.robert.loy@gmail.com>
> Testd-by: John Loy <john.robert.loy@gmail.com>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Cc: stable@vger.kernel.org
Applied to libata/for-4.14 w/ Fixes tag added and minor edits as
suggested by Dan - I changed braindead to silly, hope everyone is fine
with that.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] libata: zpodd: make arrays cdb static, reduces object code size
From: Colin King @ 2017-09-06 8:56 UTC (permalink / raw)
To: Tejun Heo, linux-ide; +Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Don't populate the arrays cdb on the stack, instead make them static.
Makes the object code smaller by 230 bytes:
Before:
text data bss dec hex filename
3797 240 0 4037 fc5 drivers/ata/libata-zpodd.o
After:
text data bss dec hex filename
3407 400 0 3807 edf drivers/ata/libata-zpodd.o
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/ata/libata-zpodd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/libata-zpodd.c b/drivers/ata/libata-zpodd.c
index 8a01d09ac4db..23a62e4015d0 100644
--- a/drivers/ata/libata-zpodd.c
+++ b/drivers/ata/libata-zpodd.c
@@ -34,7 +34,7 @@ struct zpodd {
static int eject_tray(struct ata_device *dev)
{
struct ata_taskfile tf;
- const char cdb[] = { GPCMD_START_STOP_UNIT,
+ static const char cdb[] = { GPCMD_START_STOP_UNIT,
0, 0, 0,
0x02, /* LoEj */
0, 0, 0, 0, 0, 0, 0,
@@ -55,7 +55,7 @@ static enum odd_mech_type zpodd_get_mech_type(struct ata_device *dev)
unsigned int ret;
struct rm_feature_desc *desc = (void *)(buf + 8);
struct ata_taskfile tf;
- char cdb[] = { GPCMD_GET_CONFIGURATION,
+ static const char cdb[] = { GPCMD_GET_CONFIGURATION,
2, /* only 1 feature descriptor requested */
0, 3, /* 3, removable medium feature */
0, 0, 0,/* reserved */
--
2.14.1
^ permalink raw reply related
* Re: [PATCH] ahci: don't use MSI for devices with the braindead Intel NVMe remapping scheme
From: Dan Williams @ 2017-09-05 16:55 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Tejun Heo, john.robert.loy, IDE/ATA development list, stable
In-Reply-To: <20170905164647.24101-1-hch@lst.de>
On Tue, Sep 5, 2017 at 9:46 AM, Christoph Hellwig <hch@lst.de> wrote:
> Intel AHCI controllers that also hide NVMe devices in their bar
> can't use MSI interrupts, so disable them.
>
> Reported-by: John Loy <john.robert.loy@gmail.com>
> Testd-by: John Loy <john.robert.loy@gmail.com>
s/Testd-by/Tested-by/
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Cc: stable@vger.kernel.org
Acked-by: Dan Williams <dan.j.williams@intel.com>
Please also make the subject-line drier.
^ permalink raw reply
* [PATCH] ahci: don't use MSI for devices with the braindead Intel NVMe remapping scheme
From: Christoph Hellwig @ 2017-09-05 16:46 UTC (permalink / raw)
To: tj; +Cc: dan.j.williams, john.robert.loy, linux-ide, stable
Intel AHCI controllers that also hide NVMe devices in their bar
can't use MSI interrupts, so disable them.
Reported-by: John Loy <john.robert.loy@gmail.com>
Testd-by: John Loy <john.robert.loy@gmail.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: stable@vger.kernel.org
---
drivers/ata/ahci.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5a5fd0b404eb..cb9b0e9090e3 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1469,7 +1469,14 @@ static void ahci_remap_check(struct pci_dev *pdev, int bar,
return;
dev_warn(&pdev->dev, "Found %d remapped NVMe devices.\n", count);
- dev_warn(&pdev->dev, "Switch your BIOS from RAID to AHCI mode to use them.\n");
+ dev_warn(&pdev->dev,
+ "Switch your BIOS from RAID to AHCI mode to use them.\n");
+
+ /*
+ * Don't rely on the msi-x capability in the remap case,
+ * share the legacy interrupt across ahci and remapped devices.
+ */
+ hpriv->flags |= AHCI_HFLAG_NO_MSI;
}
static int ahci_get_irq_vector(struct ata_host *host, int port)
--
2.11.0
^ permalink raw reply related
* (unknown),
From: mgriffit @ 2017-09-05 16:31 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: 99589200620834_linux-ide.zip --]
[-- Type: application/zip, Size: 3435 bytes --]
^ permalink raw reply
* Re: Boot failure due to some interaction between per-port MSI-X and Intel RST
From: Dan Williams @ 2017-09-05 15:46 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: John Loy, IDE/ATA development list
In-Reply-To: <20170904061634.GA16590@infradead.org>
On Sun, Sep 3, 2017 at 11:16 PM, Christoph Hellwig <hch@infradead.org> wrote:
> On Sun, Sep 03, 2017 at 06:42:35PM -0700, John Loy wrote:
>> I have a system that stopped booting Linux between kernel versions 4.4.9 and
>> 4.5.3. It has a SATA + NVMe accelerated volume that I use with Windows and
>> a separate SATA drive with my Linux installation. I'm not expecting the
>> remapped NVMe thing to be accessible, just the Linux disk, but none of the
>> drives are accessible.
>>
>> Bisecting the changes turned up d684a90 as the first failing change. Passing
>> pci=nomsi also allows the system to boot newer kernels. Just to be sure, I
>> built a recent kernel (4.12.9) with the PCI_IRQ_MSIX flag removed from the
>> per-port call to pci_alloc_irq_vectors in ahci_init_msi. This also allowed
>> the system to boot normally.
>>
>> I'm totally out of my depth though so I'd really appreciate it if anyone has
>> some ideas on how to proceed with a proper fix.
>
> Something like the patch below should work. Maybe Intel can provide
> an explanation on why their chipset is so fucked up that we can add
> as a comment.
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 5a5fd0b404eb..b8c8ecc854c4 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1470,6 +1470,7 @@ static void ahci_remap_check(struct pci_dev *pdev, int bar,
>
> dev_warn(&pdev->dev, "Found %d remapped NVMe devices.\n", count);
> dev_warn(&pdev->dev, "Switch your BIOS from RAID to AHCI mode to use them.\n");
> + hpriv->flags |= AHCI_HFLAG_NO_MSI;
> }
>
> static int ahci_get_irq_vector(struct ata_host *host, int port)
Yes, this patch looks good to me. As I said here [1]:
+ /*
+ * Don't rely on the msi-x capability in the remap case,
+ * share the legacy interrupt across ahci and remapped
+ * devices.
+ */
...we need to use pci-intx interrupts for both devices.
[1]: http://lists.infradead.org/pipermail/linux-nvme/2016-October/006801.html
^ permalink raw reply
* Re: Boot failure due to some interaction between per-port MSI-X and Intel RST
From: John Loy @ 2017-09-05 15:32 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linux-ide, Dan Williams
In-Reply-To: <20170904061634.GA16590@infradead.org>
On 9/3/17 11:16 PM, Christoph Hellwig wrote:
> On Sun, Sep 03, 2017 at 06:42:35PM -0700, John Loy wrote:
>> I have a system that stopped booting Linux between kernel versions 4.4.9 and
>> 4.5.3. It has a SATA + NVMe accelerated volume that I use with Windows and
>> a separate SATA drive with my Linux installation. I'm not expecting the
>> remapped NVMe thing to be accessible, just the Linux disk, but none of the
>> drives are accessible.
>>
>> Bisecting the changes turned up d684a90 as the first failing change. Passing
>> pci=nomsi also allows the system to boot newer kernels. Just to be sure, I
>> built a recent kernel (4.12.9) with the PCI_IRQ_MSIX flag removed from the
>> per-port call to pci_alloc_irq_vectors in ahci_init_msi. This also allowed
>> the system to boot normally.
>>
>> I'm totally out of my depth though so I'd really appreciate it if anyone has
>> some ideas on how to proceed with a proper fix.
>
> Something like the patch below should work. Maybe Intel can provide
> an explanation on why their chipset is so fucked up that we can add
> as a comment.
>
> diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
> index 5a5fd0b404eb..b8c8ecc854c4 100644
> --- a/drivers/ata/ahci.c
> +++ b/drivers/ata/ahci.c
> @@ -1470,6 +1470,7 @@ static void ahci_remap_check(struct pci_dev *pdev, int bar,
>
> dev_warn(&pdev->dev, "Found %d remapped NVMe devices.\n", count);
> dev_warn(&pdev->dev, "Switch your BIOS from RAID to AHCI mode to use them.\n");
> + hpriv->flags |= AHCI_HFLAG_NO_MSI;
> }
>
> static int ahci_get_irq_vector(struct ata_host *host, int port)
>
This patch works for me.
^ permalink raw reply
* [GIT PULL] libata changes for v4.14-rc1
From: Tejun Heo @ 2017-09-05 14:29 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-ide, Bartlomiej Zolnierkiewicz, Hans de Goede, linux-kernel
Hello, Linus.
Nothing major. Some new platform controller support and device
specific changes.
Thanks.
The following changes since commit 74cbd96bc2e00f5daa805e2ebf49e998f7045062:
Merge tag 'md/4.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md (2017-07-18 11:51:08 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.14
for you to fetch changes up to 687abc0f77c239dc4cc93ea5cd27cfad76ddd038:
dt-bindings: ata: add DT bindings for MediaTek SATA controller (2017-08-29 07:22:24 -0700)
----------------------------------------------------------------
Andrey Korolyov (1):
cs5536: add support for IDE controller variant
Julia Lawall (1):
ata: Drop unnecessary static
Linus Walleij (2):
ata: sata_gemini: Retire custom pin control
ata: sata_gemini: Introduce explicit IDE pin control
Nate Watterson (1):
ata: ahci_platform: Add shutdown handler
Philipp Zabel (1):
ata: sata_gemini: explicitly request exclusive reset control
Rob Herring (1):
ata: Convert to using %pOF instead of full_name
Ryder Lee (2):
ata: mediatek: add support for MediaTek SATA controller
dt-bindings: ata: add DT bindings for MediaTek SATA controller
Sergei Shtylyov (1):
pata_octeon_cf: use of_property_read_{bool|u32}()
Documentation/devicetree/bindings/ata/ahci-mtk.txt | 51 ++++++
drivers/ata/Kconfig | 10 ++
drivers/ata/Makefile | 1 +
drivers/ata/ahci_mtk.c | 196 +++++++++++++++++++++
drivers/ata/ahci_platform.c | 1 +
drivers/ata/libahci_platform.c | 34 ++++
drivers/ata/pata_amd.c | 1 +
drivers/ata/pata_cs5536.c | 1 +
drivers/ata/pata_octeon_cf.c | 10 +-
drivers/ata/sata_gemini.c | 67 +++----
drivers/ata/sata_svw.c | 2 +-
include/linux/ahci_platform.h | 2 +
include/linux/pci_ids.h | 1 +
13 files changed, 337 insertions(+), 40 deletions(-)
create mode 100644 Documentation/devicetree/bindings/ata/ahci-mtk.txt
create mode 100644 drivers/ata/ahci_mtk.c
--
tejun
^ permalink raw reply
* Re: Boot failure due to some interaction between per-port MSI-X and Intel RST
From: Christoph Hellwig @ 2017-09-04 6:16 UTC (permalink / raw)
To: John Loy; +Cc: linux-ide, Dan Williams
In-Reply-To: <fc6edbd0-d720-4112-550c-fbed78ee8b32@gmail.com>
On Sun, Sep 03, 2017 at 06:42:35PM -0700, John Loy wrote:
> I have a system that stopped booting Linux between kernel versions 4.4.9 and
> 4.5.3. It has a SATA + NVMe accelerated volume that I use with Windows and
> a separate SATA drive with my Linux installation. I'm not expecting the
> remapped NVMe thing to be accessible, just the Linux disk, but none of the
> drives are accessible.
>
> Bisecting the changes turned up d684a90 as the first failing change. Passing
> pci=nomsi also allows the system to boot newer kernels. Just to be sure, I
> built a recent kernel (4.12.9) with the PCI_IRQ_MSIX flag removed from the
> per-port call to pci_alloc_irq_vectors in ahci_init_msi. This also allowed
> the system to boot normally.
>
> I'm totally out of my depth though so I'd really appreciate it if anyone has
> some ideas on how to proceed with a proper fix.
Something like the patch below should work. Maybe Intel can provide
an explanation on why their chipset is so fucked up that we can add
as a comment.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 5a5fd0b404eb..b8c8ecc854c4 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1470,6 +1470,7 @@ static void ahci_remap_check(struct pci_dev *pdev, int bar,
dev_warn(&pdev->dev, "Found %d remapped NVMe devices.\n", count);
dev_warn(&pdev->dev, "Switch your BIOS from RAID to AHCI mode to use them.\n");
+ hpriv->flags |= AHCI_HFLAG_NO_MSI;
}
static int ahci_get_irq_vector(struct ata_host *host, int port)
^ permalink raw reply related
* Boot failure due to some interaction between per-port MSI-X and Intel RST
From: John Loy @ 2017-09-04 1:42 UTC (permalink / raw)
To: linux-ide
I have a system that stopped booting Linux between kernel versions 4.4.9
and 4.5.3. It has a SATA + NVMe accelerated volume that I use with
Windows and a separate SATA drive with my Linux installation. I'm not
expecting the remapped NVMe thing to be accessible, just the Linux disk,
but none of the drives are accessible.
Bisecting the changes turned up d684a90 as the first failing change.
Passing pci=nomsi also allows the system to boot newer kernels. Just to
be sure, I built a recent kernel (4.12.9) with the PCI_IRQ_MSIX flag
removed from the per-port call to pci_alloc_irq_vectors in
ahci_init_msi. This also allowed the system to boot normally.
I'm totally out of my depth though so I'd really appreciate it if anyone
has some ideas on how to proceed with a proper fix.
Thanks,
John
I can post the entire dmesg output if it would be helpful but the
following seems like the most relevant parts:
[ 0.516776] libata version 3.00 loaded.
[ 2.866275] ahci 0000:00:17.0: version 3.0
[ 2.866331] ahci 0000:00:17.0: Found 1 remapped NVMe devices.
[ 2.866331] ahci 0000:00:17.0: Switch your BIOS from RAID to AHCI
mode to use them.
[ 2.866335] ahci 0000:00:17.0: controller can't do SNTF, turning off
CAP_SNTF
[ 2.876533] ahci 0000:00:17.0: AHCI 0001.0301 32 slots 6 ports 6 Gbps
0x3f impl RAID mode
[ 2.876534] ahci 0000:00:17.0: flags: 64bit ncq led clo only pio slum
part deso sadm sds apst
[ 2.876538] ahci 0000:00:17.0: both AHCI_HFLAG_MULTI_MSI flag set and
custom irq handler implemented
[ 2.877032] scsi host0: ahci
[ 2.877178] scsi host1: ahci
[ 2.877342] scsi host2: ahci
[ 2.877483] scsi host3: ahci
[ 2.877647] scsi host4: ahci
[ 2.877831] scsi host5: ahci
[ 2.877845] ata1: SATA max UDMA/133 abar m524288@0xdf200000 port
0xdf200100 irq 121
[ 2.877846] ata2: SATA max UDMA/133 abar m524288@0xdf200000 port
0xdf200180 irq 122
[ 2.877847] ata3: SATA max UDMA/133 abar m524288@0xdf200000 port
0xdf200200 irq 123
[ 2.877848] ata4: SATA max UDMA/133 abar m524288@0xdf200000 port
0xdf200280 irq 124
[ 2.877849] ata5: SATA max UDMA/133 abar m524288@0xdf200000 port
0xdf200300 irq 125
[ 2.877850] ata6: SATA max UDMA/133 abar m524288@0xdf200000 port
0xdf200380 irq 126
[ 3.186836] ata6: SATA link down (SStatus 4 SControl 300)
[ 3.186882] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 3.186919] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 3.186970] ata2: SATA link down (SStatus 4 SControl 300)
[ 3.187003] ata1: SATA link down (SStatus 4 SControl 300)
[ 3.187042] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 8.676029] ata5.00: qc timeout (cmd 0xa1)
[ 8.676037] ata5.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 8.676054] ata4.00: qc timeout (cmd 0xec)
[ 8.676062] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 8.676079] ata3.00: qc timeout (cmd 0xec)
[ 8.676087] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 8.986227] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 8.986282] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 8.986309] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 19.428027] ata4.00: qc timeout (cmd 0xec)
[ 19.428035] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 19.428039] ata4: limiting SATA link speed to 1.5 Gbps
[ 19.428056] ata3.00: qc timeout (cmd 0xec)
[ 19.428064] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 19.428068] ata3: limiting SATA link speed to 3.0 Gbps
[ 19.428086] ata5.00: qc timeout (cmd 0xa1)
[ 19.428094] ata5.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 19.428097] ata5: limiting SATA link speed to 1.5 Gbps
[ 19.738226] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 19.738251] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[ 19.738276] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 50.148029] ata5.00: qc timeout (cmd 0xa1)
[ 50.148037] ata5.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 50.148054] ata4.00: qc timeout (cmd 0xec)
[ 50.148062] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 50.148078] ata3.00: qc timeout (cmd 0xec)
[ 50.148086] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 50.458231] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 320)
[ 50.458260] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 50.458289] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
^ permalink raw reply
* Re: ide: pmac: Convert to using %pOF instead of full_name
From: Michael Ellerman @ 2017-09-01 13:29 UTC (permalink / raw)
To: Rob Herring, David S. Miller, Benjamin Herrenschmidt,
Paul Mackerras
Cc: devicetree, linuxppc-dev, linux-kernel, linux-ide
In-Reply-To: <20170718214339.7774-27-robh@kernel.org>
On Tue, 2017-07-18 at 21:43:07 UTC, Rob Herring wrote:
> Now that we have a custom printf format specifier, convert users of
> full_name to use %pOF instead. This is preparation to remove storing
> of the full path string for each node.
>
> Signed-off-by: Rob Herring <robh@kernel.org>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linux-ide@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Acked-by: David S. Miller <davem@davemloft.net>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/859420e3155d8192b31a93cd92d32c
cheers
^ permalink raw reply
* (unknown),
From: robert.berry @ 2017-09-01 2:30 UTC (permalink / raw)
To: linux-ide
[-- Attachment #1: 224909365.doc --]
[-- Type: application/msword, Size: 40462 bytes --]
^ permalink raw reply
* [GIT PULL] libata fixes for v4.13-rc7
From: Tejun Heo @ 2017-08-29 18:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-ide
Hello, Linus.
Late fixes for libata. There's a minor platform driver fix but the
important one is READ LOG PAGE.
This is a new ATA command which is used to test some optional features
but it broke probing of some devices - they locked up instead of
failing the unknown command. Chritoph tried blacklisting, but, after
finding out there are multiple devices which fail this way, backed off
to testing feature bit in IDENTIFY data first, which is a bit lossy
(we can miss features on some devices) but should be a lot safer.
Thanks.
The following changes since commit 2f60e1ab2f0e148e82cb53c539ad003ffc9b9bd0:
libata: fix a couple of doc build warnings (2017-07-31 08:03:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.13-fixes
for you to fetch changes up to 2aca392398384f8a2f339f4c661a1699f4f2e2eb:
Revert "libata: quirk read log on no-name M.2 SSD" (2017-08-29 08:36:58 -0700)
----------------------------------------------------------------
Christoph Hellwig (2):
libata: quirk read log on no-name M.2 SSD
libata: check for trusted computing in IDENTIFY DEVICE data
Christophe JAILLET (1):
sata: ahci-da850: Fix some error handling paths in 'ahci_da850_probe()'
Tejun Heo (1):
Revert "libata: quirk read log on no-name M.2 SSD"
drivers/ata/ahci_da850.c | 8 ++++++--
drivers/ata/libata-core.c | 3 +++
include/linux/ata.h | 10 +++++++++-
3 files changed, 18 insertions(+), 3 deletions(-)
--
tejun
^ permalink raw reply
* Re: [PATCH] libata: quirk read log on no-name M.2 SSD
From: Ido Schimmel @ 2017-08-29 16:04 UTC (permalink / raw)
To: Tejun Heo; +Cc: Christoph Hellwig, linux-ide
In-Reply-To: <20170829154147.GP491396@devbig577.frc2.facebook.com>
On Tue, Aug 29, 2017 at 08:41:48AM -0700, Tejun Heo wrote:
> Can you please verify whether the above patch works? You can either
> remove the horkage patch and apply the above one or test the following
> git branch.
Applied the new one and reverted the old one. Works for me.
Thanks for verifying.
^ permalink raw reply
* Re: boot failure with 4.13.0-rc6 due to ATA errors
From: Henrique de Moraes Holschuh @ 2017-08-29 16:02 UTC (permalink / raw)
To: Tejun Heo; +Cc: David Ahern, Christoph Hellwig, linux-ide, LKML, Robert Elliott
In-Reply-To: <20170829155505.GR491396@devbig577.frc2.facebook.com>
On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 12:51:02PM -0300, Henrique de Moraes Holschuh wrote:
> > > > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > > > > the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> > > > > command to avoid issues with buggy devices. The only downside is that
> > > > > we can't support Security Send / Receive for a device with an older
> > > > > revision due to the conflicting use of this field in earlier
> > > > > specifications.
> > >
> > > Christoph, I'm gonna revert the horkage patch and apply this one. If
> > > you can think of a better way to do this, please let me know.
> >
> > The one thing that comes to mind would be an additional patch to allow
> > people with ATA-7 to bypass the identify device data, and rely just on
> > the read log page check, based on a kernel command line parameter.
> >
> > If we get enough sucessful reports to make it worth it, an whitelist
> > could be added...
>
> If the ones we miss are the ones based on old revisions, does it
> matter? If we have to, we can just whitelist those devices and I
Well, only if the opal functionality would actually be worth something
on those old revisions I guess. It is certainly possible that it would
be better off disabled.
> don't expect there to be many.
Indeed, but we will not get much on the way of people testing this if we
don't give them a kernel parameter ;-)
--
Henrique Holschuh
^ permalink raw reply
* Re: boot failure with 4.13.0-rc6 due to ATA errors
From: Tejun Heo @ 2017-08-29 15:55 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: David Ahern, Christoph Hellwig, linux-ide, LKML, Robert Elliott
In-Reply-To: <20170829155102.vgbzyh7fhjrurdhl@khazad-dum.debian.net>
Hello, Henrique.
On Tue, Aug 29, 2017 at 12:51:02PM -0300, Henrique de Moraes Holschuh wrote:
> > > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > > > the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> > > > command to avoid issues with buggy devices. The only downside is that
> > > > we can't support Security Send / Receive for a device with an older
> > > > revision due to the conflicting use of this field in earlier
> > > > specifications.
> >
> > Christoph, I'm gonna revert the horkage patch and apply this one. If
> > you can think of a better way to do this, please let me know.
>
> The one thing that comes to mind would be an additional patch to allow
> people with ATA-7 to bypass the identify device data, and rely just on
> the read log page check, based on a kernel command line parameter.
>
> If we get enough sucessful reports to make it worth it, an whitelist
> could be added...
If the ones we miss are the ones based on old revisions, does it
matter? If we have to, we can just whitelist those devices and I
don't expect there to be many.
Thanks.
--
tejun
^ permalink raw reply
* Re: boot failure with 4.13.0-rc6 due to ATA errors
From: Henrique de Moraes Holschuh @ 2017-08-29 15:51 UTC (permalink / raw)
To: Tejun Heo; +Cc: David Ahern, Christoph Hellwig, linux-ide, LKML, Robert Elliott
In-Reply-To: <20170829153037.GN491396@devbig577.frc2.facebook.com>
On Tue, 29 Aug 2017, Tejun Heo wrote:
> On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote:
> > On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> > > ---
> > > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> > > From: Christoph Hellwig <hch@lst.de>
> > > Date: Tue, 29 Aug 2017 14:35:50 +0200
> > > Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> > >
> > > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > > the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> > > command to avoid issues with buggy devices. The only downside is that
> > > we can't support Security Send / Receive for a device with an older
> > > revision due to the conflicting use of this field in earlier
> > > specifications.
>
> Christoph, I'm gonna revert the horkage patch and apply this one. If
> you can think of a better way to do this, please let me know.
The one thing that comes to mind would be an additional patch to allow
people with ATA-7 to bypass the identify device data, and rely just on
the read log page check, based on a kernel command line parameter.
If we get enough sucessful reports to make it worth it, an whitelist
could be added...
--
Henrique Holschuh
^ permalink raw reply
* Re: [PATCH] libata: quirk read log on no-name M.2 SSD
From: Tejun Heo @ 2017-08-29 15:41 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: idosch, linux-ide
In-Reply-To: <20170828062808.20717-1-hch@lst.de>
On Mon, Aug 28, 2017 at 08:28:08AM +0200, Christoph Hellwig wrote:
> Ivo reported that reading the log page on his systems fails,
> so quirk it as it won't support ZBC or security protocols.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reported-by: Ido Schimmel <idosch@mellanox.com>
> Tested-by: Ido Schimmel <idosch@mellanox.com>
Ido, I've reverted this patch in favor of the following one.
https://marc.info/?l=linux-ide&m=150401053011956&q=raw
Can you please verify whether the above patch works? You can either
remove the horkage patch and apply the above one or test the following
git branch.
git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.13-fixes
Thanks.
--
tejun
^ permalink raw reply
* Re: boot failure with 4.13.0-rc6 due to ATA errors
From: Tejun Heo @ 2017-08-29 15:38 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: David Ahern, linux-ide, LKML, Robert Elliott
In-Reply-To: <20170829124206.GA26738@lst.de>
On Tue, Aug 29, 2017 at 02:42:06PM +0200, Christoph Hellwig wrote:
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
>
> ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> command to avoid issues with buggy devices. The only downside is that
> we can't support Security Send / Receive for a device with an older
> revision due to the conflicting use of this field in earlier
> specifications.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Applied to libata/for-4.13-fixes.
Thanks.
--
tejun
^ permalink raw reply
* Re: boot failure with 4.13.0-rc6 due to ATA errors
From: Tejun Heo @ 2017-08-29 15:30 UTC (permalink / raw)
To: David Ahern; +Cc: Christoph Hellwig, linux-ide, LKML, Robert Elliott
In-Reply-To: <a5caf398-3ae3-4585-23d2-b2afbbc28d7d@gmail.com>
On Tue, Aug 29, 2017 at 09:08:05AM -0600, David Ahern wrote:
> On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> > ---
> > From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> > From: Christoph Hellwig <hch@lst.de>
> > Date: Tue, 29 Aug 2017 14:35:50 +0200
> > Subject: libata: check for trusted computing in IDENTIFY DEVICE data
> >
> > ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> > the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> > command to avoid issues with buggy devices. The only downside is that
> > we can't support Security Send / Receive for a device with an older
> > revision due to the conflicting use of this field in earlier
> > specifications.
Christoph, I'm gonna revert the horkage patch and apply this one. If
you can think of a better way to do this, please let me know.
Thanks.
--
tejun
^ permalink raw reply
* Re: boot failure with 4.13.0-rc6 due to ATA errors
From: David Ahern @ 2017-08-29 15:08 UTC (permalink / raw)
To: Christoph Hellwig, Tejun Heo; +Cc: linux-ide, LKML, Robert Elliott
In-Reply-To: <20170829124206.GA26738@lst.de>
On 8/29/17 6:42 AM, Christoph Hellwig wrote:
> ---
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
>
> ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> command to avoid issues with buggy devices. The only downside is that
> we can't support Security Send / Receive for a device with an older
> revision due to the conflicting use of this field in earlier
> specifications.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/ata/libata-core.c | 3 +++
> include/linux/ata.h | 10 +++++++++-
> 2 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 697f5f896b19..ca57b03ab950 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -2413,6 +2413,9 @@ static void ata_dev_config_trusted(struct ata_device *dev)
> u64 trusted_cap;
> unsigned int err;
>
> + if (!ata_id_has_trusted(dev->id))
> + return;
> +
> if (!ata_identify_page_supported(dev, ATA_LOG_SECURITY)) {
> ata_dev_warn(dev,
> "Security Log not supported\n");
> diff --git a/include/linux/ata.h b/include/linux/ata.h
> index e65ae4b2ed48..c7a353825450 100644
> --- a/include/linux/ata.h
> +++ b/include/linux/ata.h
> @@ -60,7 +60,8 @@ enum {
> ATA_ID_FW_REV = 23,
> ATA_ID_PROD = 27,
> ATA_ID_MAX_MULTSECT = 47,
> - ATA_ID_DWORD_IO = 48,
> + ATA_ID_DWORD_IO = 48, /* before ATA-8 */
> + ATA_ID_TRUSTED = 48, /* ATA-8 and later */
> ATA_ID_CAPABILITY = 49,
> ATA_ID_OLD_PIO_MODES = 51,
> ATA_ID_OLD_DMA_MODES = 52,
> @@ -889,6 +890,13 @@ static inline bool ata_id_has_dword_io(const u16 *id)
> return id[ATA_ID_DWORD_IO] & (1 << 0);
> }
>
> +static inline bool ata_id_has_trusted(const u16 *id)
> +{
> + if (ata_id_major_version(id) <= 7)
> + return false;
> + return id[ATA_ID_TRUSTED] & (1 << 0);
> +}
> +
> static inline bool ata_id_has_unload(const u16 *id)
> {
> if (ata_id_major_version(id) >= 7 &&
>
That works for me.
Tested-by: David Ahern <dsahern@gmail.com>
^ permalink raw reply
* Re: boot failure with 4.13.0-rc6 due to ATA errors
From: Tejun Heo @ 2017-08-29 14:27 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: David Ahern, linux-ide, LKML, Robert Elliott
In-Reply-To: <20170829124206.GA26738@lst.de>
Hello,
On Tue, Aug 29, 2017 at 02:42:06PM +0200, Christoph Hellwig wrote:
> We could try to check the IDENTIFY DEVICE word, but given that it has
> a dual meaning in older spec versions I don't really like the idea
> either. Untested patch below as I'm not near my OPAL capable drive.
I see.
> Also most recent ATA features seem to be keyed off a log page of some
> sort, so we'll run into more problems like this.
:(
> From e661047ec3a25587648b07c02a687a7dac778f3b Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig <hch@lst.de>
> Date: Tue, 29 Aug 2017 14:35:50 +0200
> Subject: libata: check for trusted computing in IDENTIFY DEVICE data
>
> ATA-8 and later mirrors the TRUSTED COMPUTING SUPPORTED bit in word 48 of
> the IDENTIFY DEVICE data. Check this before issuing a READ LOG PAGE
> command to avoid issues with buggy devices. The only downside is that
> we can't support Security Send / Receive for a device with an older
> revision due to the conflicting use of this field in earlier
> specifications.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
David, can you please see whether this patch resolves your issue?
Thanks.
--
tejun
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: ata: add DT bindings for MediaTek SATA controller
From: Tejun Heo @ 2017-08-29 14:24 UTC (permalink / raw)
To: Ryder Lee
Cc: Hans de Goede, Rob Herring, devicetree, linux-mediatek,
linux-kernel, linux-ide, Long Cheng
In-Reply-To: <0ac0ff921914acd95b7b5906ca435571e55c355f.1503018631.git.ryder.lee@mediatek.com>
On Fri, Aug 18, 2017 at 09:13:08AM +0800, Ryder Lee wrote:
> Add DT bindings for the onboard SATA controller present on the MediaTek
> SoCs.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> Acked-by: Rob Herring <robh@kernel.org>
Applied to libata/for-4.14.
Thanks.
--
tejun
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox