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 the per-end device target id is allocated when adding the rphy, > which is when we execute the scan of the target. > > However it will be useful to have the target id allocated earlier when > allocating the rphy for the end device. For libata we want to move to a > scheme of allocating the sdev early in the probe process and then later > executing the scan (for that target). As such, users of would libata would > require that the target id allocated earlier here (before the scan). > > Signed-off-by: John Garry <john.garry@huawei.com> > --- > drivers/scsi/scsi_transport_sas.c | 25 +++++++++++++++++-------- > 1 file changed, 17 insertions(+), 8 deletions(-) > > diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c > index 2f88c61216ee..56d325665bc7 100644 > --- a/drivers/scsi/scsi_transport_sas.c > +++ b/drivers/scsi/scsi_transport_sas.c > @@ -1433,6 +1433,7 @@ static void sas_rphy_initialize(struct sas_rphy *rphy) > struct sas_rphy *sas_end_device_alloc(struct sas_port *parent) > { > struct Scsi_Host *shost = dev_to_shost(&parent->dev); > + struct sas_host_attrs *sas_host = to_sas_host_attrs(shost); > struct sas_end_device *rdev; > > rdev = kzalloc(sizeof(*rdev), GFP_KERNEL); > @@ -1455,6 +1456,10 @@ struct sas_rphy *sas_end_device_alloc(struct sas_port *parent) > sas_rphy_initialize(&rdev->rphy); > transport_setup_device(&rdev->rphy.dev); > > + mutex_lock(&sas_host->lock); > + rdev->rphy.scsi_target_id = sas_host->next_target_id++; > + mutex_unlock(&sas_host->lock); > + > return &rdev->rphy; > } > EXPORT_SYMBOL(sas_end_device_alloc); > @@ -1500,6 +1505,16 @@ struct sas_rphy *sas_expander_alloc(struct sas_port *parent, > } > EXPORT_SYMBOL(sas_expander_alloc); > > +static bool sas_rphy_end_device_valid_tproto(struct sas_rphy *rphy) > +{ > + struct sas_identify *identify = &rphy->identify; > + > + if (identify->target_port_protocols & > + (SAS_PROTOCOL_SSP | SAS_PROTOCOL_STP | SAS_PROTOCOL_SATA)) > + return true; > + return false; You could just do: return identify->target_port_protocols & (SAS_PROTOCOL_SSP | SAS_PROTOCOL_STP | SAS_PROTOCOL_SATA)) > +} > + > /** > * sas_rphy_add - add a SAS remote PHY to the device hierarchy > * @rphy: The remote PHY to be added > @@ -1529,16 +1544,10 @@ int sas_rphy_add(struct sas_rphy *rphy) > > mutex_lock(&sas_host->lock); > list_add_tail(&rphy->list, &sas_host->rphy_list); > - if (identify->device_type == SAS_END_DEVICE && > - (identify->target_port_protocols & > - (SAS_PROTOCOL_SSP | SAS_PROTOCOL_STP | SAS_PROTOCOL_SATA))) > - rphy->scsi_target_id = sas_host->next_target_id++; > - else if (identify->device_type == SAS_END_DEVICE) > - rphy->scsi_target_id = -1; > mutex_unlock(&sas_host->lock); > > if (identify->device_type == SAS_END_DEVICE && You could move this check inside sas_rphy_end_device_valid_tproto(), no ? > - rphy->scsi_target_id != -1) { > + sas_rphy_end_device_valid_tproto(rphy)) { > int lun; > > if (identify->target_port_protocols & SAS_PROTOCOL_SSP) > @@ -1667,7 +1676,7 @@ static int sas_user_scan(struct Scsi_Host *shost, uint channel, > mutex_lock(&sas_host->lock); > list_for_each_entry(rphy, &sas_host->rphy_list, list) { > if (rphy->identify.device_type != SAS_END_DEVICE || > - rphy->scsi_target_id == -1) > + !sas_rphy_end_device_valid_tproto(rphy)) > continue; > > if ((channel == SCAN_WILD_CARD || channel == 0) &&
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
On 20/09/2022 22:58, Damien Le Moal wrote: >> +extern struct scsi_device *scsi_get_dev(struct device *parent, int >> channel, uint id, u64 lun); > > You should not need extern here, and long line... > >> + >> /* >> + > > white line change. > >> * DIF defines the exchange of protection information between >> * initiator and SBC block device. ok, I'll tidy them. Thanks, John
On 20/09/2022 23:02, Damien Le Moal wrote: >> >> return &rdev->rphy; >> } >> EXPORT_SYMBOL(sas_end_device_alloc); >> @@ -1500,6 +1505,16 @@ struct sas_rphy *sas_expander_alloc(struct >> sas_port *parent, >> } >> EXPORT_SYMBOL(sas_expander_alloc); >> +static bool sas_rphy_end_device_valid_tproto(struct sas_rphy *rphy) >> +{ >> + struct sas_identify *identify = &rphy->identify; >> + >> + if (identify->target_port_protocols & >> + (SAS_PROTOCOL_SSP | SAS_PROTOCOL_STP | SAS_PROTOCOL_SATA)) >> + return true; >> + return false; > > You could just do: > > return identify->target_port_protocols & > (SAS_PROTOCOL_SSP | SAS_PROTOCOL_STP | SAS_PROTOCOL_SATA)) OK > >> +} >> + >> /** >> * sas_rphy_add - add a SAS remote PHY to the device hierarchy >> * @rphy: The remote PHY to be added >> @@ -1529,16 +1544,10 @@ int sas_rphy_add(struct sas_rphy *rphy) >> mutex_lock(&sas_host->lock); >> list_add_tail(&rphy->list, &sas_host->rphy_list); >> - if (identify->device_type == SAS_END_DEVICE && >> - (identify->target_port_protocols & >> - (SAS_PROTOCOL_SSP | SAS_PROTOCOL_STP | SAS_PROTOCOL_SATA))) >> - rphy->scsi_target_id = sas_host->next_target_id++; >> - else if (identify->device_type == SAS_END_DEVICE) >> - rphy->scsi_target_id = -1; >> mutex_unlock(&sas_host->lock); >> if (identify->device_type == SAS_END_DEVICE && > > You could move this check inside sas_rphy_end_device_valid_tproto(), > no ? > Yeah, I suppose I could. I might require a function rename with that. >> - rphy->scsi_target_id != -1) { >> + sas_rphy_end_device_valid_tproto(rphy)) { >> int lun; >> if (identify->target_port_protocols & SAS_PROTOCOL_SSP) >> @@ -1667,7 +1676,7 @@ static int sas_user_scan(struct Scsi_Host >> *shost, uint channel, >> mutex_lock(&sas_host->lock); >> list_for_each_entry(rphy, &sas_host->rphy_list, list) { >> if (rphy->identify.device_type != SAS_END_DEVICE || >> - rphy->scsi_target_id == -1) >> + !sas_rphy_end_device_valid_tproto(rphy)) >> continue; Thanks, John