Re: [-next] serial: 8250: Match legacy NS16550A UARTs

[Florian Fainelli <f.fainelli@gmail.com>]

On 4/21/2021 12:57 PM, Andy Shevchenko wrote:
> On Wed, Apr 21, 2021 at 10:04 PM Alan Cooper <alcooperx@gmail.com> wrote:
>> On Thu, Apr 15, 2021 at 6:44 AM Andy Shevchenko
>> <andy.shevchenko@gmail.com> wrote:
>>> On Wed, Apr 14, 2021 at 7:13 PM Al Cooper <alcooperx@gmail.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