All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  • Dan Williams's avatar
    [SCSI] isci: atapi support · b50102d3
    Dan Williams authored
    Based on original implementation from Jiangbi Liu and Maciej Trela.
    
    ATAPI transfers happen in two-to-three stages.  The two stage atapi
    commands are those that include a dma data transfer.  The data transfer
    portion of these operations is handled by the hardware packet-dma
    acceleration.  The three-stage commands do not have a data transfer and
    are handled without hardware assistance in raw frame mode.
    
    stage1: transmit host-to-device fis to notify the device of an incoming
    atapi cdb.  Upon reception of the pio-setup-fis repost the task_context
    to perform the dma transfer of the cdb+data (go to stage3), or repost
    the task_context to transmit the cdb as a raw frame (go to stage 2).
    
    stage2: wait for hardware notification of the cdb transmission and then
    go to stage 3.
    
    stage3: wait for the arrival of the terminating device-to-host fis and
    terminate the command.
    
    To keep the implementation simple we only support ATAPI packet-dma
    protocol (for commands with data) to avoid needing to handle the data
    transfer manually (like we do for SATA-PIO).  This may affect
    compatibility for a small number of devices (see
    ATA_HORKAGE_ATAPI_MOD16_DMA).
    
    If the data-transfer underruns, or encounters an error the
    device-to-host fis is expected to arrive in the unsolicited frame queue
    to pass to libata for disposition.  However, in the DONE_UNEXP_FIS (data
    underrun) case it appears we need to craft a response.  In the
    DONE_REG_ERR case we do receive the UF and propagate it to libsas.
    Signed-off-by: default avatarMaciej Trela <maciej.trela@intel.com>
    Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
    Signed-off-by: default avatarJames Bottomley <JBottomley@Parallels.com>
    b50102d3
remote_device.c 46.3 KB