Re: [PATCH V3 2/2] dt-bindings: remoteproc: k3-dsp: Remove board-specific compatible from DT example

On 11:10-20210924, Suman Anna wrote:

Hi Sinthu,

On 9/17/21 4:54 AM, Sinthu Raja wrote:

quoted

From: Sinthu Raja <redacted>

The example includes a board-specific compatible property, this is
wrong as the example should be board agnostic and gets in the way of
additions for newer platforms. Replace the same with a generic soc
node.

What board specific property? This description looks wrong.

See https://lore.kernel.org/all/1631794913.472895.1119414.nullmailer@robh.at.kernel.org/ (local)

quoted

Fixes: 2a2180206ab6 ("dt-bindings: remoteproc: Add bindings for C66x DSPs on TI K3 SoCs")

What error are you trying to fix exactly? The example used below is actually how
it exactly appears in the J721E dts files, and there are no errors with
dt_binding_check.

The rproc binding should have nothing to do with j721e SoC node
description. it should describe the rproc node that is described in
binding.

This is more a cleanup than a fix.  You can look through the original binding
submission patches to see why it is done like this.

This is blocking any updates we would want to do in k3.yaml.

If this is triggered by the changes you are making to k3.yaml file as part of
the J721E EAIK changes, then you probably may want to look at how you are doing

that again. Looks like the k3.yaml file is being modified now to enforce
"board-compatible", "soc-compatible" which may have triggered an error in this file.

Please evaluate if you need to modify it to support just the "soc-compatible" as
one of the items.

See above link. This is not to do with eaik / sk. I am trying to
standardize the board definitions in yaml for k3 and this binding
specifically is getting in the way.


I still don't understand what your contention is here. Are you arguing
that the binding example is correct and should be tied to a platform?


Yes, I know I can introduce oneOf and a little more intricate solution,
	but besides that, i disagree that a rproc binding should even
	have SoC specific top level node description in it.
a) rproc.yaml does'nt even describe the SoC. soc.yaml does.
b) The node property examples are supposed to be examples not tied to a
   specific SoC.

quoted

Signed-off-by: Sinthu Raja <redacted>
---

Changes since V2:
* review comment updates, including simplifying the changes, commit
  message and $subject updates.

V2: https://lore.kernel.org/all/20210818074030.1877-1-sinthu.raja@ti.com/ (local)
V1: https://lore.kernel.org/all/20210817152005.21575-1-sinthu.raja@ti.com/ (local)

 .../devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml       | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
index 6070456a7b67..5ec6505ac408 100644
--- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml
+++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml

@@ -133,9 +133,7 @@ unevaluatedProperties: false
 
 examples:
   - |
-    / {
-        model = "Texas Instruments K3 J721E SoC";
-        compatible = "ti,j721e";
+    soc {

While this may be resolving the dt_bindings_check you might be seeing with the
modified k3.yaml, note that "soc" property is not used on K3 dts files, you
might be creating confusion for people who look at this example and the actual
usage.

It is a common usage model. NOTE: these are example nodes and NOT meant
as SoC representation. I dont see the confusion.
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel