From: "Rafael J. Wysocki" <rafael@kernel.org>
To: "chenxiang (M)" <chenxiang66@hisilicon.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>, Sebastian Reichel <sre@kernel.org>,
John Garry <john.garry@huawei.com>,
Linux PM <linux-pm@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>
Subject: Re: [RFC PATCH] PM:runtime:Remove the link state check in function rpm_get_supplier()
Date: Mon, 21 Sep 2020 18:02:20 +0200 [thread overview]
Message-ID: <CAJZ5v0hkUqBLw-PjTeP2nSxF1+knTUoFevv3hPQL=6x1t5BcoA@mail.gmail.com> (raw)
In-Reply-To: <28bc46a7-7140-cc80-43a5-c1de8adfd81f@hisilicon.com>
On Mon, Sep 21, 2020 at 9:12 AM chenxiang (M) <chenxiang66@hisilicon.com> wrote:
>
>
>
> 在 2020/7/30 13:48, chenxiang 写道:
> > From: Xiang Chen <chenxiang66@hisilicon.com>
> >
> > To support runtime PM for hisi SAS driver (the dirver is in directory
> > drivers/scsi/hisi_sas), we add device link between scsi_device->sdev_gendev
> > (consumer device) and hisi_hba->dev(supplier device) with flags
> > DL_FLAG_PM_RUNTIME | DL_FLAG_RPM_ACTIVE.
> > After runtime suspended consumers and supplier, unload the dirver which
> > cause a hung. We find that it calls function device_release_driver_internal()
> > to release supplier device hisi_hba->dev, as the device link is busy,
> > it sets the device link as DL_STATE_SUPPLIER_UNBIND, and then call function
> > device_release_driver_internal() to release consumer device
> > scsi_device->sdev_gendev). Then It will try to call pm_runtime_get_sync()
> > to resume consumer device, as consumer-supplier relation exists, it will try
> > to resume supplier first, but as the link state is already set as
> > DL_STATE_SUPPLIER_UNBIND, so it skips resuming supplier and only resume
> > consumer which cause a hung (it sends IOs to resume scsi_device while
> > SAS controller is suspended). Simple flow is as follows:
> >
> > device_release_driver_internal -> (supplier device)
> > if device_links_busy ->
> > device_links_unbind_consumers ->
> > ...
> > WRITE_ONCE(link->status, DL_STATE_SUPPLIER_UNBIND)
> > device_release_driver_internal (consumer device)
> > pm_runtime_get_sync -> (consumer device)
> > ...
> > __rpm_callback ->
> > rpm_get_suppliers ->
> > if link->state == DL_STATE_SUPPLIER_UNBIND -> skip the action of resuming the supplier
> > ...
> > pm_runtime_clean_up_links
> > ...
>
> Hi Rafael, do you have any idea about this issue?
>
> > It should guarantee correct suspend/resume ordering between a supplier
> > device and its consumer devices (resume the supplier device before resuming
> > consumer devices, and suspend consumer devices before suspending supplier
> > device) for runtime PM, but it seems the check in rpm_get_supplier() breaks
> > the rule, so remove it.
> >
> > Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com>
> > ---
> > drivers/base/power/runtime.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> > index 9f62790..a8edd92 100644
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -291,8 +291,7 @@ static int rpm_get_suppliers(struct device *dev)
> > device_links_read_lock_held()) {
> > int retval;
> >
> > - if (!(link->flags & DL_FLAG_PM_RUNTIME) ||
> > - READ_ONCE(link->status) == DL_STATE_SUPPLIER_UNBIND)
> > + if (!(link->flags & DL_FLAG_PM_RUNTIME))
AFAICS you need to make the analogous change in rpm_put_suppliers(),
but apart from this it should be fine.
Thanks!
> > continue;
> >
> > retval = pm_runtime_get_sync(link->supplier);
>
>
next prev parent reply other threads:[~2020-09-21 16:02 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-30 5:48 [RFC PATCH] PM:runtime:Remove the link state check in function rpm_get_supplier() chenxiang
2020-09-21 7:11 ` chenxiang (M)
2020-09-21 16:02 ` Rafael J. Wysocki [this message]
2020-09-22 9:32 ` chenxiang (M)
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='CAJZ5v0hkUqBLw-PjTeP2nSxF1+knTUoFevv3hPQL=6x1t5BcoA@mail.gmail.com' \
--to=rafael@kernel.org \
--cc=chenxiang66@hisilicon.com \
--cc=john.garry@huawei.com \
--cc=linux-pm@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=pavel@ucw.cz \
--cc=sre@kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).