linux-kernel - Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART controller

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: <8c553dcc-e352-6e69-e08c-4e6237555ea7@ti.com>
Date:   Fri, 15 Jun 2018 22:47:53 +0530
From:   Sekhar Nori <nsekhar@...com>
To:     Rob Herring <robh@...nel.org>, Nishanth Menon <nm@...com>
CC:     Santosh Shilimkar <ssantosh@...nel.org>,
        Will Deacon <will.deacon@....com>,
        Catalin Marinas <catalin.marinas@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mark Rutland <mark.rutland@....com>,
        <linux-serial@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Tony Lindgren <tony@...mide.com>, Vignesh R <vigneshr@...com>,
        Tero Kristo <t-kristo@...com>,
        Russell King <linux@...linux.org.uk>,
        Sudeep Holla <sudeep.holla@....com>
Subject: Re: [RFC PATCH 3/6] serial: 8250_omap: Add support for AM654 UART
 controller

Hi Rob,

On Wednesday 13 June 2018 02:36 AM, Rob Herring wrote:
> On Tue, Jun 05, 2018 at 01:01:22AM -0500, Nishanth Menon wrote:
>> AM654 uses a UART controller that is compatible (partially) with
>> existing 8250 UART, however, has a few differences with respect to DMA
>> support and control paths. Introduce a base definition that allows us
>> to build up the differences in follow on patches.
>>
>> Cc: Sekhar Nori <nsekhar@...com>
>> Cc: Vignesh R <vigneshr@...com>
>> Signed-off-by: Nishanth Menon <nm@...com>
>> ---
>>  Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
>>  drivers/tty/serial/8250/8250_omap.c                      | 1 +
>>  2 files changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> index 4b0f05adb228..c35d5ece1156 100644
>> --- a/Documentation/devicetree/bindings/serial/omap_serial.txt
>> +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
>> @@ -1,6 +1,7 @@
>>  OMAP UART controller
>>  
>>  Required properties:
>> +- compatible : should be "ti,am654-uart" for AM654 controllers
> 
> Not compatible with any existing TI 8250 UARTs?

Curious on why you asked about this. Are you suggesting why not:

"ti,<new-soc>-uart", "ti,<old-soc>-uart"

or you are asking why introduce "ti,<new-soc>-uart" unless there is
clear demonstrable need for using it in driver code.

In general, I think "ti,<new-soc>-uart", "ti,<old-soc>-uart" in
device-tree (and by extension in binding document) is better even in
there are no _known_ incompatibilities at the time of initial driver
submission. The reason is silicon integration and process differences
many times spill over into driver.

Of course, the idea is not to go postal and create a new compatible for
every pin-compatible part number that gets created, but probably a new
compatible should be created for a new silicon die.

We have just started introducing support for this SoC, and since it
reuses many IPs, this question is likely to come up again.

In this particular case though, Nishanth is perfectly right in not saying

compatible : should be "ti,am654-uart", "ti,omap4-uart"

Because we *know* UART DMA integration is different and a match against
omap4 would result in non-working UART once DMA is enabled by default.

Thanks,
Sekhar