kernel/linux.git/drivers/ata/libahci.c, branch v6.3

ata: libata: respect successfully completed commands during errors

2023-01-04T04:39:19+00:00

In AHCI specification 1.3.1: "5.5.3 Processing Completed Commands" "For each port that has an interrupt pending: 1. Software determines the cause of the interrupt by reading the PxIS register. It is possible for multiple bits to be set. 2. Software clears appropriate bits in the PxIS register corresponding to the cause of the interrupt. 3. Software clears the interrupt bit in IS.IPS corresponding to the port. 4. If executing non-queued commands, software reads the PxCI register, and compares the current value to the list of commands previously issued by software that are still outstanding. If executing native queued commands, software reads the PxSACT register and compares the current value to the list of commands previously issued by software. Software completes with success any outstanding command whose corresponding bit has been cleared in the respective register. PxCI and PxSACT are volatile registers; software should only use their values to determine commands that have completed, not to determine which commands have previously been issued. 5. If there were errors, noted in the PxIS register, software performs error recovery actions (see section 6.2.2)." The documentation for the PxSACT shadow register in AHCI: "The device clears bits in this field by sending a Set Device Bits FIS to the host. The HBA clears bits in this field that are set to ‘1’ in the SActive field of the Set Device Bits FIS. The HBA only clears bits that correspond to native queued commands that have completed successfully." Additionally, in SATA specification 3.5a: "11.15 FPDMA QUEUED command protocol" "DFPDMAQ11: ERROR Halt command processing and transmit Set Device Bits FIS to host with the ERR bit in Status field set to one, Interrupt bit set to one, ATA error code set to one in the ERROR field, bits in ACT field cleared to zero for any outstanding queued commands, and bits set to one for any successfully completed queued commands that completion notification not yet delivered." I.e. even when the HBA triggers an error interrupt, the HBA will still clear successfully completed commands in PxSACT. Commands that did not complete successfully will still have its bit set in PxSACT. (Which means the command that caused the NCQ error and queued commands that had not yet finished at the time when the NCQ error occurred.) Additionally, for a HBA that does not have the libata flag AHCI_HFLAG_MULTI_MSI set, all ap->locks will point to host->lock, which means that IRQs will be disabled for one port while another port's IRQ handler is running. The HBA will still receive FISes from the device, even if IRQs on the HBA itself are disabled. What can thus e.g. receive a FIS that completes several commands successfully, followed by a FIS that does (or does not) complete additional commands with the error bit set, to indicate that at least one command was aborted. Therefore, modify ahci_handle_port_interrupt() using the new helper ahci_qc_complete() to complete the commands that have already been signaled as successfully through a regular completion SDB FIS, as not doing so would simply cause successfully completed commands to be retried for no good reason. Co-developed-by: Damien Le Moal Signed-off-by: Damien Le Moal Signed-off-by: Niklas Cassel

ata: libata: read the shared status for successful NCQ commands once

2023-01-04T04:38:14+00:00

Currently, the status is being read for each QC, inside ata_qc_complete(), which means that QCs being completed by ata_qc_complete_multiple() (i.e. multiple QCs completed during a single interrupt), can have different status and error bits set. This is because the FIS Receive Area will get updated as soon as the HBA receives a new FIS from the device in the NCQ case. Here is an example of the problem: ata14.00: ata_qc_complete_multiple: done_mask: 0x180000 qc tag: 19 cmd: 0x61 flags: 0x11b err_mask: 0x0 tf->status: 0x40 qc tag: 20 cmd: 0x61 flags: 0x11b err_mask: 0x0 tf->status: 0x43 A print in ata_qc_complete_multiple(), shows that done_mask is: 0x180000 which means that tag 19 and 20 were completed. Another print in ata_qc_complete(), after the call to fill_result_tf(), shows that tag 19 and 20 have different status values, even though they were completed in the same ata_qc_complete_multiple() call. If PMP is not enabled, simply read the status and error once, before calling ata_qc_complete() for each QC. Without PMP, we know that all QCs must share the same status and error values. If PMP is enabled, we also read the status before calling ata_qc_complete(), however, we still read the status for each QC, since the QCs can belong to different PMP links (which means that the QCs does not necessarily share the same status and error values). Do all this by introducing the new port operation .qc_ncq_fill_rtf. If set, this operation is called in ata_qc_complete_multiple() to set the result tf for all completed QCs signaled by the last SDB FIS received. QCs that have their result tf filled are marked with the new flag ATA_QCFLAG_RTF_FILLED so that any later execution of the qc_fill_rtf port operation does nothing (e.g. when called from ata_qc_complete()). Co-developed-by: Damien Le Moal Signed-off-by: Damien Le Moal Signed-off-by: Niklas Cassel

