On Friday, October 03, 2014 10:59:10 AM Dmitry Torokhov wrote: > 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. Well stated, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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
