On Mon, Jan 23, 2017 at 11:24:18AM +0100, Peter Rosin wrote: > On 2017-01-22 14:30, Jonathan Cameron wrote: > > On 18/01/17 15:57, Peter Rosin wrote: > >> Allow bindings for a GPIO controlled mux to be specified in the > >> mux consumer node. > >> > >> Signed-off-by: Peter Rosin <peda@xxxxxxxxxx> > > Code is good as far as I am concerned. Only question is whether this > > Hmmm, now that I think some more about it, the code supporting the > simplified binding (patch 12/12) is a bit fishy in one respect. > > A driver that calls mux_control_get and gets a mux_control that happens > to be backed by an implicit mux chip (i.e. using the simplified binding) > will not be able to reverse the resource allocation with less than a > complete destruction of itself. Now, this is likely not a problem in > most cases, but I bet it will creep up at the most inopportune time. And > your remark that I'm the one that has to maintain this makes me dislike > this concept... > > I.e. mux_control_put *should* reverse mux_control_get, but this simply > does not happen for the implicit mux chips, as implicit mux chips are > not put away until the owning device is put away. I think this is because you aren't creating a device in this case. Nodes in DT are not the only way to create devices. Drivers can create a child device when they find mux-gpios property. > Every time I have tried to come up with a way to implement the simplified > bindings I seem to hit one of these subtleties. > > > is worth the hassle given the normal bindings don't give that high > > a burden in complexity! I was going to change my mind here, but we already have "mux-gpios" as a binding at least for i2c-gpio-mux. So really the question is do we want to support that here? > I am missing an ack from Rob though. > > > I don't really care either way:) > > But Rob seems to care, this series just has to find a way to get out of > his too-much-churn-will-look-at-it-later list. I sadly don't know how to > pull that trick... By complaining that I'm putting it off... :) I guess I'm okay with this series in general. I will reply on the specific patches today. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
