From: John Garry <john.g.garry@oracle.com>
To: "Li, Eric (Honggang)" <Eric.H.Li@Dell.com>,
Jason Yan <yanaijie@huawei.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: Wed, 8 May 2024 08:48:29 +0100 [thread overview]
Message-ID: <eb90005b-1ef7-4bb6-bc62-84af5a03e3e7@oracle.com> (raw)
In-Reply-To: <SJ0PR19MB5415CFA77DCC17E0BFAEEF76C4E52@SJ0PR19MB5415.namprd19.prod.outlook.com>
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?
Thanks,
John
next prev parent reply other threads:[~2024-05-08 7:49 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 [this message]
2024-05-08 8:29 ` Li, Eric (Honggang)
2024-05-09 3:52 ` Jason Yan
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=eb90005b-1ef7-4bb6-bc62-84af5a03e3e7@oracle.com \
--to=john.g.garry@oracle.com \
--cc=Eric.H.Li@Dell.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=yanaijie@huawei.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