From: Jason Yan <yanaijie@huawei.com>
To: "Li, Eric (Honggang)" <Eric.H.Li@Dell.com>,
John Garry <john.g.garry@oracle.com>,
"james.bottomley@hansenpartnership.com"
<James.Bottomley@HansenPartnership.com>,
"Martin K . Petersen" <martin.petersen@oracle.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: Issue in sas_ex_discover_dev() for multiple level of SAS expanders in a domain
Date: Sat, 11 May 2024 11:41:10 +0800 [thread overview]
Message-ID: <ec087459-ae19-f593-f046-846c041e397d@huawei.com> (raw)
In-Reply-To: <SJ0PR19MB54152471D18241A020914B2AC4E52@SJ0PR19MB5415.namprd19.prod.outlook.com>
On 2024/5/8 16:29, Li, Eric (Honggang) wrote:
>> -----Original Message-----
>> From: John Garry <john.g.garry@oracle.com>
>> Sent: Wednesday, May 8, 2024 3:48 PM
>> To: Li, Eric (Honggang) <Eric.H.Li@Dell.com>; Jason Yan <yanaijie@huawei.com>;
>> james.bottomley@hansenpartnership.com; Martin K . Petersen <martin.petersen@oracle.com>
>> Cc: linux-scsi@vger.kernel.org
>> Subject: Re: Issue in sas_ex_discover_dev() for multiple level of SAS expanders in a domain
>>
>>
>> [EXTERNAL EMAIL]
>>
>> On 08/05/2024 01:59, Li, Eric (Honggang) wrote:
>>>>> Call to sas_ex_join_wide_port() makes the rest PHYs associated with
>>>>> that existing port
>>>> (making it become wideport) and set up sysfs between the PHY and
>>>> port. > Set PHY_STATE_DISCOVERED would make the rest PHYs not being
>>>> scanned/discovered again (as this wide port is already scanned).
>>>>
>>>> If you can just confirm that re-adding the code to set phy_state =
>>>> DISCOVERED is good enough to see the SAS disks again, then this can
>>>> be further discussed. >>
>>> OK. I will work on that and keep you updated.
>>
>> I expect a flow like this for scanning of the downstream expander:
>>
>> sas_discover_new(struct domain_device *dev [upstream expander], int
>> phy_id_a) -> sas_ex_discover_devices(single = -1) ->
>> sas_ex_discover_dev(phy_id_b) for each phy in @dev non-vacant and non-discovered ->
>> sas_ex_discover_expander( [downstream expander]) for first phy scanned which belongs to
>> downstream expander.
>>
>> And following that we have continue to scan phys in sas_ex_discover_devices(single = -1) ->
>> sas_ex_discover_dev(phy_id_b) ->
>> sas_ex_join_wide_port() -> for each non-vacant and non-discovered phy in phy_id_b which
>> matches that downstream expander.
>>
>> Can you see why this does not actually work/occur?
>>
>
> before calling sas_ex_join_wide_port(), sas_dev_present_in_domain() finds the attached_sas_address of PHY (phy_id_b) is already in the domain of that root port, and then disable all PHYs to that downstream expander (in sas_ex_disable_port(dev, attached_sas_addr))
> Therefore, I think we need to switch the order of function call to sas_ex_join_wide_port() and sas_dev_present_in_domain().
Hi Eric,
Can you test the following patch to see if it works?
Author: Jason Yan <yanaijie@huawei.com>
Date: Sat May 11 11:33:35 2024 +0800
scsi: libsas: Skip disable PHYs which can form wide ports
Signed-off-by: Jason Yan <yanaijie@huawei.com>
diff --git a/drivers/scsi/libsas/sas_expander.c
b/drivers/scsi/libsas/sas_expander.c
index f6e6db8b8aba..39a86857bc52 100644
--- a/drivers/scsi/libsas/sas_expander.c
+++ b/drivers/scsi/libsas/sas_expander.c
@@ -618,15 +618,17 @@ static void sas_ex_disable_port(struct
domain_device *dev, u8 *sas_addr)
}
}
-static int sas_dev_present_in_domain(struct asd_sas_port *port,
+static int sas_dev_present_in_domain(struct domain_device *dev,
u8 *sas_addr)
{
- struct domain_device *dev;
+ struct domain_device *tmp;
if (SAS_ADDR(port->sas_addr) == SAS_ADDR(sas_addr))
return 1;
- list_for_each_entry(dev, &port->dev_list, dev_list_node) {
- if (SAS_ADDR(dev->sas_addr) == SAS_ADDR(sas_addr))
+ list_for_each_entry(tmp, &dev->port->dev_list, dev_list_node) {
+ if (tmp->parent == dev)
+ continue;
+ if (SAS_ADDR(tmp->sas_addr) == SAS_ADDR(sas_addr))
return 1;
}
return 0;
@@ -973,7 +975,7 @@ static int sas_ex_discover_dev(struct domain_device
*dev, int phy_id)
return 0;
}
- if (sas_dev_present_in_domain(dev->port, ex_phy->attached_sas_addr))
+ if (sas_dev_present_in_domain(dev, ex_phy->attached_sas_addr))
sas_ex_disable_port(dev, ex_phy->attached_sas_addr);
if (ex_phy->attached_dev_type == SAS_PHY_UNUSED) {
next prev parent reply other threads:[~2024-05-11 3:41 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-24 8:59 Issue in sas_ex_discover_dev() for multiple level of SAS expanders in a domain Li, Eric (Honggang)
2024-04-24 10:46 ` John Garry
2024-04-25 2:57 ` Jason Yan
2024-04-25 5:03 ` Li, Eric (Honggang)
2024-04-30 14:22 ` Li, Eric (Honggang)
2024-05-01 14:23 ` John Garry
2024-05-03 3:15 ` Li, Eric (Honggang)
2024-05-03 8:33 ` John Garry
2024-05-06 1:49 ` Li, Eric (Honggang)
2024-05-07 8:03 ` John Garry
2024-05-07 8:44 ` Li, Eric (Honggang)
2024-05-07 9:17 ` John Garry
2024-05-07 11:17 ` Li, Eric (Honggang)
2024-05-07 15:14 ` John Garry
2024-05-08 0:59 ` Li, Eric (Honggang)
2024-05-08 7:48 ` John Garry
2024-05-08 8:29 ` Li, Eric (Honggang)
2024-05-09 3:52 ` Jason Yan
2024-05-11 3:41 ` Jason Yan [this message]
2024-05-14 9:23 ` Li, Eric (Honggang)
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=ec087459-ae19-f593-f046-846c041e397d@huawei.com \
--to=yanaijie@huawei.com \
--cc=Eric.H.Li@Dell.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=john.g.garry@oracle.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.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 read-only IMAP folder(s) and NNTP newsgroup(s).