On 3/25/23 4:05 AM, Krzysztof Kozlowski wrote: > On 23/03/2023 02:29, Dipen Patel wrote: >> The property is not necessary as it is a constant value and can be >> hardcoded in the driver code. >> >> Signed-off-by: Dipen Patel <dipenp@xxxxxxxxxx> >> --- >> .../timestamp/nvidia,tegra194-hte.yaml | 43 ++----------------- >> 1 file changed, 4 insertions(+), 39 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml >> index 158dbe58c49f..eafc33e9ae2e 100644 >> --- a/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml >> +++ b/Documentation/devicetree/bindings/timestamp/nvidia,tegra194-hte.yaml >> @@ -42,10 +42,13 @@ properties: >> >> nvidia,slices: >> $ref: /schemas/types.yaml#/definitions/uint32 >> + deprecated: true >> 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 the value depends on the HTE instance in the chip. >> + property and the value depends on the HTE instance in the chip. The AON >> + GTE instances for both Tegra194 and Tegra234 has 3 slices. The Tegra194 >> + LIC instance has 11 slices and Tegra234 LIC has 17 slices. >> enum: [3, 11, 17] >> >> '#timestamp-cells': >> @@ -56,46 +59,10 @@ 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 > > You just added this entire block in previous patch. Adding it there and > immediately removing does not make much sense. Yes, probably I should just keep that block in this patch as it is since there is a deprecate field already introduced by this patch which should be enough. >> - > > > > Best regards, > Krzysztof >
