From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.55.52.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 08B7C4644F; Wed, 27 Dec 2023 17:40:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="e+k+3EUT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1703698822; x=1735234822; h=date:from:to:cc:subject:message-id:mime-version; bh=dErD4TBWCprBJyD9UF9opetoam1CYE1CQ+c0zqbUmpA=; b=e+k+3EUTIh1OSz+TZKmTBaiBASQelrwBZROHcJJNE0oJ/Jjv2ezV9IXz lWJI2f2Pblx7PaC5ORa8n8pkXWLS65s94T+oaLpoNjjZW2K3l0i0cJ97k YjFXhjaXLIGcpB8w321T6LXUJ/vMEeUMStyTeEjSCKKZKVOhpEU5GvJv8 36Tk85QBOSbeLQVdw99N6VUHuXrK80Vjo7jh6RCbI0dhO91/K00LaDv29 7xMpWOnRrwFHJGrYi8lFu0uCZaWvqJqznxyz/g3zFtvT19lMOuCQF8XIn 4eGK2RqykIrDw9fZi4E3GBFV5dNBw4EQmMDRBovR4yTPoTTy+291D37ul w==; X-IronPort-AV: E=McAfee;i="6600,9927,10936"; a="395355618" X-IronPort-AV: E=Sophos;i="6.04,309,1695711600"; d="scan'208";a="395355618" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Dec 2023 09:40:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10936"; a="771485823" X-IronPort-AV: E=Sophos;i="6.04,309,1695711600"; d="scan'208";a="771485823" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga007.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Dec 2023 09:40:17 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.97) (envelope-from ) id 1rIXt7-00000009Tfi-1pRq; Wed, 27 Dec 2023 19:40:13 +0200 Date: Wed, 27 Dec 2023 19:40:13 +0200 From: Andy Shevchenko To: Christoph Niedermaier Cc: Lino Sanfilippo , Lukas Wunner , Crescent CY Hsieh , Rasmus Villemoes , Greg Kroah-Hartman , Jiri Slaby , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-serial@vger.kernel.org" , Ilpo =?iso-8859-1?Q?J=E4rvinen?= , "brenda.streiff@ni.com" , Tomas Paukrt Subject: Re: [PATCH 1/2] dt-bindings: serial: rs485: add rs485-mux-gpios binding Message-ID: Precedence: bulk X-Mailing-List: linux-serial@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: 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