Re: [PATCH 0/2 v3] Add pl031 RTC support for Hi6220

[Arnd Bergmann]

On Wednesday, July 6, 2016 5:58:14 PM CEST John Stultz wrote:
> On Wed, Jul 6, 2016 at 12:38 AM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Wednesday, July 6, 2016 12:20:15 AM CEST John Stultz wrote:
> >> On Wed, Jul 6, 2016 at 12:04 AM, Olof Johansson <olof@xxxxxxxxx> wrote:
> >> > On Tue, Jul 5, 2016 at 11:55 PM, John Stultz <john.stultz@xxxxxxxxxx> wrote:
> 
> Though this seemingly goes against the otherwise widely recommended
> approach of breaking up patches into small obvious chunks.
> 
> And personally, and I don't mean to criticize, but the suggestions
> here (use numerical values, then later rename to macros; add
> everything in one go, then make dts changes a release later) all seem
> like non-optimal workarounds for the fact that adding almost any
> functionality requires cross subsystem-maintainer negotiations (or two
> release steps to get one bit of functionality merged).
> 
> It seems like it might even just be clearer to make the
> two-release-steps method the widely broadcast rule (ie: no
> dependencies on in-flight patches for dts changes), so this doesn't
> confuse/dismay new developers.
> 
> Anyway... In this case, I don't have the clk documentation, so I'll
> ping Zhangfei to check if there is any other clock values that should
> be added in the future, but at least for HiKey, while there are still
> a few clk patches remaining in the tree, I don't have any more
> additions to the clk list.

I think the main underlying problem is hardware that is so badly
structured that there is no way to describe it other than to enumerate
each output in a header file and have a separate handler in the driver
for it.

We typically have it easier for other subsystems like irqchip or gpio
where nobody would consider writing a driver that can only handle
the I/O lines that are used on their board with a minimal set of
drivers, but for some reason it seems acceptable to do it for clock
controllers just because they are harder to describe.

For the common case where the driver developer actually has a
description of the clock controller hardware in a manual, I see
no reason not to implement the complete driver right away.

	Arnd