On Tue, Sep 11, 2018 at 8:33 AM Adam Rudziński <adam.rudzinski@xxxxxxxxxx> wrote: > Yes. Actually, keeping control over CTS in IMX requires to keep UART > enabled (bit 0 in UCR1) and the receiver enabled (bit 1 in UCR2). > > Bullseye! There is a short moment on boot when Linux has already > muxed the pin to CTS, but didn't configure the peripheral yet. Yesterday > I've started to prepare a fix, and spent some time trying to understand > what was happening, just to have come to the same conclusion, that > it wouldn't work completely well. > > Here, I would argue that it is fundamentally wrong in Linux. I think > that the correct approach to pinmuxing would be if the driver did that > when probed. Is there available any mechanism preventing Linux > to do the pinmuxing but still starting the driver? This happens because you have a device tree (or similar) defining a "default" state for this device. As has been pointed out by Uwe there is also an "init" state if you want to define a state that happens before probe() but will be different from "default". This might not help you a lot. However its is completely optional to have a "default" state. Nobody is forcing anyone to have a "default" or "init" pin control state. It is perfectly possible to just have states "foo" and "bar" and no other states defined at all, and this gives complete control of when and where (if ever) the driver switches between these states and it will then do so explicitly by looking up and selecting pin control states with: pinctrl_get() pinctrl_lookup_state() pinctrl_select_state() As people were mostly doing the same, we have standard states that will get help from the device core. What you need to do to get rid of this is audit all device trees (etc) and rename the "default" state, to someting else like "foo" and then handle it with code in all drivers that need it. git grep pinctrl_lookup_state will give you some good ideas on what other drivers do. Yours, Linus Walleij
