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

[Simon Glass]

Hi,

On 20 March 2017 at 01:08, Maxime Ripard
<maxime.ripard at free-electrons.com> wrote:
> On Sun, Mar 12, 2017 at 02:21:35PM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 3 March 2017 at 03:52, Dr. Philipp Tomsich
>> <philipp.tomsich at theobroma-systems.com> wrote:
>> > Hi Simon,
>> >
>> > On 03 Mar 2017, at 05:52, Simon Glass <sjg at chromium.org> wrote:
>> >
>> > Hi Philipp,
>> >
>> > 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.
>
> It does, but it's not really what we're doing in the linux driver. It
> has one driver, with one device, but registering into multiple
> frameworks.

I believe that the U-Boot equivalent of this is to have a parent
device with several children each in its own uclass.

Regards,
Simon