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-...@vger.kernel.org
> > > Cc: Ivan Kokshaysky <i...@jurassic.park.msu.ru>
> > > Cc: Matt Turner <matts...@gmail.com>
> > > Cc: linux-al...@vger.kernel.org
> > > Cc: Thomas Bogendoerfer <tsbog...@alpha.franken.de>
> > > Cc: linux-m...@vger.kernel.org
> > > Cc: "James E.J. Bottomley" <james.bottom...@hansenpartnership.com>
> > > Cc: Helge Deller <del...@gmx.de>
> > > Cc: linux-par...@vger.kernel.org
> > > Cc: Michael Ellerman <m...@ellerman.id.au>
> > > Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org>
> > > Cc: Paul Mackerras <pau...@samba.org>
> > > Cc: linuxppc-dev@lists.ozlabs.org
> > > Cc: "David S. Miller" <da...@davemloft.net>
> > > Cc: sparcli...@vger.kernel.org
> > > Cc: Arnd Bergmann <a...@arndb.de>
> > > Cc: linux-a...@vger.kernel.org
> > > Cc: linux-...@vger.kernel.org
> > > Signed-off-by: Ilpo Järvinen <ilpo.jarvi...@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?
> > > diff --git a/drivers/char/pcmcia/synclink_cs.c
> > > b/drivers/char/pcmcia/synclink_cs.c
> > > index 78baba55a8b5..d179b9b57a25 100644
> > > --- a/drivers/char/pcmcia/synclink_cs.c
> > > +++ b/drivers/char/pcmcia/synclink_cs.c
> > > @@ -2287,6 +2287,8 @@ static void mgslpc_set_termios(struct tty_struct
> > > *tty, struct ktermios *old_term
> > > == RELEVANT_IFLAG(old_termios->c_iflag)))
> > > return;
> > >
> > > + tty->termios.c_cflag &= ~ADDRB;
> >
> > Having to do this for all drivers feels wrong. It isn't needed for any
> > other flag, right?
>
> My understanding is that it would be needed for other flags too, it's just
> that many drivers probably haven't cared enough. Some drivers certainly
> clear a few flags they don't support while others don't clear any but
> it's also challenging to determine it which flags which driver supports.
> How bad the impact is per flag varies.
>
> > That makes me really not like this change as it
> > feels very ackward and
> > yet-another-thing-a-serial-driver-has-to-remember.
>
> It would be nice to have some mask for supported bits per driver. But it
> will be challenging to add at this point and I'm far from sure I could get
> them right per driver even if carefully trying to.
>
> > And as you are wanting to pass this bit to userspace, where is that
> > documented?
>
> Ah, I probably should add it to driver-api/serial/driver.rst too but ADDRB
> is certainly mentioned alongside with other addressing mode documentation
> I wrote for the later changes in this series.
--
i.
