On 15/10/2026 16:29, Ben Levinsky wrote: > >> >> >> *From: *Krzysztof Kozlowski <[email protected]> >> *Date: *Thursday, October 15, 2026 at 2:46 AM >> *To: *Levinsky, Ben <[email protected]> >> *Cc: *[email protected] <[email protected]>; >> [email protected] >> <[email protected]>; [email protected] >> <[email protected]>; >> [email protected] <[email protected]>; [email protected] <[email protected]>; >> [email protected] <[email protected]>; Simek, Michal >> <[email protected]>; >> [email protected] <[email protected]>; >> [email protected] <[email protected]>; linux-arm- >> [email protected] <[email protected]>; linux- >> [email protected] <[email protected]>; Shah, Tanmay >> <[email protected]> >> *Subject: *Re: [PATCH 3/6] dt-bindings: mailbox: Add AMD PL Mailbox IP >> >> On Wed, Oct 14, 2026 at 02:34:23PM -0700, Ben Levinsky wrote: >> > Document the AMD programmable-logic Mailbox IP used for bidirectional >> > FIFO communication between two processor-facing interfaces. >> > >> > The same IP is used on ZynqMP, Versal, Versal NET and Versal Gen 2. >> > Name each SoC in its compatible, and use amd,zynqmp-pl-mbox-2.1 as the >> > fallback that drivers match. >> > >> > Define the transmit and receive channel indices together with the register >> > aperture, interrupt, and interface clock. Describe the FIFO depth chosen >> > when the IP is configured, so that the driver can size received messages >> > to it. >> > >> > Assisted-by: LLM sparse >> >> How sparse assists here? It's something new. Since when does it parse >> yaml code? > > Hi Krzysztof, > > Thank you for the review. > > You are right, sparse was not used for this patch. It was only run on > the C patches of the series, and I applied the same trailer to the > whole series by mistake. In v2 the binding patches will name only the > model, and the tool list will match what was actually used on each > patch. > >> >> > Signed-off-by: Ben Levinsky <[email protected]> >> > --- >> > .../mailbox/amd,zynqmp-pl-mbox-2.1.yaml | 74 +++++++++++++++++++ >> > 1 file changed, 74 insertions(+) >> > create mode 100644 >> Documentation/devicetree/bindings/mailbox/amd,zynqmp-pl- >> mbox-2.1.yaml >> > >> > diff --git a/Documentation/devicetree/bindings/mailbox/amd,zynqmp-pl- >> mbox-2.1.yaml b/Documentation/devicetree/bindings/mailbox/amd,zynqmp-pl- >> mbox-2.1.yaml >> > new file mode 100644 >> > index 000000000000..2cc0d106b888 >> > --- /dev/null >> > +++ >> b/Documentation/devicetree/bindings/mailbox/amd,zynqmp-pl-mbox-2.1.yaml >> > @@ -0,0 +1,74 @@ >> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> > +%YAML 1.2 >> > +--- >> > +$id: http://devicetree.org/schemas/mailbox/amd,zynqmp-pl-mbox-2.1.yaml# >> <http://devicetree.org/schemas/mailbox/amd,zynqmp-pl-mbox-2.1.yaml#> >> > +$schema: http://devicetree.org/meta-schemas/core.yaml# <http:// >> devicetree.org/meta-schemas/core.yaml#> >> > + >> > +title: AMD Programmable Logic Mailbox IP >> > + >> > +maintainers: >> > + - Ben Levinsky <[email protected]> >> > + >> > +description: | >> > + The AMD Programmable Logic Mailbox IP provides bidirectional message >> passing >> > + between two processor-facing interfaces. Each interface writes >> messages to >> > + a send FIFO and reads messages from a receive FIFO. The register >> aperture, >> > + interrupt, and clock described by a node belong to one processor-facing >> > + interface. Channel 0 represents transmit and channel 1 represents >> receive >> > + for that interface. >> > + >> > +properties: >> > + compatible: >> > + oneOf: >> > + - const: amd,zynqmp-pl-mbox-2.1 >> >> What is 2.1? Your SoC has different versions? > > 2.1 is the version of the Mailbox IP core in the Xilinx IP catalog > (Mailbox v2.1). It is not a SoC version. The IP is synthesized into the > programmable logic, so the same core is used on every SoC, and the SoC > names in the compatibles do not add information.
Heh? This is in contrast to writing bindings. > > In v2 I will use a single IP-versioned compatible, "xlnx,mailbox-2.1", > and drop the SoC-specific ones. This is also the compatible the Xilinx > device tree generator already emits for this IP. No, use SoC naming. Just like every other vendor. Remember: before doing something completely different, first find arguments why your vendor/patchset should be special. Best regards, Krzysztof
