linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).