linux-kernel - Re: [PATCH 1/2] dt-bindings: remoteproc: Add VCP support for mt8196

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <860ae623-f33f-4cfe-be08-6bb6524ecf94@kernel.org>
Date: Wed, 2 Apr 2025 13:11:43 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Xiangzhi Tang <xiangzhi.tang@...iatek.com>,
 Bjorn Andersson <andersson@...nel.org>,
 Mathieu Poirier <mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org,
 Project_Global_Chrome_Upstream_Group@...iatek.com, jjian.zhou@...iatek.com,
 hailong.fan@...iatek.com
Subject: Re: [PATCH 1/2] dt-bindings: remoteproc: Add VCP support for mt8196

On 02/04/2025 11:19, Xiangzhi Tang wrote:
> +
> +description:
> +  The MediaTek VCP enables the SoC control the MediaTek Video Companion Risc-V coprocessor.

Wrap at coding style.

> +
> +properties:
> +  compatible:
> +    enum:
> +      - mediatek,mt8196-vcp
> +
> +  reg:
> +    items:
> +      - description: sram base
> +      - description: cfg group IO
> +      - description: cfg core group IO
> +      - description: cfg sec group IO
> +      - description: vcp rdy group IO
> +
> +  reg-names:
> +    items:
> +      - const: sram
> +      - const: cfg
> +      - const: cfg_core
> +      - const: cfg_sec
> +      - const: vcp_vlp_ao_rsvd7
> +
> +  interrupts:
> +    maxItems: 1
> +
> +  mboxes:
> +    description:
> +      Using mailbox to communicate with VCP, it should have this
> +      property and list of phandle, mailbox specifiers. See
> +      Documentation/devicetree/bindings/mailbox/mediatek,mt8196-vcp-mbox.yaml
> +      for details.

Drop entire description, redundant.

> +    $ref: /schemas/types.yaml#/definitions/phandle-array
> +

No, you do not get your own type. Instead list items or just maxItems.


> +  mbox-names:
> +    maxItems: 5

No, you must list the items.

> +
> +  power-domains:
> +    description:
> +      A phandle and PM domain specifier as defined by bindings
> +      of the power controller specified by phandle. See
> +      Documentation/devicetree/bindings/power/power-domain.yaml for details.

Look how other bindings do it. Do not repeat obvious stuff, do not
develop bindings entirely different than all others.

> +    maxItems: 1
> +
> +  iommus:
> +    description:
> +      Using MediaTek iommu to apply larb ports for Multimedia Memory
> +      Management Unit and address translation
> +      Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml

Really, look at other code first.

> +
> +  memory-region:
> +    maxItems: 1
> +
> +  vcp-mem-tbl:
> +    description:
> +      Manage reserved memory for VCP RTOS FW and various features.

No, reserved memory is in memory-region. Drop property.

> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    minItems: 2
> +    maxItems: 12
> +
> +patternProperties:
> +  "^vcp_[a-f0-9]+$":

Follow DTS coding style.

Heh, nothing here was really tested and you have obvious bugs pointed
out by simple testing of DTS.

Why these children are needed in the first place? Offsets are implied by
parent compatible.

> +    type: object
> +    description:
> +      The MediaTek VCP integrated to SoC might be a multi-core version.
> +      The other cores are represented as child nodes of the boot core.
> +      There are some integration differences for the IP like the usage of
> +      address translator for translating SoC bus addresses into address
> +      space for the processor.
> +
> +      The SRAM are shared by all cores, each VCP core only using a piece
> +      SRAM memory. The power of SRAM should be enabled before booting VCP cores.
> +      The size of SRAM are varied on differnt SoCs.
> +
> +      The VCP cores has differences on different SoCs to support for
> +      Hart.
> +
> +    properties:
> +      compatible:
> +        enum:
> +          - mediatek,vcp-core
> +          - mediatek,mmup-core
> +
> +      twohart:

Missing vendor prefix, look at writing bindings and other examples.

> +        enum: [0, 1]
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +
> +      sram-offset:
> +        description:
> +          Allocated SRAM memory for each VCP core used.
> +        $ref: /schemas/types.yaml#/definitions/uint32
> +
> +    required:
> +      - compatible
> +      - twohart
> +      - sram-offset
> +
> +    additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - reg-names
> +  - interrupts
> +  - mboxes
> +  - mbox-names
> +  - power-domains
> +  - iommus
> +  - memory-region
> +  - vcp-mem-tbl
> +
> +additionalProperties: false
> +
> +examples:
> +  - |
> +    #include <dt-bindings/interrupt-controller/arm-gic.h>
> +    #include <dt-bindings/interrupt-controller/irq.h>
> +    #include <dt-bindings/power/mt8196-power.h>
> +
> +    vcp: vcp@...00000 {
> +        compatible = "mediatek,mt8196-vcp";
> +        reg = <0x31800000 0x60000>,
> +              <0x31a04000 0xa000>,
> +              <0x31bd0000 0x1000>,
> +              <0x31a70020 0x100>,
> +              <0x1c00091c 0x4>;

Quite different address,  are you sure this is still part of this
device? Looks like on register.


Best regards,
Krzysztof