Re: libata and software reset

[John Garry <john.garry@huawei.com>]

On 19/10/2022 10:56, Damien Le Moal wrote:
>> The difference really comes down to the controller programming interface.
>>
>> For ahci we have a MMIO interface to issue the software reset command.
>>
>> For my SAS controller of interest, there is no such MMIO interface. To
>> issue the reset we build a h2d fis with a SRST set, and send on the
>> controller ring buffer like any other IO.
>>
>> As I mentioned, we can set the SRST for the h2d fis on the HW interface
>> without issue, and it works fine. The problem for me is that the command
>> comes via libsas/driver, and I would like it to come from libata such
>> that it has a ATA queued command associated. But then we have the
>> problem that the port is frozen at such times that we want to issue this
>> command.
> Yeah, qc is too high level for this to work.

Some more background is that this is all related to the "reserved" 
commands work. The issue is that it is difficult to differentiate 
between this libsas softreset command and normal ATA queued commands - 
the normal check is "is the device associated sata", but that doesn't 
work. If we could always have a ATA queued command, then that would be 
better. But, as you say, it is too high level.

Let me check what else I would do. BTW, I will send an update on that 
work in a day or so.

> But we could probably do
> something generic at TF or FIS level. libata-sata.c has already some
> code in that area, something for a "reset TF/FIS" would fit in that file
> too. libahci could also use that too.
>

yeah, that would seem a good consolidation.

Thanks!