[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <569cb47c-af63-cf70-ae1a-4c5116dd4877@huawei.com>
Date: Fri, 23 Sep 2022 11:30:49 +0100
From: John Garry <john.garry@...wei.com>
To: Jason Yan <yanaijie@...wei.com>, <martin.petersen@...cle.com>,
<jejb@...ux.ibm.com>
CC: <linux-scsi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<hare@...e.com>, <hch@....de>, <bvanassche@....org>,
<jinpu.wang@...ud.ionos.com>
Subject: Re: [PATCH 6/7] scsi: pm8001: use dev_and_phy_addr_same() instead of
open coded
On 23/09/2022 11:13, Jason Yan wrote:
>>
>> Please explain why.
>>
>> I would assume that if those helpers were only used in libsas code
>> (and not LLDDs) then they could be put in sas_internal.h and no need
>> for export
>>
>
>
> Sorry, I did not make it clear. I mean we need to export
> sas_find_attathed_phy() below. Not the sas address comparation helpers.
That seems fine to me.
About sas_find_attathed_phy() implementation,
> +static inline int sas_find_attathed_phy(struct expander_device *ex_dev,
> + struct domain_device *dev)
> +{
> + struct ex_phy *phy;
> + int phy_id;
> +
> + for (phy_id = 0; phy_id < ex_dev->num_phys; phy_id++) {
> + phy = &ex_dev->ex_phy[phy_id];
> + if (SAS_ADDR(phy->attached_sas_addr)
> + == SAS_ADDR(dev->sas_addr))
> + return phy_id;
> + }
> +
> + return ex_dev->num_phys;
Returning ex_dev->num_phys would seem ok, but then the LLDD needs to
check that return against ex_dev->num_phys. It seems ok, but I'm still
not 100% comfortable with that. Maybe returning -ENODEV may be better.
Or return boolean and pass phy_id as pointer to be filled in when
returning true.
> +}
Thanks,
John
Powered by blists - more mailing lists