Re: [PATCH 1/6] dt-bindings: Add Bao IPC shared memory driver binding

João Peixoto <[email protected]>
Newsgroups org.infradead.lists.linux-riscv,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 1/7/26 16:46, Krzysztof Kozlowski wrote:
> On 07/01/2026 17:28,[email protected] wrote:
>> From: João Peixoto<[email protected]>
>>
>> This patch introduces a device tree binding for the Bao IPC Shared Memory
>> device, which enables communication between Bao hypervisor guests through
>> dedicated shared-memory regions.
>>
>> Signed-off-by: João Peixoto<[email protected]>
> Respond to feedback instead of ignoring it. I don't see any changelog
> either.
>
> Last posting was LLM junk so I will not spend much time on this.

Apologies. v2 was sent without a changelog and, worse, threaded onto the v1
thread. Both are fixed: v3 is its own thread with a changelog in the cover
letter and under each patch's --- line. I have also gone back through every
comment from v1 and v2 and addressed them one by one; each is answered in
this thread and summarised in the cover letter.

> A nit, subject: drop second/last, redundant "binding". The "dt-bindings"
> prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
Done. The subject is now "dt-bindings: bao: add IPC shared-memory device".

> Do not attach (thread) your patchsets to some other threads (unrelated
> or older versions). This buries them deep in the mailbox and might
> interfere with applying entire sets. See also:
> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
>
Understood, sorry. v3 is a fresh thread, not a reply to the previous 
version.

>> ---
>>   .../devicetree/bindings/bao/bao,ipcshmem.yaml | 82 +++++++++++++++++++
>>   .../devicetree/bindings/vendor-prefixes.yaml  |  2 +
>>   2 files changed, 84 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/bao/bao,ipcshmem.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/bao/bao,ipcshmem.yaml b/Documentation/devicetree/bindings/bao/bao,ipcshmem.yaml
>> new file mode 100644
>> index 000000000000..fa91800db99a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/bao/bao,ipcshmem.yaml
>> @@ -0,0 +1,82 @@
>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>> +%YAML 1.2
>> +---
>> +$id:http://devicetree.org/schemas/bao/bao,ipcshmem.yaml#
>> +$schema:http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Bao IPC Shared Memory Device
> Nothing here is suitable for bindings, really. Simplified node for
> establishing channel of communication to hypervisor would be allowed.
> But multiple devices for that? No point. Develop proper interface with
> your hypervisor for all this.
>
>> +
>> +maintainers:
>> +  - José Martins<[email protected]>
>> +  - David Cerdeira<[email protected]>
>> +  - João Peixoto<[email protected]>
>> +
>> +description: |
>> +  Shared memory based communication device for Bao hypervisor guests.
>> +
>> +  The device describes a set of shared-memory regions used for
>> +  communication between Bao guests. Each guest instantiating this
>> +  device uses one region for reading data produced by a peer guest
>> +  and another region for writing data consumed by that peer.
>> +
>> +properties:
>> +  compatible:
>> +    const: bao,ipcshmem
>> +
>> +  reg:
>> +    description:
>> +      Shared memory region used for IPC.
>> +    minItems: 2
>> +    maxItems: 2
> Look at other bindings.
>
>> +
>> +  read-channel:
>> +    description: |
>> +      Shared-memory sub-region that this guest reads from.
>> +
>> +      This region is written by the peer Bao guest and read by the
>> +      guest instantiating this device.
>> +
>> +      Consists of two cells:
>> +        - offset into the shared-memory region defined by `reg`
>> +        - size in bytes
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    minItems: 2
>> +    maxItems: 2
> Drop property, reg defines it.
>
>> +
>> +  write-channel:
> Drop property, reg defines it.
>
>
>> +    description: |
>> +      Shared-memory sub-region that this guest writes to.
>> +
>> +      This region is written by the guest instantiating this device and
>> +      read by the peer Bao guest.
>> +
>> +      Consists of two cells:
>> +        - offset into the shared-memory region defined by `reg`
>> +        - size in bytes
>> +    $ref: /schemas/types.yaml#/definitions/uint32-array
>> +    minItems: 2
>> +    maxItems: 2
Reworked exactly as you suggested. The two channels are now described by reg
itself instead of by separate offset/size properties:

   reg = <0xf0000000 0x2000>,   /* region this guest reads from  */
         <0xf0002000 0x2000>;   /* region this guest writes to  */
   reg-names = "read", "write";

read-channel and write-channel are gone; the driver derives both regions 
from
reg/reg-names.
>> +
>> +  id:
>> +    description:
>> +      Driver instance ID.
>> +    $ref: /schemas/types.yaml#/definitions/uint32
> NAK, not allowed. Read writing bindings.
The bare "id" is dropped. The one value the driver still needs is the
hypervisor-assigned channel number it passes to the notify hypercall - that
is part of the guest<->hypervisor ABI, not a Linux instance number. It 
is now
a vendor property, "bao,id", documented as "must match the identifier
configured for the channel in the hypervisor". If you would prefer this
expressed differently (e.g. derived from an alias), I am happy to change it,
please let me know.
>> +
>> +required:
>> +  - compatible
>> +  - reg
>> +  - read-channel
>> +  - write-channel
>> +  - id
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> +  - |
>> +    bao-ipc@f0000000 {
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
> If you cannot find a name matching your device, please check in kernel
> sources for similar cases or you can grow the spec (via pull request to
> DT spec repo).
The example node is now generic: "shmem@f0000000".

>> +        compatible = "bao,ipcshmem";
>> +        reg = <0x0 0xf0000000 0x0 0x00010000>;
>> +        read-channel = <0x0 0x2000>;
>> +        write-channel = <0x2000 0x2000>;
>> +        id = <0>;
>> +    };
>> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> index c7591b2aec2a..c047fbd6b91a 100644
>> --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
>> @@ -223,6 +223,8 @@ patternProperties:
>>       description: Shenzhen AZW Technology Co., Ltd.
>>     "^baikal,.*":
>>       description: BAIKAL ELECTRONICS, JSC
>> +  "^bao,.*":
>> +    description: Bao Hypervisor
> Vendor prefixes are for companies. What is the company here? What is
> stock ticker or website?
>
>
>>     "^bananapi,.*":
>>       description: BIPAI KEJI LIMITED
>>     "^beacon,.*":
"bao" is the Bao Project, an open-source static-partitioning hypervisor
(https://github.com/bao-project), not a single company - analogous to the
existing "qemu" and "virtio" prefixes, which likewise name a software
interface rather than a vendor. I have updated the vendor-prefixes entry
accordingly. If you would rather namespace this under the maintaining 
company
(https://www.osyx.tech/) instead of the project, say the word and I will 
switch it.
> Best regards,
> Krzysztof

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.