linux-kernel - Re: [-next] serial: 8250: Match legacy NS16550A 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]

Date:   Wed, 21 Apr 2021 22:57:57 +0300
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Alan Cooper <alcooperx@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@...adcom.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jirislaby@...nel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>
Subject: Re: [-next] serial: 8250: Match legacy NS16550A UARTs

On Wed, Apr 21, 2021 at 10:04 PM Alan Cooper <alcooperx@...il.com> wrote:
> On Thu, Apr 15, 2021 at 6:44 AM Andy Shevchenko
> <andy.shevchenko@...il.com> wrote:
> > On Wed, Apr 14, 2021 at 7:13 PM Al Cooper <alcooperx@...il.com> wrote:

> The problem is that when both the 8250_of and 8250_bcm7271 drivers
> were running, occasionally the 8250_of driver would be bound to the
> enhanced UART instead of the 8250_bcm7271 driver. This was happening
> because we use SCMI based clocks which come up late in initialization
> and cause probe DEFER's when the two drivers get their clocks.
> Occasionally the SCMI clock would become ready between the
> 8250_bcm7271 probe and the 8250_of probe and the 8250_of driver would
> be bound. To fix this we decided to config only our 8250_bcm7271
> driver and added "ns16665a0" to the compatible string so the driver
> would work on our older system.

Interesting reading.

As far as I understand the 8250 approach (*), you blacklist (or
whatever naming you prefer, b/c 8250_of seems does not have such) the
binding based on the presence of the specific compatible string.

I.o.w. in 8250_of you need to check if you are trying to probe the
device which has both compatible strings. In that case you simply
return -ENODEV.

*) 8250_pci does like this.

-- 
With Best Regards,
Andy Shevchenko