All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Saravana Kannan <saravanak@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Len Brown <lenb@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Vladimir Oltean <olteanv@gmail.com>,
	"Cc: Android Kernel" <kernel-team@android.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	netdev <netdev@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v3 1/3] driver core: fw_devlink: Improve handling of cyclic dependencies
Date: Sat, 18 Sep 2021 16:38:42 +0200	[thread overview]
Message-ID: <CAJZ5v0iM6U9_xuXjghDR+8upHA+SdZdmp2nGaOhaLTPR54BhmA@mail.gmail.com> (raw)
In-Reply-To: <20210915170940.617415-2-saravanak@google.com>

On Wed, Sep 15, 2021 at 7:09 PM Saravana Kannan <saravanak@google.com> wrote:
>
> When we have a dependency of the form:
>
> Device-A -> Device-C
>         Device-B
>
> Device-C -> Device-B
>
> Where,
> * Indentation denotes "child of" parent in previous line.
> * X -> Y denotes X is consumer of Y based on firmware (Eg: DT).
>
> We have cyclic dependency: device-A -> device-C -> device-B -> device-A
>
> fw_devlink current treats device-C -> device-B dependency as an invalid
> dependency and doesn't enforce it but leaves the rest of the
> dependencies as is.
>
> While the current behavior is necessary, it is not sufficient if the
> false dependency in this example is actually device-A -> device-C. When
> this is the case, device-C will correctly probe defer waiting for
> device-B to be added, but device-A will be incorrectly probe deferred by
> fw_devlink waiting on device-C to probe successfully. Due to this, none
> of the devices in the cycle will end up probing.
>
> To fix this, we need to go relax all the dependencies in the cycle like
> we already do in the other instances where fw_devlink detects cycles.
> A real world example of this was reported[1] and analyzed[2].
>
> [1] - https://lore.kernel.org/lkml/0a2c4106-7f48-2bb5-048e-8c001a7c3fda@samsung.com/
> [2] - https://lore.kernel.org/lkml/CAGETcx8peaew90SWiux=TyvuGgvTQOmO4BFALz7aj0Za5QdNFQ@mail.gmail.com/
> Fixes: f9aa460672c9 ("driver core: Refactor fw_devlink feature")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
>  drivers/base/core.c | 17 ++++++++++++-----
>  1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index e65dd803a453..316df6027093 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -1772,14 +1772,21 @@ static int fw_devlink_create_devlink(struct device *con,
>          * be broken by applying logic. Check for these types of cycles and
>          * break them so that devices in the cycle probe properly.
>          *
> -        * If the supplier's parent is dependent on the consumer, then
> -        * the consumer-supplier dependency is a false dependency. So,
> -        * treat it as an invalid link.
> +        * If the supplier's parent is dependent on the consumer, then the
> +        * consumer and supplier have a cyclic dependency. Since fw_devlink
> +        * can't tell which of the inferred dependencies are incorrect, don't
> +        * enforce probe ordering between any of the devices in this cyclic
> +        * dependency. Do this by relaxing all the fw_devlink device links in
> +        * this cycle and by treating the fwnode link between the consumer and
> +        * the supplier as an invalid dependency.
>          */
>         sup_dev = fwnode_get_next_parent_dev(sup_handle);
>         if (sup_dev && device_is_dependent(con, sup_dev)) {
> -               dev_dbg(con, "Not linking to %pfwP - False link\n",
> -                       sup_handle);
> +               dev_info(con, "Fixing up cyclic dependency with %pfwP (%s)\n",
> +                        sup_handle, dev_name(sup_dev));

Why not dev_dbg()?

Other than this, the change makes sense to me.

> +               device_links_write_lock();
> +               fw_devlink_relax_cycle(con, sup_dev);
> +               device_links_write_unlock();
>                 ret = -EINVAL;
>         } else {
>                 /*
> --
> 2.33.0.309.g3052b89438-goog
>

  reply	other threads:[~2021-09-18 14:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15 17:09 [PATCH v3 0/3] fw_devlink bug fixes Saravana Kannan
2021-09-15 17:09 ` [PATCH v3 1/3] driver core: fw_devlink: Improve handling of cyclic dependencies Saravana Kannan
2021-09-18 14:38   ` Rafael J. Wysocki [this message]
2021-09-15 17:09 ` [PATCH v3 2/3] driver core: fw_devlink: Add support for FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD Saravana Kannan
2021-09-18 15:03   ` Rafael J. Wysocki
2021-09-19  1:16     ` Andrew Lunn
2021-09-19  6:41       ` Greg Kroah-Hartman
2021-09-21 16:15       ` Greg Kroah-Hartman
2021-09-21 16:35         ` Rafael J. Wysocki
2021-09-21 17:56           ` Andrew Lunn
2021-09-21 18:56             ` Rafael J. Wysocki
2021-09-21 19:50               ` Andrew Lunn
2021-09-21 20:07                 ` Saravana Kannan
2021-09-21 21:02                   ` Andrew Lunn
2021-09-21 21:54                     ` Saravana Kannan
2021-09-21 22:04                       ` Andrew Lunn
2021-09-21 22:26                         ` Saravana Kannan
2021-09-22  0:45                           ` Andrew Lunn
2021-09-22  1:00                             ` Saravana Kannan
2021-09-22 12:52                               ` Andrew Lunn
2021-09-23 12:48                   ` Rafael J. Wysocki
2021-09-15 17:09 ` [PATCH v3 3/3] net: mdiobus: Set FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD for mdiobus parents Saravana Kannan
2021-09-23 17:30 ` [PATCH v3 0/3] fw_devlink bug fixes Greg Kroah-Hartman
2021-09-23 19:44   ` Vladimir Oltean
2021-09-24  6:09     ` Greg Kroah-Hartman
2021-09-23 22:28 ` Florian Fainelli

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=CAJZ5v0iM6U9_xuXjghDR+8upHA+SdZdmp2nGaOhaLTPR54BhmA@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hkallweit1@gmail.com \
    --cc=kernel-team@android.com \
    --cc=kuba@kernel.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=m.szyprowski@samsung.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=saravanak@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.