Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
IronPort-SDR: Z5tjoK9ZDHQmXSQrL+CKo+1kuLdVAO/cmM+DfNHvbecVrKaYcxy529Wdy5L6NJ19kO+SqWi+H8
 5ZUINkIljGMWhac81u5nUmhp/j0ccq23ADF2oHCiezYxf20yxgFyIPRDdGGVYepHMmxdlHiomd
 npGD3iEp/G4qmt+bFxtDlKKZMxhBTTeHTjKAe7KpM4GdUw12Ov3EZUDJ6NjnBo8u85wlKfj80e
 fSOMgAHgyLtPx3g9mZsLxsTde0mkGHpjlzG+YHBaCtGtdUKATaye+Q16VE4kEl+CU12uGqbZ3t
 +2iwIoqzFUD6k5RBmFus48l7
IronPort-SDR: sKPUqq0LX6tkd2bD+7mSuxqizZuiZMwcnoqjVzBrcAVRaw5+boi1DfGYTPkQjpi3lCzpu6cPij
 lV6EC16DG/ALeGD82H+W01FWbmfLTi5DRSN6qRaH5vvqDH18aKdeAEyXl+aYb1QCAsOEOCCJ50
 tnCHnr/ztKlrCC7JiLJhktyLooln9AyFTdUgy3VeotyElDUdRlHDFg1B4mJtHmD9KyWdFUZ3dw
 Wb3GtY5hDBAGEfePxkjxMX4FOr71efwKtMvt+0VdirXhDzgtBC+DBy6huQKNEAAo1vHmKTr9QY
 ocw=
WDCIronportException: Internal
Message-ID: <ecde5199-bb9e-6df4-832a-f3707babd3d6@opensource.wdc.com>
Date:   Wed, 21 Sep 2022 07:02:42 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.1
Subject: Re: [PATCH RFC 2/6] scsi: scsi_transport_sas: Allocate end device
 target id in the rphy alloc
Content-Language: en-US
To:     John Garry <john.garry@huawei.com>, jejb@linux.ibm.com,
        martin.petersen@oracle.com, hare@suse.de, hch@lst.de
Cc:     linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-scsi@vger.kernel.org, brking@us.ibm.com
References: <1663669630-21333-1-git-send-email-john.garry@huawei.com>
 <1663669630-21333-3-git-send-email-john.garry@huawei.com>
From:   Damien Le Moal <damien.lemoal@opensource.wdc.com>
Organization: Western Digital Research
In-Reply-To: <1663669630-21333-3-git-send-email-john.garry@huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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) &&

-- 
Damien Le Moal
Western Digital Research