On Fri, Nov 25, 2016 at 10:24 AM, Peter Rosin <peda@xxxxxxxxxx> wrote: >[Me] >> struct device *gpiod_get_backing_device(struct gpio_desc *d); >> >> Is simple but is it really what you want? > > Well, my first attempt was to simply have a property in the > devicetree stating that the mux was controlled from the same > i2c bus it was muxing, but that was shot down because it > should be possible to deduce this from the implementation (or > something of that meaning, it was a while ago), which to me > meant examining the "struct device"-tree. The problem goes into any subsystem providing resources for a mux in this case, generally for example it is not OK for a device to runtime suspend or shut down its regulator or turn off its clock if it is acting as a mux. GPIO and pin control just happens to be two resource in this specific case. > For the gpio_desc it is easy. However, it is worse for the > pinctrl case. It is annoying to do this in a sense, because it starts to kill the abstraction we have created exactly in order to avoid consumers having to worry much about their providers internals. No we are opening the can and letting the stuff out all over the place. Have you looked into the discussion about device dependencies in general? Isn't this problem mappable as a subset of that? This was discussed at length at the last kernel summit: https://lwn.net/Articles/705852/ See especially Rafael's commit 9ed9895370aedd6032af2a9181c62c394d08223b to driver core in linux-next Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
