[U-Boot] [PATCH v2 2/6] dm: core: Allow multiple drivers to bind for a single node

[Heiko Stübner]

Hi Simon,

Am Sonntag, 12. März 2017, 14:21:35 CET schrieb Simon Glass:
> On 3 March 2017 at 03:52, Dr. Philipp Tomsich
> <philipp.tomsich at theobroma-systems.com> wrote:
> > On 03 Mar 2017, at 05:52, Simon Glass <sjg at chromium.org> wrote:
> > On 22 February 2017 at 13:47, Philipp Tomsich
> > <philipp.tomsich at theobroma-systems.com> wrote:
> > 
> > Currently, driver binding stops once it encounters the first
> > compatible driver that doesn't refuse to bind. However, there are
> > cases where a single node will need to be handled by multiple driver
> > classes. For those cases we provide a configurable option to continue
> > to bind after the first driver has been found.
> > 
> > The first use cases for this are from the DM conversion of the sunxi
> > (Allwinner) architecture:
> > * pinctrl (UCLASS_PINCTRL) and gpio (UCLASS_GPIO) drivers need to
> > 
> >   bind against a single node
> > 
> > * clock (UCLASS_CLK) and reset (UCLASS_RESET) drivers also need to
> > 
> >   bind against a single node
> > 
> > Does linux work this way? Another approach would be to have a separate
> > MISC driver with two children, one pinctrl, one clk.
> > 
> > 
> > The linux CLK driver creates and registers a reset-controller; the PINCTRL
> > driver
> > does the same with the gpio-controller. Similar code to do this is easily
> > possible in
> > U-Boot … see sunxi_pctrl_bind_gpio(…) in [PATCH v2 1/6] of this series.
> > 
> > However, binding multiple times makes for much simpler code and allows to
> > keep
> > driver data in separate drivers.
> 
> My question was more whether Linux registers multiple drivers with one
> device node. It's just not something I expected.
> 
> I'm not really convinced on this. It will break the current one-to-one
> relationship, and functions like device_get_child_by_of_offset(). I
> think it would be better to have a MISC driver with two children.

In the regular device model the Linux kernel also generally has a one-to-one 
model. There are special cases, like clock and timer init using special 
handling, or things like "syscon" which acts like more of a flag and can live 
next to a regular device.

Therefore things like the Rockchip clock controller create the reset 
controller included in the CRU block. A behaviour the uboot clk driver mimics.

Also doesn't allowing multiple drivers to sit on top of a node create 
contention on who gets access to registers? At least in the kernel multiple 
mappings of registers are generally not favoured.


Heiko