boot failure with 4.13.0-rc6 due to ATA errors

boot failure with 4.13.0-rc6 due to ATA errors

[David Ahern]

Not sure why mailing list to direct this bug report to, so starting with
libata based on the error messages.

Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch
fails to boot due to ATA errors:

[    9.185203] ata1.00: failed to set xfermode (err_mask=0x40)
[    9.500825] ata1.00: revalidation failed (errno=-5)
[   20.449205] ata1.00: failed to set xfermode (err_mask=0x40)

I just tried Linus' top of tree (cc4a41fe5541) and it still fails. With
v4.12 the same switch boots and 'dmesg | grep ata' shows:

[    0.129080] libata version 3.00 loaded.
[    1.016520] ata1: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce100 irq 27
[    1.016524] ata2: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce180 irq 27
[    1.016528] ata3: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce200 irq 27
[    1.016531] ata4: SATA max UDMA/133 abar m2048@0xdffce000 port
0xdffce280 irq 27
[    1.028623] ata5: SATA max UDMA/133 abar m2048@0xdffcd000 port
0xdffcd100 irq 28
[    1.028627] ata6: SATA max UDMA/133 abar m2048@0xdffcd000 port
0xdffcd180 irq 28
[    1.326767] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[    1.328646] ata2: SATA link down (SStatus 0 SControl 300)
[    1.330519] ata4: SATA link down (SStatus 0 SControl 300)
[    1.330554] ata3: SATA link down (SStatus 0 SControl 300)
[    1.330575] ata1.00: ATA-9: InnoDisk Corp. - mSATA 3ME, S130604, max
UDMA/133
[    1.330581] ata1.00: 31277232 sectors, multi 16: LBA48 NCQ (depth
31/32), AA
[    1.332433] ata1.00: failed to get Identify Device Data, Emask 0x1
[    1.332709] ata1.00: failed to get Identify Device Data, Emask 0x1
[    1.332717] ata1.00: configured for UDMA/133
[    1.335813] ata6: SATA link down (SStatus 0 SControl 300)
[    1.339829] ata5: SATA link down (SStatus 0 SControl 300)

Given the overhead of building, installing, booting and recovering from
a failed boot, 'git bisect' is not a realistic option for this switch
option unless some one can cut the span to a few iterations.

If it helps, lspci and lsscsi output from an older kernel:

# lspci
00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
Transaction Router (rev 02)
00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 1 (rev 02)
00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 2 (rev 02)
00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
Port 3 (rev 02)
00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus
2.0 (rev 02)
00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354
(rev 03)
00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
Enhanced Host Controller (rev 02)
00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA2 Controller (rev 02)
00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
SATA3 Controller (rev 02)
00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
01:00.0 Ethernet controller: Broadcom Corporation Device b854 (rev 03)


# lsscsi
[0:0:0:0]    disk    ATA      InnoDisk Corp. - 604   /dev/sda

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Tejun Heo]

