Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210112134054.342-1-calvin.johnson@oss.nxp.com>
 <20210112134054.342-10-calvin.johnson@oss.nxp.com> <CAGETcx-7JVz=QLCMWicHqoagWYjeBXdFJmSv1v6MQhtPt2RS=Q@mail.gmail.com>
 <20210112180343.GI4077@smile.fi.intel.com> <CAJZ5v0iW0jJUcXtiQtLOakkSejZCJD=hTFLL4mvoAN3ZTB+1Tw@mail.gmail.com>
 <CAHp75VcJS10KMA5amUc36PFgj0FLddj1fXD4dUtuAchrVhhzPg@mail.gmail.com>
 <CAJZ5v0ga5RqwFzbBqSChJ7=gBBM-7dWNQPz6bqvqsNAkWZJ=vQ@mail.gmail.com>
 <CAGETcx8DP8J53ntxX2VCSnbMfq1qki7gD-md+NC_jVfOkTam3g@mail.gmail.com> <CAJZ5v0gUCUxJX9sGJiZ+zTVYrc3rjuUO2B2fx+O6PewbG7F8aw@mail.gmail.com>
In-Reply-To: <CAJZ5v0gUCUxJX9sGJiZ+zTVYrc3rjuUO2B2fx+O6PewbG7F8aw@mail.gmail.com>
From:   Saravana Kannan <saravanak@google.com>
Date:   Fri, 22 Jan 2021 12:58:24 -0800
Message-ID: <CAGETcx-904Cr11nVW6PC=OqWnwM-ZC-DdEUa8+7JmhsH3UOqHw@mail.gmail.com>
Subject: Re: [net-next PATCH v3 09/15] device property: Introduce fwnode_get_id()
To:     "Rafael J. Wysocki" <rafael@kernel.org>
Cc:     Andy Shevchenko <andy.shevchenko@gmail.com>,
        Calvin Johnson <calvin.johnson@oss.nxp.com>,
        Grant Likely <grant.likely@arm.com>,
        Jeremy Linton <jeremy.linton@arm.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Russell King - ARM Linux admin <linux@armlinux.org.uk>,
        Cristi Sovaiala <cristian.sovaiala@nxp.com>,
        Florin Laurentiu Chiculita <florinlaurentiu.chiculita@nxp.com>,
        Ioana Ciornei <ioana.ciornei@nxp.com>,
        Madalin Bucur <madalin.bucur@oss.nxp.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Marcin Wojtas <mw@semihalf.com>,
        Pieter Jansen Van Vuuren <pieter.jansenvv@bamboosystems.io>,
        Jon <jon@solid-run.com>,
        Diana Madalina Craciun <diana.craciun@nxp.com>,
        LKML <linux-kernel@vger.kernel.org>,
        netdev <netdev@vger.kernel.org>,
        Laurentiu Tudor <laurentiu.tudor@nxp.com>,
        ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
        "linux.cj" <linux.cj@gmail.com>,
        linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
        Bartosz Golaszewski <bgolaszewski@baylibre.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
        Randy Dunlap <rdunlap@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, Jan 22, 2021 at 8:34 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Wed, Jan 20, 2021 at 9:01 PM Saravana Kannan <saravanak@google.com> wrote:
> >
> > On Wed, Jan 20, 2021 at 11:15 AM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Wed, Jan 20, 2021 at 7:51 PM Andy Shevchenko
> > > <andy.shevchenko@gmail.com> wrote:
> > > >
> > > > On Wed, Jan 20, 2021 at 8:18 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
> > > > > On Tue, Jan 12, 2021 at 7:02 PM Andy Shevchenko
> > > > > <andy.shevchenko@gmail.com> wrote:
> > > > > > On Tue, Jan 12, 2021 at 09:30:31AM -0800, Saravana Kannan wrote:
> > > > > > > On Tue, Jan 12, 2021 at 5:42 AM Calvin Johnson
> > > > > > > <calvin.johnson@oss.nxp.com> wrote:
> > > >
> > > > ...
> > > >
> > > > > > > > +       ret = fwnode_property_read_u32(fwnode, "reg", id);
> > > > > > > > +       if (!(ret && is_acpi_node(fwnode)))
> > > > > > > > +               return ret;
> > > > > > > > +
> > > > > > > > +#ifdef CONFIG_ACPI
> > > > > > > > +       status = acpi_evaluate_integer(ACPI_HANDLE_FWNODE(fwnode),
> > > > > > > > +                                      METHOD_NAME__ADR, NULL, &adr);
> > > > > > > > +       if (ACPI_FAILURE(status))
> > > > > > > > +               return -EINVAL;
> > > > > > > > +       *id = (u32)adr;
> > > > > > > > +#endif
> > > > > > > > +       return 0;
> > > >
> > > > > > > Also ACPI and DT
> > > > > > > aren't mutually exclusive if I'm not mistaken.
> > > > > >
> > > > > > That's why we try 'reg' property for both cases first.
> > > > > >
> > > > > > is_acpi_fwnode() conditional is that what I don't like though.
> > > > >
> > > > > I'm not sure what you mean here, care to elaborate?
> > > >
> > > > I meant is_acpi_node(fwnode) in the conditional.
> > > >
> > > > I think it's redundant and we can simple do something like this:
> > > >
> > > >   if (ret) {
> > > > #ifdef ACPI
> > > >     ...
> > > > #else
> > > >     return ret;
> > > > #endif
> > > >   }
> > > >   return 0;
> > > >
> > > > --
> > >
> > > Right, that should work.  And I'd prefer it too.
> >
> > Rafael,
> >
> > 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.

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.

-Saravana