On 2016-09-27 21:14, Viresh Kumar wrote: > On 27-09-16, 20:38, Stefan Agner wrote: >> The i.MX I2C driver touches the pinctrl in its prepare/unprepare >> callbacks. >> >> So, on a i.MX or Vybrid, the call chain looks like this: >> >> i2c_generic_gpio_recovery >> -> i2c_get_gpios_for_recovery >> -> gpio_request_one >> -> i2c_generic_recovery >> -> prepare_recovery (i2c_imx_prepare_recovery) >> -> pinctrl_select_state [gpio] > > Why is this done here? And not in gpio_request_one? > You need to differentiate between Vybrid and i.MX: Vybrid muxes a pin to GPIO on gpio_request_one (via .gpio_request_enable callback) i.MX does not mux a pin as GPIO on its own, but needs to be muxed explicitly. That has been always the case... I don't know what behavior is right, it is just "different"... In Vybrid I did it that way because I knew that was the behavior of another SoC I worked on (namely a Tegra)... And I had to touch the pinctrl register anyway (using gpio_set_direction, to set the direction). I guess in the end it boils down to one question: Is the GPIO and pinctrl API ment to be orthogonal? If so, then we probably should select the GPIO via pinctrl in the i.MX I2C driver but mux the pin in gpio_request_one similar as we do it on Vybrid... But that would be rather invasive change... @Shawn, Linus Walleij, others, what is your take on that? >> -> unprepare_recovery (i2c_imx_unprepare_recovery) >> -> pinctrl_select_state [default] >> -> i2c_put_gpios_for_recovery >> -> gpio_free Currently free does not restore the last pinmux, so if the API's are meant to be completely orthogonal we need to store the pinmux in gpio_request_one so we can restore it in gpio_free. -- Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html