Messages in this thread | | | Subject | Re: [PATCH v1 1/1] mux: mux-intel-usb: Add Intel USB Multiplexer driver | From | Hans de Goede <> | Date | Wed, 31 May 2017 20:27:28 +0200 |
| |
Hi,
On 31-05-17 17:30, Peter Rosin wrote: > On 2017-05-31 16:18, Hans de Goede wrote: >> Hi, >> >> On 31-05-17 15:05, Peter Rosin wrote: >>> On 2017-05-31 14:21, Hans de Goede wrote: >>>> actually this is the first time I hear about a mux framework >>>> at all. Is there a git tree with the patches for this somewhere ? >>> >>> https://gitlab.com/peda-linux/mux.git in the "mux" branch. >>> >>> Series posted here: >>> https://lkml.org/lkml/2017/5/14/160 >> >> Thank you. >> >> I see that mux_control_get() currently relies on devicetree describing >> the mux, that is not going to work on non devicetree platforms like >> x86 where the relation typically is not described ad all (*) ? > > Yes, I'm aware of this.
Ok, good.
> I wanted to keep things simple. Also, see > my reply on the other branch of this discussion. > > https://lkml.org/lkml/2017/5/31/58 > >> Typically there would be a global list of mux_controls maintained >> by mux_[de]register and then mux_control_get() would walk this list >> until it finds a matching name. The names to register would then be >> passed in by platform data/code when registering and likewise the >> consumer would be passed a unique name to pass into mux_control_get() >> through platform data / code, would that work for you ? >> >> Note one option would be to set the names to use when registering >> a mux chip through device_properties, this is what the power-supply >> subsys is currently doing more or less. > > I had this lose plan to match by the struct device name, but if that > is not working the above seems fine too...
There are 2 problems with using dev_name() :
1) dev_name() will be coupled to the mux_chip and one mux_chip may have multiple controllers (you could add a number postfix to work around this)
2) The caller of mux_control_get() wants a fixed name, where as dev_name is not always fixed, e.g. with mux-chips which communicate via i2c it is something like 7-0064 where 7 is the i2c bus-number which depends on probe ordering and thus may not even be the same every boot.
Regards,
Hans
| |