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

Date:   Thu, 18 Aug 2016 20:31:52 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:     Rob Herring <robh@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Marcel Holtmann <marcel@...tmann.org>,
        Jiri Slaby <jslaby@...e.com>,
        Sebastian Reichel <sre@...nel.org>,
        Pavel Machek <pavel@....cz>,
        Peter Hurley <peter@...leysoftware.com>,
        NeilBrown <neil@...wn.name>, Arnd Bergmann <arnd@...db.de>,
        Linus Walleij <linus.walleij@...aro.org>,
        linux-bluetooth@...r.kernel.org, linux-serial@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] UART slave device bus

> Am 18.08.2016 um 17:38 schrieb One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>:
> 
>>> Your changes also don't work because serial uart drivers are not obliged
>>> to use any of the uart buffering helpers and particularly on the rx side
>>> many do not do so and the performance hit would be too high.  
>> 
>> The SoC I have, is using it.
> 
> The Linux kernel does generalised implementations. Yes it may work on
> your board but it doesn't work for everything.

It needs to work only on boards with a SoC UART. Not with a tty over
USB or something else. This is the generalisation I see. Any SoC with
uart_port driver support (and as far as I see many are).

> It's the difference
> between doing it properly and hacking your board to work.

Agreed. But solving problems nobody really has is overengineering.

Especially if the generalised implementation that is being discussed
(tty_port) does not even solve the problem. Or only in a very clumsy
and difficult way. In such a case a generalisation seems to be the
wrong approach to me.

And we should start to accept that we mix up different requirements
and try a single solution for almost everyone we can imagine (which
isn't bad initially, but can prohibit to find a solution at all) except the
real use case that is on the table. That is why I always come back
to the practical problem to implement my driver and want to know
how it can be done.

BR,
Nikolaus