diff mbox series

[RESEND,v3,1/3] dt-bindings: hwmon: esm: Add ESM support for TI K3 devices

Message ID 20230424105011.70674-2-n-francis@ti.com
State New
Headers
Series Add support for ESM |

Commit Message

Neha Malcom Francis April 24, 2023, 10:50 a.m. UTC 
  Document the binding for TI K3 ESM (Error Signaling Module) block.

Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
---
 .../bindings/hwmon/ti,j721e-esm.yaml          | 53 +++++++++++++++++++
 1 file changed, 53 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml

Comments

Krzysztof Kozlowski April 24, 2023, 2:38 p.m. UTC | #1 
On 24/04/2023 12:50, Neha Malcom Francis wrote:
> Document the binding for TI K3 ESM (Error Signaling Module) block.
> 
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> ---
>  .../bindings/hwmon/ti,j721e-esm.yaml          | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

---

This is an automated instruction, just in case, because many review tags
are being ignored. If you do not know the process, here is a short
explanation:

Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions, under or above your Signed-off-by tag. Tools like b4 can help
here. However, there's no need to repost patches *only* to add the tags.
The upstream maintainer will do that for acks received on the version
they apply.

https://elixir.bootlin.com/linux/v5.17/source/Documentation/process/submitting-patches.rst#L540

Best regards,
Krzysztof
Guenter Roeck April 24, 2023, 2:44 p.m. UTC | #2 
On Mon, Apr 24, 2023 at 04:20:09PM +0530, Neha Malcom Francis wrote:
> Document the binding for TI K3 ESM (Error Signaling Module) block.
> 
> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>

I think I am missing what this has to do with hardware
monitoring. I see a driver submission into drivers/misc,
but that doesn't explain the suggested location of the
devicetree bindings, and I kind of resist the idea that hwmon
should be the dumping ground for bindings which don't have
a home.

Guenter

> ---
>  .../bindings/hwmon/ti,j721e-esm.yaml          | 53 +++++++++++++++++++
>  1 file changed, 53 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
> 
> diff --git a/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
> new file mode 100644
> index 000000000000..c5eb7f46cc46
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
> @@ -0,0 +1,53 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# Copyright (C) 2022 Texas Instruments Incorporated
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/hwmon/ti,j721e-esm.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments K3 ESM
> +
> +maintainers:
> +  - Neha Malcom Francis <n-francis@ti.com>
> +
> +description:
> +  The ESM (Error Signaling Module) is an IP block on TI K3 devices
> +  that allows handling of safety events somewhat similar to what interrupt
> +  controller would do. The safety signals have their separate paths within
> +  the SoC, and they are handled by the ESM, which routes them to the proper
> +  destination, which can be system reset, interrupt controller, etc. In the
> +  simplest configuration the signals are just routed to reset the SoC.
> +
> +properties:
> +  compatible:
> +    const: ti,j721e-esm
> +
> +  reg:
> +    maxItems: 1
> +
> +  ti,esm-pins:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +    description:
> +      integer array of ESM interrupt pins to route to external event pin
> +      which can be used to reset the SoC.
> +    minItems: 1
> +    maxItems: 255
> +
> +additionalProperties: false
> +
> +required:
> +  - compatible
> +  - reg
> +  - ti,esm-pins
> +
> +examples:
> +  - |
> +    bus {
> +        #address-cells = <2>;
> +        #size-cells = <2>;
> +        esm@700000 {
> +            compatible = "ti,j721e-esm";
> +            reg = <0x0 0x700000 0x0 0x1000>;
> +            ti,esm-pins = <344>, <345>;
> +        };
> +    };
Krzysztof Kozlowski April 25, 2023, 9:07 a.m. UTC | #3 
On 24/04/2023 16:44, Guenter Roeck wrote:
> On Mon, Apr 24, 2023 at 04:20:09PM +0530, Neha Malcom Francis wrote:
>> Document the binding for TI K3 ESM (Error Signaling Module) block.
>>
>> Signed-off-by: Neha Malcom Francis <n-francis@ti.com>
> 
> I think I am missing what this has to do with hardware
> monitoring. I see a driver submission into drivers/misc,
> but that doesn't explain the suggested location of the
> devicetree bindings, and I kind of resist the idea that hwmon
> should be the dumping ground for bindings which don't have
> a home.

Hi Guenter,

This was my suggestion in the previous version, that this device could
look like something related to fault handling or hardware monitoring.
Whether it fits hwmon, I am no sure, just proposed it. Definitely I do
not think of hwmon as dumping ground, but I am rather trying to find
proper place for esm, instead of dumping it in misc (which is a dumping
ground :) ).

https://lore.kernel.org/all/eb6bfe2e-1e44-bfb5-01b9-bbf53eba6501@linaro.org/

Best regards,
Krzysztof
diff mbox series

Patch

diff --git a/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
new file mode 100644
index 000000000000..c5eb7f46cc46
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ti,j721e-esm.yaml
@@ -0,0 +1,53 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# Copyright (C) 2022 Texas Instruments Incorporated
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/ti,j721e-esm.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 ESM
+
+maintainers:
+  - Neha Malcom Francis <n-francis@ti.com>
+
+description:
+  The ESM (Error Signaling Module) is an IP block on TI K3 devices
+  that allows handling of safety events somewhat similar to what interrupt
+  controller would do. The safety signals have their separate paths within
+  the SoC, and they are handled by the ESM, which routes them to the proper
+  destination, which can be system reset, interrupt controller, etc. In the
+  simplest configuration the signals are just routed to reset the SoC.
+
+properties:
+  compatible:
+    const: ti,j721e-esm
+
+  reg:
+    maxItems: 1
+
+  ti,esm-pins:
+    $ref: /schemas/types.yaml#/definitions/uint32-array
+    description:
+      integer array of ESM interrupt pins to route to external event pin
+      which can be used to reset the SoC.
+    minItems: 1
+    maxItems: 255
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - ti,esm-pins
+
+examples:
+  - |
+    bus {
+        #address-cells = <2>;
+        #size-cells = <2>;
+        esm@700000 {
+            compatible = "ti,j721e-esm";
+            reg = <0x0 0x700000 0x0 0x1000>;
+            ti,esm-pins = <344>, <345>;
+        };
+    };