[PATCH v5 05/10] serial: termbits: ADDRB to indicate 9th bit addressing mode

Greg KH gregkh at linuxfoundation.org
Wed Apr 27 00:10:26 AEST 2022


On Tue, Apr 26, 2022 at 05:01:31PM +0300, Ilpo Järvinen wrote:
> One additional thing below I missed on the first read.
> 
> On Tue, 26 Apr 2022, Ilpo Järvinen wrote:
> > On Tue, 26 Apr 2022, Greg KH wrote:
> > 
> > > On Tue, Apr 26, 2022 at 03:24:43PM +0300, Ilpo Järvinen wrote:
> > > > Add ADDRB to termbits to indicate 9th bit addressing mode. This change
> > > > is necessary for supporting devices with RS485 multipoint addressing
> > > > [*]. A later patch in the patch series adds support for Synopsys
> > > > Designware UART capable for 9th bit addressing mode. In this mode, 9th
> > > > bit is used to indicate an address (byte) within the communication
> > > > line. The 9th bit addressing mode is selected using ADDRB introduced by
> > > > an earlier patch.
> > > > 
> > > > [*] Technically, RS485 is just an electronic spec and does not itself
> > > > specify the 9th bit addressing mode but 9th bit seems at least
> > > > "semi-standard" way to do addressing with RS485.
> > > > 
> > > > Cc: linux-api at vger.kernel.org
> > > > Cc: Ivan Kokshaysky <ink at jurassic.park.msu.ru>
> > > > Cc: Matt Turner <mattst88 at gmail.com>
> > > > Cc: linux-alpha at vger.kernel.org
> > > > Cc: Thomas Bogendoerfer <tsbogend at alpha.franken.de>
> > > > Cc: linux-mips at vger.kernel.org
> > > > Cc: "James E.J. Bottomley" <James.Bottomley at HansenPartnership.com>
> > > > Cc: Helge Deller <deller at gmx.de>
> > > > Cc: linux-parisc at vger.kernel.org
> > > > Cc: Michael Ellerman <mpe at ellerman.id.au>
> > > > Cc: Benjamin Herrenschmidt <benh at kernel.crashing.org>
> > > > Cc: Paul Mackerras <paulus at samba.org>
> > > > Cc: linuxppc-dev at lists.ozlabs.org
> > > > Cc: "David S. Miller" <davem at davemloft.net>
> > > > Cc: sparclinux at vger.kernel.org
> > > > Cc: Arnd Bergmann <arnd at arndb.de>
> > > > Cc: linux-arch at vger.kernel.org
> > > > Cc: linux-usb at vger.kernel.org
> > > > Signed-off-by: Ilpo Järvinen <ilpo.jarvinen at linux.intel.com>
> > > > ---
> 
> > > >  #define CMSPAR    010000000000          /* mark or space (stick) parity */
> > > >  #define CRTSCTS   020000000000          /* flow control */
> > > >  
> > > > diff --git a/arch/powerpc/include/uapi/asm/termbits.h b/arch/powerpc/include/uapi/asm/termbits.h
> > > > index ed18bc61f63d..c6a033732f39 100644
> > > > --- a/arch/powerpc/include/uapi/asm/termbits.h
> > > > +++ b/arch/powerpc/include/uapi/asm/termbits.h
> > > > @@ -171,6 +171,7 @@ struct ktermios {
> > > >  #define HUPCL	00040000
> > > >  
> > > >  #define CLOCAL	00100000
> > > > +#define ADDRB	004000000000		/* address bit */
> > > >  #define CMSPAR	  010000000000		/* mark or space (stick) parity */
> > > >  #define CRTSCTS	  020000000000		/* flow control */
> > > >  
> > > > diff --git a/arch/sparc/include/uapi/asm/termbits.h b/arch/sparc/include/uapi/asm/termbits.h
> > > > index ce5ad5d0f105..5eb1d547b5c4 100644
> > > > --- a/arch/sparc/include/uapi/asm/termbits.h
> > > > +++ b/arch/sparc/include/uapi/asm/termbits.h
> > > > @@ -201,6 +201,7 @@ struct ktermios {
> > > >  #define B3500000  0x00001012
> > > >  #define B4000000  0x00001013  */
> > > >  #define CIBAUD	  0x100f0000  /* input baud rate (not used) */
> > > > +#define ADDRB	  0x20000000  /* address bit */
> > > >  #define CMSPAR	  0x40000000  /* mark or space (stick) parity */
> > > >  #define CRTSCTS	  0x80000000  /* flow control */
> > > 
> > > Why all the different values?  Can't we pick one and use it for all
> > > arches?  Having these be different in different arches and userspace
> > > should not be a thing for new fields, right?
> 
> ADDRB value is the same for all archs (it's just this octal vs hex 
> notation I've followed as per the nearby defines within the same file
> which makes them look different).
> 
> Should I perhaps add to my cleanup list conversion of all those octal ones 
> to hex?

Argh, yes, please, let's do that now, I totally missed that.  Will let
us see how to unify them as well.

thanks,

greg k-h


More information about the Linuxppc-dev mailing list