netdev - Re: [net-next PATCH v3 09/15] device property: Introduce fwnode_get

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: <CAHp75VcVNj0+KZiLEsPgfz=fZoLr9g1=6ikeUo7FZ1rd4FKpWQ@mail.gmail.com>
Date:   Fri, 22 Jan 2021 23:06:14 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Saravana Kannan <saravanak@...gle.com>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        Calvin Johnson <calvin.johnson@....nxp.com>,
        Grant Likely <grant.likely@....com>,
        Jeremy Linton <jeremy.linton@....com>,
        Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Russell King - ARM Linux admin <linux@...linux.org.uk>,
        Cristi Sovaiala <cristian.sovaiala@....com>,
        Florin Laurentiu Chiculita <florinlaurentiu.chiculita@....com>,
        Ioana Ciornei <ioana.ciornei@....com>,
        Madalin Bucur <madalin.bucur@....nxp.com>,
        Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
        Marcin Wojtas <mw@...ihalf.com>,
        Pieter Jansen Van Vuuren <pieter.jansenvv@...boosystems.io>,
        Jon <jon@...id-run.com>,
        Diana Madalina Craciun <diana.craciun@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>,
        Laurentiu Tudor <laurentiu.tudor@....com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        "linux.cj" <linux.cj@...il.com>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Laurent Pinchart <laurent.pinchart+renesas@...asonboard.com>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [net-next PATCH v3 09/15] device property: Introduce fwnode_get_id()

On Fri, Jan 22, 2021 at 10:59 PM Saravana Kannan <saravanak@...gle.com> wrote:
> On Fri, Jan 22, 2021 at 8:34 AM Rafael J. Wysocki <rafael@...nel.org> wrote:
> > On Wed, Jan 20, 2021 at 9:01 PM Saravana Kannan <saravanak@...gle.com> wrote:
> > > On Wed, Jan 20, 2021 at 11:15 AM Rafael J. Wysocki <rafael@...nel.org> wrote:


> > > I'd rather this new function be an ops instead of a bunch of #ifdef or
> > > if (acpi) checks. Thoughts?
> >
> > Well, it looks more like a helper function than like an op and I'm not
> > even sure how many potential users of it will expect that _ADR should
> > be evaluated in the absence of the "reg" property.
> >
> > It's just that the "reg" property happens to be kind of an _ADR
> > equivalent in this particular binding AFAICS.
>
> I agree it is not clear how useful this helper function is going to be.
>
> But in general, to me, any time the wrapper/helper functions in
> drivers/base/property.c need to do something like this:
>
> if (ACPI)
>    ACPI specific code
> if (OF)
>    OF specific code
>
> I think the code should be pushed to the fwnode ops. That's one of the
> main point of fwnode. So that firmware specific stuff is done by
> firmware specific code. Also, when adding support for new firmware,
> it's pretty clear what support the firmware needs to implement.
> Instead of having to go fix up a bunch of code all over the place.

Wishful thinking.
In the very case of GPIO it's related to framework using headers local
to framework. Are you suggesting to open its guts to the entire wild
world?
I don't think it's a good idea. You see, here we have different
layering POD types, which are natural and quite low level that ops
suits best for them and quite different resource types like GPIO. And
the latter is closer to certain framework rather than to POD handling
cases.

> So fwnode_ops->get_id() would be the OP ACPI and OF would implement.
> And then we can have a wrapper in drivers/base/property.c.


-- 
With Best Regards,
Andy Shevchenko