On Thu, Dec 11, 2014 at 12:58:37PM +0000, Mark Brown wrote:
I'd expect someone reading the change in the regulator API to have at least some idea how this fits in with the rest of the API and how to use it, and probably more importantly I'd expect to be able to understand why this is DT only.
Yep.
This is a repetitive problem, and I fully agree with your concern about stuff which is supposed to be arch-independent being designed with only DT in mind.
New core kernel features should *not* be designed with only DT in mind - DT is not the only firmware description language which the kernel supports. Folk need to understand that if they design a new arch independent kernel feature where the sole use case is with DT, that new feature is probably going to get rejected, especially when it's something as generic as resource tracking.
The world is not DT only.
On 12/11/2014 02:43 PM, Russell King - ARM Linux wrote:
On Thu, Dec 11, 2014 at 12:58:37PM +0000, Mark Brown wrote:
I'd expect someone reading the change in the regulator API to have at least some idea how this fits in with the rest of the API and how to use it, and probably more importantly I'd expect to be able to understand why this is DT only.
Yep.
This is a repetitive problem, and I fully agree with your concern about stuff which is supposed to be arch-independent being designed with only DT in mind.
New core kernel features should *not* be designed with only DT in mind - DT is not the only firmware description language which the kernel supports. Folk need to understand that if they design a new arch independent kernel feature where the sole use case is with DT, that new feature is probably going to get rejected, especially when it's something as generic as resource tracking.
The world is not DT only.
OK. I will post next version of patchset with resource/provider lookup left to frameworks (regulators, clock, etc), this way it will be fully firmware agnostic. I will add also better description of the framework.
Regards Andrzej
dri-devel@lists.freedesktop.org