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@theobroma-systems.com wrote:
On 03 Mar 2017, at 05:52, Simon Glass sjg@chromium.org wrote: On 22 February 2017 at 13:47, Philipp Tomsich philipp.tomsich@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