On Fri, Oct 03, 2014 at 02:43:03PM +0100, Mark Rutland wrote: > Hi Rafael, > > On Wed, Oct 01, 2014 at 03:10:40AM +0100, Rafael J. Wysocki wrote: > > From: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> > > > > We have lots of existing Device Tree enabled drivers and allocating > > separate _HID for each is not feasible. Instead we allocate special > > _HID "PRP0001" that means that the match should be done using Device > > Tree compatible property using driver's .of_match_table instead. > > That's hopefully not the precise meaning of "PRP0001" unless we're > attempting no semblance of OS independence here? > > I'm still of the opinion that marrying ACPI to existing (and often > ill-defined) DT bindings is a bad idea. While it's expedient, I believe > this is going to be a long-term maintenance nightmare. > > I'm very concerned with the prospect of model mismatch between the two > (e.g. DT clocks properties where ACPI has traditionally been in charge > of clock management). I've not seen any high-level guidelines w.r.t. > what should live in _DSD properties and what should not (at least not in > the ACPI spec itself). There are almost certainly properties that only > make sense if !ACPI, and likely there will be some that only make sense > if ACPI. > > So I think that in its current level of standardisation, _DSD only makes > sense for simple device properties, and not relationships between > devices, except where ACPI already has some kind of a model (which > currently seems to cover interrupts and GPIOs). I'd also hope that we > could expose a 'clean' subset of DT bidnings (i.e. those which aren't > known to be kept around only for compatibility with legacy DTBs). > > I do not believe it makes sense to share such a low-level interface. > Given the aforementioned model differences, and the fact that we don't > need to support _every_ device tree binding, I don't see why this can't > be handled with separate probe paths in the drivers we care about (as we > already do for DT vs platform data). Because as a driver writer I do not want to implement N+1 ways of getting device configuration. I want one API that works independently of the underlying platform. The DT vs platform data is bad enough already. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
