[PATCH v2 1/2] ata: sata_dwc_460ex: Fix crash due to OOB write

[PATCH v2 1/2] ata: sata_dwc_460ex: Fix crash due to OOB write

[Christian Lamparter]

the driver uses libata's "tag" values from in various arrays.
Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
the value of the SATA_DWC_QCMD_MAX needs to account for that.

Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
this as reported by Tice Rex on the OpenWrt Forum and
reproduced (with symbols) here:

| BUG: Kernel NULL pointer dereference at 0x00000000
| Faulting instruction address: 0xc03ed4b8
| Oops: Kernel access of bad area, sig: 11 [#1]
| BE PAGE_SIZE=4K PowerPC 44x Platform
| CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
| NIP:  c03ed4b8 LR: c03d27e8 CTR: c03ed36c
| REGS: cfa59950 TRAP: 0300   Not tainted  (5.4.163)
| MSR:  00021000 <CE,ME>  CR: 42000222  XER: 00000000
| DEAR: 00000000 ESR: 00000000
| GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]
| [..]
| NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254
| LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc
| Call Trace:
| [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)
| [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc
| [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524
| [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0
| [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204
| [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130
| [...]

This is because sata_dwc_dma_xfer_complete() NULLs the
dma_pending's next neighbour "chan" (a *dma_chan struct) in
this '32' case right here (line ~735):
> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;

Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes
the NULL'd hsdevp->chan to the dmaengine_slave_config() which then
causes the crash.

With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.
This avoids the OOB. But please note, there was a worthwhile discussion
on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not
be a "fake" 33 command-long queue size.

Ideally, the dw driver should account for the ATA_TAG_INTERNAL.
In Damien Le Moal's words: "... having looked at the driver, it
is a bigger change than just faking a 33rd "tag" that is in fact
not a command tag at all."

Fixes: 28361c403683c ("libata: add extra internal command")
Cc: stable@kernel.org # 4.18+
BugLink: https://github.com/openwrt/openwrt/issues/9505
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
v1 -> v2: replaced '33' magic value (Damien)
	  Dropped (invalid) Reported-by (Damien)
	  Proper BugLink (Andy - OpenWrt's github issue tracker)
---
 drivers/ata/sata_dwc_460ex.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/sata_dwc_460ex.c b/drivers/ata/sata_dwc_460ex.c
index bec33d781ae0..e3263e961045 100644
--- a/drivers/ata/sata_dwc_460ex.c
+++ b/drivers/ata/sata_dwc_460ex.c
@@ -137,7 +137,11 @@ struct sata_dwc_device {
 #endif
 };
 
-#define SATA_DWC_QCMD_MAX	32
+/*
+ * Allow one extra special slot for commands and DMA management
+ * to account for libata internal commands.
+ */
+#define SATA_DWC_QCMD_MAX	(ATA_MAX_QUEUE + 1)
 
 struct sata_dwc_device_port {
 	struct sata_dwc_device	*hsdev;
-- 
2.35.1

[PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Christian Lamparter]

Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
the a message: "READ LOG DMA EXT failed, trying PIO" during boot.

Initially this was discovered because it caused a crash
with the sata_dwc_460ex controller on a WD MyBook Live DUO.

The reporter "Tice Rex" which has the unique opportunity that he
has two Samsung 840 EVO SSD! One with the older firmware "EXT0BB0Q"
which booted fine and didn't expose "READ LOG DMA EXT". But the
newer/latest firmware "EXT0DB6Q" caused the headaches.

BugLink: https://github.com/openwrt/openwrt/issues/9505
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
v1 -> v2: removed Reported-by Tag (Damien)
	  opened up a issue + added BugLink (Andy)
---
 drivers/ata/libata-core.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 0c854aebfe0b..760c0d81d148 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -4014,6 +4014,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
 						ATA_HORKAGE_ZERO_AFTER_TRIM, },
 	{ "Crucial_CT*MX100*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
 						ATA_HORKAGE_ZERO_AFTER_TRIM, },
+	{ "Samsung SSD 840 EVO*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
+						ATA_HORKAGE_NO_DMA_LOG |
+						ATA_HORKAGE_ZERO_AFTER_TRIM, },
 	{ "Samsung SSD 840*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
 						ATA_HORKAGE_ZERO_AFTER_TRIM, },
 	{ "Samsung SSD 850*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
-- 
2.35.1

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Reimar Döffinger]

> On 19 Mar 2022, at 21:11, Christian Lamparter <chunkeey@gmail.com> wrote:
> 
> Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
> the a message: "READ LOG DMA EXT failed, trying PIO" during boot.

I don't see any info on which kernel this happened with anywhere.
Because there was a bug that tried to use READ LOG DMA EXT even though DMA was not enabled.
That was fixed by a patch from me for 5.16 (and backports).
The behaviour you describe matches the possible symptoms of that bug.
So it would be good to know we're not blaming the drive for an already fixed bug in the kernel...
(I am still seeing some issues that READ LOG EXT - the non-DMA version - times out with interrupt lost for some device/controller combinations, but at least that "only" adds an extra 15 seconds to the boot. It's still a bit silly because in combination with e.g. IDE controllers READ LOG provides absolutely no useful functionality as far as I can tell).

Best regards,
Reimar

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Reimar Döffinger]

> On 19 Mar 2022, at 21:31, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
> 
> 
> 
>> On 19 Mar 2022, at 21:11, Christian Lamparter <chunkeey@gmail.com> wrote:
>> 
>> Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
>> the a message: "READ LOG DMA EXT failed, trying PIO" during boot.
> 
> I don't see any info on which kernel this happened with anywhere.
> Because there was a bug that tried to use READ LOG DMA EXT even though DMA was not enabled.
> That was fixed by a patch from me for 5.16 (and backports).
> The behaviour you describe matches the possible symptoms of that bug.
> So it would be good to know we're not blaming the drive for an already fixed bug in the kernel...

Ok, seems not the case, fix is in 5.4.160 and the first report was from 5.4.179 it seems.

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Damien Le Moal]

On 2022/03/20 5:31, Reimar Döffinger wrote:
> 
> 
>> On 19 Mar 2022, at 21:11, Christian Lamparter <chunkeey@gmail.com> wrote:
>> 
>> Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with the a
>> message: "READ LOG DMA EXT failed, trying PIO" during boot.
> 
> I don't see any info on which kernel this happened with anywhere. Because
> there was a bug that tried to use READ LOG DMA EXT even though DMA was not
> enabled. That was fixed by a patch from me for 5.16 (and backports). The
> behaviour you describe matches the possible symptoms of that bug. So it would
> be good to know we're not blaming the drive for an already fixed bug in the
> kernel... (I am still seeing some issues that READ LOG EXT - the non-DMA
> version - times out with interrupt lost for some device/controller
> combinations, but at least that "only" adds an extra 15 seconds to the boot.
> It's still a bit silly because in combination with e.g. IDE controllers READ
> LOG provides absolutely no useful functionality as far as I can tell).

Yes, the added 15s is a longer timeout to wait for READ LOG EXT reply on resume.
Some drives are slow to respond and that was causing drives to disapear on
resume. I agree that for old IDE/PATA drive, we could disable READ LOG [DMA[ EXT
entirely as all the information for the drive can be found in the IDENTIFY data.
So no point. All the pata drivers could set the nolog horkage. There are still
many more recent drives that have weird behavior with read log though. This is a
pain to sort out and can be done only if a bug report is filed.

I am preparing a series to improve the libata.force boot parameter to allow
setting any horkage/link flag to disable things for drives that do not behave
nicely. That will allow users to tune systems without having to wait for the
kernel to be patched.

> 
> Best regards, Reimar


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Sergey Shtylyov]

Hello!

On 3/19/22 11:11 PM, Christian Lamparter wrote:

> Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
> the a message: "READ LOG DMA EXT failed, trying PIO" during boot.
> 
> Initially this was discovered because it caused a crash
> with the sata_dwc_460ex controller on a WD MyBook Live DUO.
> 
> The reporter "Tice Rex" which has the unique opportunity that he
> has two Samsung 840 EVO SSD! One with the older firmware "EXT0BB0Q"
> which booted fine and didn't expose "READ LOG DMA EXT". But the
> newer/latest firmware "EXT0DB6Q" caused the headaches.
> 
> BugLink: https://github.com/openwrt/openwrt/issues/9505
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> v1 -> v2: removed Reported-by Tag (Damien)
> 	  opened up a issue + added BugLink (Andy)
> ---
>  drivers/ata/libata-core.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 0c854aebfe0b..760c0d81d148 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -4014,6 +4014,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>  						ATA_HORKAGE_ZERO_AFTER_TRIM, },
>  	{ "Crucial_CT*MX100*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
>  						ATA_HORKAGE_ZERO_AFTER_TRIM, },
> +	{ "Samsung SSD 840 EVO*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
> +						ATA_HORKAGE_NO_DMA_LOG |
> +						ATA_HORKAGE_ZERO_AFTER_TRIM, },
>  	{ "Samsung SSD 840*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
>  						ATA_HORKAGE_ZERO_AFTER_TRIM, },

  Shouldn't this entry be modified instead?

[...]

MBR, Sergey

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Andy Shevchenko]

On Mon, Mar 21, 2022 at 11:00:51AM +0300, Sergey Shtylyov wrote:
> On 3/19/22 11:11 PM, Christian Lamparter wrote:

...

> > +	{ "Samsung SSD 840 EVO*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
> > +						ATA_HORKAGE_NO_DMA_LOG |
> > +						ATA_HORKAGE_ZERO_AFTER_TRIM, },
> >  	{ "Samsung SSD 840*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
> >  						ATA_HORKAGE_ZERO_AFTER_TRIM, },
> 
>   Shouldn't this entry be modified instead?

Wouldn't it modify much more devices with unknown outcome?
I would be on the safer side as done by this patch.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Damien Le Moal]

On 2022/03/21 19:43, Andy Shevchenko wrote:
> On Mon, Mar 21, 2022 at 11:00:51AM +0300, Sergey Shtylyov wrote:
>> On 3/19/22 11:11 PM, Christian Lamparter wrote:
> 
> ...
> 
>>> +	{ "Samsung SSD 840 EVO*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
>>> +						ATA_HORKAGE_NO_DMA_LOG |
>>> +						ATA_HORKAGE_ZERO_AFTER_TRIM, },
>>>  	{ "Samsung SSD 840*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
>>>  						ATA_HORKAGE_ZERO_AFTER_TRIM, },
>>
>>   Shouldn't this entry be modified instead?
> 
> Wouldn't it modify much more devices with unknown outcome?
> I would be on the safer side as done by this patch.
> 

Yes, I think so too. A little googling shows that there are "840 xxx", "840 PRO
xxx" and "840 EVO xxx", at least as product names. Not sure how all these are
grouped with the actual device reported model.

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Damien Le Moal]

On 3/20/22 05:11, Christian Lamparter wrote:
> Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
> the a message: "READ LOG DMA EXT failed, trying PIO" during boot.
> 
> Initially this was discovered because it caused a crash
> with the sata_dwc_460ex controller on a WD MyBook Live DUO.
> 
> The reporter "Tice Rex" which has the unique opportunity that he
> has two Samsung 840 EVO SSD! One with the older firmware "EXT0BB0Q"
> which booted fine and didn't expose "READ LOG DMA EXT". But the
> newer/latest firmware "EXT0DB6Q" caused the headaches.
> 
> BugLink: https://github.com/openwrt/openwrt/issues/9505
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> ---
> v1 -> v2: removed Reported-by Tag (Damien)
> 	  opened up a issue + added BugLink (Andy)
> ---
>   drivers/ata/libata-core.c | 3 +++
>   1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
> index 0c854aebfe0b..760c0d81d148 100644
> --- a/drivers/ata/libata-core.c
> +++ b/drivers/ata/libata-core.c
> @@ -4014,6 +4014,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = {
>   						ATA_HORKAGE_ZERO_AFTER_TRIM, },
>   	{ "Crucial_CT*MX100*",		"MU01",	ATA_HORKAGE_NO_NCQ_TRIM |
>   						ATA_HORKAGE_ZERO_AFTER_TRIM, },
> +	{ "Samsung SSD 840 EVO*",	NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
> +						ATA_HORKAGE_NO_DMA_LOG |
> +						ATA_HORKAGE_ZERO_AFTER_TRIM, },
>   	{ "Samsung SSD 840*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |
>   						ATA_HORKAGE_ZERO_AFTER_TRIM, },
>   	{ "Samsung SSD 850*",		NULL,	ATA_HORKAGE_NO_NCQ_TRIM |

Applied to for-5.18-fixes. Thanks !

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v2 1/2] ata: sata_dwc_460ex: Fix crash due to OOB write

[Damien Le Moal]

On 3/20/22 05:11, Christian Lamparter wrote:
> the driver uses libata's "tag" values from in various arrays.
> Since the mentioned patch bumped the ATA_TAG_INTERNAL to 32,
> the value of the SATA_DWC_QCMD_MAX needs to account for that.
> 
> Otherwise ATA_TAG_INTERNAL usage cause similar crashes like
> this as reported by Tice Rex on the OpenWrt Forum and
> reproduced (with symbols) here:
> 
> | BUG: Kernel NULL pointer dereference at 0x00000000
> | Faulting instruction address: 0xc03ed4b8
> | Oops: Kernel access of bad area, sig: 11 [#1]
> | BE PAGE_SIZE=4K PowerPC 44x Platform
> | CPU: 0 PID: 362 Comm: scsi_eh_1 Not tainted 5.4.163 #0
> | NIP:  c03ed4b8 LR: c03d27e8 CTR: c03ed36c
> | REGS: cfa59950 TRAP: 0300   Not tainted  (5.4.163)
> | MSR:  00021000 <CE,ME>  CR: 42000222  XER: 00000000
> | DEAR: 00000000 ESR: 00000000
> | GPR00: c03d27e8 cfa59a08 cfa55fe0 00000000 0fa46bc0 [...]
> | [..]
> | NIP [c03ed4b8] sata_dwc_qc_issue+0x14c/0x254
> | LR [c03d27e8] ata_qc_issue+0x1c8/0x2dc
> | Call Trace:
> | [cfa59a08] [c003f4e0] __cancel_work_timer+0x124/0x194 (unreliable)
> | [cfa59a78] [c03d27e8] ata_qc_issue+0x1c8/0x2dc
> | [cfa59a98] [c03d2b3c] ata_exec_internal_sg+0x240/0x524
> | [cfa59b08] [c03d2e98] ata_exec_internal+0x78/0xe0
> | [cfa59b58] [c03d30fc] ata_read_log_page.part.38+0x1dc/0x204
> | [cfa59bc8] [c03d324c] ata_identify_page_supported+0x68/0x130
> | [...]
> 
> This is because sata_dwc_dma_xfer_complete() NULLs the
> dma_pending's next neighbour "chan" (a *dma_chan struct) in
> this '32' case right here (line ~735):
>> hsdevp->dma_pending[tag] = SATA_DWC_DMA_PENDING_NONE;
> 
> Then the next time, a dma gets issued; dma_dwc_xfer_setup() passes
> the NULL'd hsdevp->chan to the dmaengine_slave_config() which then
> causes the crash.
> 
> With this patch, SATA_DWC_QCMD_MAX is now set to ATA_MAX_QUEUE + 1.
> This avoids the OOB. But please note, there was a worthwhile discussion
> on what ATA_TAG_INTERNAL and ATA_MAX_QUEUE is. And why there should not
> be a "fake" 33 command-long queue size.
> 
> Ideally, the dw driver should account for the ATA_TAG_INTERNAL.
> In Damien Le Moal's words: "... having looked at the driver, it
> is a bigger change than just faking a 33rd "tag" that is in fact
> not a command tag at all."
> 
> Fixes: 28361c403683c ("libata: add extra internal command")
> Cc: stable@kernel.org # 4.18+
> BugLink: https://github.com/openwrt/openwrt/issues/9505
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>

Applied to for-5.18-fixes. Thanks !


-- 
Damien Le Moal
Western Digital Research

Re: [PATCH v2 2/2] ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs

[Christian Lamparter]

(I likely butchered that import into thunderbird).

On 19/03/2022 21:42, Reimar Döffinger wrote:
>> On 19 Mar 2022, at 21:31, Reimar Döffinger <Reimar.Doeffinger@gmx.de> wrote:
>>
>>
>> Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with
>> the a message: "READ LOG DMA EXT failed, trying PIO" during boot.
>> I don't see any info on which kernel this happened with anywhere.
>> Because there was a bug that tried to use READ LOG DMA EXT even though
> DMA was not enabled.
>> That was fixed by a patch from me for 5.16 (and backports).
>> The behaviour you describe matches the possible symptoms of that bug.
>> So it would be good to know we're not blaming the drive for an already =
> fixed bug in the kernel...
>
> Ok, seems not the case, fix is in 5.4.160 and the first report was from
> 5.4.179 it seems.

I can provide more information. While I don't have the TiceRex's
Samsung 840 EVO 250GB SSD. I have my own Samsung EVO 120GB.
I flashed it long ago with the same new/latest firmware.

---
# hdparm -i /dev/sdb
/dev/sdb:

ATA device, with non-removable media
        Model Number:       Samsung SSD 840 EVO 120GB
        Serial Number:      XXXXXXXXXXXXXXXX
        Firmware Revision:  EXT0DB6Q
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0x0039)
        Supported: 9 8 7 6 5
        Likely used: 9
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   234441648
        LBA48  user addressable sectors:   234441648
        Logical  Sector size:                   512 bytes
        Physical Sector size:                   512 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:      114473 MBytes
        device size with M = 1000*1000:      120034 MBytes (120 GB)
        cache/buffer size  = unknown
        Nominal Media Rotation Rate: Solid State Device
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 1   Current = 1
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    NOP cmd
           *    DOWNLOAD_MICROCODE
                SET_MAX security extension
           *    48-bit Address feature set
           *    Device Configuration Overlay feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
                Write-Read-Verify feature set
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Phy event counters
           *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT  <=== !!!
                DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Asynchronous notification (eg. media change)
           *    Software settings preservation
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Error Recovery Control (AC3)
           *    SCT Features Control (AC4)
           *    SCT Data Tables (AC5)
           *    Device encrypts all user data
           *    DOWNLOAD MICROCODE DMA command
           *    SET MAX SETPASSWORD/UNLOCK DMA commands
           *    WRITE BUFFER DMA command
           *    READ BUFFER DMA command
           *    Data Set Management TRIM supported (limit 8 blocks)
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
        not     frozen
        not     expired: security count
                supported: enhanced erase
        2min for SECURITY ERASE UNIT. 8min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: XXXXXXXXXX
        NAA             : X
        IEEE OUI        : X
        Unique ID       : X
Checksum: correct
---

Mine also claims to have "READ_LOG_DMA_EXT equivalent to READ_LOG_EXT" enabled.
But yee, it's not working. This is with "Linux OpenWrt 5.10.104". Which is
5.10.104 and a lot of OpenWrt patches (but nothing related to
READ_LOG_(DMA_)EXT).

Cheers,
Christian