linux-kernel - Re: [PATCHv4] serial: imx: Add DMA buffer configuration via sysfs

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20210305124252.c3ffgca6wjqpkn45@earth.universe>
Date:   Fri, 5 Mar 2021 13:42:52 +0100
From:   Sebastian Reichel <sebastian.reichel@...labora.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Jiri Slaby <jirislaby@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>, Ian Ray <ian.ray@...com>,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        kernel@...labora.com
Subject: Re: [PATCHv4] serial: imx: Add DMA buffer configuration via sysfs

Hi Greg,

On Fri, Mar 05, 2021 at 01:06:12PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 05, 2021 at 12:50:58PM +0100, Sebastian Reichel wrote:
> > From: Fabien Lahoudere <fabien.lahoudere@...labora.com>
> > 
> > In order to optimize serial communication (performance/throughput VS
> > latency), we may need to tweak DMA period number and size. This adds
> > sysfs attributes to configure those values before initialising DMA.
> > The defaults will stay the same as before (16 buffers with a size of
> > 1024 bytes). Afterwards the values can be read/write with the
> > following sysfs files:
> > 
> > /sys/class/tty/ttymxc*/dma_buffer_size
> > /sys/class/tty/ttymxc*/dma_buffer_count
> 
> Ick no.  Custom sysfs attributes for things like serial ports are crazy.
> 
> > This is mainly needed for GEHC CS ONE (arch/arm/boot/dts/imx53-ppd.dts),
> > which has multiple microcontrollers connected via UART controlling. One
> > of the UARTs is connected to an on-board microcontroller at 19200 baud,
> > which constantly pushes critical data (so aging character detect
> > interrupt will never trigger). This data must be processed at 50-200 Hz,
> > so UART should return data in less than 5-20ms. With 1024 byte DMA
> > buffer (and a constant data stream) the read operation instead needs
> > 1024 byte / 19200 baud = 53.333ms, which is way too long (note: Worst
> > Case would be remote processor sending data with short pauses <= 7
> > characters, which would further increase this number). The current
> > downstream kernel instead configures 24 bytes resulting in 1.25ms,
> > but that is obviously not sensible for normal UART use cases and cannot
> > be used as new default.
> 
> Why can't this be a device tree attribute? Why does this have to be a
> sysfs thing that no one will know how to tune and set over time.  This
> hardware should not force a user to manually tune it to get it to work
> properly, this isn't the 1990's anymore :(
> 
> Please never force a user to choose stuff like this, they never will
> know what to do.

This used to be a DT attribute in PATCHv1. It has been moved over to
sysfs since PATCHv2, since it does not describe the hardware, but
configuration. Unfortunately lore.kernel.org does not have the full
thread, but this is the discussion:

https://lore.kernel.org/linux-serial/20170629182618.jpahpmuq364ldcv2@pengutronix.de/

From downstream POV this can be done either by adding a DT property
to the UART node, or by adding a udev rule.

From my POV there is not a huge difference. In both cases we will
be bound by an ABI afterwards, in both cases people will usually
stick to the default value and in both cases people that do deviate
from the default probably ran into problems and started to look
for a solution.

Thanks,

-- Sebastian

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)