On Wed, Apr 21, 2021 at 11:00 PM Florian Fainelli <f.fainelli@xxxxxxxxx> wrote: > > > > On 4/21/2021 12:57 PM, Andy Shevchenko wrote: > > On Wed, Apr 21, 2021 at 10:04 PM Alan Cooper <alcooperx@xxxxxxxxx> wrote: > >> On Thu, Apr 15, 2021 at 6:44 AM Andy Shevchenko > >> <andy.shevchenko@xxxxxxxxx> wrote: > >>> On Wed, Apr 14, 2021 at 7:13 PM Al Cooper <alcooperx@xxxxxxxxx> 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. I suggest to upstream it anyway.It will make the kernel robust. -- With Best Regards, Andy Shevchenko
