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:   Tue, 29 Nov 2022 18:55:04 -0800
From:   Dipen Patel <dipenp@...dia.com>
To:     Rob Herring <robh@...nel.org>
Cc:     thierry.reding@...il.com, jonathanh@...dia.com,
        linux-kernel@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-gpio@...r.kernel.org, linus.walleij@...aro.org,
        devicetree@...r.kernel.org, linux-doc@...r.kernel.org,
        timestamp@...ts.linux.dev
Subject: Re: [PATCH 4/7] dt-bindings: timestamp: Add Tegra234 support

On 11/7/22 12:06 PM, Rob Herring wrote:
> On Thu, Nov 03, 2022 at 10:45:20AM -0700, Dipen Patel wrote:
>> Added timestamp provider support for the Tegra234 in devicetree
>> bindings.
>>
>> Signed-off-by: Dipen Patel <dipenp@...dia.com>
>> ---
>>  .../timestamp/nvidia,tegra194-hte.yaml        | 44 +++++++++++++++++--
>>  1 file changed, 40 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> index c31e207d1652..158dbe58c49f 100644
>> --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml
>> @@ -4,7 +4,7 @@
>>  $id: http://devicetree.org/schemas/timestamp/nvidia,tegra194-hte.yaml#
>>  $schema: http://devicetree.org/meta-schemas/core.yaml#
>>  
>> -title: Tegra194 on chip generic hardware timestamping engine (HTE)
>> +title: Tegra on chip generic hardware timestamping engine (HTE) provider
>>  
>>  maintainers:
>>    - Dipen Patel <dipenp@...dia.com>
>> @@ -23,6 +23,8 @@ properties:
>>      enum:
>>        - nvidia,tegra194-gte-aon
>>        - nvidia,tegra194-gte-lic
>> +      - nvidia,tegra234-gte-aon
>> +      - nvidia,tegra234-gte-lic
> 
> How is the h/w in this chip different from the existing one? I'm 
> assuming it must be because you don't have a fallback compatible.
t234-gte-lic has different slices and signal lines it can support. t234-gte-aon
has again different slices and more gpio lines it can support and has
different GTE-GPIO mapping than t194-gte-aon.
> 
>>  
>>    reg:
>>      maxItems: 1
>> @@ -43,9 +45,8 @@ properties:
>>      description:
>>        HTE lines are arranged in 32 bit slice where each bit represents different
>>        line/signal that it can enable/configure for the timestamp. It is u32
>> -      property and depends on the HTE instance in the chip. The value 3 is for
>> -      GPIO GTE and 11 for IRQ GTE.
>> -    enum: [3, 11]
>> +      property and the value depends on the HTE instance in the chip.
> 
> If this statement was true, then this property makes sense...
> 
>> +    enum: [3, 11, 17]
>>  
>>    '#timestamp-cells':
>>      description:
>> @@ -55,6 +56,41 @@ properties:
>>        mentioned in the nvidia GPIO device tree binding document.
>>      const: 1
>>  
>> +allOf:
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra194-gte-aon
>> +              - nvidia,tegra234-gte-aon
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 3
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra194-gte-lic
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 11
>> +
>> +  - if:
>> +      properties:
>> +        compatible:
>> +          contains:
>> +            enum:
>> +              - nvidia,tegra234-gte-lic
>> +    then:
>> +      properties:
>> +        nvidia,slices:
>> +          const: 17
> 
> However, if there is only one possible value for each compatible, then 
> being per instance can't really be true. I guess 'aon' or 'lic' define 
> the instance? That's not normal practice. Are there other differences?
aon and lic are gte hardware instances but meant for different signals i.e.
lic is for interrupt lines while aon is for always on domain GPIO lines.
> 
> It seems like 'nvidia,slices' should be implied from the compatible 
> string.
thats true, assuming we have all those specified compatible strings from this patch.
> 
> Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