On Wed, Aug 30, 2017 at 6:24 PM, jmondi <jacopo@xxxxxxxxxx> wrote: > On Wed, Aug 30, 2017 at 04:32:55PM +0200, Thomas Petazzoni wrote: >> On Wed, 30 Aug 2017 09:22:55 -0500, Timur Tabi wrote: >> > No, that's it. The question is, what exactly should the 'request' >> > function do? Should it be modifying the hardware to satisfy the >> > request? When I wrote my patch, I assumed that it wouldn't. I thought >> > that request simply answered the question, "can I touch this GPIO"? >> >> No, it also muxes the pin in GPIO, and you can see the "reference" >> implementation pinctrl-single also does it. >> >> Let's see what Linus W. has to say about the semantic of the "request" >> operation. >> >> But if we change the semantic of "request" to no longer mux the hardware >> as GPIO, then you will also have regressions, because there are plenty >> of GPIOs that are requested, but not explicitly muxed as GPIOs in the >> DT, precisely because today requesting a GPIO is sufficient to have it >> re-muxed as GPIO at the pinctrl level. > > Just to point out one of Renesas' pin controller devices seems to > suffer from the same problem, introduced by Timur's commit > > https://www.spinics.net/lists/linux-renesas-soc/msg17647.html > > This is indeed caused by the "request" introduced by the above said > commit, that in rza1 pincontroller, actually muxes the requested > pin as GPIO. To clarify: which causes havoc if that pin is used as e.g. an SDRAM address line. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- 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