ata: libata: simplify qc_fill_rtf port operation interface

2023-01-04T04:37:45+00:00

The boolean return value of the qc_fill_rtf operation is used nowhere. Simplify this operation interface by making it a void function. All drivers defining this operation are also updated. Signed-off-by: Damien Le Moal Signed-off-by: Niklas Cassel Reviewed-by: John Garry

ata: scsi: rename flag ATA_QCFLAG_FAILED to ATA_QCFLAG_EH

2023-01-04T04:36:26+00:00

The name ATA_QCFLAG_FAILED is misleading since it does not mean that a QC completed in error, or that it didn't complete at all. It means that libata decided to schedule EH for the QC, so the QC is now owned by the libata error handler (EH). The normal execution path is responsible for not accessing a QC owned by EH. libata core enforces the rule by returning NULL from ata_qc_from_tag() for QCs owned by EH. It is quite easy to mistake that a QC marked with ATA_QCFLAG_FAILED was an error. However, a QC that was actually an error is instead indicated by having qc->err_mask set. E.g. when we have a NCQ error, we abort all QCs, which currently will mark all QCs as ATA_QCFLAG_FAILED. However, it will only be a single QC that is an error (i.e. has qc->err_mask set). Rename ATA_QCFLAG_FAILED to ATA_QCFLAG_EH to more clearly highlight that this flag simply means that a QC is now owned by EH. This new name will not mislead to think that the QC was an error (which is instead indicated by having qc->err_mask set). This also makes it more obvious that the EH code skips all QCs that do not have ATA_QCFLAG_EH set (rather than ATA_QCFLAG_FAILED), since the EH code should simply only care about QCs that are owned by EH itself. Signed-off-by: Niklas Cassel Reviewed-by: John Garry Signed-off-by: Damien Le Moal

ata: make use of ata_port_is_frozen() helper

2022-10-18T04:53:27+00:00

Clean up the code by making use of the newly introduced ata_port_is_frozen() helper function. Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal

ata: libahci: read correct status and error field for NCQ commands

2022-10-17T02:31:52+00:00

Currently, for PIO commands, ahci_qc_fill_rtf() reads the status and error fields from the PIO Setup FIS area of the Received FIS Structure. For any non-PIO command, ahci_qc_fill_rtf() currently reads the status and error fields from the D2H Register FIS area of the Received FIS Structure. This is simply not correct. According to the SATA 3.5a specification: 11.10 DMA DATA-IN command protocol and 11.11 DMA DATA-OUT command protocol: READ DMA and WRITE DMA (non-NCQ commands) will end with the Send_status state, which transmits a Register D2H FIS. Likewise, in: 11.15 FPDMA QUEUED command protocol: READ FPDMA QUEUED and WRITE FPDMA QUEUED (NCQ commands) will end with the SendStatus state, which transmits a Set Device Bits FIS. So, for NCQ commands, there is never a D2H Register FIS sent. Reading the status and error fields from the D2H Register FIS area for a NCQ command, will result in us returning the status and error values for the last non-NCQ command, which is incorrect. Update ahci_qc_fill_rtf() to read the status and error fields from the correct area in the Received FIS Structure for NCQ commands. Once reason why this has not been detected before, could be because, in case of an NCQ error, ata_eh_analyze_ncq_error() will overwrite the (incorrect) status and error values set by ahci_qc_fill_rtf(). However, even successful NCQ commands can have bits set in the status field (e.g. the sense data available bit), so it is mandatory to read the status from the correct area also for NCQ commands. Signed-off-by: Niklas Cassel Signed-off-by: Damien Le Moal

