Re: [RFC][PATCH 0/14] PM / shmobile: Pass power domain information via DT (was: Re: [RFD] PM: Device

["Rafael J. Wysocki" <rjw@sisk.pl>]

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