On Mon, Mar 07, 2022 at 08:18:54PM +0100, Lukas Wunner wrote: > On Mon, Mar 07, 2022 at 11:19:59AM +0200, Ilpo Järvinen wrote: > > On Mon, 7 Mar 2022, Andy Shevchenko wrote: ... > That's for DT platforms, but I suppose you've got ACPI. Not sure > how it's handled there, the ACPI 6.4 spec contains a "UART Serial Bus > Connection Resource Descriptor" but nothing on RS-485, so I guess > the only option is to use regular DT properties in a _DSD object? Which make me think that this series needs an additional patch to describe RS485 enumeration for ACPI case (somewhere in Documentation/firmware-guide/acpi/enumeration.rst IIRC the filename). ... > > I initially had additional version check here while developing this > > patch series but it seemed to not provide any added value due those > > other factors that need to be considered. > > Here's another idea: > > Read TCR register on ->probe. It's POR value is 0x6 if RS-485 is > supported by the chip, else 0x0. (Page 220 of the 4.01a spec says > UCV register does not exist if additional features are not implemented > and reading from this register address returns 0, I suppose the same > applies to TCR if RS-485 is not implemented.) > > Since the driver may change the polarity in the TCR register, be sure > to write 0x6 to it on ->remove so that you can still correctly detect > presence of the RS-485 feature after unbind/rebind of the driver. What to do in the case when DE pin is muxed to RTS and locked in pin control IP by firmware (no possibility to change the muxing in the OS)? -- With Best Regards, Andy Shevchenko
