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: Fri, 1 Dec 2023 09:22:48 +0000 [thread overview]
Message-ID: <25b6b575-3108-41cc-96d4-70279ce61a48@oracle.com> (raw)
In-Reply-To: <d6b20d8f-7653-6806-d7c8-0adc54f1333b@huawei.com>
On 30/11/2023 03:53, yangxingui wrote:
>>>
>>> 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())?
>
> Well, okay, as follows?
> +++ b/drivers/scsi/libsas/sas_expander.c
> @@ -856,9 +856,7 @@ static bool sas_ex_join_wide_port(struct
> domain_device *parent, int phy_id)
>
> if (!memcmp(phy->attached_sas_addr,
> ephy->attached_sas_addr,
> SAS_ADDR_SIZE) && ephy->port) {
> - sas_port_add_phy(ephy->port, phy->phy);
> - phy->port = ephy->port;
> - phy->phy_state = PHY_DEVICE_DISCOVERED;
> + sas_port_add_ex_phy(ephy->port, phy);
> return true;
this looks ok. How about adding this helper and using it in a separate
change?
> }
> }
> diff --git a/drivers/scsi/libsas/sas_internal.h
> b/drivers/scsi/libsas/sas_internal.h
> index e860d5b19880..39ffa60a9a01 100644
> --- a/drivers/scsi/libsas/sas_internal.h
> +++ b/drivers/scsi/libsas/sas_internal.h
> @@ -189,6 +189,13 @@ static inline void sas_phy_set_target(struct
> asd_sas_phy *p, struct domain_devic
> }
> }
>
> +static inline void sas_port_add_ex_phy(struct sas_port *port, struct
> ex_phy *ex_phy)
> +{
> + sas_port_add_phy(port, ex_phy->phy);
> + ex_phy->port = port;
> + ex_phy->phy_state = PHY_DEVICE_DISCOVERED;
> +}
I'd prefer sas_expander.c, but sas_add_parent_port() is here... having
said that, sas_add_parent_port() is only used in sas_expander.c
> +
> static inline void sas_add_parent_port(struct domain_device *dev, int
> phy_id)
> {
> struct expander_device *ex = &dev->ex_dev;
> @@ -201,8 +208,7 @@ static inline void sas_add_parent_port(struct
> domain_device *dev, int phy_id)
> BUG_ON(sas_port_add(ex->parent_port));
> sas_port_mark_backlink(ex->parent_port);
> }
> - sas_port_add_phy(ex->parent_port, ex_phy->phy);
> + sas_port_add_ex_phy(ex->parent_port, ex_phy);
> }
>
>>
>>> 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?
> Yes, but in fact it has not reached that stage yet. After setting the
> address to 0, it will continue to create a new port and try to add other
> phys with the same address as it to this new port.
creating a port for SAS address == 0 and adding phys seems incorrect, right?
>
>>
>> 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?
> Yes, in order to avoid this situation, in the current patch, we will not
> force the SAS address to be set to 0 when the device type is not NULL,
> but will still use the address obtained after requesting the expander.
ok, let me check that again later today.
Thanks,
John
next prev parent reply other threads:[~2023-12-01 9:23 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
2023-11-30 3:53 ` yangxingui
2023-12-01 9:22 ` John Garry [this message]
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=25b6b575-3108-41cc-96d4-70279ce61a48@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®