Received-SPF: pass (google.com: domain of linux-kernel+bounces-12183-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Wed, 27 Dec 2023 19:40:13 +0200
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Christoph Niedermaier <cniedermaier@dh-electronics.com>
Cc: Lino Sanfilippo <LinoSanfilippo@gmx.de>, Lukas Wunner <lukas@wunner.de>,
	Crescent CY Hsieh <crescentcy.hsieh@moxa.com>,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jirislaby@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
	Ilpo =?iso-8859-1?Q?J=E4rvinen?= <ilpo.jarvinen@linux.intel.com>,
	"brenda.streiff@ni.com" <brenda.streiff@ni.com>,
	Tomas Paukrt <tomaspaukrt@email.cz>
Subject: Re: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios
 binding
Message-ID: <ZYxhfVxv6xb4LF7C@smile.fi.intel.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

On Sun, Dec 24, 2023 at 10:11:17AM +0000, Christoph Niedermaier wrote:
> From: Lino Sanfilippo [mailto:LinoSanfilippo@gmx.de]
> Sent: Saturday, December 23, 2023 2:41 PM
> > On 23.12.23 13:49, Christoph Niedermaier wrote:
> >> From: Lukas Wunner [mailto:lukas@wunner.de]
> >> Sent: Thursday, December 21, 2023 4:53 PM
> >>> On Thu, Dec 14, 2023 at 01:41:47PM +0000, Christoph Niedermaier wrote:
> >>>> I will summarize the current situation from my point of view, maybe it helps:
> >>>>
> >>>> RS-232:
> >>>>   - Full Duplex Point-to-Point connection
> >>>>   - No transceiver control with RTS
> >>>>   - No termination
> >>>>   - No extra struct in use
> >>>>
> >>>> RS-422:
> >>>>   - Full Duplex Point-to-Point connection
> >>>>   - No transceiver control with RTS needed
> >>>>   - Termination possible
> >>>>   - Extra struct serial_rs485 needed if termination is used
> >>>>  => RS-422 can be used in RS-232 operation, but if a termination should be
> >>>>     switchable the RS485 flag has to be enabled. But then also transceiver
> >>>>     control will be enabled. Not a very satisfying situation.
> >>>
> >>> Well why don't we just allow enabling or disabling RS-485 termination
> >>> independently from the SER_RS485_ENABLED bit in struct serial_rs485?
> >>>
> >>> Just let the user issue a TIOCSRS485 ioctl to toggle termination even
> >>> if in RS-232 mode and use that mode for RS-422.
> >>>
> >>> Looks like the simplest solution to me.
> >>
> >> Sounds not bad. The termination should only depend on whether the GPIO is
> >> given or not.
> >>
> >> Irrespective of this, I think the Linos idea of an RS-422 mode is not bad.
> >> This allows you to take care of special features that were previously
> >> overlooked. For example, hardware flow control can be switched off so that
> >> this does not cause any problems.
> >>
> > 
> > Also note, that RS232 and RS422 may NOT always be the same from driver perspective.
> > Take a look at 8250_excar.c for example. That driver has to configure the hardware
> > accordingly when switching from RS232 to RS422 (see iot2040_rs485_config()).
> > 
> > While a SER_RS485_MODE_RS422 flag set by userspace could work to switch to RS422, I
> > still think that the cleanest solution would be another ioctl TIOCSRS422 with a
> > parameter like
> > 
> > struct serial_rs422 {
> >        __u32   flags;
> > #define SER_RS422_ENABLED              (1 << 0)
> > #define SER_RS422_TERMINATE_BUS        (1 << 1)
> >         __u32   padding[7]
> > };
> > 
> > The SER_RS485_MODE_RS422 flag could still be used internally as a hint to the driver.
> > That solution would also be expandable if needed. I planned to send a patch that
> > implements this
> > as a RFC to the mailing list (maybe in the next few days).
> 
> Having your own ioctl is a nice distinction, but when I think about it for a moment,
> questions come to mind:
> 
> From userspace perspective then there are two termination flags
> SER_RS485_TERMINATE_BUS and SER_RS422_TERMINATE_BUS?
> How will they interact internally?
> 
> What about the devicetree property?
> Will there be rs422-term-gpios as well?
> 
> Could the user enable RS422 and RS485 at the same time?

Exactly, if you are going for this, just make a new entry into union, and
use flags for that. So, you probably will have the same IOCTL, but which
will serve RS422/RS385 purposes excluding odds of the use of the pieces.

-- 
With Best Regards,
Andy Shevchenko