On Fri, Sep 22, 2017 at 8:02 PM, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > On Fri, Sep 22, 2017 at 03:23:05PM +0200, Linus Walleij wrote: >> On Thu, Sep 21, 2017 at 8:28 AM, Uwe Kleine-König >> <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: >> >> > on an i.MX25 machine on my desk a UART RX line is guarded by a transistor >> > like this: >> > >> > ,------------------------. >> > | ,---------. | >> > | | imx25 o--RX----◁---o--- >> > | | o--GPIO--' | >> > | `---------' | >> > `------------------------' >> >> This is inside the SoC, right, not outside it? >> >> In the rest of my answer I assume this. > > No, that's on the board. So your reply unfortunately doesn't match the > problem :-| OK sorry for my stupid and pointless assumption about this being inside the SoC, I should ask before I talk. >> If this is on the board, using enable-gpios is proper. > > enable-gpios as I suggested below that is? If so I assume you will be > open for a generic approach to implement this? So the enable-gpios as part of the pin control state like below: >> > My first idea was to make this a property of the UART and added a >> > enable-gpios property for it[1]. But now I wonder if this is better >> > abstracted as an enable-gpios property in the pinctrl node. Something >> > like: >> > >> > pinctrl_uart5: uart5 { >> > fsl,pins = < >> > MX25_PAD_ECB__UART5_TXD 0x00002080 /* TXD */ >> > MX25_PAD_LBA__UART5_RXD 0x00000000 /* RXD */ >> > MX25_PAD_CS4__UART5_CTS 0x00002001 /* RTS */ >> > MX25_PAD_CS5__GPIO_3_21 0x00002001 /* #RXD_EN */ >> > >; >> > enable-gpios = <&gpio3 21 GPIO_ACTIVE_LOW>; >> > }; >> > >> > Would this make sense? Maybe with a more intuitive name? I would nominally make it part of the UART node and picked up by the UART driver. Unless there is compelling reasons to believe that this is something we will see a lot and not a particular oddity. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html