^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) libATA Developer's Guide
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) :Author: Jeff Garzik
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Introduction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) ============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) libATA is a library used inside the Linux kernel to support ATA host
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) controllers and devices. libATA provides an ATA driver API, class
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) transports for ATA and ATAPI devices, and SCSI<->ATA translation for ATA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) devices according to the T10 SAT specification.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) This Guide documents the libATA driver API, library functions, library
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) internals, and a couple sample ATA low-level drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) libata Driver API
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) =================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) :c:type:`struct ata_port_operations <ata_port_operations>`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) is defined for every low-level libata
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) hardware driver, and it controls how the low-level driver interfaces
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) with the ATA and SCSI layers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) FIS-based drivers will hook into the system with ``->qc_prep()`` and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) ``->qc_issue()`` high-level hooks. Hardware which behaves in a manner
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) similar to PCI IDE hardware may utilize several generic helpers,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) defining at a bare minimum the bus I/O addresses of the ATA shadow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) register blocks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) :c:type:`struct ata_port_operations <ata_port_operations>`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) ----------------------------------------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) Disable ATA port
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) ~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) void (*port_disable) (struct ata_port *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) Called from :c:func:`ata_bus_probe` error path, as well as when unregistering
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) from the SCSI module (rmmod, hot unplug). This function should do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) whatever needs to be done to take the port out of use. In most cases,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) :c:func:`ata_port_disable` can be used as this hook.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) Called from :c:func:`ata_bus_probe` on a failed probe. Called from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) :c:func:`ata_scsi_release`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) Post-IDENTIFY device configuration
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) void (*dev_config) (struct ata_port *, struct ata_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) Called after IDENTIFY [PACKET] DEVICE is issued to each device found.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) Typically used to apply device-specific fixups prior to issue of SET
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) FEATURES - XFER MODE, and prior to operation.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) This entry may be specified as NULL in ata_port_operations.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) Set PIO/DMA mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) ~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) void (*set_piomode) (struct ata_port *, struct ata_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) void (*set_dmamode) (struct ata_port *, struct ata_device *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) void (*post_set_mode) (struct ata_port *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) unsigned int (*mode_filter) (struct ata_port *, struct ata_device *, unsigned int);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) Hooks called prior to the issue of SET FEATURES - XFER MODE command. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) optional ``->mode_filter()`` hook is called when libata has built a mask of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) the possible modes. This is passed to the ``->mode_filter()`` function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) which should return a mask of valid modes after filtering those
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) unsuitable due to hardware limits. It is not valid to use this interface
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) to add modes.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) ``dev->pio_mode`` and ``dev->dma_mode`` are guaranteed to be valid when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) ``->set_piomode()`` and when ``->set_dmamode()`` is called. The timings for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85) any other drive sharing the cable will also be valid at this point. That
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) is the library records the decisions for the modes of each drive on a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) channel before it attempts to set any of them.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) ``->post_set_mode()`` is called unconditionally, after the SET FEATURES -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) XFER MODE command completes successfully.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) ``->set_piomode()`` is always called (if present), but ``->set_dma_mode()``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) is only called if DMA is possible.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) Taskfile read/write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) ~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) void (*sff_tf_load) (struct ata_port *ap, struct ata_taskfile *tf);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) void (*sff_tf_read) (struct ata_port *ap, struct ata_taskfile *tf);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) ``->tf_load()`` is called to load the given taskfile into hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) registers / DMA buffers. ``->tf_read()`` is called to read the hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106) registers / DMA buffers, to obtain the current set of taskfile register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) values. Most drivers for taskfile-based hardware (PIO or MMIO) use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108) :c:func:`ata_sff_tf_load` and :c:func:`ata_sff_tf_read` for these hooks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) PIO data read/write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) ~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) void (*sff_data_xfer) (struct ata_device *, unsigned char *, unsigned int, int);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) All bmdma-style drivers must implement this hook. This is the low-level
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) operation that actually copies the data bytes during a PIO data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) transfer. Typically the driver will choose one of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) :c:func:`ata_sff_data_xfer`, or :c:func:`ata_sff_data_xfer32`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) ATA command execute
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) ~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) void (*sff_exec_command)(struct ata_port *ap, struct ata_taskfile *tf);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) causes an ATA command, previously loaded with ``->tf_load()``, to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) initiated in hardware. Most drivers for taskfile-based hardware use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) :c:func:`ata_sff_exec_command` for this hook.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) Per-cmd ATAPI DMA capabilities filter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) int (*check_atapi_dma) (struct ata_queued_cmd *qc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) Allow low-level driver to filter ATA PACKET commands, returning a status
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) indicating whether or not it is OK to use DMA for the supplied PACKET
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) command.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) This hook may be specified as NULL, in which case libata will assume
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) that atapi dma can be supported.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) Read specific ATA shadow registers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) u8 (*sff_check_status)(struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) u8 (*sff_check_altstatus)(struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) Reads the Status/AltStatus ATA shadow register from hardware. On some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) hardware, reading the Status register has the side effect of clearing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) the interrupt condition. Most drivers for taskfile-based hardware use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) :c:func:`ata_sff_check_status` for this hook.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) Write specific ATA shadow register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) void (*sff_set_devctl)(struct ata_port *ap, u8 ctl);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) Write the device control ATA shadow register to the hardware. Most
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) drivers don't need to define this.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) Select ATA device on bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) ~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) void (*sff_dev_select)(struct ata_port *ap, unsigned int device);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) Issues the low-level hardware command(s) that causes one of N hardware
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) devices to be considered 'selected' (active and available for use) on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) the ATA bus. This generally has no meaning on FIS-based devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) Most drivers for taskfile-based hardware use :c:func:`ata_sff_dev_select` for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) this hook.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) Private tuning method
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) ~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) void (*set_mode) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) By default libata performs drive and controller tuning in accordance
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) with the ATA timing rules and also applies blacklists and cable limits.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) Some controllers need special handling and have custom tuning rules,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) typically raid controllers that use ATA commands but do not actually do
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) drive timing.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204) **Warning**
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) This hook should not be used to replace the standard controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) tuning logic when a controller has quirks. Replacing the default
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) tuning logic in that case would bypass handling for drive and bridge
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) quirks that may be important to data reliability. If a controller
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210) needs to filter the mode selection it should use the mode_filter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) hook instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) Control PCI IDE BMDMA engine
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218) void (*bmdma_setup) (struct ata_queued_cmd *qc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) void (*bmdma_start) (struct ata_queued_cmd *qc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) void (*bmdma_stop) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) u8 (*bmdma_status) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224) When setting up an IDE BMDMA transaction, these hooks arm
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) (``->bmdma_setup``), fire (``->bmdma_start``), and halt (``->bmdma_stop``) the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) hardware's DMA engine. ``->bmdma_status`` is used to read the standard PCI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) IDE DMA Status register.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) These hooks are typically either no-ops, or simply not implemented, in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) FIS-based drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) Most legacy IDE drivers use :c:func:`ata_bmdma_setup` for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) :c:func:`bmdma_setup` hook. :c:func:`ata_bmdma_setup` will write the pointer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) to the PRD table to the IDE PRD Table Address register, enable DMA in the DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235) Command register, and call :c:func:`exec_command` to begin the transfer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) Most legacy IDE drivers use :c:func:`ata_bmdma_start` for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) :c:func:`bmdma_start` hook. :c:func:`ata_bmdma_start` will write the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) ATA_DMA_START flag to the DMA Command register.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) Many legacy IDE drivers use :c:func:`ata_bmdma_stop` for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) :c:func:`bmdma_stop` hook. :c:func:`ata_bmdma_stop` clears the ATA_DMA_START
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) flag in the DMA command register.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) Many legacy IDE drivers use :c:func:`ata_bmdma_status` as the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) :c:func:`bmdma_status` hook.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) High-level taskfile hooks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) ~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253) enum ata_completion_errors (*qc_prep) (struct ata_queued_cmd *qc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 254) int (*qc_issue) (struct ata_queued_cmd *qc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 255)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 256)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 257) Higher-level hooks, these two hooks can potentially supersede several of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 258) the above taskfile/DMA engine hooks. ``->qc_prep`` is called after the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 259) buffers have been DMA-mapped, and is typically used to populate the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 260) hardware's DMA scatter-gather table. Some drivers use the standard
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 261) :c:func:`ata_bmdma_qc_prep` and :c:func:`ata_bmdma_dumb_qc_prep` helper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 262) functions, but more advanced drivers roll their own.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 263)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 264) ``->qc_issue`` is used to make a command active, once the hardware and S/G
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 265) tables have been prepared. IDE BMDMA drivers use the helper function
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 266) :c:func:`ata_sff_qc_issue` for taskfile protocol-based dispatch. More
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 267) advanced drivers implement their own ``->qc_issue``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 268)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 269) :c:func:`ata_sff_qc_issue` calls ``->sff_tf_load()``, ``->bmdma_setup()``, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 270) ``->bmdma_start()`` as necessary to initiate a transfer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 271)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 272) Exception and probe handling (EH)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 273) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 274)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 275) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 276)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 277) void (*eng_timeout) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 278) void (*phy_reset) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 279)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 280)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 281) Deprecated. Use ``->error_handler()`` instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 282)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 283) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 284)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 285) void (*freeze) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 286) void (*thaw) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 287)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 288)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 289) :c:func:`ata_port_freeze` is called when HSM violations or some other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 290) condition disrupts normal operation of the port. A frozen port is not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 291) allowed to perform any operation until the port is thawed, which usually
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 292) follows a successful reset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 293)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 294) The optional ``->freeze()`` callback can be used for freezing the port
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 295) hardware-wise (e.g. mask interrupt and stop DMA engine). If a port
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 296) cannot be frozen hardware-wise, the interrupt handler must ack and clear
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 297) interrupts unconditionally while the port is frozen.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 298)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 299) The optional ``->thaw()`` callback is called to perform the opposite of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 300) ``->freeze()``: prepare the port for normal operation once again. Unmask
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 301) interrupts, start DMA engine, etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 302)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 303) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 304)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 305) void (*error_handler) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 306)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 307)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 308) ``->error_handler()`` is a driver's hook into probe, hotplug, and recovery
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 309) and other exceptional conditions. The primary responsibility of an
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 310) implementation is to call :c:func:`ata_do_eh` or :c:func:`ata_bmdma_drive_eh`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 311) with a set of EH hooks as arguments:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 312)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 313) 'prereset' hook (may be NULL) is called during an EH reset, before any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 314) other actions are taken.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 315)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 316) 'postreset' hook (may be NULL) is called after the EH reset is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 317) performed. Based on existing conditions, severity of the problem, and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 318) hardware capabilities,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 319)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 320) Either 'softreset' (may be NULL) or 'hardreset' (may be NULL) will be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 321) called to perform the low-level EH reset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 322)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 323) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 324)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 325) void (*post_internal_cmd) (struct ata_queued_cmd *qc);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 326)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 327)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 328) Perform any hardware-specific actions necessary to finish processing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 329) after executing a probe-time or EH-time command via
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 330) :c:func:`ata_exec_internal`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 331)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 332) Hardware interrupt handling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 333) ~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 334)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 335) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 336)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 337) irqreturn_t (*irq_handler)(int, void *, struct pt_regs *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 338) void (*irq_clear) (struct ata_port *);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 339)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 340)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 341) ``->irq_handler`` is the interrupt handling routine registered with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 342) system, by libata. ``->irq_clear`` is called during probe just before the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 343) interrupt handler is registered, to be sure hardware is quiet.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 344)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 345) The second argument, dev_instance, should be cast to a pointer to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 346) :c:type:`struct ata_host_set <ata_host_set>`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 347)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 348) Most legacy IDE drivers use :c:func:`ata_sff_interrupt` for the irq_handler
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 349) hook, which scans all ports in the host_set, determines which queued
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 350) command was active (if any), and calls ata_sff_host_intr(ap,qc).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 351)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 352) Most legacy IDE drivers use :c:func:`ata_sff_irq_clear` for the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 353) :c:func:`irq_clear` hook, which simply clears the interrupt and error flags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 354) in the DMA status register.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 355)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 356) SATA phy read/write
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 357) ~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 358)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 359) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 360)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 361) int (*scr_read) (struct ata_port *ap, unsigned int sc_reg,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 362) u32 *val);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 363) int (*scr_write) (struct ata_port *ap, unsigned int sc_reg,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 364) u32 val);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 365)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 366)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 367) Read and write standard SATA phy registers. Currently only used if
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 368) ``->phy_reset`` hook called the :c:func:`sata_phy_reset` helper function.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 369) sc_reg is one of SCR_STATUS, SCR_CONTROL, SCR_ERROR, or SCR_ACTIVE.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 370)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 371) Init and shutdown
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 372) ~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 373)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 374) ::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 375)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 376) int (*port_start) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 377) void (*port_stop) (struct ata_port *ap);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 378) void (*host_stop) (struct ata_host_set *host_set);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 379)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 380)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 381) ``->port_start()`` is called just after the data structures for each port
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 382) are initialized. Typically this is used to alloc per-port DMA buffers /
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 383) tables / rings, enable DMA engines, and similar tasks. Some drivers also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 384) use this entry point as a chance to allocate driver-private memory for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 385) ``ap->private_data``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 386)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 387) Many drivers use :c:func:`ata_port_start` as this hook or call it from their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 388) own :c:func:`port_start` hooks. :c:func:`ata_port_start` allocates space for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 389) a legacy IDE PRD table and returns.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 390)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 391) ``->port_stop()`` is called after ``->host_stop()``. Its sole function is to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 392) release DMA/memory resources, now that they are no longer actively being
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 393) used. Many drivers also free driver-private data from port at this time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 394)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 395) ``->host_stop()`` is called after all ``->port_stop()`` calls have completed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 396) The hook must finalize hardware shutdown, release DMA and other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 397) resources, etc. This hook may be specified as NULL, in which case it is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 398) not called.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 399)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 400) Error handling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 401) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 402)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 403) This chapter describes how errors are handled under libata. Readers are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 404) advised to read SCSI EH (Documentation/scsi/scsi_eh.rst) and ATA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 405) exceptions doc first.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 406)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 407) Origins of commands
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 408) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 409)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 410) In libata, a command is represented with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 411) :c:type:`struct ata_queued_cmd <ata_queued_cmd>` or qc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 412) qc's are preallocated during port initialization and repetitively used
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 413) for command executions. Currently only one qc is allocated per port but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 414) yet-to-be-merged NCQ branch allocates one for each tag and maps each qc
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 415) to NCQ tag 1-to-1.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 416)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 417) libata commands can originate from two sources - libata itself and SCSI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 418) midlayer. libata internal commands are used for initialization and error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 419) handling. All normal blk requests and commands for SCSI emulation are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 420) passed as SCSI commands through queuecommand callback of SCSI host
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 421) template.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 422)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 423) How commands are issued
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 424) -----------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 425)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 426) Internal commands
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 427) First, qc is allocated and initialized using :c:func:`ata_qc_new_init`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 428) Although :c:func:`ata_qc_new_init` doesn't implement any wait or retry
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 429) mechanism when qc is not available, internal commands are currently
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 430) issued only during initialization and error recovery, so no other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 431) command is active and allocation is guaranteed to succeed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 432)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 433) Once allocated qc's taskfile is initialized for the command to be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 434) executed. qc currently has two mechanisms to notify completion. One
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 435) is via ``qc->complete_fn()`` callback and the other is completion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 436) ``qc->waiting``. ``qc->complete_fn()`` callback is the asynchronous path
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 437) used by normal SCSI translated commands and ``qc->waiting`` is the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 438) synchronous (issuer sleeps in process context) path used by internal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 439) commands.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 440)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 441) Once initialization is complete, host_set lock is acquired and the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 442) qc is issued.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 443)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 444) SCSI commands
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 445) All libata drivers use :c:func:`ata_scsi_queuecmd` as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 446) ``hostt->queuecommand`` callback. scmds can either be simulated or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 447) translated. No qc is involved in processing a simulated scmd. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 448) result is computed right away and the scmd is completed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 449)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 450) For a translated scmd, :c:func:`ata_qc_new_init` is invoked to allocate a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 451) qc and the scmd is translated into the qc. SCSI midlayer's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 452) completion notification function pointer is stored into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 453) ``qc->scsidone``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 454)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 455) ``qc->complete_fn()`` callback is used for completion notification. ATA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 456) commands use :c:func:`ata_scsi_qc_complete` while ATAPI commands use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 457) :c:func:`atapi_qc_complete`. Both functions end up calling ``qc->scsidone``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 458) to notify upper layer when the qc is finished. After translation is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 459) completed, the qc is issued with :c:func:`ata_qc_issue`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 460)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 461) Note that SCSI midlayer invokes hostt->queuecommand while holding
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 462) host_set lock, so all above occur while holding host_set lock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 463)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 464) How commands are processed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 465) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 466)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 467) Depending on which protocol and which controller are used, commands are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 468) processed differently. For the purpose of discussion, a controller which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 469) uses taskfile interface and all standard callbacks is assumed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 470)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 471) Currently 6 ATA command protocols are used. They can be sorted into the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 472) following four categories according to how they are processed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 473)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 474) ATA NO DATA or DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 475) ATA_PROT_NODATA and ATA_PROT_DMA fall into this category. These
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 476) types of commands don't require any software intervention once
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 477) issued. Device will raise interrupt on completion.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 478)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 479) ATA PIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 480) ATA_PROT_PIO is in this category. libata currently implements PIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 481) with polling. ATA_NIEN bit is set to turn off interrupt and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 482) pio_task on ata_wq performs polling and IO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 483)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 484) ATAPI NODATA or DMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 485) ATA_PROT_ATAPI_NODATA and ATA_PROT_ATAPI_DMA are in this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 486) category. packet_task is used to poll BSY bit after issuing PACKET
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 487) command. Once BSY is turned off by the device, packet_task
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 488) transfers CDB and hands off processing to interrupt handler.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 489)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 490) ATAPI PIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 491) ATA_PROT_ATAPI is in this category. ATA_NIEN bit is set and, as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 492) in ATAPI NODATA or DMA, packet_task submits cdb. However, after
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 493) submitting cdb, further processing (data transfer) is handed off to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 494) pio_task.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 495)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 496) How commands are completed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 497) --------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 498)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 499) Once issued, all qc's are either completed with :c:func:`ata_qc_complete` or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 500) time out. For commands which are handled by interrupts,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 501) :c:func:`ata_host_intr` invokes :c:func:`ata_qc_complete`, and, for PIO tasks,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 502) pio_task invokes :c:func:`ata_qc_complete`. In error cases, packet_task may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 503) also complete commands.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 504)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 505) :c:func:`ata_qc_complete` does the following.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 506)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 507) 1. DMA memory is unmapped.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 508)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 509) 2. ATA_QCFLAG_ACTIVE is cleared from qc->flags.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 510)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 511) 3. :c:expr:`qc->complete_fn` callback is invoked. If the return value of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 512) callback is not zero. Completion is short circuited and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 513) :c:func:`ata_qc_complete` returns.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 514)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 515) 4. :c:func:`__ata_qc_complete` is called, which does
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 516)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 517) 1. ``qc->flags`` is cleared to zero.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 518)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 519) 2. ``ap->active_tag`` and ``qc->tag`` are poisoned.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 520)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 521) 3. ``qc->waiting`` is cleared & completed (in that order).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 522)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 523) 4. qc is deallocated by clearing appropriate bit in ``ap->qactive``.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 524)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 525) So, it basically notifies upper layer and deallocates qc. One exception
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 526) is short-circuit path in #3 which is used by :c:func:`atapi_qc_complete`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 527)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 528) For all non-ATAPI commands, whether it fails or not, almost the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 529) code path is taken and very little error handling takes place. A qc is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 530) completed with success status if it succeeded, with failed status
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 531) otherwise.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 532)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 533) However, failed ATAPI commands require more handling as REQUEST SENSE is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 534) needed to acquire sense data. If an ATAPI command fails,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 535) :c:func:`ata_qc_complete` is invoked with error status, which in turn invokes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 536) :c:func:`atapi_qc_complete` via ``qc->complete_fn()`` callback.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 537)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 538) This makes :c:func:`atapi_qc_complete` set ``scmd->result`` to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 539) SAM_STAT_CHECK_CONDITION, complete the scmd and return 1. As the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 540) sense data is empty but ``scmd->result`` is CHECK CONDITION, SCSI midlayer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 541) will invoke EH for the scmd, and returning 1 makes :c:func:`ata_qc_complete`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 542) to return without deallocating the qc. This leads us to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 543) :c:func:`ata_scsi_error` with partially completed qc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 544)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 545) :c:func:`ata_scsi_error`
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 546) ------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 547)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 548) :c:func:`ata_scsi_error` is the current ``transportt->eh_strategy_handler()``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 549) for libata. As discussed above, this will be entered in two cases -
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 550) timeout and ATAPI error completion. This function calls low level libata
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 551) driver's :c:func:`eng_timeout` callback, the standard callback for which is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 552) :c:func:`ata_eng_timeout`. It checks if a qc is active and calls
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 553) :c:func:`ata_qc_timeout` on the qc if so. Actual error handling occurs in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 554) :c:func:`ata_qc_timeout`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 555)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 556) If EH is invoked for timeout, :c:func:`ata_qc_timeout` stops BMDMA and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 557) completes the qc. Note that as we're currently in EH, we cannot call
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 558) scsi_done. As described in SCSI EH doc, a recovered scmd should be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 559) either retried with :c:func:`scsi_queue_insert` or finished with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 560) :c:func:`scsi_finish_command`. Here, we override ``qc->scsidone`` with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 561) :c:func:`scsi_finish_command` and calls :c:func:`ata_qc_complete`.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 562)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 563) If EH is invoked due to a failed ATAPI qc, the qc here is completed but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 564) not deallocated. The purpose of this half-completion is to use the qc as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 565) place holder to make EH code reach this place. This is a bit hackish,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 566) but it works.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 567)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 568) Once control reaches here, the qc is deallocated by invoking
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 569) :c:func:`__ata_qc_complete` explicitly. Then, internal qc for REQUEST SENSE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 570) is issued. Once sense data is acquired, scmd is finished by directly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 571) invoking :c:func:`scsi_finish_command` on the scmd. Note that as we already
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 572) have completed and deallocated the qc which was associated with the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 573) scmd, we don't need to/cannot call :c:func:`ata_qc_complete` again.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 574)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 575) Problems with the current EH
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 576) ----------------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 577)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 578) - Error representation is too crude. Currently any and all error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 579) conditions are represented with ATA STATUS and ERROR registers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 580) Errors which aren't ATA device errors are treated as ATA device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 581) errors by setting ATA_ERR bit. Better error descriptor which can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 582) properly represent ATA and other errors/exceptions is needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 583)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 584) - When handling timeouts, no action is taken to make device forget
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 585) about the timed out command and ready for new commands.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 586)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 587) - EH handling via :c:func:`ata_scsi_error` is not properly protected from
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 588) usual command processing. On EH entrance, the device is not in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 589) quiescent state. Timed out commands may succeed or fail any time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 590) pio_task and atapi_task may still be running.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 591)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 592) - Too weak error recovery. Devices / controllers causing HSM mismatch
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 593) errors and other errors quite often require reset to return to known
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 594) state. Also, advanced error handling is necessary to support features
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 595) like NCQ and hotplug.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 596)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 597) - ATA errors are directly handled in the interrupt handler and PIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 598) errors in pio_task. This is problematic for advanced error handling
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 599) for the following reasons.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 600)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 601) First, advanced error handling often requires context and internal qc
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 602) execution.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 603)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 604) Second, even a simple failure (say, CRC error) needs information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 605) gathering and could trigger complex error handling (say, resetting &
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 606) reconfiguring). Having multiple code paths to gather information,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 607) enter EH and trigger actions makes life painful.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 608)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 609) Third, scattered EH code makes implementing low level drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 610) difficult. Low level drivers override libata callbacks. If EH is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 611) scattered over several places, each affected callbacks should perform
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 612) its part of error handling. This can be error prone and painful.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 613)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 614) libata Library
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 615) ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 616)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 617) .. kernel-doc:: drivers/ata/libata-core.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 618) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 619)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 620) libata Core Internals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 621) =====================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 622)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 623) .. kernel-doc:: drivers/ata/libata-core.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 624) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 625)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 626) .. kernel-doc:: drivers/ata/libata-eh.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 627)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 628) libata SCSI translation/emulation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 629) =================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 630)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 631) .. kernel-doc:: drivers/ata/libata-scsi.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 632) :export:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 633)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 634) .. kernel-doc:: drivers/ata/libata-scsi.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 635) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 636)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 637) ATA errors and exceptions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 638) =========================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 639)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 640) This chapter tries to identify what error/exception conditions exist for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 641) ATA/ATAPI devices and describe how they should be handled in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 642) implementation-neutral way.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 643)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 644) The term 'error' is used to describe conditions where either an explicit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 645) error condition is reported from device or a command has timed out.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 646)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 647) The term 'exception' is either used to describe exceptional conditions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 648) which are not errors (say, power or hotplug events), or to describe both
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 649) errors and non-error exceptional conditions. Where explicit distinction
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 650) between error and exception is necessary, the term 'non-error exception'
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 651) is used.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 652)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 653) Exception categories
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 654) --------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 655)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 656) Exceptions are described primarily with respect to legacy taskfile + bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 657) master IDE interface. If a controller provides other better mechanism
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 658) for error reporting, mapping those into categories described below
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 659) shouldn't be difficult.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 660)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 661) In the following sections, two recovery actions - reset and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 662) reconfiguring transport - are mentioned. These are described further in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 663) `EH recovery actions <#exrec>`__.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 664)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 665) HSM violation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 666) ~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 667)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 668) This error is indicated when STATUS value doesn't match HSM requirement
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 669) during issuing or execution any ATA/ATAPI command.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 670)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 671) - ATA_STATUS doesn't contain !BSY && DRDY && !DRQ while trying to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 672) issue a command.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 673)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 674) - !BSY && !DRQ during PIO data transfer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 675)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 676) - DRQ on command completion.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 677)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 678) - !BSY && ERR after CDB transfer starts but before the last byte of CDB
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 679) is transferred. ATA/ATAPI standard states that "The device shall not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 680) terminate the PACKET command with an error before the last byte of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 681) the command packet has been written" in the error outputs description
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 682) of PACKET command and the state diagram doesn't include such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 683) transitions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 684)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 685) In these cases, HSM is violated and not much information regarding the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 686) error can be acquired from STATUS or ERROR register. IOW, this error can
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 687) be anything - driver bug, faulty device, controller and/or cable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 688)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 689) As HSM is violated, reset is necessary to restore known state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 690) Reconfiguring transport for lower speed might be helpful too as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 691) transmission errors sometimes cause this kind of errors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 692)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 693) ATA/ATAPI device error (non-NCQ / non-CHECK CONDITION)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 694) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 695)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 696) These are errors detected and reported by ATA/ATAPI devices indicating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 697) device problems. For this type of errors, STATUS and ERROR register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 698) values are valid and describe error condition. Note that some of ATA bus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 699) errors are detected by ATA/ATAPI devices and reported using the same
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 700) mechanism as device errors. Those cases are described later in this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 701) section.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 702)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 703) For ATA commands, this type of errors are indicated by !BSY && ERR
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 704) during command execution and on completion.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 705)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 706) For ATAPI commands,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 707)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 708) - !BSY && ERR && ABRT right after issuing PACKET indicates that PACKET
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 709) command is not supported and falls in this category.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 710)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 711) - !BSY && ERR(==CHK) && !ABRT after the last byte of CDB is transferred
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 712) indicates CHECK CONDITION and doesn't fall in this category.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 713)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 714) - !BSY && ERR(==CHK) && ABRT after the last byte of CDB is transferred
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 715) \*probably\* indicates CHECK CONDITION and doesn't fall in this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 716) category.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 717)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 718) Of errors detected as above, the following are not ATA/ATAPI device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 719) errors but ATA bus errors and should be handled according to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 720) `ATA bus error <#excatATAbusErr>`__.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 721)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 722) CRC error during data transfer
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 723) This is indicated by ICRC bit in the ERROR register and means that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 724) corruption occurred during data transfer. Up to ATA/ATAPI-7, the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 725) standard specifies that this bit is only applicable to UDMA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 726) transfers but ATA/ATAPI-8 draft revision 1f says that the bit may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 727) applicable to multiword DMA and PIO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 728)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 729) ABRT error during data transfer or on completion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 730) Up to ATA/ATAPI-7, the standard specifies that ABRT could be set on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 731) ICRC errors and on cases where a device is not able to complete a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 732) command. Combined with the fact that MWDMA and PIO transfer errors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 733) aren't allowed to use ICRC bit up to ATA/ATAPI-7, it seems to imply
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 734) that ABRT bit alone could indicate transfer errors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 735)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 736) However, ATA/ATAPI-8 draft revision 1f removes the part that ICRC
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 737) errors can turn on ABRT. So, this is kind of gray area. Some
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 738) heuristics are needed here.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 739)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 740) ATA/ATAPI device errors can be further categorized as follows.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 741)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 742) Media errors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 743) This is indicated by UNC bit in the ERROR register. ATA devices
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 744) reports UNC error only after certain number of retries cannot
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 745) recover the data, so there's nothing much else to do other than
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 746) notifying upper layer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 747)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 748) READ and WRITE commands report CHS or LBA of the first failed sector
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 749) but ATA/ATAPI standard specifies that the amount of transferred data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 750) on error completion is indeterminate, so we cannot assume that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 751) sectors preceding the failed sector have been transferred and thus
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 752) cannot complete those sectors successfully as SCSI does.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 753)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 754) Media changed / media change requested error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 755) <<TODO: fill here>>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 756)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 757) Address error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 758) This is indicated by IDNF bit in the ERROR register. Report to upper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 759) layer.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 760)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 761) Other errors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 762) This can be invalid command or parameter indicated by ABRT ERROR bit
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 763) or some other error condition. Note that ABRT bit can indicate a lot
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 764) of things including ICRC and Address errors. Heuristics needed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 765)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 766) Depending on commands, not all STATUS/ERROR bits are applicable. These
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 767) non-applicable bits are marked with "na" in the output descriptions but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 768) up to ATA/ATAPI-7 no definition of "na" can be found. However,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 769) ATA/ATAPI-8 draft revision 1f describes "N/A" as follows.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 770)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 771) 3.2.3.3a N/A
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 772) A keyword the indicates a field has no defined value in this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 773) standard and should not be checked by the host or device. N/A
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 774) fields should be cleared to zero.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 775)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 776) So, it seems reasonable to assume that "na" bits are cleared to zero by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 777) devices and thus need no explicit masking.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 778)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 779) ATAPI device CHECK CONDITION
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 780) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 781)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 782) ATAPI device CHECK CONDITION error is indicated by set CHK bit (ERR bit)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 783) in the STATUS register after the last byte of CDB is transferred for a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 784) PACKET command. For this kind of errors, sense data should be acquired
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 785) to gather information regarding the errors. REQUEST SENSE packet command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 786) should be used to acquire sense data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 787)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 788) Once sense data is acquired, this type of errors can be handled
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 789) similarly to other SCSI errors. Note that sense data may indicate ATA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 790) bus error (e.g. Sense Key 04h HARDWARE ERROR && ASC/ASCQ 47h/00h SCSI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 791) PARITY ERROR). In such cases, the error should be considered as an ATA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 792) bus error and handled according to `ATA bus error <#excatATAbusErr>`__.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 793)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 794) ATA device error (NCQ)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 795) ~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 796)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 797) NCQ command error is indicated by cleared BSY and set ERR bit during NCQ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 798) command phase (one or more NCQ commands outstanding). Although STATUS
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 799) and ERROR registers will contain valid values describing the error, READ
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 800) LOG EXT is required to clear the error condition, determine which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 801) command has failed and acquire more information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 802)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 803) READ LOG EXT Log Page 10h reports which tag has failed and taskfile
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 804) register values describing the error. With this information the failed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 805) command can be handled as a normal ATA command error as in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 806) `ATA/ATAPI device error (non-NCQ / non-CHECK CONDITION) <#excatDevErr>`__
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 807) and all other in-flight commands must be retried. Note that this retry
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 808) should not be counted - it's likely that commands retried this way would
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 809) have completed normally if it were not for the failed command.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 810)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 811) Note that ATA bus errors can be reported as ATA device NCQ errors. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 812) should be handled as described in `ATA bus error <#excatATAbusErr>`__.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 813)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 814) If READ LOG EXT Log Page 10h fails or reports NQ, we're thoroughly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 815) screwed. This condition should be treated according to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 816) `HSM violation <#excatHSMviolation>`__.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 817)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 818) ATA bus error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 819) ~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 820)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 821) ATA bus error means that data corruption occurred during transmission
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 822) over ATA bus (SATA or PATA). This type of errors can be indicated by
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 823)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 824) - ICRC or ABRT error as described in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 825) `ATA/ATAPI device error (non-NCQ / non-CHECK CONDITION) <#excatDevErr>`__.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 826)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 827) - Controller-specific error completion with error information
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 828) indicating transmission error.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 829)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 830) - On some controllers, command timeout. In this case, there may be a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 831) mechanism to determine that the timeout is due to transmission error.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 832)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 833) - Unknown/random errors, timeouts and all sorts of weirdities.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 834)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 835) As described above, transmission errors can cause wide variety of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 836) symptoms ranging from device ICRC error to random device lockup, and,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 837) for many cases, there is no way to tell if an error condition is due to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 838) transmission error or not; therefore, it's necessary to employ some kind
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 839) of heuristic when dealing with errors and timeouts. For example,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 840) encountering repetitive ABRT errors for known supported command is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 841) likely to indicate ATA bus error.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 842)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 843) Once it's determined that ATA bus errors have possibly occurred,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 844) lowering ATA bus transmission speed is one of actions which may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 845) alleviate the problem. See `Reconfigure transport <#exrecReconf>`__ for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 846) more information.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 847)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 848) PCI bus error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 849) ~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 850)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 851) Data corruption or other failures during transmission over PCI (or other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 852) system bus). For standard BMDMA, this is indicated by Error bit in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 853) BMDMA Status register. This type of errors must be logged as it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 854) indicates something is very wrong with the system. Resetting host
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 855) controller is recommended.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 856)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 857) Late completion
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 858) ~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 859)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 860) This occurs when timeout occurs and the timeout handler finds out that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 861) the timed out command has completed successfully or with error. This is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 862) usually caused by lost interrupts. This type of errors must be logged.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 863) Resetting host controller is recommended.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 864)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 865) Unknown error (timeout)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 866) ~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 867)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 868) This is when timeout occurs and the command is still processing or the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 869) host and device are in unknown state. When this occurs, HSM could be in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 870) any valid or invalid state. To bring the device to known state and make
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 871) it forget about the timed out command, resetting is necessary. The timed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 872) out command may be retried.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 873)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 874) Timeouts can also be caused by transmission errors. Refer to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 875) `ATA bus error <#excatATAbusErr>`__ for more details.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 876)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 877) Hotplug and power management exceptions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 878) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 879)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 880) <<TODO: fill here>>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 881)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 882) EH recovery actions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 883) -------------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 884)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 885) This section discusses several important recovery actions.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 886)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 887) Clearing error condition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 888) ~~~~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 889)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 890) Many controllers require its error registers to be cleared by error
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 891) handler. Different controllers may have different requirements.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 892)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 893) For SATA, it's strongly recommended to clear at least SError register
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 894) during error handling.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 895)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 896) Reset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 897) ~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 898)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 899) During EH, resetting is necessary in the following cases.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 900)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 901) - HSM is in unknown or invalid state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 902)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 903) - HBA is in unknown or invalid state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 904)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 905) - EH needs to make HBA/device forget about in-flight commands
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 906)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 907) - HBA/device behaves weirdly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 908)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 909) Resetting during EH might be a good idea regardless of error condition
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 910) to improve EH robustness. Whether to reset both or either one of HBA and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 911) device depends on situation but the following scheme is recommended.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 912)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 913) - When it's known that HBA is in ready state but ATA/ATAPI device is in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 914) unknown state, reset only device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 915)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 916) - If HBA is in unknown state, reset both HBA and device.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 917)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 918) HBA resetting is implementation specific. For a controller complying to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 919) taskfile/BMDMA PCI IDE, stopping active DMA transaction may be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 920) sufficient iff BMDMA state is the only HBA context. But even mostly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 921) taskfile/BMDMA PCI IDE complying controllers may have implementation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 922) specific requirements and mechanism to reset themselves. This must be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 923) addressed by specific drivers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 924)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 925) OTOH, ATA/ATAPI standard describes in detail ways to reset ATA/ATAPI
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 926) devices.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 927)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 928) PATA hardware reset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 929) This is hardware initiated device reset signalled with asserted PATA
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 930) RESET- signal. There is no standard way to initiate hardware reset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 931) from software although some hardware provides registers that allow
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 932) driver to directly tweak the RESET- signal.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 933)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 934) Software reset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 935) This is achieved by turning CONTROL SRST bit on for at least 5us.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 936) Both PATA and SATA support it but, in case of SATA, this may require
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 937) controller-specific support as the second Register FIS to clear SRST
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 938) should be transmitted while BSY bit is still set. Note that on PATA,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 939) this resets both master and slave devices on a channel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 940)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 941) EXECUTE DEVICE DIAGNOSTIC command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 942) Although ATA/ATAPI standard doesn't describe exactly, EDD implies
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 943) some level of resetting, possibly similar level with software reset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 944) Host-side EDD protocol can be handled with normal command processing
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 945) and most SATA controllers should be able to handle EDD's just like
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 946) other commands. As in software reset, EDD affects both devices on a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 947) PATA bus.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 948)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 949) Although EDD does reset devices, this doesn't suit error handling as
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 950) EDD cannot be issued while BSY is set and it's unclear how it will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 951) act when device is in unknown/weird state.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 952)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 953) ATAPI DEVICE RESET command
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 954) This is very similar to software reset except that reset can be
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 955) restricted to the selected device without affecting the other device
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 956) sharing the cable.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 957)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 958) SATA phy reset
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 959) This is the preferred way of resetting a SATA device. In effect,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 960) it's identical to PATA hardware reset. Note that this can be done
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 961) with the standard SCR Control register. As such, it's usually easier
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 962) to implement than software reset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 963)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 964) One more thing to consider when resetting devices is that resetting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 965) clears certain configuration parameters and they need to be set to their
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 966) previous or newly adjusted values after reset.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 967)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 968) Parameters affected are.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 969)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 970) - CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 971)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 972) - Parameters set with SET FEATURES including transfer mode setting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 973)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 974) - Block count set with SET MULTIPLE MODE
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 975)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 976) - Other parameters (SET MAX, MEDIA LOCK...)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 977)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 978) ATA/ATAPI standard specifies that some parameters must be maintained
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 979) across hardware or software reset, but doesn't strictly specify all of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 980) them. Always reconfiguring needed parameters after reset is required for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 981) robustness. Note that this also applies when resuming from deep sleep
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 982) (power-off).
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 983)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 984) Also, ATA/ATAPI standard requires that IDENTIFY DEVICE / IDENTIFY PACKET
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 985) DEVICE is issued after any configuration parameter is updated or a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 986) hardware reset and the result used for further operation. OS driver is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 987) required to implement revalidation mechanism to support this.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 988)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 989) Reconfigure transport
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 990) ~~~~~~~~~~~~~~~~~~~~~
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 991)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 992) For both PATA and SATA, a lot of corners are cut for cheap connectors,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 993) cables or controllers and it's quite common to see high transmission
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 994) error rate. This can be mitigated by lowering transmission speed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 995)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 996) The following is a possible scheme Jeff Garzik suggested.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 997)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 998) If more than $N (3?) transmission errors happen in 15 minutes,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 999)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1000) - if SATA, decrease SATA PHY speed. if speed cannot be decreased,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1001)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1002) - decrease UDMA xfer speed. if at UDMA0, switch to PIO4,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1003)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1004) - decrease PIO xfer speed. if at PIO3, complain, but continue
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1005)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1006) ata_piix Internals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1007) ===================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1008)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1009) .. kernel-doc:: drivers/ata/ata_piix.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1010) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1011)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1012) sata_sil Internals
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1013) ===================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1014)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1015) .. kernel-doc:: drivers/ata/sata_sil.c
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1016) :internal:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1017)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1018) Thanks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1019) ======
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1020)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1021) The bulk of the ATA knowledge comes thanks to long conversations with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1022) Andre Hedrick (www.linux-ide.org), and long hours pondering the ATA and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1023) SCSI specifications.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1024)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1025) Thanks to Alan Cox for pointing out similarities between SATA and SCSI,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1026) and in general for motivation to hack on libata.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1027)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1028) libata's device detection method, ata_pio_devchk, and in general all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1029) the early probing was based on extensive study of Hale Landis's
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1030) probe/reset code in his ATADRVR driver (www.ata-atapi.com).
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags