From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "open list:SERIAL DRIVERS" <linux-serial@vger.kernel.org>,
"Al Cooper" <alcooperx@gmail.com>,
bcm-kernel-feedback-list <bcm-kernel-feedback-list@broadcom.com>,
"Jim Quinlan" <jim2101024@gmail.com>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Jiri Slaby" <jirislaby@kernel.org>,
"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH tty-next] serial: 8250: of: Check for CONFIG_SERIAL_8250_BCM7271
Date: Fri, 23 Apr 2021 21:54:05 +0300 [thread overview]
Message-ID: <CAHp75VfkSZyKo5JqBL0MuMzyPis59ebJKW5c7c-53K9h4d5bCA@mail.gmail.com> (raw)
In-Reply-To: <20210423183206.3917725-1-f.fainelli@gmail.com>
On Fri, Apr 23, 2021 at 9:34 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
>
> From: Jim Quinlan <jim2101024@gmail.com>
>
> Our SoC's have always had a NS16650A UART core and older SoC's would
> have a compatible string of: 'compatible = ""ns16550a"' and use the
> 8250_of driver. Our newer SoC's have added enhancements to the base
> core to add support for DMA and accurate high speed baud rates and use
> this newer 8250_bcm7271 driver. The Device Tree node for our enhanced
> UARTs has a compatible string of: 'compatible = "brcm,bcm7271-uart",
> "ns16550a"''. With both drivers running and the link order setup so
> that the 8250_bcm7217 driver is initialized before the 8250_of driver,
> we should bind the 8250_bcm7271 driver to the enhanced UART, or for
> upstream kernels that don't have the 8250_bcm7271 driver, we bind to
> the 8250_of driver.
>
> 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.
>
> This commit has of_platform_serial_probe() check specifically for the
> "brcm,bcm7271-uart" and whether its companion driver is enabled. If it
> is the case, and the clock provider is not ready, we want to make sure
> that when the 8250_bcm7271.c driver returns EPROBE_DEFER, we are not
> getting the UART registered via 8250_of.c.
Thanks!
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Jim Quinlan <jim2101024@gmail.com>
> Signed-off-by: Al Cooper <alcooperx@gmail.com>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> drivers/tty/serial/8250/8250_of.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_of.c b/drivers/tty/serial/8250/8250_of.c
> index 0b077b45d6a9..bce28729dd7b 100644
> --- a/drivers/tty/serial/8250/8250_of.c
> +++ b/drivers/tty/serial/8250/8250_of.c
> @@ -192,6 +192,10 @@ static int of_platform_serial_probe(struct platform_device *ofdev)
> u32 tx_threshold;
> int ret;
>
> + if (IS_ENABLED(CONFIG_SERIAL_8250_BCM7271) &&
> + of_device_is_compatible(ofdev->dev.of_node, "brcm,bcm7271-uart"))
> + return -ENODEV;
> +
> port_type = (unsigned long)of_device_get_match_data(&ofdev->dev);
> if (port_type == PORT_UNKNOWN)
> return -EINVAL;
> --
> 2.25.1
>
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2021-04-23 18:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 18:32 [PATCH tty-next] serial: 8250: of: Check for CONFIG_SERIAL_8250_BCM7271 Florian Fainelli
2021-04-23 18:54 ` Andy Shevchenko [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAHp75VfkSZyKo5JqBL0MuMzyPis59ebJKW5c7c-53K9h4d5bCA@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=alcooperx@gmail.com \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=f.fainelli@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=j.neuschaefer@gmx.net \
--cc=jim2101024@gmail.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).