On Mon, 7 Mar 2022, Andy Shevchenko wrote: > 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)? The SoC also has a pin to select between RS485 and RS232. With a combo transceiver, TCR-based heuristic just runs into the same problems as the version-based one did. -- i.
