[PATCH V2 1/2] dt-bindings: serial: add Broadcom's BCMBCA family High Speed UART

[William Zhang]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski at linaro.org>
> Sent: Wednesday, November 22, 2023 10:46 AM
> To: William Zhang <william.zhang at broadcom.com>; Rafał Miłecki
> <zajec5 at gmail.com>; Florian Fainelli <florian.fainelli at broadcom.com>;
> Anand Gore <anand.gore at broadcom.com>; Kursad Oney
> <kursad.oney at broadcom.com>; Rob Herring <robh+dt at kernel.org>;
> Krzysztof Kozlowski <krzysztof.kozlowski+dt at linaro.org>; Conor Dooley
> <conor+dt at kernel.org>
> Cc: Greg Kroah-Hartman <gregkh at linuxfoundation.org>; Jiri Slaby
> <jirislaby at kernel.org>; Andre Przywara <andre.przywara at arm.com>;
> Alexandre TORGUE <alexandre.torgue at st.com>; Neil Armstrong
> <neil.armstrong at linaro.org>; linux-serial at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; bcm-
> kernel-feedback-list at broadcom.com; Rafał Miłecki <rafal at milecki.pl>
> Subject: Re: [PATCH V2 1/2] dt-bindings: serial: add Broadcom's BCMBCA
> family High Speed UART
>
> On 22/11/2023 19:39, William Zhang wrote:
> > Hi,
> >
> > On 11/22/2023 07:52 AM, Rafał Miłecki wrote:
> >> On 22.11.2023 16:50, Krzysztof Kozlowski wrote:
> >>> On 22/11/2023 16:49, Rafał Miłecki wrote:
> >>>>>> For example a year ago I added binding for BCMBCA SoC timer
> without
> >>>>>> actual driver, see e112f2de151b ("dt-bindings: timer: Add
> Broadcom's
> >>>>>> BCMBCA timers").
> >>>>>>
> >>>>>> I'm not sure if we're going to agree on this, but personally I like
> >>>>>> describing hardware as much as I can. So it's well documented /
> >>>>>> understood and people may eventually write drivers for it. Maybe
> it's
> >>>>>> partially because I come from Broadcom's world that isn't well
> known
> >>>>>> for upstream efforts in general.
> >>>>>
> >>>>> The problem is that "brcm,bcmbca-hs-uart" is not describing
> >>>>> hardware. It
> >>>>> is saying that all these devices have similar (compatible)
> >>>>> programming
> >>>>> model, so the OS can use just one compatible. This goes away from
> pure
> >>>>> hardware description into interpretation.
> >>>>>
> > It is the same hardware IP block used in bcmbca SoCs.  To me, it
> > perfectly describe the hardware IP block and it does not need fallback
> > because there is no fallback.  We did that for SPI controller although
> > it has two revisions of that IP block so we have brcm,bcmbca-hsspi-v1.0
> > and 1.1
> >
> >>>>> Rob already commented on such non-SoC compatibles multiple times.
> I do
> >>>>> not see any reason here to not use specific compatible as fallback.
> >>>>
> > Sorry I missed Rob's comments.  If we have any new rule or notes about
> > this, I would like to check it out.
> >
> >>>> Do I get it right we should rather have some base specific compatible
> >>>> like: "brcm,bcm63138-hs-uart" and then if anything use fallback to it
> >>>> like: "brcm,bcm4908-hs-uart", "brcm,bcm63138-hs-uart"; ?
> >>>
> >>> Yes, or the other way around, depends which is probably the oldest.
> > If we absolutely can not use bcmbca-hs-uart, I would suggest to use
>
> We can, but I am surprised that you want without any driver. What's the
> point of generic compatible?
>
I agree we should have the driver along with the dts. But it looks it
depends on
the bandwidth of Rafal.

> > bcm63xx-hs-uart to be more soc specific and in fact the oldest SoC have
>
> What is xx? Wildcard? I mean... ehhh...
>
Bcm63 series of SoC (DSL broadband chip, part of the bcmbca family) and it
is
the oldest chip for such IP.   bcm63xx has been used in many ip block's
compatible
string for long time in the upstream kernel.

> Best regards,
> Krzysztof
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4212 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20231122/18566ea9/attachment-0001.p7s>