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: <072cc4c2-9a63-312a-a4bd-b4aa6d393a7e@gmail.com>
Date:   Wed, 21 Apr 2021 13:00:55 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        Alan Cooper <alcooperx@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        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 4/21/2021 12:57 PM, Andy Shevchenko wrote:
> 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.

Yes we had a downstream patch not submitted that did exactly that:

+       if (IS_ENABLED(CONFIG_SERIAL_8250_BCM7271) &&
+           of_device_is_compatible(ofdev->dev.of_node,
"brcm,bcm7271-uart"))
+               return -ENODEV;
+

but thanks to Al's findings it does not appear to be needed anymore, we
could submit it somehow if you feel like other scenarios like having
SCMI and the UART drivers as modules.
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