Re: Issue in sas_ex_discover_dev() for multiple level of SAS expanders in a domain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/05/2024 04:15, Li, Eric (Honggang) wrote:
John,

I agree that the call to sas_ex_join_wide_port() is not mandatory. In
fact, some logic here is similar to that function. We don't need to do
it again.
But just updating the phy_state may not be enough. I suppose you still
need to add that PHY into the corresponding wide port by calling
sas_port_add_phy() and update phy->port.
Just updating the phy_state may avoid the port disabled in this issue,
but other missing piece of work may cause other issues.


If you check the commit in which that call to sas_ex_join_wide_port() was originally added - 19252de - it was added together with the comment "Due to races, the phy might not get added to the wide port, so we add the phy to the wide port here". However the code to set phy_state = PHY_STATE_DISCOVERED already existed before that commit.

When all that code was removed in a1b6fb947f923, I am just wondering if we have kept the phy_state = PHY_STATE_DISCOVERED code.

Anyway, would we really join a wideport with the downstream expander? I would just assume that we would be creating a new wideport, and a subsequent scanned phy would be added to it.


Eric Li


Internal Use - Confidential

Please don't add this.

I am also getting an "Retrieval using the IMAP4 protocol failed for the following message: 56472" error on your messages." Anyway idea why?

Thanks,
John




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux