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
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>;
+ };
+ };
--
2.34.1
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>;
> + };
> + };
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
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
© 2016 - 2026 Red Hat, Inc.