Message ID | 1663669630-21333-1-git-send-email-john.garry@huawei.com |
---|---|
Headers | show |
Series | libata/scsi/libsas: Allocate SCSI device earlier for ata port probe | expand |
On 9/20/22 19:27, John Garry wrote: > Currently for libata the SCSI device (sdev) associated with an ata_device > is allocated when the port probe has completed. > > It's useful to have the SCSI device and its associated request queue > available earlier for the port probe. Specifically if we have the > request queue available, then we can: > - Easily put ATA qc in SCSI cmnd priv data > - Send ATA internal commands on SCSI device request queue for [0]. The > current solution there is to use the shost sdev request queue, which > isn't great. > > This series changes the ata port probe to alloc the sdev in the > ata_device revalidation, and then just do a SCSI starget scan afterwards. > > Why an RFC? > 1. IPR driver needs to be fixed up - it does not use ATA EH port probe > Mail [1] needs following up Yes. If IPR could be converted to ata error_handler, a lot of code can be simplified in libata too. > 2. SATA PMP support needs verification, but I don't have a setup Port multiplier behind a sas HBA will be challenging to setup :) I can try, but I will need to open up one of my servers and hook a small PMP box to one of the pm8001 plugs. I may have the cables for that... Let me check. > 3. This series needs to be merged into or go after [0] > > Patch 1/6 could be merged now. > > [0] https://lore.kernel.org/linux-ide/1654770559-101375-1-git-send-email-john.garry@huawei.com/ > [1] https://lore.kernel.org/linux-ide/369448ed-f89a-c2db-1850-91450d8b5998@opensource.wdc.com/ > > Any comments welcome - please have a look. > > Based on v6.0-rc4 and tested for QEMU AHCI and libsas. > > John Garry (6): > scsi: core: Use SCSI_SCAN_RESCAN in __scsi_add_device() > scsi: scsi_transport_sas: Allocate end device target id in the rphy > alloc > scsi: core: Add scsi_get_dev() > ata: libata-scsi: Add ata_scsi_setup_sdev() > scsi: libsas: Add sas_ata_setup_device() > ata: libata-scsi: Allocate sdev early in port probe > > drivers/ata/libata-eh.c | 4 +++ > drivers/ata/libata-scsi.c | 45 +++++++++++++++++++++---------- > drivers/ata/libata.h | 1 + > drivers/scsi/libsas/sas_ata.c | 20 ++++++++++++++ > drivers/scsi/scsi_scan.c | 28 ++++++++++++++++++- > drivers/scsi/scsi_transport_sas.c | 25 +++++++++++------ > include/linux/libata.h | 2 ++ > include/scsi/scsi_host.h | 3 +++ > 8 files changed, 105 insertions(+), 23 deletions(-) >
On 21/09/2022 05:04, Damien Le Moal wrote: > On 9/20/22 19:27, John Garry wrote: >> Currently for libata the SCSI device (sdev) associated with an ata_device >> is allocated when the port probe has completed. >> >> It's useful to have the SCSI device and its associated request queue >> available earlier for the port probe. Specifically if we have the >> request queue available, then we can: >> - Easily put ATA qc in SCSI cmnd priv data >> - Send ATA internal commands on SCSI device request queue for [0]. The >> current solution there is to use the shost sdev request queue, which >> isn't great. >> This series changes the ata port probe to alloc the sdev in the >> ata_device revalidation, and then just do a SCSI starget scan afterwards. >> >> Why an RFC? >> 1. IPR driver needs to be fixed up - it does not use ATA EH port probe >> Mail [1] needs following up > > Yes. If IPR could be converted to ata error_handler, a lot of code can > be simplified in libata too. Hmmm... yeah, it would be good to see progress there. > >> 2. SATA PMP support needs verification, but I don't have a setup > > Port multiplier behind a sas HBA will be challenging to setup :) > I can try, but I will need to open up one of my servers and hook a small > PMP box to one of the pm8001 plugs. I may have the cables for that... > Let me check. I was more thinking of just AHCI with a port multiplier. As for SAS controllers, I don't think it's something to be concerned about. For a start, I know for sure that hisi_sas HW does not support port multipliers, and I don't think that pm8001 does either. In addition, libsas does not even support it - I did see a series in the scsi list from years ago (to support it), but it did not progress. Thanks, John
On 9/21/22 17:24, John Garry wrote: > On 21/09/2022 05:04, Damien Le Moal wrote: >> On 9/20/22 19:27, John Garry wrote: >>> Currently for libata the SCSI device (sdev) associated with an >>> ata_device >>> is allocated when the port probe has completed. >>> >>> It's useful to have the SCSI device and its associated request queue >>> available earlier for the port probe. Specifically if we have the >>> request queue available, then we can: >>> - Easily put ATA qc in SCSI cmnd priv data >>> - Send ATA internal commands on SCSI device request queue for [0]. The >>> current solution there is to use the shost sdev request queue, which >>> isn't great. >>> This series changes the ata port probe to alloc the sdev in the >>> ata_device revalidation, and then just do a SCSI starget scan >>> afterwards. >>> >>> Why an RFC? >>> 1. IPR driver needs to be fixed up - it does not use ATA EH port probe >>> Mail [1] needs following up >> >> Yes. If IPR could be converted to ata error_handler, a lot of code can >> be simplified in libata too. > > Hmmm... yeah, it would be good to see progress there. > >> >>> 2. SATA PMP support needs verification, but I don't have a setup >> >> Port multiplier behind a sas HBA will be challenging to setup :) >> I can try, but I will need to open up one of my servers and hook a >> small PMP box to one of the pm8001 plugs. I may have the cables for >> that... Let me check. > > I was more thinking of just AHCI with a port multiplier. OK. I got confused :) Easy then, my test box is all hooked up already. Will give this a spin. > > As for SAS controllers, I don't think it's something to be concerned > about. For a start, I know for sure that hisi_sas HW does not support > port multipliers, and I don't think that pm8001 does either. In > addition, libsas does not even support it - I did see a series in the > scsi list from years ago (to support it), but it did not progress. > > Thanks, > John