On Tuesday, July 24, 2012, Rafael J. Wysocki wrote: > On Tuesday, July 24, 2012, Arnd Bergmann wrote: > > On Tuesday 24 July 2012, Rafael J. Wysocki wrote: > > > On Tuesday, July 24, 2012, Arnd Bergmann wrote: > > > > On Saturday 21 July 2012, Rafael J. Wysocki wrote: > > > > > > > > > > Sorry for taking so long to reply. I am really not that familiar with > > > > the > > > > power domain requirements, but I do have two comments on your approach: > > > > > > > > * I think when we want to add a generic concept to the device tree such > > > > as power domains, we should always make it specified in a generic way. > > > > > > Do we really want that? I'm a bit skeptical, because apparently nobody > > > cares, as the (zero) response to this patchset evidently indicates and > > > since nobody cares, it's probably better not to add such "generic" things > > > just yet. > > > > Well, the trouble with bindings is that they are much harder to change > > later, at least in incompatible ways. > > Hmm, so I think you wanted to say that it might be burdensome to retain the > code handling the old binding once we had started to use a new generic one. > > I can agree with that, but that's quite similar to user space interfaces. > Once we've exposed a user space interface of some kind and someone starts > to use it, we'll have to maintain it going forward for the user in question. > However, there is a way to deprecate old user space interfaces and it has > happened. > > In this particular case the burden would be on Renesas, but I don't think it > would affect anybody else.
Whereas, if we go for a generic binding and get it wrong (which is quite likely, given the general lack of information on what the needs are), we'll have a much bigger problem that _will_ affect everyone. So, my opinion is to go for vendor-specific attributes of limited scope for now, that will be relatively easy to deprecate in the future. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/