Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 8 Mar 2022 14:16:56 +0200 (EET)
From:   =?ISO-8859-15?Q?Ilpo_J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>
To:     Andy Shevchenko <andy.shevchenko@gmail.com>
cc:     Lukas Wunner <lukas@wunner.de>,
        "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Johan Hovold <johan@kernel.org>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Raymond Tan <raymond.tan@intel.com>,
        Heiko Stuebner <heiko@sntech.de>
Subject: Re: [PATCH 1/7] serial: 8250_dwlib: RS485 HW half duplex support
In-Reply-To: <YiZfdlw0A75cojCx@smile.fi.intel.com>
Message-ID: <6931d6ad-7520-b585-a8ba-35349e730bb@linux.intel.com>
References: <20220302095606.14818-1-ilpo.jarvinen@linux.intel.com> <20220302095606.14818-2-ilpo.jarvinen@linux.intel.com> <20220306184857.GA19394@wunner.de> <CAHp75Vdxa_p866t5B7zJ8nHS-v+tu3vLiW0=vaBznnyCGyve_g@mail.gmail.com> <ab82f6a-8d1b-8e89-4ea-77d1a55667d2@linux.intel.com>
 <20220307191854.GA27748@wunner.de> <YiZfdlw0A75cojCx@smile.fi.intel.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="8323329-463480829-1646741577=:1613"
Content-ID: <57315a41-d689-1245-85b2-783950081b7@linux.intel.com>
Precedence: bulk

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.

--8323329-463480829-1646741577=:1613
Content-Type: text/plain; CHARSET=ISO-8859-15
Content-Transfer-Encoding: 8BIT
Content-ID: <43444a8-f88-5b0-5b8e-b22c72a4fc9@linux.intel.com>

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.
--8323329-463480829-1646741577=:1613--