LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Serge Semin <fancer.lancer@gmail.com>
Cc: Jiri Slaby <jslaby@suse.com>,
	Serge Semin <Sergey.Semin@t-platforms.ru>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/7] tty: max310x: Simplify the code and fix a few bugs
Date: Tue, 21 May 2019 12:17:01 +0200	[thread overview]
Message-ID: <20190521101701.GA31141@kroah.com> (raw)
In-Reply-To: <20190514101415.26754-1-fancer.lancer@gmail.com>

On Tue, May 14, 2019 at 01:14:08PM +0300, Serge Semin wrote:
> 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@gmail.com>

Nice cleanups, all now applied, thanks!

greg k-h

      parent reply	other threads:[~2019-05-21 10:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-14 10:14 Serge Semin
2019-05-14 10:14 ` [PATCH 1/7] tty: max310x: Simplify tx-work item code Serge Semin
2019-05-14 10:14 ` [PATCH 2/7] tty: max310x: Introduce max310x_one port macro-wrapper Serge Semin
2019-05-14 10:14 ` [PATCH 3/7] tty: max310x: Don't pass stacked buffers to SPI Serge Semin
2019-05-14 10:14 ` [PATCH 4/7] tty: max310x: Fix invalid baudrate divisors calculator Serge Semin
2019-05-14 10:14 ` [PATCH 5/7] tty: max310x: Add rx-during-tx rs485 flag support Serge Semin
2019-05-14 10:14 ` [PATCH 6/7] tty: max310x: Optionally enable rs485 on startup Serge Semin
2019-05-14 10:14 ` [PATCH 7/7] tty: max310x: Split uart characters insertion loop Serge Semin
2019-05-21 10:17 ` Greg Kroah-Hartman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190521101701.GA31141@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=Sergey.Semin@t-platforms.ru \
    --cc=fancer.lancer@gmail.com \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --subject='Re: [PATCH 0/7] tty: max310x: Simplify the code and fix a few bugs' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).