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: Thu, 9 May 2024 11:52:51 +0800 [thread overview]
Message-ID: <0c4ea5fd-9013-4ade-0597-b42626fe5757@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().
If this is true then all cascaded expanders will have this issue, I
wonder why the test guys have not report it until now.
Thanks,
Jason
祝一切顺利
>
next prev parent reply other threads:[~2024-05-09 3:52 UTC|newest]
Thread overview: 22+ 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 [this message]
2024-05-11 3:41 ` Jason Yan
2024-05-14 9:23 ` Li, Eric (Honggang)
2025-06-10 13:05 ` Li, Eric (Honggang)
2025-06-10 13:33 ` Jason Yan
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=0c4ea5fd-9013-4ade-0597-b42626fe5757@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.