linux-kernel - Re: [PATCH v2 3/8] dt-bindings: Add bindings for Tegra234 NVDEC

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]
Date:   Wed, 14 Sep 2022 15:19:01 +0300
From:   Mikko Perttunen <cyndis@...si.fi>
To:     Rob Herring <robh@...nel.org>
Cc:     Thierry Reding <thierry.reding@...il.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Jonathan Hunter <jonathanh@...dia.com>,
        devicetree@...r.kernel.org, Sameer Pujar <spujar@...dia.com>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Mikko Perttunen <mperttunen@...dia.com>,
        linux-tegra@...r.kernel.org, Ashish Mhetre <amhetre@...dia.com>
Subject: Re: [PATCH v2 3/8] dt-bindings: Add bindings for Tegra234 NVDEC

On 9/14/22 15:08, Rob Herring wrote:
> On Tue, Sep 13, 2022 at 04:14:41PM +0300, Mikko Perttunen wrote:
>> From: Mikko Perttunen <mperttunen@...dia.com>
>>
>> Update NVDEC bindings for Tegra234. This new engine version only has
>> two memory clients, but now requires three clocks, and as a bigger
>> change the engine loads firmware from a secure carveout configured by
>> the bootloader.
>>
>> For the latter, we need to add a phandle to the memory controller
>> to query the location of this carveout, and several other properties
>> containing offsets into the firmware inside the carveout. These
>> properties are intended to be populated through a device tree overlay
>> configured at flashing time, so that the values correspond to the
>> flashed NVDEC firmware.
>>
>> As the binding was getting large with many conditional properties,
>> also split the Tegra234 version out into a separate file.
>>
>> Signed-off-by: Mikko Perttunen <mperttunen@...dia.com>
>> ---
>> v2:
>> - Split out into separate file to avoid complexity with
>>    conditionals etc.
>> ---
>>   .../gpu/host1x/nvidia,tegra234-nvdec.yaml     | 154 ++++++++++++++++++
>>   1 file changed, 154 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml
>> new file mode 100644
>> index 000000000000..eab0475ca983
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpu/host1x/nvidia,tegra234-nvdec.yaml
>> @@ -0,0 +1,154 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: "http://devicetree.org/schemas/gpu/host1x/nvidia,tegra234-nvdec.yaml#"
>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#"
>> +
>> +title: Device tree binding for NVIDIA Tegra234 NVDEC
>> +
>> +description: |
>> +  NVDEC is the hardware video decoder present on NVIDIA Tegra210
>> +  and newer chips. It is located on the Host1x bus and typically
>> +  programmed through Host1x channels.
>> +
>> +maintainers:
>> +  - Thierry Reding <treding@...il.com>
>> +  - Mikko Perttunen <mperttunen@...dia.com>
>> +
>> +properties:
>> +  $nodename:
>> +    pattern: "^nvdec@[0-9a-f]*$"
>> +
>> +  compatible:
>> +    enum:
>> +      - nvidia,tegra234-nvdec
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  clocks:
>> +    maxItems: 3
>> +
>> +  clock-names:
>> +    items:
>> +      - const: nvdec
>> +      - const: fuse
>> +      - const: tsec_pka
>> +
>> +  resets:
>> +    maxItems: 1
>> +
>> +  reset-names:
>> +    items:
>> +      - const: nvdec
>> +
>> +  power-domains:
>> +    maxItems: 1
>> +
>> +  iommus:
>> +    maxItems: 1
>> +
>> +  dma-coherent: true
>> +
>> +  interconnects:
>> +    items:
>> +      - description: DMA read memory client
>> +      - description: DMA write memory client
>> +
>> +  interconnect-names:
>> +    items:
>> +      - const: dma-mem
>> +      - const: write
>> +
>> +  nvidia,memory-controller:
>> +    $ref: /schemas/types.yaml#/definitions/phandle
>> +    description:
>> +      phandle to the memory controller for determining carveout information.
>> +
>> +  nvidia,bl-manifest-offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      Offset to bootloader manifest from beginning of firmware. Typically set as
>> +      part of a device tree overlay corresponding to flashed firmware.
>> +
>> +  nvidia,bl-code-offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      Offset to bootloader code section from beginning of firmware. Typically set as
>> +      part of a device tree overlay corresponding to flashed firmware.
>> +
>> +  nvidia,bl-data-offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      Offset to bootloader data section from beginning of firmware. Typically set as
>> +      part of a device tree overlay corresponding to flashed firmware.
>> +
>> +  nvidia,os-manifest-offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      Offset to operating system manifest from beginning of firmware. Typically set as
>> +      part of a device tree overlay corresponding to flashed firmware.
>> +
>> +  nvidia,os-code-offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      Offset to operating system code section from beginning of firmware. Typically set as
>> +      part of a device tree overlay corresponding to flashed firmware.
>> +
>> +  nvidia,os-data-offset:
>> +    $ref: /schemas/types.yaml#/definitions/uint32
>> +    description:
>> +      Offset to operating system data section from beginning of firmware. Typically set as
>> +      part of a device tree overlay corresponding to flashed firmware.
> 
> I don't think DT is the place for describing your runtime loaded
> firmware layout.
> 
> Rob

The way I see it, from the kernel's point of view it's not runtime 
loaded but a contract with the bootloader. Bootloader sets up hardware 
in a certain way the kernel doesn't otherwise know so the bootloader 
needs to tell the kernel how the hardware is set up.

The fact that the information is supplied through an overlay is 
accidental -- equivalently the bootloader that sets up the firmware 
could adjust the device tree like we do in other situations, but in this 
case an overlay is an easier implementation method.

Thanks,
Mikko