(cc'ing Christoph)

On Mon, Aug 28, 2017 at 12:40:39PM -0600, David Ahern wrote:
> Not sure why mailing list to direct this bug report to, so starting with
> libata based on the error messages.
> 
> Some where between v4.12 and 4.13.0-rc6 a Celestica redstone switch
> fails to boot due to ATA errors:
> 
> [    9.185203] ata1.00: failed to set xfermode (err_mask=0x40)
> [    9.500825] ata1.00: revalidation failed (errno=-5)
> [   20.449205] ata1.00: failed to set xfermode (err_mask=0x40)
> 
> I just tried Linus' top of tree (cc4a41fe5541) and it still fails. With
> v4.12 the same switch boots and 'dmesg | grep ata' shows:
> 
> [    0.129080] libata version 3.00 loaded.
> [    1.016520] ata1: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce100 irq 27
> [    1.016524] ata2: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce180 irq 27
> [    1.016528] ata3: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce200 irq 27
> [    1.016531] ata4: SATA max UDMA/133 abar m2048@0xdffce000 port
> 0xdffce280 irq 27
> [    1.028623] ata5: SATA max UDMA/133 abar m2048@0xdffcd000 port
> 0xdffcd100 irq 28
> [    1.028627] ata6: SATA max UDMA/133 abar m2048@0xdffcd000 port
> 0xdffcd180 irq 28
> [    1.326767] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
> [    1.328646] ata2: SATA link down (SStatus 0 SControl 300)
> [    1.330519] ata4: SATA link down (SStatus 0 SControl 300)
> [    1.330554] ata3: SATA link down (SStatus 0 SControl 300)
> [    1.330575] ata1.00: ATA-9: InnoDisk Corp. - mSATA 3ME, S130604, max
> UDMA/133
> [    1.330581] ata1.00: 31277232 sectors, multi 16: LBA48 NCQ (depth
> 31/32), AA
> [    1.332433] ata1.00: failed to get Identify Device Data, Emask 0x1
> [    1.332709] ata1.00: failed to get Identify Device Data, Emask 0x1
> [    1.332717] ata1.00: configured for UDMA/133
> [    1.335813] ata6: SATA link down (SStatus 0 SControl 300)
> [    1.339829] ata5: SATA link down (SStatus 0 SControl 300)
> 
> Given the overhead of building, installing, booting and recovering from
> a failed boot, 'git bisect' is not a realistic option for this switch
> option unless some one can cut the span to a few iterations.
> 
> If it helps, lspci and lsscsi output from an older kernel:
> 
> # lspci
> 00:00.0 Host bridge: Intel Corporation Atom processor C2000 SoC
> Transaction Router (rev 02)
> 00:01.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 1 (rev 02)
> 00:02.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 2 (rev 02)
> 00:03.0 PCI bridge: Intel Corporation Atom processor C2000 PCIe Root
> Port 3 (rev 02)
> 00:0e.0 Host bridge: Intel Corporation Atom processor C2000 RAS (rev 02)
> 00:0f.0 IOMMU: Intel Corporation Atom processor C2000 RCEC (rev 02)
> 00:13.0 System peripheral: Intel Corporation Atom processor C2000 SMBus
> 2.0 (rev 02)
> 00:14.0 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:14.1 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:14.2 Ethernet controller: Intel Corporation Ethernet Connection I354
> (rev 03)
> 00:16.0 USB controller: Intel Corporation Atom processor C2000 USB
> Enhanced Host Controller (rev 02)
> 00:17.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
> SATA2 Controller (rev 02)
> 00:18.0 SATA controller: Intel Corporation Atom processor C2000 AHCI
> SATA3 Controller (rev 02)
> 00:1f.0 ISA bridge: Intel Corporation Atom processor C2000 PCU (rev 02)
> 00:1f.3 SMBus: Intel Corporation Atom processor C2000 PCU SMBus (rev 02)
> 01:00.0 Ethernet controller: Broadcom Corporation Device b854 (rev 03)
> 
> 
> # lsscsi
> [0:0:0:0]    disk    ATA      InnoDisk Corp. - 604   /dev/sda

Can you please verify whether 818831c8b22f ("libata: implement
SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
to verify that the problem is there, and try the one prior?

Thanks.

-- 
tejun

Re: boot failure with 4.13.0-rc6 due to ATA errors

[David Ahern]

On 8/28/17 1:59 PM, Tejun Heo wrote:
> Can you please verify whether 818831c8b22f ("libata: implement
> SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
> to verify that the problem is there, and try the one prior?

That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
works fine.

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Tejun Heo]

Hello,

On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote:
> On 8/28/17 1:59 PM, Tejun Heo wrote:
> > Can you please verify whether 818831c8b22f ("libata: implement
> > SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
> > to verify that the problem is there, and try the one prior?
> 
> That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
> works fine.

Christoph, is there anything we can do to further gate issuing of the
offending command?  Otherwise, we might have to go for whitelist
instead.

Thanks.

-- 
tejun

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Christoph Hellwig]

On Mon, Aug 28, 2017 at 02:22:25PM -0700, Tejun Heo wrote:
> Hello,
> 
> On Mon, Aug 28, 2017 at 02:26:52PM -0600, David Ahern wrote:
> > On 8/28/17 1:59 PM, Tejun Heo wrote:
> > > Can you please verify whether 818831c8b22f ("libata: implement
> > > SECURITY PROTOCOL IN/OUT") is the culprit?  ie. try to boot the commit
> > > to verify that the problem is there, and try the one prior?
> > 
> > That commit is the problem. a0fd2454a36ffab2ce39b3a91c1385a5f98e63f0
> > works fine.
> 
> Christoph, is there anything we can do to further gate issuing of the
> offending command?  Otherwise, we might have to go for whitelist
> instead.

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.

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>
---
 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 &&
-- 
2.11.0

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Tejun Heo]

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

Re: boot failure with 4.13.0-rc6 due to ATA errors

[David Ahern]

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>

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Tejun Heo]

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

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Tejun Heo]

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

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Henrique de Moraes Holschuh]

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

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Tejun Heo]

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

Re: boot failure with 4.13.0-rc6 due to ATA errors

[Henrique de Moraes Holschuh]

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