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.toms...@theobroma-systems.com> wrote: > > On 03 Mar 2017, at 05:52, Simon Glass <s...@chromium.org> wrote: > > 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. > > 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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
