All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <swboyd@chromium.org>
To: Frank Rowand <frowand.list@gmail.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Rob Herring <robh+dt@kernel.org>,
	Saravana Kannan <saravanak@google.com>
Cc: kernel-team@android.com, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1] of: property: fw_devlink: Add support for remote-endpoint
Date: Tue, 30 Mar 2021 12:36:06 -0700	[thread overview]
Message-ID: <161713296600.2260335.7459463781834702722@swboyd.mtv.corp.google.com> (raw)
In-Reply-To: <20210330185056.1022008-1-saravanak@google.com>

Quoting Saravana Kannan (2021-03-30 11:50:55)
> remote-endpoint property seems to always come in pairs where two devices
> point to each other. So, we can't really tell from DT if there is a
> functional probe order dependency between these two devices.
> 
> However, there can be other dependencies between two devices that point
> to each other with remote-endpoint. This non-remote-endpoint dependency
> combined with one of the remote-endpoint dependency can lead to a cyclic
> dependency[1].
> 
> To avoid this cyclic dependency from incorrectly blocking probes,
> fw_devlink needs to be made aware of remote-endpoint dependencies even
> though remote-endpoint dependencies by themselves won't affect probe
> ordering (because fw_devlink will see the cyclic dependency between
> remote-endpoint devices and ignore the dependencies that cause the
> cycle).
> 
> Also, if a device ever needs to know if a non-probe-blocking
> remote-endpoint has finished probing, it can now use the sync_state() to
> figure it out.
> 
> [1] - https://lore.kernel.org/lkml/CAGETcx9Snf23wrXqjDhJiTok9M3GcoVYDSyNYSMj9QnSRrA=cA@mail.gmail.com/#t
> Fixes: ea718c699055 ("Revert "Revert "driver core: Set fw_devlink=on by default""")
> Reported-by: Stephen Boyd <swboyd@chromium.org>
> Signed-off-by: Saravana Kannan <saravanak@google.com>
> ---

Tested-by: Stephen Boyd <swboyd@chromium.org>

> diff --git a/drivers/of/property.c b/drivers/of/property.c
> index 5036a362f52e..2bb3158c9e43 100644
> --- a/drivers/of/property.c
> +++ b/drivers/of/property.c
> @@ -1225,6 +1230,8 @@ static struct device_node *parse_##fname(struct device_node *np,       \
>   * @parse_prop.prop_name: Name of property holding a phandle value
>   * @parse_prop.index: For properties holding a list of phandles, this is the
>   *                   index into the list
> + * @optional: The property can be an optional dependency.

This bit conflicted for me on linux-next today so I dropped it in favor
of 3915fed92365 ("of: property: Provide missing member description and
remove excess param").

> + * @node_not_dev: The consumer node containing the property is never a device.
>   *
>   * Returns:
>   * parse_prop() return values are

  reply	other threads:[~2021-03-30 19:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30 18:50 [PATCH v1] of: property: fw_devlink: Add support for remote-endpoint Saravana Kannan
2021-03-30 19:36 ` Stephen Boyd [this message]
2021-03-30 19:45   ` Saravana Kannan
2021-04-02 15:07 ` Greg Kroah-Hartman

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=161713296600.2260335.7459463781834702722@swboyd.mtv.corp.google.com \
    --to=swboyd@chromium.org \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-team@android.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh+dt@kernel.org \
    --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.