ata: ahci: Introduce firmware-specific caps initialization

2022-09-16T16:40:02+00:00

There are systems with no BIOS or comprehensive embedded firmware which could be able to properly initialize the SATA AHCI controller platform-specific capabilities. In that case a good alternative to having a clever bootloader is to create a device tree node with the properties well describing all the AHCI-related platform specifics. All the settings which are normally detected and marked as available in the HBA and its ports capabilities fields [1] could be defined in the platform DTB by means of a set of the dedicated properties. Such approach perfectly fits to the DTB-philosophy - to provide hardware/platform description. So here we suggest to extend the SATA AHCI device tree bindings with two additional DT-properties: 1) "hba-cap" - HBA platform generic capabilities like: - SSS - Staggered Spin-up support. - SMPS - Mechanical Presence Switch support. 2) "hba-port-cap" - HBA platform port capabilities like: - HPCP - Hot Plug Capable Port. - MPSP - Mechanical Presence Switch Attached to Port. - CPD - Cold Presence Detection. - ESP - External SATA Port. - FBSCP - FIS-based Switching Capable Port. All of these capabilities require to have a corresponding hardware configuration. Thus it's ok to have them defined in DTB. Even though the driver currently takes into account the state of the ESP and FBSCP flags state only, there is nothing wrong with having all of them supported by the generic AHCI library in order to have a complete OF-based platform-capabilities initialization procedure. These properties will be parsed in the ahci_platform_get_resources() method and their values will be stored in the saved_* fields of the ahci_host_priv structure, which in its turn then will be used to restore the H.CAP, H.PI and P#.CMD capability fields on device init and after HBA reset. Please note this modification concerns the HW-init HBA and its ports flags only, which are by specification [1] are supposed to be initialized by the BIOS/platform firmware/expansion ROM and which are normally declared in the one-time-writable-after-reset register fields. Even though these flags aren't supposed to be cleared after HBA reset some AHCI instances may violate that rule so we still need to perform the fields resetting after each reset. Luckily the corresponding functionality has already been partly implemented in the framework of the ahci_save_initial_config() and ahci_restore_initial_config() methods. [1] Serial ATA AHCI 1.3.1 Specification, p. 103 Signed-off-by: Serge Semin Signed-off-by: Damien Le Moal

ata: libahci: Don't read AHCI version twice in the save-config method

2022-09-16T16:39:50+00:00

There is no point in reading the AHCI version all over in the tail of the ahci_save_initial_config() method. That register is RO and doesn't change its value even after reset. So just reuse the data, which has already been read from there earlier in the head of the function. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: libahci: Discard redundant force_port_map parameter

2022-09-16T16:39:46+00:00

Currently there are four port-map-related fields declared in the ahci_host_priv structure and used to setup the HBA ports mapping. First the ports-mapping is read from the PI register and immediately stored in the saved_port_map field. If forced_port_map is initialized with non-zero value then its value will have greater priority over the value read from PI, thus it will override the saved_port_map field. That value will be then masked by a non-zero mask_port_map field and after some sanity checks it will be stored in the ahci_host_priv.port_map field as a final port mapping. As you can see the logic is a bit too complicated for such a simple task. We can freely get rid from at least one of the fields with no change to the implemented semantic. The force_port_map field can be replaced with taking non-zero saved_port_map value into account. So if saved_port_map is pre-initialized by the low level drivers (platform drivers) then it will have greater priority over the value read from PI register and will be used as actual HBA ports mapping later on. Thus the ports map forcing task will be just transferred from force_port_map to the saved_port_map field. This modification will perfectly fit into the feature of having OF-based initialization of the HW-init HBA CSR fields we are about to introduce in the next commit. Signed-off-by: Serge Semin Reviewed-by: Hannes Reinecke Signed-off-by: Damien Le Moal

ata: add/use ata_taskfile::{error|status} fields

2022-02-20T00:06:05+00:00

Add the explicit error and status register fields to 'struct ata_taskfile' using the anonymous *union*s ('struct ide_taskfile' had that for ages!) and update the libata taskfile code accordingly. There should be no object code changes resulting from that... Signed-off-by: Sergey Shtylyov Signed-off-by: Damien Le Moal