Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20210414134539.42332-1-alcooperx@gmail.com> <CAHp75VfQetCJJZ_U70xEduVBQHEx_GkHeKBs2uzNtvcq9H0BqQ@mail.gmail.com>
 <CAOGqxeUiFE0348Y=yEoD7bnMaGnFkbvNy3WZ2oSZZzR4D-xz_w@mail.gmail.com>
 <CAHp75VfD7i9irKDxk0v+j1c1wFrcu9v+OA-X7+edsg6johhJnQ@mail.gmail.com> <072cc4c2-9a63-312a-a4bd-b4aa6d393a7e@gmail.com>
In-Reply-To: <072cc4c2-9a63-312a-a4bd-b4aa6d393a7e@gmail.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Wed, 21 Apr 2021 23:12:54 +0300
Message-ID: <CAHp75VfTu-MAwrrDscP215=cPXQ7hwWCgMQkbHEEvrJdqwgiEA@mail.gmail.com>
Subject: Re: [-next] serial: 8250: Match legacy NS16550A UARTs
To:     Florian Fainelli <f.fainelli@gmail.com>
Cc:     Alan Cooper <alcooperx@gmail.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jirislaby@kernel.org>,
        "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Apr 21, 2021 at 11:00 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
>
>
> 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.

I suggest to upstream it anyway.It will make the kernel robust.

-- 
With Best Regards,
Andy Shevchenko