Re: [PATCH 01/11] mfd: add the Berlin controller driver

From: Arnd Bergmann
Date: Wed Feb 18 2015 - 11:16:04 EST

On Wednesday 18 February 2015 16:59:42 Sebastian Hesselbarth wrote:
> > The alternative is to come up with a way to probe all the child
> > devices automatically, but then we should make that parent device
> > have a generic driver that does not need to know about the children
> > and that can work on any platform with similar requirements.
> Ok, this is most likely the part that Lee doesn't like on the current
> driver: a platform_device for registering platform_devices *only* and
> only for Berlin.
> So, out of the two options:
> (a) Go for syscon_of_populate_devices() with a new compatible (I guess)
> and having sub-nodes for each Linux subsystem that we want to have
> a platform_device for. I fear that this will clash with early
> registration of clk and we still have to find a way, i.e. device
> naming policy, to match the drivers with their devices.

I don't see the problem with early clk registration, AFAICT it should
just work as expected, you just end up with an extra platform_device
for the clocks that does not get bound to a driver later because the
device node is already in use by the clock driver.

> (b) Join clk, pinctrl, reset into a single chip/soc-control node and
> rewrite the sub-drivers to not directly rely on DT compatible.
> With this, joining all sub-drivers into drivers/soc/berlin would
> be a sane approach, right? Also, I have the strong feeling, that
> we will encounter situations later that will require the clk driver
> to pull a reset before changing a specific clk rate, e.g. for GPU.

If we do this, I think it should be a single driver as well, without
subdrivers. We should probably just do this if there is a small number
of subsystems to bind to, so the driver doesn't get out of hand.

This driver could live in drivers/soc then.

If you want to have subdrivers after all, that would be a classic
MFD and should live in drivers/mfd. The binding would be the same
for both approaches.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at