在2024年5月7日五月 下午5:50，Conor Dooley写道： > On Tue, May 07, 2024 at 10:01:52AM +0100, Jiaxun Yang wrote: >> Add devicetree binding documentation for MIPS Coherence Manager. >> >> Signed-off-by: Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> >> --- >> .../devicetree/bindings/mips/mips-cm.yaml | 37 ++++++++++++++++++++++ >> 1 file changed, 37 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/mips/mips-cm.yaml b/Documentation/devicetree/bindings/mips/mips-cm.yaml >> new file mode 100644 >> index 000000000000..b92b008d7758 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/mips/mips-cm.yaml Hi Cornor, Thanks for your comments. > > Filename matching the compatible please. Ok. > >> @@ -0,0 +1,37 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/mips/mips-cm.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: MIPS Coherence Manager >> + >> +description: | >> + Defines a location of the MIPS Coherence Manager registers. >> + >> +maintainers: >> + - Jiaxun Yang <jiaxun.yang@xxxxxxxxxxx> >> + >> +properties: >> + compatible: >> + const: mti,mips-cm > > Is it actually only available on mips? Google seems to report there > being Coherence Managers on their RISC-V offerings too. I think for MIPS's RISC-V system, it is only used by SBI and transparent to kernel, so it won't present in DT. Register fields for RISC-V system is totally different with MIPS one, and there is no driver to be reused. In MIPS system CM code is highly coupled with arch code, so for RISC-V if we want to expose it to kernel we'll need a new set of driver and a new binding. > >> + reg: >> + description: | > > The | isn't needed, there's no formatting to preserve. Ok. > >> + Base address and size of an unoccupied memory region, which will be >> + used to map the MIPS CM registers block. > > This sounds like it should actually be a memory-region that references > some reserved memory, not a reg, given the description. I think the > commit message here is lacking any information about what the intentions > are for this binding. So it's actually a register block that can be remapped to anywhere in MMIO address space. DeviceTree usually passes firmware's mapping location to kernel. There are some other similar bindings like mti,mips-cdmm and mti,mips-cpc, I just copied phraseology from them, should I try to explain it more here? > >> + maxItems: 1 >> + >> +required: >> + - compatible >> + - reg >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + cm@1fbf8000 { > > And a generic node name here please. I actually don't quite know what to > suggest though, but "coherency-manager" would likely be better than > "cm". Ok Thanks! - Jiaxun > > Thanks, > Conor. > >> + compatible = "mti,mips-cm"; >> + reg = <0x1bde8000 0x8000>; >> + }; >> +... >> >> -- >> 2.34.1 >> > > 附件: > * signature.asc -- - Jiaxun
