Re: libata and software reset

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

On 18/10/2022 16:04, Niklas Cassel wrote:
>> Hi guys,
>>
>> In the hisi_sas driver there are times in which we need to issue an ATA
>> software reset. For this we use hisi_sas_softreset_ata_disk() ->
>> sas_execute_ata_cmd() -> sas_execute_tmf(), which uses libsas "slow task"
>> mechanism to issue the command.
>>
>> I would like if libata provided such a function to issue a software reset,
>> such that we can send the command as an ATA queued command.
>>
>> The problem is that often when we would want to issue this software reset
>> the associated ata port is frozen, like in ATA EH, and so we cannot issue
>> ATA queued commands - internal or normal - at that time.
>>
>> Is there any way to solve this? Or I am just misunderstanding how and when
>> ATA queued commands can and should be used?
>>
> Hello John,

Hi Niklas,

> 
> See the kdoc above __ata_port_freeze():
> "This function is called when HSM violation or some other
> condition disrupts normal operation of the port.  Frozen port
> is not allowed to perform any operation until the port is
> thawed, which usually follows a successful reset.

ok, I see.

> 
> ap->ops->freeze() callback can be used for freezing the port
> hardware-wise (e.g. mask interrupt and stop DMA engine).  If a
> port cannot be frozen hardware-wise, the interrupt handler
> must ack and clear interrupts unconditionally while the port
> is frozen."
> 
> 
> ata_port_operations.qc_issue() is obviously an operation on the port,
> so it makes sense that it is not allowed.

hmmm..ok, then.


> Interrupts are also usually masked or disabled at this time, so we
> won't get an IRQ with the completion.

Doesn't this policy really just depend on the host controller driver?

> 
> Perhaps one could argue that there could be an API to execute a polled
> command. But if the port is in a bad state,
  e.g. a HSM error (RDY bit
> is not set), issuing a command would likely fail anyway, regardless if
> using polling or IRQs.
> 
> 
>> I assume that ata_port_operations.softreset callback requires a method to be
>> able to issue the softreset directly from the driver, like ahci_softreset()
>> -> ahci_do_softreset() -> ahci_exec_polled_cmd().
> Yes, looking .softreset in a few ata drivers, they all seem issue the
> softreset directly from the driver.
> (e.g. ahci_do_softreset() calls ahci_exec_polled_cmd() which just always
> uses bit 0 in PORT_CMD_ISSUE, so it ignores hw_tag.)
> 
> But I don't think that I fully understand your problem.
> 
> hisi_sas_softreset_ata_disk() -> sas_execute_ata_cmd() -> sas_execute_tmf()
> calls lldd_execute_task() (hisi_sas_queue_command()) and then calls
> waits for completion.
> 
> How is this different from e.g. the libahci case?

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.

> Doesn't this end up being the same as resetting the port directly from the
> driver? (if we ignore all the callbacks)
> Or do you actually get stuck on a ata_port_is_frozen() check somewhere?


Thanks,
John