How to handle named resources with DT?

[balbi@ti.com (Felipe Balbi)]

Hi,

On Wed, Aug 24, 2011 at 12:15:03PM -0700, Kevin Hilman wrote:
> 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.

on top of all that, for IPs which are used on many SoCs (such as MUSB)
it's quite silly to force all users to provide resources in a certain
order. It sounds to me that this will be prone to error in many ways
until everything is synced up and on the correct order.

Ditching _byname is a very bad idea.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110825/59dcac69/attachment.sig>