From: John Garry <john.g.garry@oracle.com>
To: yangxingui <yangxingui@huawei.com>,
yanaijie@huawei.com, jejb@linux.ibm.com,
martin.petersen@oracle.com, damien.lemoal@opensource.wdc.com
Cc: linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org,
linuxarm@huawei.com, prime.zeng@hisilicon.com,
kangfenglong@huawei.com, chenxiang66@hisilicon.com
Subject: Re: [PATCH v4] scsi: libsas: Fix the failure of adding phy with zero-address to port
Date: Wed, 29 Nov 2023 12:54:33 +0000 [thread overview]
Message-ID: <cf98eb9f-ac42-4d9b-9cf3-3085f6fc0cda@oracle.com> (raw)
In-Reply-To: <baacad33-f568-6151-75a2-dfc09caf2a81@huawei.com>
On 28/11/2023 03:45, yangxingui wrote:
>
> On 2023/11/28 3:28, John Garry wrote:
>> On 24/11/2023 02:27, yangxingui wrote:
>>>> We already do this in sas_ex_join_wide_port(), right?
>>> No, If the addr of ex_phy matches dev->parent,
>>> sas_ex_join_wide_port() will not be called, but sas_add_parent_port()
>>> will be called as follows:
>>> static int sas_ex_discover_dev(struct domain_device *dev, int phy_id)
>>> {
>>> struct expander_device *ex = &dev->ex_dev;
>>> struct ex_phy *ex_phy = &ex->ex_phy[phy_id];
>>> struct domain_device *child = NULL;
>>> int res = 0;
>>>
>>> <...>
>>> /* Parent and domain coherency */
>>> if (!dev->parent && sas_phy_match_port_addr(dev->port,
>>> ex_phy)) {
>>> sas_add_parent_port(dev, phy_id);
>>> return 0;
>>> }
>>> if (dev->parent && sas_phy_match_dev_addr(dev->parent,
>>> ex_phy)) {
>>> sas_add_parent_port(dev, phy_id);
>>> if (ex_phy->routing_attr == TABLE_ROUTING)
>>> sas_configure_phy(dev, phy_id,
>>> dev->port->sas_addr, 1);
>>> return 0;
>>> }
>>> <...>
>>> }
>>>
>>>>
>>>> I am not saying that what we do now does not have a problem - I am
>>>> just trying to understand what currently happens
>>>
>>> ok, because ex_phy->port is not set when calling
>>> sas_add_parent_port(), when deleting phy from the parent wide port,
>>> it is not removed from the phy_list of the parent wide port as follows:
>>> static void sas_unregister_devs_sas_addr(struct domain_device *parent,
>>> int phy_id, bool last)
>>> {
>>> <...>
>>> // Since ex_phy->port is not set, this branch will not be enter
>>
>> But then how does this ever work? It is because we follow path
>> sas_rediscover_dev() -> sas_discover_new() ->
>> sas_ex_discover_devices() -> sas_ex_discover_dev() ->
>> sas_add_parent_port(), and not sas_rediscover_dev() ->
>> sas_discover_new() -> sas_ex_join_wide_port()? If so, is that because
>> ephy->sas_attached_phy == 0 in sas_discover_new() ->
>> sas_ex_join_wide_port() and it fails?
>>
>> BTW, about something mentioned earlier - adding the phy19 with SAS_ADDR
>
> Yes,
> For phy19, when the phy is attached and added to the parent wide port,
> the path is:
> sas_rediscover()
> ->sas_discover_new()
> ->sas_ex_discover_devices()
> ->sas_ex_discover_dev()
> -> sas_add_parent_port().
ok, so then the change to set ex_phy->port = ex->parent_port looks ok.
Maybe we can put this in a helper with the sas_port_add_phy() call, as
it is duplicated in sas_ex_join_wide_port()
Do we also need to set ex_phy->phy_state (like sas_ex_join_wide_port())?
> And the path called when it is removed from parent wide port is:
> sas_rediscover()
> ->sas_unregister_devs_sas_addr() // The sas address of phy19
> becomes 0. Since ex_phy->port is NULL, phy19 is not removed from the
> parent wide port's phy_list.
>
> For phy0, it is connected to a new sata device.
> sas_rediscover()
> ->sas_discover_new()->sas_ex_phy_discover()
> ->sas_ex_phy_discover_helper()
> ->sas_set_ex_phy() // The device type
> is stp. Since the linkrate is 5 and less than 1.5G, sas_address is set
> to 0.
Then when we get the proper linkrate later, will we then rediscover and
set the proper SAS address? I am just wondering if this change is really
required?
BTW, Even with the change to set ex_phy->port = ex->parent_port, are we
still joining the host-attached expander phy (19) to a port with SAS
address == 0?
> ->sas_ex_discover_devices()
> ->sas_ex_discover_dev()
> ->sas_ex_discover_end_dev()
> ->sas_port_alloc() // Create
> port-7:7:0
> ->sas_ex_get_linkrate()
> ->sas_port_add_phy() // Try
> adding phy19 to port->7:7:0, triggering BUG()
Thanks,
John
next prev parent reply other threads:[~2023-11-29 12:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-17 9:00 Xingui Yang
2023-11-23 14:52 ` John Garry
2023-11-24 2:27 ` yangxingui
2023-11-27 19:28 ` John Garry
2023-11-28 3:45 ` yangxingui
2023-11-29 12:54 ` John Garry [this message]
2023-11-30 3:53 ` yangxingui
2023-12-01 9:22 ` John Garry
2023-12-04 11:49 ` yangxingui
2023-11-24 8:01 ` yangxingui
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=cf98eb9f-ac42-4d9b-9cf3-3085f6fc0cda@oracle.com \
--to=john.g.garry@oracle.com \
--cc=chenxiang66@hisilicon.com \
--cc=damien.lemoal@opensource.wdc.com \
--cc=jejb@linux.ibm.com \
--cc=kangfenglong@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=martin.petersen@oracle.com \
--cc=prime.zeng@hisilicon.com \
--cc=yanaijie@huawei.com \
--cc=yangxingui@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
all inboxes | Powered by JetHome®