linux-kernel - Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the number of xilinx ps uarts

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: <af6f5a938ea9807b708356790e0f53e1@vanmierlo.com>
Date:   Thu, 25 May 2017 11:27:50 +0200
From:   Maarten Brock <m.brock@...mierlo.com>
To:     Michal Simek <michal.simek@...inx.com>
Cc:     Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Rob Herring <robh+dt@...nel.org>,
        Sam Povilus <kernel.development@...il.us>,
        gregkh@...uxfoundation.org, jslaby@...e.com,
        soren.brinkmann@...inx.com, linux-serial@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-serial-owner@...r.kernel.org
Subject: Re: [PATCH 1/1] xilinx ps uart: Adding a kernel parameter for the
 number of xilinx ps uarts

On 2017-05-24 18:09, Michal Simek wrote:
> On 24.5.2017 15:31, Alan Cox wrote:
>>> I am not saying that config option is perfect solution. It is at 
>>> least
>>> aligned with 5 others serial drivers in the tree.
>> 
>> And the fact people keep doing hacks jutifies continuing to make a 
>> mess.
>> Especialy as in this case it's entirely theoretical. Nobody has 
>> produced
>> actual hardware that hits the limit. Nobody has filed a bug, nobody is
>> impacted.
> 
> This is the reason why we are talking about it how to do it right.
> 
> With this ps uart it is not that easy because this is cadence RTL which
> is not in public IP database but the same think is with uartlite.
> Limit there is 16. If you really want that I can create that HW design
> which will require more than 16 uartlites in one design.
> 
> 
>> Creating extra CONFIG_ entries for junk like this is ridiculous, most 
>> of
>> the others at least have the excuse of being old code.
> 
> No doubt about it. I am just trying to find out what's the way you are
> suggesting.

A patch was already recently sent to this mailing list to add a CONFIG_
entry for the maximum number of uartlite devices. It is, as you say, 
quite
easy to create a device with more than 16 uartlite devices. (It is
probably harder to create one with many Cadence RTL PS uarts since that
would require a license.)

IMHO it is quite normal for anyone using the uartlite to build his/her 
own
kernel. and thus make config settings. But it is cumbersome to have to
modify the kernel sources. If the number of uartlites could be retrieved
from the device tree that would probably be even better if the price in
complexity and code size is reasonable.

Maarten