linux-kernel - [PATCH 0/7] tty: max310x: Simplify the code and fix a few bugs

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: <20190514101415.26754-1-fancer.lancer@gmail.com>
Date:   Tue, 14 May 2019 13:14:08 +0300
From:   Serge Semin <fancer.lancer@...il.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>
Cc:     Serge Semin <Sergey.Semin@...latforms.ru>,
        linux-serial@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: [PATCH 0/7] tty: max310x: Simplify the code and fix a few bugs

I started using this driver two years ago in kernek 4.4 and then in kernel
4.9. It didn't go well from the very beginning due to my platform
peculiarities: DW SPI core with hardware CS and relatively slow MIPS-based
SoC. This patchset is intended to fix some of the problems I found out
during the max310x driver utilization with max14830 device.

First of all it was discovered, that workqueue API isn't optimally used.
Work context isn't re-entrant by design, so the mutex used to guard the
TX-method is redundant. schedule_work() method is also created in a way
the work item is scheduled only if it isn't pending. Patch 1 concerns all
these fixes. Seeing the similar container_of(uart_port) is used three
times in the driver, the patch 2 introduces a macro to_max310x_port() to
get a pointer to corresponding struct max310x_one. This is the code
simplification and is going to be used in the following patches.

It was found out, that batch read and write methods used buffers allocated
on the kernel stack. Since they might be utilized by SPI controllers for
DMA it might be unsafe on some platforms. Patch 3 provides a dedicated
kmalloced buffers for this.

The baud-rate calculator function didn't work correct for all the possible
baud-rates requested within a pre-defined input reference frequency.
Instead an algo fully compliant with datasheet divisor formulae is
implemented in patch 4.

Patches 5 and 6 are created to fix some rs485 issues. Particularly the
rs485 mode is configured on the port startup if it's enabled. And seeing
the mode2 register provides a way to enable/disable the echo-suppression
in RS485 mode, it is used to implement the SER_RS485_RX_DURING_TX flag
support.

Finally it was discovered that in case if inbound hardware FIFO
experienced overflow, a lot of '\0' characters inserted into the
flip-buffer as a character of the RX-FIFO overrun. It isn't quite correct
since the overflow happened only after the last character had been
received. Patch 7 is dedicated to push only a single RX-FIFO overrun
character in this case.

Signed-off-by: Serge Semin <fancer.lancer@...il.com>

Serge Semin (7):
  tty: max310x: Simplify tx-work item code
  tty: max310x: Introduce max310x_one port macro-wrapper
  tty: max310x: Don't pass stacked buffers to SPI
  tty: max310x: Fix invalid baudrate divisors calculator
  tty: max310x: Add rx-during-tx rs485 flag support
  tty: max310x: Optionally enable rs485 on startup
  tty: max310x: Split uart characters insertion loop

 drivers/tty/serial/max310x.c | 157 +++++++++++++++++++++--------------
 1 file changed, 95 insertions(+), 62 deletions(-)

-- 
2.21.0