linux-kernel - Re: [RFC PATCH 0/3] UART slave device bus

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: <61F43885-BE05-482C-9AD6-B52A2DA166B8@goldelico.com>
Date:   Fri, 19 Aug 2016 19:42:37 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:     Sebastian Reichel <sre@...nel.org>, Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Jiri Slaby <jslaby@...e.com>, Pavel Machek <pavel@....cz>,
        Peter Hurley <peter@...leysoftware.com>,
        NeilBrown <neil@...wn.name>, Arnd Bergmann <arnd@...db.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        "open list:BLUETOOTH DRIVERS" <linux-bluetooth@...r.kernel.org>,
        "linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] UART slave device bus


> Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>:
> 
>> If possible, please do a callback for every character that arrives.
>> And not only if the rx buffer becomes full, to give the slave driver
>> a chance to trigger actions almost immediately after every character.
>> This probably runs in interrupt context and can happen often.
> 
> We don't realistically have the clock cycles to do that on a low end
> embedded processor handling high speed I/O.

well, if we have a low end embedded processor and high-speed I/O, then
buffering the data before processing doesn't help either since processing
still will eat up clock cycles.

> The best you can do is
> trigger a workqueue to switch the buffer data around and call the helper
> while the uart may be receiving more bytes.

Ok, assuming DMA double buffering might (almost) double throughput.

The question is if this is needed at all. If we have a bluetooth stack with HCI the
fastest UART interface I am aware of is running at 3 Mbit/s. 10 bits incl. framing
means 300kByte/s equiv. 3µs per byte to process. Should be enough to decide
if the byte should go to a buffer or not, check checksums, or discard and move
the protocol engine to a different state. This is what I assume would be done in
a callback. No processing needing some ms per frame.

> 
> What you are asking for you'd get out of the first parts of tidying up
> the receive paths because you'd set a different port->rx() method and get
> bursts of characters, flags and length data.
> 
> Alan