On Fri, Jan 22, 2021 at 1:05 PM Andy Shevchenko <andy.shevchenko@xxxxxxxxx> wrote: > > On Fri, Jan 22, 2021 at 10:59 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > On Fri, Jan 22, 2021 at 8:34 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > On Wed, Jan 20, 2021 at 9:01 PM Saravana Kannan <saravanak@xxxxxxxxxx> wrote: > > > > On Wed, Jan 20, 2021 at 11:15 AM Rafael J. Wysocki <rafael@xxxxxxxxxx> 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? What are you even talking about? How is whatever you are saying remotely related to getting an "id" for a fwnode? > I don't think it's a good idea. You see, here we have different > layering POD types, POD? > 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. > -Saravana
