On Wed, Mar 18, 2015 at 02:23:18PM +0100, Sebastian Hesselbarth wrote: > On 18.03.2015 13:30, Wolfram Sang wrote: > >On Mon, Mar 09, 2015 at 01:21:05PM +0100, Sebastian Hesselbarth wrote: > >>I2C mux pinctrl driver currently determines the number of sub-busses by > >>counting available pinctrl-names. Unfortunately, this requires each > >>incarnation of the devicetree node with different available sub-busses > >>to be rewritten. > >> > >>This patch reworks i2c-mux-pinctrl driver to count the number of > >>available sub-nodes instead. The rework should be compatible to the old > >>way of probing for sub-busses and additionally allows to disable unused > >>sub-busses with standard DT property status = "disabled". > > > >Not sure about this change. With DYNAMIC_OF these days, you can't rely > >that 'disabled' stays disabled all the time. My gut feeling tells me > >that people will want to use this someday. > > Possible. But this change just makes i2c-mux-pinctrl honor status > property at all. There is no functional change except it now allows > you to disable any of the sub-busses. Actually, this is the feature I like. However, I wonder if we shouldn't have that in the core, say in of_i2c_register_devices()? > I agree that this driver still does not cope well with DYNAMIC_OF but > neither did the former implementation. How about we settle this driver > to this implementation now and wait for any maniac that wants to use it > the way you are suggesting above? Sure. I don't want you to make this driver OF_DYNAMIC compatible. I just thought it makes it harder, though, e.g. you allocate memory for the number of active busses not the number of possibilities, so that would have to be reverted by the "maniac". I am still at the glimpse level, but what if we let the mux-pinctrl parse all the data (even for disabled busses), but only the enabled ones will get a muxed adapter because this is handled in of_i2c_register_devices()? > BTW, I have received a patchwork update notification - it may be > unrelated but I prefer the Dove dts/dtsi changes to go through mvebu > tree. Yes, I only take dts patches in rare cases.
Attachment:
signature.asc
Description: Digital signature
