linux-kernel - Re: [PATCH v2 08/17] driver core: Add fwnode link support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20201207195607.GG693271@unreal>
Date:   Mon, 7 Dec 2020 21:56:07 +0200
From:   Leon Romanovsky <leon@...nel.org>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Marc Zyngier <maz@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Tomi Valkeinen <tomi.valkeinen@...com>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Android Kernel Team <kernel-team@...roid.com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-efi <linux-efi@...r.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [PATCH v2 08/17] driver core: Add fwnode link support

On Mon, Dec 07, 2020 at 11:25:03AM -0800, Saravana Kannan wrote:
> On Sat, Dec 5, 2020 at 11:48 PM Leon Romanovsky <leon@...nel.org> wrote:
> >
> > On Fri, Nov 20, 2020 at 06:02:23PM -0800, Saravana Kannan wrote:
> > > Add support for creating supplier-consumer links between fwnodes.  It is
> > > intended for internal use the driver core and generic firmware support
> > > code (eg. Device Tree, ACPI), so it is simple by design and the API
> > > provided is limited.
> > >
> > > Signed-off-by: Saravana Kannan <saravanak@...gle.com>
> > > ---
> > >  drivers/base/core.c    | 98 ++++++++++++++++++++++++++++++++++++++++++
> > >  drivers/of/dynamic.c   |  1 +
> > >  include/linux/fwnode.h | 14 ++++++
> > >  3 files changed, 113 insertions(+)
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index 401fa7e3505c..e2b246a44d1a 100644
> > > --- a/drivers/base/core.c
> > > +++ b/drivers/base/core.c
> > > @@ -50,6 +50,104 @@ static LIST_HEAD(wait_for_suppliers);
> > >  static DEFINE_MUTEX(wfs_lock);
> > >  static LIST_HEAD(deferred_sync);
> > >  static unsigned int defer_sync_state_count = 1;
> > > +static DEFINE_MUTEX(fwnode_link_lock);
> > > +
> > > +/**
> > > + * fwnode_link_add - Create a link between two fwnode_handles.
> > > + * @con: Consumer end of the link.
> > > + * @sup: Supplier end of the link.
> > > + *
> > > + * Create a fwnode link between fwnode handles @con and @sup. The fwnode link
> > > + * represents the detail that the firmware lists @sup fwnode as supplying a
> > > + * resource to @con.
> > > + *
> > > + * The driver core will use the fwnode link to create a device link between the
> > > + * two device objects corresponding to @con and @sup when they are created. The
> > > + * driver core will automatically delete the fwnode link between @con and @sup
> > > + * after doing that.
> > > + *
> > > + * Attempts to create duplicate links between the same pair of fwnode handles
> > > + * are ignored and there is no reference counting.
> >
> > Sorry to ask, but why is that?
> > Isn't this a programmer error?
>
> No, not a programmer error.
>
> One firmware node can point to the same supplier many times. For
> example, the consumer can be using multiple clocks from the same
> supplier clock controller. In the context of fw_devlink, there's no
> reason to keep track of each clock dependency separately because we'll
> be creating only one device link from fwnode link. So multiple fwnode
> link attempts between the same two devices are just treated as one
> instance of dependency. I hope that clarifies things.

Yes, thanks.

>
> -Saravana