linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Garry <john.garry@huawei.com>
To: <axboe@kernel.dk>, <damien.lemoal@opensource.wdc.com>,
	<jejb@linux.ibm.com>, <martin.petersen@oracle.com>,
	<jinpu.wang@cloud.ionos.com>, <hare@suse.de>,
	<bvanassche@acm.org>, <hch@lst.de>, <ming.lei@redhat.com>,
	<niklas.cassel@wdc.com>
Cc: <linux-block@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-ide@vger.kernel.org>, <linux-scsi@vger.kernel.org>,
	<linuxarm@huawei.com>, John Garry <john.garry@huawei.com>
Subject: [PATCH RFC v3 13/22] scsi: scsi_transport_sas: Allocate end device target id in the rphy alloc
Date: Tue, 25 Oct 2022 18:18:07 +0800	[thread overview]
Message-ID: <1666693096-180008-14-git-send-email-john.garry@huawei.com> (raw)
In-Reply-To: <1666693096-180008-1-git-send-email-john.garry@huawei.com>

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 | 28 ++++++++++++++++++----------
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c
index da075dfc7cd0..c03e88990264 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,17 @@ struct sas_rphy *sas_expander_alloc(struct sas_port *parent,
 }
 EXPORT_SYMBOL(sas_expander_alloc);
 
+static bool sas_rphy_valid_tproto_end_device(struct sas_rphy *rphy)
+{
+	struct sas_identify *identify = &rphy->identify;
+
+	if (identify->device_type != SAS_END_DEVICE)
+		return false;
+
+	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 +1545,9 @@ 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 &&
-	    rphy->scsi_target_id != -1) {
+	if (sas_rphy_valid_tproto_end_device(rphy)) {
 		int lun;
 
 		if (identify->target_port_protocols & SAS_PROTOCOL_SSP)
@@ -1672,8 +1681,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)
+		if (!sas_rphy_valid_tproto_end_device(rphy))
 			continue;
 
 		if ((channel == SCAN_WILD_CARD || channel == 0) &&
-- 
2.35.3


  parent reply	other threads:[~2022-10-25  9:51 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25 10:17 [PATCH RFC v3 00/22] blk-mq/libata/scsi: SCSI driver tagging improvements Part I John Garry
2022-10-25 10:11 ` John Garry
2022-10-25 10:17 ` [PATCH RFC v3 01/22] blk-mq: Don't get budget for reserved requests John Garry
2022-10-27  1:16   ` Damien Le Moal
2022-10-27  9:09     ` John Garry
2022-10-25 10:17 ` [PATCH RFC v3 02/22] scsi: core: Add scsi_get_dev() John Garry
2022-10-25 10:17 ` [PATCH RFC v3 03/22] scsi: core: Implement reserved command handling John Garry
2022-10-27  1:18   ` Damien Le Moal
2022-10-27  7:51     ` Hannes Reinecke
2022-10-27  8:16       ` John Garry
2022-10-27  9:11     ` John Garry
2022-10-25 10:17 ` [PATCH RFC v3 04/22] scsi: core: Add support to send reserved commands John Garry
2022-10-27  1:21   ` Damien Le Moal
2022-10-27  9:13     ` John Garry
2022-10-27  9:18       ` Damien Le Moal
2022-10-25 10:17 ` [PATCH RFC v3 05/22] scsi: core: Add support for reserved command timeout handling John Garry
2022-10-25 10:18 ` [PATCH RFC v3 06/22] scsi: libsas: Improve sas_ex_discover_expander() error handling John Garry
2022-10-25 10:18 ` [PATCH RFC v3 07/22] scsi: libsas: Notify LLDD expander found before calling sas_rphy_add() John Garry
2022-10-25 10:18 ` [PATCH RFC v3 08/22] scsi: scsi_transport_sas: Alloc sdev for expander John Garry
2022-10-25 10:18 ` [PATCH RFC v3 09/22] scsi: libsas: Add sas_alloc_slow_task_rq() John Garry
2022-10-25 10:18 ` [PATCH RFC v3 10/22] scsi: libsas: Add sas_queuecommand_internal() John Garry
2022-10-25 10:18 ` [PATCH RFC v3 11/22] scsi: libsas: Add sas_internal_timeout() John Garry
2022-10-25 10:18 ` [PATCH RFC v3 12/22] scsi: core: Use SCSI_SCAN_RESCAN in __scsi_add_device() John Garry
2022-10-25 10:18 ` John Garry [this message]
2022-10-25 10:18 ` [PATCH RFC v3 14/22] ata: libata-scsi: Add ata_scsi_setup_sdev() John Garry
2022-10-25 10:18 ` [PATCH RFC v3 15/22] scsi: libsas: Add sas_ata_setup_device() John Garry
2022-10-25 10:18 ` [PATCH RFC v3 16/22] ata: libata-scsi: Allocate sdev early in port probe John Garry
2022-10-27  1:34   ` Damien Le Moal
2022-10-27  8:11     ` Hannes Reinecke
2022-10-27  9:16       ` Damien Le Moal
2022-10-27  9:51         ` Hannes Reinecke
2022-11-07 10:09           ` John Garry
2022-11-07 10:20             ` Hannes Reinecke
2022-10-25 10:18 ` [PATCH RFC v3 17/22] scsi: libsas drivers: Reserve tags John Garry
2022-10-25 10:18 ` [PATCH RFC v3 18/22] scsi: libsas: Queue SMP commands as requests John Garry
2022-10-27  1:36   ` Damien Le Moal
2022-10-27 10:45     ` John Garry
2022-10-25 10:18 ` [PATCH RFC v3 19/22] scsi: libsas: Queue TMF " John Garry
2022-10-25 10:18 ` [PATCH RFC v3 20/22] scsi: core: Add scsi_alloc_request_hwq() John Garry
2022-10-25 10:18 ` [PATCH RFC v3 21/22] scsi: libsas: Queue internal abort commands as requests John Garry
2022-10-29  1:15   ` chenxiang (M)
2022-11-02 10:04     ` John Garry
2022-11-03  3:09       ` chenxiang (M)
2022-10-25 10:18 ` [PATCH RFC v3 22/22] scsi: libsas: Delete sas_task_slow.timer John Garry

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1666693096-180008-14-git-send-email-john.garry@huawei.com \
    --to=john.garry@huawei.com \
    --cc=axboe@kernel.dk \
    --cc=bvanassche@acm.org \
    --cc=damien.lemoal@opensource.wdc.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=jejb@linux.ibm.com \
    --cc=jinpu.wang@cloud.ionos.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=martin.petersen@oracle.com \
    --cc=ming.lei@redhat.com \
    --cc=niklas.cassel@wdc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).