How to handle named resources with DT?

[khilman@ti.com (Kevin Hilman)]

Grant Likely <grant.likely@secretlab.ca> writes:

> On Fri, Aug 12, 2011 at 9:09 AM, Cousson, Benoit <b-cousson@ti.com> wrote:
>> On 8/12/2011 4:35 PM, Arnd Bergmann wrote:
 
[...]

>>
>>> I think it's much easier to change the existing users of _byname over
>>> to fixed indexes than to come up with a new scheme that is better.

I disagree.  It's not only about ordering.  More on that below.

>> As you said previously, since we have to support both legacy probing and DT
>> for some time, it will be easier for these drivers to rely on the same API.
>>
>> Considering that adding that new property is not a huge effort anyway and
>> _byname API is a standard API that any driver should be able to use if
>> needed, it still worth adding the DT support for named resources for my
>> point of view.
>
> The assumption being made here is that the current Linux
> implementation detail dictates the binding design, but it does not.
>
> Binding authors should certainly look at the Linux implementation for
> inspiration, but established DT patterns still prevail if they are
> suitable for describing the hardware. In this case the pattern is that
> tuples in the reg property are strongly ordered and specified by the
> driver binding.
>
> So, I remain unconvinced that the 'reg' property binding is
> insufficient.  

If significant, in-tree usages of the feature for platform_devices is
not enough, What are you looking for as convincing arguments? 

> I have no plans to merge support for fetching _byname values from the
> device tree.

I find this an unfortunate position to hold to in this climate of
consolidation.

One of the goals of consolidation is to have core features handled by
core code.  To me this is a classic trade-off.  Either we implement it
in core code, or we force all the users (drivers, in this case) to
implement it themselves.  IMO, consolidation should be pointing us to
solving these kinds of problems in core code, rather than spreading it
across a bunch of drivers (and device code where the data lives.)
Especially so in this case since there are existing, in-tree users
demonstrating the usefulness of _byname.

Not implementing this in core code means all drivers using _byname have
to be converted, adding multiple lines of (IMHO ugly) code when it could
be implemented cleanly by core code, keeping drivers much more readable.
To me, the fact that there would also be an API difference compared to
the existing platform_device probing (which will stay for the forseeable
future) would be a major eye-sore in the drivers.

In addition, converting all the drivers away from _byname is not just a
matter of changing the drivers.  It also means of course you have to
make sure that all of the data is in order.  On OMAP, that means
reworking and/or regenerating all of the hwmod data to ensure it is in
the right order.  Sounds like the kind of churn that would get us
flamed.

But that's not all...

It's not just about data ordering.  As already pointed out, use of
_byname is also used to differentiate between different
versions/capabilities of the IP.  The driver can determine based on the
availability of a named resource the capabilities of the device.
Forcing resource ordering means some other mechanism also has to be
added for detection of the IP version and/or capabilities.

In summary, with the push towards consolidation, we're also trying to
have common drivers that support multiple versions of an IP across
differnet SoCs with varying capabilities.  Having named resources on the
platform_device is an established way of handling this cleanly in the
driver without the driver having to check SoC-specific or IP-version
specific registers.

Kevin