linux-kernel - [PATCH 0/5] serial, Malta: Fixes to magic multipliers for SMSC Super I/O UARTs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.2105181800170.3032@angie.orcam.me.uk>
Date:   Thu, 10 Jun 2021 20:38:22 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>
cc:     linux-mips@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: [PATCH 0/5] serial, Malta: Fixes to magic multipliers for SMSC Super
 I/O UARTs

Hi,

 I've noticed our Malta platform serial driver does not take advantage of 
support for the special UART divisor values for the bit rates of 230400 
and 460800 bits per second its SMSC FDC37M817 Super I/O hardware provides.  

 Our 8250 core provides for these divisors via the UPF_MAGIC_MULTIPLIER 
flag, so I thought it would be a straightforward platform change, but it 
has turned out that the flag has AFAICT never worked (I wonder how people 
test those things).  The only platform currently in our tree that sets the 
flag uses it for a different purpose.

 I've fixed UPF_MAGIC_MULTIPLIER handling then in our 8250 core, added 
reporting so that people have a chance to know the rates are supported and 
then added the flag to Malta platform initialisers for Super I/O UARTs.  
I have examined YAMON sources to verify that we don't have to enable the 
special UART divisor values ourselves.  See individual change descriptions 
for further details.

 Verified with a WTI CPM-800 site manager device which supports bit rates 
of up to 230400bps.  Also verified at 230400bps and 460800bps with an 
EXSYS EX-44072 option card under Linux, based on the Oxford Semiconductor 
OXPCIe952 device in its native mode; our clock settings are however off 
enough for OxSemi PCIe devices for the former data rate only just working 
and the latter making transmission go out of sync with data corruption 
resulting.  Another patch series to fix OxSemi handling bugs follows then.

 Verification of the OxSemi patch series actually revealed an interesting 
peculiarity of the SMSC Super I/O IC that contradicts SMSC documentation.  
I have added a clarification as 1/5 of this patch series, originally meant 
to contain four patches only.  This has been confirmed both with the Malta 
board concerned here and my old x86 server, which also has a similar SMSC 
Super I/O part, although with high-speed operation not enabled by the 
BIOS.

 NB occasional input overruns were observed at 460800bps (with a MIPS 5Kc 
@160MHz running this Malta), which could be eliminated by lowering the 
`rx_trig_bytes' parameter to 4 from the default of 8 (the UART core in the 
FDC37M817 has a 16-byte FIFO), via sysfs.  Perhaps it would make sense to 
change the default, at least for the higher-speed ports?

 Please apply.

  Maciej