Re: [PATCH v2 1/2] ata: libata-core: Skip HPA resize for locked drives

[Damien Le Moal]

On 7/8/26 02:01, TJ Adams wrote:
> On Mon, Jul 6, 2026 at 11:02 PM Damien Le Moal <dlemoal@xxxxxxxxxx> wrote:
>>
>> On 7/7/26 06:00, TJ Adams wrote:
>>> Skip HPA resize in ata_hpa_resize() if the drive is security locked.
>>> If the drive is locked, the command to read the native max address
>>> fails with -EACCES, which currently causes the sticky quirk
>>> ATA_QUIRK_BROKEN_HPA to be set on the device.
>>>
>>> Setting this sticky quirk causes subsequent revalidations (after the
>>> drive is unlocked) to bypass HPA checks, preventing the unlocked drive
>>> from exposing its full native capacity without a reboot or device removal.
>>>
>>> Signed-off-by: Terrence Adams <tadamsjr@xxxxxxxxxx>
>>
>> Doesn't this need the same fixes tag as patch 2 ?
> 
> Hey Damien,
> 
> I don't think this should have the same fixes tag as patch 2, because without
> commit 91842ed844a0 ("ata: libata-core: Set capacity to zero for a security
> locked drive") the problem still exists.
> 
> The quirk gets set not because of the capacity being zero but because the locked
> drive returns -EACCES.
> 
> I think Fixes: 05027adccc09 ("libata: remiplement ata_hpa_resize()"), might be
> better for this patch.

Most likely not. This dates back to 2007 and security was not supported until
2017 (commit 818831c8b22f7). Let me dig a little more. But at the very least, I
will add a Cc: stable tag to the patch.

> If you agree, I can send a v3 or if it's easier, feel free to amend the commit
> message yourself.

No need to resend. I will add whatever tag is needed.
Thanks.

> 
> Best Regards,
> TJ Adams
> 


-- 
Damien Le Moal
Western Digital Research