Message ID | 20231121121324.23268-1-zajec5@gmail.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [1/2] dt-bindings: serial: add Broadcom's BCM63138 High Speed UART | expand |
Hi Rafal, This same HS UART exists on all the bcmbca SoCs that listed in brcm,bcmbca.yaml. I suggest to use bcmbca for all instead of naming based on each individual chip. This will be consistent with spi, nand and other common periph blocks used in bcmbca SoCs. Thanks, William On 11/21/2023 04:13 AM, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > > It's an UART controller that first appeared on BCM63138 SoC and then was > reused on other bcmbca familiy chipsets. > > Signed-off-by: Rafał Miłecki <rafal@milecki.pl> > --- > .../serial/brcm,bcm63138-hs-uart.yaml | 44 +++++++++++++++++++ > 1 file changed, 44 insertions(+) > create mode 100644 Documentation/devicetree/bindings/serial/brcm,bcm63138-hs-uart.yaml > > diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm63138-hs-uart.yaml b/Documentation/devicetree/bindings/serial/brcm,bcm63138-hs-uart.yaml > new file mode 100644 > index 000000000000..91a7e945be39 > --- /dev/null > +++ b/Documentation/devicetree/bindings/serial/brcm,bcm63138-hs-uart.yaml > @@ -0,0 +1,44 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/serial/brcm,bcm63138-hs-uart.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Broadcom's BCM63138 High Speed UART > + > +description: > + High speed serial port controller that was designed to handle Bluetooth > + devices communication. It supports sending custom frames that need to be > + processed by a host system. > + > +maintainers: > + - Rafał Miłecki <rafal@milecki.pl> > + > +allOf: > + - $ref: serial.yaml# > + > +properties: > + compatible: > + const: brcm,bcm63138-hs-uart > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > +required: > + - reg > + - interrupts > + > +unevaluatedProperties: false > + > +examples: > + - | > + #include <dt-bindings/interrupt-controller/arm-gic.h> > + > + serial@fffec400 { > + compatible = "brcm,bcm63138-hs-uart"; > + reg = <0xfffec400 0x1e0>; > + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; > + }; >
On 21/11/2023 13:13, Rafał Miłecki wrote: > From: Rafał Miłecki <rafal@milecki.pl> > Thank you for your patch. There is something to discuss/improve. > + > +properties: > + compatible: > + const: brcm,bcm63138-hs-uart > + > + reg: > + maxItems: 1 > + > + interrupts: > + maxItems: 1 > + > +required: Missing compatible. Best regards, Krzysztof
On 21.11.2023 23:38, Krzysztof Kozlowski wrote: > On 21/11/2023 13:13, Rafał Miłecki wrote: >> From: Rafał Miłecki <rafal@milecki.pl> >> > > Thank you for your patch. There is something to discuss/improve. > >> + >> +properties: >> + compatible: >> + const: brcm,bcm63138-hs-uart >> + >> + reg: >> + maxItems: 1 >> + >> + interrupts: >> + maxItems: 1 >> + >> +required: > > Missing compatible. I stopped putting "compatible" in "required" in schemas back in 2020 :O Back then I received a comment from Rob [0] in discussion on [PATCH] dt-bindings: mtd: convert "fixed-partitions" to the json-schema telling to drop it: On 10.12.2020 03:48, Rob Herring wrote: > And drop 'compatible' as required. It's redundant anyways because the > schema will only be applied if compatible matches. So I'll need some help here please. Should I start including "compatible" in "required" after all? Or is that situation specific (could you explain what does it depend on)? [0] https://lore.kernel.org/linux-devicetree/20201210024840.GA1510718@robh.at.kernel.org/
On 22/11/2023 07:17, Rafał Miłecki wrote: > On 21.11.2023 23:38, Krzysztof Kozlowski wrote: >> On 21/11/2023 13:13, Rafał Miłecki wrote: >>> From: Rafał Miłecki <rafal@milecki.pl> >>> >> >> Thank you for your patch. There is something to discuss/improve. >> >>> + >>> +properties: >>> + compatible: >>> + const: brcm,bcm63138-hs-uart >>> + >>> + reg: >>> + maxItems: 1 >>> + >>> + interrupts: >>> + maxItems: 1 >>> + >>> +required: >> >> Missing compatible. > > I stopped putting "compatible" in "required" in schemas back in 2020 :O > > Back then I received a comment from Rob [0] in discussion on > [PATCH] dt-bindings: mtd: convert "fixed-partitions" to the json-schema > telling to drop it: > > On 10.12.2020 03:48, Rob Herring wrote: > > And drop 'compatible' as required. It's redundant anyways because the > > schema will only be applied if compatible matches. > > So I'll need some help here please. Should I start including > "compatible" in "required" after all? Or is that situation specific > (could you explain what does it depend on)? Hm, it is redundant, true, although I always preferred it listed to be explicit. But in such case no problem: Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm63138-hs-uart.yaml b/Documentation/devicetree/bindings/serial/brcm,bcm63138-hs-uart.yaml new file mode 100644 index 000000000000..91a7e945be39 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/brcm,bcm63138-hs-uart.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/brcm,bcm63138-hs-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom's BCM63138 High Speed UART + +description: + High speed serial port controller that was designed to handle Bluetooth + devices communication. It supports sending custom frames that need to be + processed by a host system. + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: brcm,bcm63138-hs-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + serial@fffec400 { + compatible = "brcm,bcm63138-hs-uart"; + reg = <0xfffec400 0x1e0>; + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>; + };