Hi, On 20 March 2017 at 01:08, Maxime Ripard <maxime.rip...@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.toms...@theobroma-systems.com> wrote: >> > Hi Simon, >> > >> > On 03 Mar 2017, at 05:52, Simon Glass <s...@chromium.org> wrote: >> > >> > Hi Philipp, >> > >> > On 22 February 2017 at 13:47, Philipp Tomsich >> > <philipp.toms...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot