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 for Android: free password hash cracker in your pocket

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

Message-ID: <20160821180910.51cf919d@lxorguk.ukuu.org.uk>
Date:   Sun, 21 Aug 2016 18:09:10 +0100
From:   One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:     "H. Nikolaus Schaller" <hns@...delico.com>
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

> Let me ask a question about your centralized and pre-cooked buffering approach.
> 
> As far as I see, even then the kernel API must notify the driver at the right moment
> that a new block has arrived. Right?

The low level driver queues words (data byte, flag byte)
The buffer processing workqueue picks those bytes from the queue and
atomically empties the queue
The workqueue involves the receive handler.

> But how does the kernel API know how long such a block is?

It's as long as the data that has arrived in that time.

> Usually there is a start byte/character, sometimes a length indicator, then payload data,
> some checksum and finally a stop byte/character. For NMEA it is $, no length, * and \r\n.
> For other serial protocols it might be AT, no length, and \r. Or something different.
> HCI seems to use 2 byte op-code or 1 byte event code and 1 byte parameter length.

It doesn't look for any kind of protocol block headers. The routine
invoked by the work queue does any frame recovery.

> So I would even conclude that you usually can't even use DMA based UART receive
> processing for arbitrary and not well-defined protocols. Or have to assume that the

We do, today for bluetooth and other protocols just fine - it's all about
data flows not about framing in the protocol sense.

Alan