* [PATCH 01/11] dt-bindings: gpio: Add NVIDIA LSTP GPIO
2026-10-12 17:35 [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Adrian Ambrozewicz
@ 2026-10-12 17:35 ` Adrian Ambrozewicz
2026-10-12 17:43 ` sashiko-bot
2026-10-13 6:09 ` Krzysztof Kozlowski
2026-10-12 17:36 ` [PATCH 02/11] dt-bindings: i2c: Add NVIDIA LSTP I2C Adrian Ambrozewicz
` (4 subsequent siblings)
5 siblings, 2 replies; 16+ messages in thread
From: Adrian Ambrozewicz @ 2026-10-12 17:35 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Donald Shannon, linux-usb, linux-gpio, devicetree, linux-kernel,
Greg Kroah-Hartman
Add the binding for a GPIO channel of an NVIDIA LSTP USB adapter. The
node is a child of the adapter's USB device or interface node, matched
to a channel the device reports by reg (the channel ID) and compatible
(the channel type).
The device firmware reports the number of lines and their names and
directions; the node adds line names, hogs and interrupt consumers. Pins
the firmware reports as LEDs are LEDs, not GPIO lines, and an optional
leds child node describes them.
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
---
.../bindings/gpio/nvidia,lstp-gpio.yaml | 276 ++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 283 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
diff --git a/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
new file mode 100644
index 000000000000..4ca5081e509d
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
@@ -0,0 +1,276 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/gpio/nvidia,lstp-gpio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA LSTP GPIO Channel
+
+maintainers:
+ - Adrian Ambrozewicz <aambrozewicz@nvidia.com>
+ - Donald Shannon <donalds@nvidia.com>
+
+description: |
+ GPIO controller channel on an NVIDIA LSTP USB device.
+
+ The number of GPIO lines and their default names and directions are
+ reported by the device firmware.
+
+ gpio-line-names overrides the firmware-reported pin names. The
+ gpio-controller and #gpio-cells properties let consumers (e.g.
+ gpio-leds, gpio-keys) reference the lines by phandle.
+
+ The channel is also an interrupt controller. A consumer may reference
+ a line through a *-gpios property and use it as an interrupt, or
+ reference it through interrupts-extended, or interrupt-parent and
+ interrupts, using the interrupt-controller and #interrupt-cells
+ properties. An interrupt line must be an input; the firmware-reported
+ pin direction is authoritative and is not changed at runtime.
+
+ GPIO hog child nodes are supported for boot-time pin configuration.
+
+ Pins the device firmware reports as LEDs are not GPIO lines; each is
+ an LED instead, named after the firmware pin name. An optional leds
+ child node describes some of them: their names, initial state, default
+ trigger, and a pattern the device plays on its own.
+
+ Because the controller sits behind USB, every line access is a USB
+ transaction that blocks until it completes. Consumers that need
+ non-blocking line access cannot use this controller.
+
+properties:
+ compatible:
+ const: nvidia,lstp-gpio
+
+ reg:
+ description: Channel ID reported by the device firmware.
+ maxItems: 1
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description: |
+ Two cells: pin number and flags.
+ Cell 0: GPIO pin offset (0-based).
+ Cell 1: GPIO flags (e.g. GPIO_ACTIVE_LOW).
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+ description: |
+ Two cells: GPIO line offset and trigger flags.
+ Cell 0: GPIO line offset (0-based), same numbering as #gpio-cells.
+ Cell 1: Trigger flags (see <dt-bindings/interrupt-controller/irq.h>).
+
+ gpio-line-names:
+ description: |
+ Optional list of human-readable names for each GPIO line.
+ Overrides the firmware-reported pin names. The number of entries
+ must not exceed the number of GPIO lines reported by firmware.
+ minItems: 1
+ maxItems: 255
+
+ leds:
+ type: object
+ description: |
+ LED pins of the channel. A pin the device firmware reports as an
+ LED is an LED whether or not it has a node here, and a node for a
+ pin the firmware does not report as an LED is ignored.
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ patternProperties:
+ "^led@[0-9a-f]+$":
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+ description: |
+ One LED pin. The LED takes its name from label, or from color,
+ function and function-enumerator, instead of the firmware pin
+ name.
+
+ properties:
+ reg:
+ description: Pin number, in the channel's own pin numbering.
+ maxItems: 1
+
+ default-state:
+ description: |
+ Written to the device once, when the LED is set up, and "off"
+ when absent, as in leds/common.yaml. "keep" leaves the LED as
+ the device firmware set it; the device cannot report its
+ current state. Not written for a node with led-pattern.
+
+ led-pattern:
+ description: |
+ A pattern the device plays in a loop once the LED is set up.
+ Each entry is <brightness duration>: brightness from 0 to
+ 255, held or faded towards for duration milliseconds,
+ depending on the pin's firmware-reported LED mode. The
+ pattern is sent to the device once and played there without
+ further USB traffic. It must fit in a single request, which
+ for a device with 64-byte USB endpoints is ten entries; a
+ longer pattern is not sent.
+ minItems: 1
+ maxItems: 255
+ items:
+ items:
+ - description: Brightness
+ maximum: 255
+ - description: Duration in milliseconds
+
+ active-low: false
+ flash-max-microamp: false
+ flash-max-timeout-us: false
+ inactive-high-impedance: false
+ led-max-microamp: false
+ led-sources: false
+ max-brightness: false
+ panic-indicator: false
+ retain-state-shutdown: false
+ retain-state-suspended: false
+
+ required:
+ - reg
+
+ anyOf:
+ - required: [label]
+ - required: [function]
+
+ dependentSchemas:
+ led-pattern:
+ properties:
+ default-state: false
+ linux,default-trigger: false
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ additionalProperties: false
+
+patternProperties:
+ "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
+ type: object
+ required:
+ - gpio-hog
+
+dependentRequired:
+ interrupt-controller: ["#interrupt-cells"]
+ "#interrupt-cells": [interrupt-controller]
+
+required:
+ - compatible
+ - reg
+ - gpio-controller
+ - "#gpio-cells"
+
+additionalProperties: false
+
+examples:
+ - |
+ /* Minimal: let firmware define pin count and names */
+ interface {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@3 {
+ compatible = "nvidia,lstp-gpio";
+ reg = <3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ - |
+ /* Override pin names and add a hog */
+ interface {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio_ch: gpio@3 {
+ compatible = "nvidia,lstp-gpio";
+ reg = <3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "STATUS_LED", "ALERT_INT";
+
+ led-hog {
+ gpio-hog;
+ gpios = <0 0>;
+ output-high;
+ line-name = "status-led-hog";
+ };
+ };
+ };
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ /* Act as an interrupt controller for a consumer via interrupts-extended */
+ interface {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio_irq_ch: gpio@3 {
+ compatible = "nvidia,lstp-gpio";
+ reg = <3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ key-alert {
+ label = "alert";
+ linux,code = <143>; /* KEY_WAKEUP */
+ /* Line 1 as a falling-edge interrupt source */
+ interrupts-extended = <&gpio_irq_ch 1 IRQ_TYPE_EDGE_FALLING>;
+ };
+ };
+ - |
+ #include <dt-bindings/leds/common.h>
+
+ /* Name two firmware-reported LED pins; one plays a pattern on its own */
+ interface {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ gpio@3 {
+ compatible = "nvidia,lstp-gpio";
+ reg = <3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@4 {
+ reg = <4>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_POWER;
+ default-state = "on";
+ };
+
+ led@5 {
+ reg = <5>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_STATUS;
+ /* Two short flashes, then a pause */
+ led-pattern = <255 100>, <0 100>, <255 100>, <0 700>;
+ };
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 65e8a4b5c90b..284000589694 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19565,6 +19565,13 @@ L: linux-acpi@vger.kernel.org
S: Maintained
F: drivers/acpi/apei/ghes-nvidia.c
+NVIDIA LSTP USB ADAPTER DRIVERS
+M: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
+M: Donald Shannon <donalds@nvidia.com>
+L: linux-usb@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
+
NVIDIA VRS RTC DRIVER
M: Shubhi Garg <shgarg@nvidia.com>
L: linux-tegra@vger.kernel.org
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH 01/11] dt-bindings: gpio: Add NVIDIA LSTP GPIO
2026-10-12 17:35 ` [PATCH 01/11] dt-bindings: gpio: Add NVIDIA LSTP GPIO Adrian Ambrozewicz
@ 2026-10-12 17:43 ` sashiko-bot
2026-10-13 6:09 ` Krzysztof Kozlowski
1 sibling, 0 replies; 16+ messages in thread
From: sashiko-bot @ 2026-10-12 17:43 UTC (permalink / raw)
To: Adrian Ambrozewicz; +Cc: robh, linux-gpio, devicetree, linux-usb, conor+dt
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: missing interrupt-controller in required list
--
commit aeb4a4fc6444001bea560a7fa11534922cb0e28e
Author: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
dt-bindings: gpio: Add NVIDIA LSTP GPIO
Add the binding for a GPIO channel of an NVIDIA LSTP USB adapter. The
node is a child of the adapter's USB device or interface node, matched
to a channel the device reports by reg and compatible.
> diff --git a/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
> new file mode 100644
> index 0000000000000..4ca5081e509d5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
[ ... ]
> +dependentRequired:
> + interrupt-controller: ["#interrupt-cells"]
> + "#interrupt-cells": [interrupt-controller]
> +
> +required:
> + - compatible
> + - reg
> + - gpio-controller
> + - "#gpio-cells"
[Severity: Medium]
The documentation states this hardware is also an interrupt controller, but
this required list omits the interrupt-controller and #interrupt-cells
properties.
Should interrupt-controller and #interrupt-cells be moved from
dependentRequired into this unconditional required list? Subsystem rules
mandate that core hardware provider capabilities like an interrupt controller
must be globally required with appropriate constraints. Placing them in
dependentRequired treats them as optional rather than globally required.
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + /* Minimal: let firmware define pin count and names */
> + interface {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio@3 {
> + compatible = "nvidia,lstp-gpio";
> + reg = <3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
[Severity: Medium]
Does this example omit the interrupt provider capabilities?
Subsystem rules require that all examples include all required properties.
If the interrupt-controller properties are made globally required, examples
1, 2, and 4 will also need to be updated to include them.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012-lstp-usb-adapter-v1-0-aambrozewicz@nvidia.com?part=1
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 01/11] dt-bindings: gpio: Add NVIDIA LSTP GPIO
2026-10-12 17:35 ` [PATCH 01/11] dt-bindings: gpio: Add NVIDIA LSTP GPIO Adrian Ambrozewicz
2026-10-12 17:43 ` sashiko-bot
@ 2026-10-13 6:09 ` Krzysztof Kozlowski
1 sibling, 0 replies; 16+ messages in thread
From: Krzysztof Kozlowski @ 2026-10-13 6:09 UTC (permalink / raw)
To: Adrian Ambrozewicz, Linus Walleij, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Donald Shannon, linux-usb, linux-gpio, devicetree, linux-kernel,
Greg Kroah-Hartman
On 12/10/2026 19:35, Adrian Ambrozewicz wrote:
> Add the binding for a GPIO channel of an NVIDIA LSTP USB adapter. The
> node is a child of the adapter's USB device or interface node, matched
> to a channel the device reports by reg (the channel ID) and compatible
> (the channel type).
>
> The device firmware reports the number of lines and their names and
> directions; the node adds line names, hogs and interrupt consumers. Pins
> the firmware reports as LEDs are LEDs, not GPIO lines, and an optional
> leds child node describes them.
>
> Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
> ---
> .../bindings/gpio/nvidia,lstp-gpio.yaml | 276 ++++++++++++++++++
> MAINTAINERS | 7 +
> 2 files changed, 283 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
>
> diff --git a/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml b/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
> new file mode 100644
> index 000000000000..4ca5081e509d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
> @@ -0,0 +1,276 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/nvidia,lstp-gpio.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA LSTP GPIO Channel
> +
> +maintainers:
> + - Adrian Ambrozewicz <aambrozewicz@nvidia.com>
> + - Donald Shannon <donalds@nvidia.com>
> +
> +description: |
> + GPIO controller channel on an NVIDIA LSTP USB device.
What is LSTP?
> +
> + The number of GPIO lines and their default names and directions are
> + reported by the device firmware.
> +
> + gpio-line-names overrides the firmware-reported pin names. The
> + gpio-controller and #gpio-cells properties let consumers (e.g.
> + gpio-leds, gpio-keys) reference the lines by phandle.
Why are you describing the binding? This is pointless. Describe the
hardware.
> +
> + The channel is also an interrupt controller. A consumer may reference
> + a line through a *-gpios property and use it as an interrupt, or
What? Please read other bindings to understand what is here.
> + reference it through interrupts-extended, or interrupt-parent and
> + interrupts, using the interrupt-controller and #interrupt-cells
> + properties. An interrupt line must be an input; the firmware-reported
> + pin direction is authoritative and is not changed at runtime.
> +
> + GPIO hog child nodes are supported for boot-time pin configuration.
> +
> + Pins the device firmware reports as LEDs are not GPIO lines; each is
> + an LED instead, named after the firmware pin name. An optional leds
> + child node describes some of them: their names, initial state, default
> + trigger, and a pattern the device plays on its own.
> +
> + Because the controller sits behind USB, every line access is a USB
> + transaction that blocks until it completes. Consumers that need
> + non-blocking line access cannot use this controller.
> +
> +properties:
> + compatible:
> + const: nvidia,lstp-gpio
What is lstp?
> +
> + reg:
> + description: Channel ID reported by the device firmware.
> + maxItems: 1
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> + description: |
> + Two cells: pin number and flags.
> + Cell 0: GPIO pin offset (0-based).
> + Cell 1: GPIO flags (e.g. GPIO_ACTIVE_LOW).
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> + description: |
> + Two cells: GPIO line offset and trigger flags.
> + Cell 0: GPIO line offset (0-based), same numbering as #gpio-cells.
> + Cell 1: Trigger flags (see <dt-bindings/interrupt-controller/irq.h>).
> +
> + gpio-line-names:
> + description: |
> + Optional list of human-readable names for each GPIO line.
> + Overrides the firmware-reported pin names. The number of entries
> + must not exceed the number of GPIO lines reported by firmware.
> + minItems: 1
> + maxItems: 255
> +
> + leds:
> + type: object
> + description: |
> + LED pins of the channel. A pin the device firmware reports as an
> + LED is an LED whether or not it has a node here, and a node for a
> + pin the firmware does not report as an LED is ignored.
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + patternProperties:
> + "^led@[0-9a-f]+$":
> + type: object
> + $ref: /schemas/leds/common.yaml#
> + unevaluatedProperties: false
> + description: |
> + One LED pin. The LED takes its name from label, or from color,
> + function and function-enumerator, instead of the firmware pin
> + name.
> +
> + properties:
> + reg:
> + description: Pin number, in the channel's own pin numbering.
> + maxItems: 1
> +
> + default-state:
> + description: |
> + Written to the device once, when the LED is set up, and "off"
> + when absent, as in leds/common.yaml. "keep" leaves the LED as
> + the device firmware set it; the device cannot report its
> + current state. Not written for a node with led-pattern.
> +
> + led-pattern:
> + description: |
> + A pattern the device plays in a loop once the LED is set up.
> + Each entry is <brightness duration>: brightness from 0 to
> + 255, held or faded towards for duration milliseconds,
> + depending on the pin's firmware-reported LED mode. The
> + pattern is sent to the device once and played there without
> + further USB traffic. It must fit in a single request, which
> + for a device with 64-byte USB endpoints is ten entries; a
> + longer pattern is not sent.
> + minItems: 1
> + maxItems: 255
> + items:
> + items:
> + - description: Brightness
> + maximum: 255
> + - description: Duration in milliseconds
> +
> + active-low: false
> + flash-max-microamp: false
> + flash-max-timeout-us: false
> + inactive-high-impedance: false
> + led-max-microamp: false
> + led-sources: false
> + max-brightness: false
> + panic-indicator: false
> + retain-state-shutdown: false
> + retain-state-suspended: false
Why are you repeating all standard properties? Drop.
> +
> + required:
> + - reg
> +
> + anyOf:
> + - required: [label]
> + - required: [function]
I don't get why simple binding is made so complicated.
> +
> + dependentSchemas:
> + led-pattern:
> + properties:
> + default-state: false
> + linux,default-trigger: false
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> +
> + additionalProperties: false
> +
> +patternProperties:
> + "^(hog-[0-9]+|.+-hog(-[0-9]+)?)$":
> + type: object
> + required:
> + - gpio-hog
> +
> +dependentRequired:
> + interrupt-controller: ["#interrupt-cells"]
> + "#interrupt-cells": [interrupt-controller]
> +
> +required:
> + - compatible
> + - reg
> + - gpio-controller
> + - "#gpio-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + /* Minimal: let firmware define pin count and names */
> + interface {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio@3 {
> + compatible = "nvidia,lstp-gpio";
> + reg = <3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> + - |
> + /* Override pin names and add a hog */
> + interface {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio_ch: gpio@3 {
> + compatible = "nvidia,lstp-gpio";
> + reg = <3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-line-names = "STATUS_LED", "ALERT_INT";
> +
> + led-hog {
> + gpio-hog;
> + gpios = <0 0>;
> + output-high;
> + line-name = "status-led-hog";
> + };
> + };
> + };
> + - |
> + #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + /* Act as an interrupt controller for a consumer via interrupts-extended */
> + interface {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio_irq_ch: gpio@3 {
> + compatible = "nvidia,lstp-gpio";
> + reg = <3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + key-alert {
> + label = "alert";
> + linux,code = <143>; /* KEY_WAKEUP */
> + /* Line 1 as a falling-edge interrupt source */
> + interrupts-extended = <&gpio_irq_ch 1 IRQ_TYPE_EDGE_FALLING>;
> + };
> + };
Drop irrelevant. Keep only one complete example. Two if they are different.
> + - |
> + #include <dt-bindings/leds/common.h>
> +
> + /* Name two firmware-reported LED pins; one plays a pattern on its own */
> + interface {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio@3 {
> + compatible = "nvidia,lstp-gpio";
> + reg = <3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> +
> + leds {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + led@4 {
> + reg = <4>;
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_POWER;
> + default-state = "on";
> + };
> +
> + led@5 {
> + reg = <5>;
> + color = <LED_COLOR_ID_AMBER>;
> + function = LED_FUNCTION_STATUS;
> + /* Two short flashes, then a pause */
> + led-pattern = <255 100>, <0 100>, <255 100>, <0 700>;
> + };
> + };
> + };
So that's the only example you should keep.
> + };
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 02/11] dt-bindings: i2c: Add NVIDIA LSTP I2C
2026-10-12 17:35 [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Adrian Ambrozewicz
2026-10-12 17:35 ` [PATCH 01/11] dt-bindings: gpio: Add NVIDIA LSTP GPIO Adrian Ambrozewicz
@ 2026-10-12 17:36 ` Adrian Ambrozewicz
2026-10-12 17:41 ` sashiko-bot
2026-10-13 6:11 ` Krzysztof Kozlowski
2026-10-12 17:36 ` [PATCH 03/11] dt-bindings: spi: Add NVIDIA LSTP SPI Adrian Ambrozewicz
` (3 subsequent siblings)
5 siblings, 2 replies; 16+ messages in thread
From: Adrian Ambrozewicz @ 2026-10-12 17:36 UTC (permalink / raw)
To: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Donald Shannon, linux-usb, linux-i2c, devicetree, linux-kernel,
Greg Kroah-Hartman
Add the binding for an I2C controller channel of an NVIDIA LSTP USB
adapter. Peripherals on the bus are child nodes, as for any I2C
controller. The device sets the bus speed and the protocol cannot
change it, so clock-frequency is not supported.
nvidia,retries sets how many times the host re-issues a transfer that
failed on arbitration loss or a busy bus (default 3). The generic I2C
controller schema has no property for this. A device that reports its
own arbitration retries handles both cases itself, and the property is
ignored for it.
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
---
.../bindings/i2c/nvidia,lstp-i2c.yaml | 71 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 72 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
new file mode 100644
index 000000000000..eacabed52cd1
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/i2c/nvidia,lstp-i2c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA LSTP I2C Channel
+
+maintainers:
+ - Adrian Ambrozewicz <aambrozewicz@nvidia.com>
+ - Donald Shannon <donalds@nvidia.com>
+
+description: |
+ I2C controller channel on an NVIDIA LSTP USB device.
+
+ Peripherals on the bus are described as child nodes. An i2c alias
+ gives the bus a fixed number.
+
+ The bus speed is set by the device. The LSTP protocol has no way to
+ change it, so clock-frequency is not supported and is ignored.
+
+allOf:
+ - $ref: /schemas/i2c/i2c-controller.yaml#
+
+properties:
+ compatible:
+ const: nvidia,lstp-i2c
+
+ reg:
+ description: Channel ID reported by the device firmware.
+ maxItems: 1
+
+ nvidia,retries:
+ description: |
+ Number of times the host re-issues a transfer that fails on
+ arbitration loss or a busy bus before giving up.
+
+ Ignored when the channel config reports non-zero bus arbitration
+ retries. Such a device is expected to retry both arbitration loss and
+ a busy bus itself before reporting failure, so the host adds no
+ attempts on top.
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 255
+ default: 3
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interface {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@2 {
+ compatible = "nvidia,lstp-i2c";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ nvidia,retries = <5>;
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp102";
+ reg = <0x48>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 284000589694..d8092f6d91b2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19571,6 +19571,7 @@ M: Donald Shannon <donalds@nvidia.com>
L: linux-usb@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
+F: Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
NVIDIA VRS RTC DRIVER
M: Shubhi Garg <shgarg@nvidia.com>
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH 02/11] dt-bindings: i2c: Add NVIDIA LSTP I2C
2026-10-12 17:36 ` [PATCH 02/11] dt-bindings: i2c: Add NVIDIA LSTP I2C Adrian Ambrozewicz
@ 2026-10-12 17:41 ` sashiko-bot
2026-10-13 6:11 ` Krzysztof Kozlowski
1 sibling, 0 replies; 16+ messages in thread
From: sashiko-bot @ 2026-10-12 17:41 UTC (permalink / raw)
To: Adrian Ambrozewicz; +Cc: conor+dt, linux-usb, robh, devicetree
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: incomplete schema validation allows unsupported clock-frequency property
--
commit 16ee132f4b8daa2cd636b3b3437f38ceb664442e
Author: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
dt-bindings: i2c: Add NVIDIA LSTP I2C
This commit adds a device tree binding for the I2C controller channel on an
NVIDIA LSTP USB device. It includes configurations for the compatible string,
register ID, and a custom property for arbitration retries. The documentation
notes that the device sets the bus speed, so clock-frequency is unsupported.
> diff --git a/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
> new file mode 100644
> index 0000000000000..eacabed52cd1c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
> @@ -0,0 +1,71 @@
[ ... ]
> +description: |
> + I2C controller channel on an NVIDIA LSTP USB device.
> +
> + Peripherals on the bus are described as child nodes. An i2c alias
> + gives the bus a fixed number.
> +
> + The bus speed is set by the device. The LSTP protocol has no way to
> + change it, so clock-frequency is not supported and is ignored.
> +
> +allOf:
> + - $ref: /schemas/i2c/i2c-controller.yaml#
> +
> +properties:
> + compatible:
> + const: nvidia,lstp-i2c
[Severity: Low]
Since this schema inherits from /schemas/i2c/i2c-controller.yaml# which
evaluates and permits the standard clock-frequency property, should
clock-frequency: false be explicitly defined in this properties block?
Because the property is evaluated by the $ref, the unevaluatedProperties:
false directive at the bottom of the schema does not reject it. Device
trees that incorrectly specify clock-frequency for this controller will
silently pass schema validation, despite the binding's documentation stating
it is not supported.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012-lstp-usb-adapter-v1-0-aambrozewicz@nvidia.com?part=2
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 02/11] dt-bindings: i2c: Add NVIDIA LSTP I2C
2026-10-12 17:36 ` [PATCH 02/11] dt-bindings: i2c: Add NVIDIA LSTP I2C Adrian Ambrozewicz
2026-10-12 17:41 ` sashiko-bot
@ 2026-10-13 6:11 ` Krzysztof Kozlowski
1 sibling, 0 replies; 16+ messages in thread
From: Krzysztof Kozlowski @ 2026-10-13 6:11 UTC (permalink / raw)
To: Adrian Ambrozewicz, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Donald Shannon, linux-usb, linux-i2c, devicetree, linux-kernel,
Greg Kroah-Hartman
On 12/10/2026 19:36, Adrian Ambrozewicz wrote:
> Add the binding for an I2C controller channel of an NVIDIA LSTP USB
> adapter. Peripherals on the bus are child nodes, as for any I2C
> controller. The device sets the bus speed and the protocol cannot
> change it, so clock-frequency is not supported.
>
> nvidia,retries sets how many times the host re-issues a transfer that
> failed on arbitration loss or a busy bus (default 3). The generic I2C
> controller schema has no property for this. A device that reports its
> own arbitration retries handles both cases itself, and the property is
> ignored for it.
>
> Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
> ---
> .../bindings/i2c/nvidia,lstp-i2c.yaml | 71 +++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
>
> diff --git a/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml b/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
> new file mode 100644
> index 000000000000..eacabed52cd1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
> @@ -0,0 +1,71 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
We do not use that tag. Drop it everywhere.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/i2c/nvidia,lstp-i2c.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA LSTP I2C Channel
> +
> +maintainers:
> + - Adrian Ambrozewicz <aambrozewicz@nvidia.com>
> + - Donald Shannon <donalds@nvidia.com>
> +
> +description: |
> + I2C controller channel on an NVIDIA LSTP USB device.
Say something useful.
> +
> + Peripherals on the bus are described as child nodes. An i2c alias
> + gives the bus a fixed number.
What are you describing here?
> +
> + The bus speed is set by the device. The LSTP protocol has no way to
> + change it, so clock-frequency is not supported and is ignored.
> +
> +allOf:
> + - $ref: /schemas/i2c/i2c-controller.yaml#
> +
> +properties:
> + compatible:
> + const: nvidia,lstp-i2c
> +
> + reg:
> + description: Channel ID reported by the device firmware.
> + maxItems: 1
> +
> + nvidia,retries:
You described the desired Linux feature or behavior, not the actual
hardware. The bindings are about the latter, so instead you need to
rephrase the property and its description to match actual hardware
capabilities/features/configuration etc.
> + description: |
> + Number of times the host re-issues a transfer that fails on
> + arbitration loss or a busy bus before giving up.
> +
> + Ignored when the channel config reports non-zero bus arbitration
> + retries. Such a device is expected to retry both arbitration loss and
> + a busy bus itself before reporting failure, so the host adds no
> + attempts on top.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + maximum: 255
> + default: 3
> +
> +required:
> + - compatible
> + - reg
Incomplete, where are any resources? If you do not have any, then this
should be folded into the parent node.
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + interface {
> + #address-cells = <1>;
> + #size-cells = <0>;
Why do you need that wrapping node and what is "interface"?
> +
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 03/11] dt-bindings: spi: Add NVIDIA LSTP SPI
2026-10-12 17:35 [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Adrian Ambrozewicz
2026-10-12 17:35 ` [PATCH 01/11] dt-bindings: gpio: Add NVIDIA LSTP GPIO Adrian Ambrozewicz
2026-10-12 17:36 ` [PATCH 02/11] dt-bindings: i2c: Add NVIDIA LSTP I2C Adrian Ambrozewicz
@ 2026-10-12 17:36 ` Adrian Ambrozewicz
2026-10-12 17:46 ` sashiko-bot
2026-10-13 6:11 ` Krzysztof Kozlowski
2026-10-12 17:36 ` [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter Adrian Ambrozewicz
` (2 subsequent siblings)
5 siblings, 2 replies; 16+ messages in thread
From: Adrian Ambrozewicz @ 2026-10-12 17:36 UTC (permalink / raw)
To: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Donald Shannon, linux-usb, linux-spi, devicetree, linux-kernel,
Greg Kroah-Hartman
Add the binding for an SPI controller channel of an NVIDIA LSTP USB
adapter. Peripherals on the bus are child nodes, as for any SPI
controller. The firmware reports the number of chip selects and the bus
speed; only chip selects 0 and 1 can be addressed.
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
---
.../bindings/spi/nvidia,lstp-spi.yaml | 68 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 69 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
diff --git a/Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml b/Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
new file mode 100644
index 000000000000..5a96faab9106
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/nvidia,lstp-spi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA LSTP SPI Channel
+
+maintainers:
+ - Adrian Ambrozewicz <aambrozewicz@nvidia.com>
+ - Donald Shannon <donalds@nvidia.com>
+
+description: |
+ SPI controller channel on an NVIDIA LSTP USB device.
+
+ Peripherals on the bus are described as child nodes. The number of
+ chip selects and the bus speed are reported by the device firmware;
+ only chip selects 0 and 1 can be addressed.
+
+allOf:
+ - $ref: /schemas/spi/spi-controller.yaml#
+
+properties:
+ compatible:
+ const: nvidia,lstp-spi
+
+ reg:
+ description: Channel ID reported by the device firmware.
+ maxItems: 1
+
+patternProperties:
+ "@[0-9a-f]+$":
+ type: object
+
+ properties:
+ reg:
+ description: Chip select.
+ maximum: 1
+
+ spi-max-frequency:
+ description: Must not exceed the speed reported by the device firmware.
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ interface {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi@1 {
+ compatible = "nvidia,lstp-spi";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <18750000>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index d8092f6d91b2..a45adf95d36d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19572,6 +19572,7 @@ L: linux-usb@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
F: Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
+F: Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
NVIDIA VRS RTC DRIVER
M: Shubhi Garg <shgarg@nvidia.com>
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH 03/11] dt-bindings: spi: Add NVIDIA LSTP SPI
2026-10-12 17:36 ` [PATCH 03/11] dt-bindings: spi: Add NVIDIA LSTP SPI Adrian Ambrozewicz
@ 2026-10-12 17:46 ` sashiko-bot
2026-10-13 6:11 ` Krzysztof Kozlowski
1 sibling, 0 replies; 16+ messages in thread
From: sashiko-bot @ 2026-10-12 17:46 UTC (permalink / raw)
To: Adrian Ambrozewicz; +Cc: devicetree, linux-usb, conor+dt, robh
> Add the binding for an SPI controller channel of an NVIDIA LSTP USB
> adapter. Peripherals on the bus are child nodes, as for any SPI
> controller. The firmware reports the number of chip selects and the bus
> speed; only chip selects 0 and 1 can be addressed.
>
> Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012-lstp-usb-adapter-v1-0-aambrozewicz@nvidia.com?part=3
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 03/11] dt-bindings: spi: Add NVIDIA LSTP SPI
2026-10-12 17:36 ` [PATCH 03/11] dt-bindings: spi: Add NVIDIA LSTP SPI Adrian Ambrozewicz
2026-10-12 17:46 ` sashiko-bot
@ 2026-10-13 6:11 ` Krzysztof Kozlowski
1 sibling, 0 replies; 16+ messages in thread
From: Krzysztof Kozlowski @ 2026-10-13 6:11 UTC (permalink / raw)
To: Adrian Ambrozewicz, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Donald Shannon, linux-usb, linux-spi, devicetree, linux-kernel,
Greg Kroah-Hartman
On 12/10/2026 19:36, Adrian Ambrozewicz wrote:
> Add the binding for an SPI controller channel of an NVIDIA LSTP USB
> adapter. Peripherals on the bus are child nodes, as for any SPI
> controller. The firmware reports the number of chip selects and the bus
> speed; only chip selects 0 and 1 can be addressed.
>
> Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
> ---
> .../bindings/spi/nvidia,lstp-spi.yaml | 68 +++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
>
> diff --git a/Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml b/Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
> new file mode 100644
> index 000000000000..5a96faab9106
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
> @@ -0,0 +1,68 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
All comments apply here as well.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter
2026-10-12 17:35 [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Adrian Ambrozewicz
` (2 preceding siblings ...)
2026-10-12 17:36 ` [PATCH 03/11] dt-bindings: spi: Add NVIDIA LSTP SPI Adrian Ambrozewicz
@ 2026-10-12 17:36 ` Adrian Ambrozewicz
2026-10-12 17:47 ` sashiko-bot
` (2 more replies)
2026-10-13 11:37 ` [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Greg Kroah-Hartman
2026-10-13 11:39 ` Greg Kroah-Hartman
5 siblings, 3 replies; 16+ messages in thread
From: Adrian Ambrozewicz @ 2026-10-12 17:36 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Donald Shannon, linux-usb, devicetree, linux-kernel
Add the binding for the NVIDIA LSTP USB adapter. The device multiplexes
SPI, I2C, GPIO, IPMI and UART channels over the bulk endpoints of one
interface and reports its channels itself, so it needs no device tree
to work. A node describes what the device cannot report: peripherals on
its buses, GPIO line names and hogs, and LEDs.
Channel nodes go under the device node or under the interface node, as
usb-device.yaml lays out for the device's descriptors. The GPIO, I2C
and SPI channels reference their own schemas. The IPMI and UART channel
nodes are defined here and carry only compatible, reg and status; they
exist for status = "disabled", which keeps a channel the firmware
reports from being used.
Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
---
.../devicetree/bindings/usb/nvidia,lstp.yaml | 280 ++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 281 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
diff --git a/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml b/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
new file mode 100644
index 000000000000..62b21051ab20
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
@@ -0,0 +1,280 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/nvidia,lstp.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: NVIDIA LSTP USB Multi-Function Device
+
+maintainers:
+ - Adrian Ambrozewicz <aambrozewicz@nvidia.com>
+ - Donald Shannon <donalds@nvidia.com>
+
+description: |
+ The NVIDIA LSTP (Low-Speed Transport Protocol) device is a USB device
+ that exposes function channels (SPI, I2C, GPIO, IPMI, UART) over one USB
+ interface. Channel traffic is multiplexed over the bulk endpoints of
+ that interface.
+
+ The device reports its channels, their types and their IDs itself, so
+ it needs no device tree to work. A node adds only what the device
+ cannot report: peripherals on its SPI and I2C buses, GPIO line names
+ and hogs, and LEDs. As for any USB device, a node is matched to the
+ device by position alone, each level by the port number in reg, so a
+ node suits only an LSTP device hard-wired on the board.
+
+ Each channel node is matched to a firmware-reported channel by reg (the
+ channel ID) and compatible (the channel type). A channel without a node
+ is still usable. A channel whose node has status = "disabled" is not
+ used at all.
+
+ Where the channel nodes go follows the rules for USB device and
+ interface nodes in usb-device.yaml, which depend on the device's
+ descriptors and not on its compatible:
+
+ - A device of class 0 with one configuration and one interface has a
+ combined node. The channels go directly under the device node, which
+ has #address-cells = <1>.
+ - Any other device has an interface node for the LSTP interface,
+ interface@N with reg = <N C> (interface number, configuration value).
+ The channels go under it, and the device node has
+ #address-cells = <2>.
+
+ For interface 2, in configuration 1, of a device on port 3 of a hub on
+ root port 1, the path from the host controller node is hub@1, then the
+ device node with reg = <3>, then interface@2 with reg = <2 1>.
+
+ The reg of a node on a root-hub port, hub@1 here, is the host
+ controller's port number, which is not always the port number in the
+ USB path. On an xHCI controller it is the one-based index of the
+ port's register set, and the USB 2 and USB 3 ports share that one
+ numbering. A node on a port of an external hub uses the hub's port
+ number, as the USB path shows it.
+
+allOf:
+ - $ref: /schemas/usb/usb-device.yaml#
+ - $ref: "#/$defs/channels"
+ - if:
+ properties:
+ "#address-cells":
+ const: 1
+ then:
+ patternProperties:
+ "^interface@": false
+ else:
+ patternProperties:
+ "^(spi|i2c|gpio|serial|ipmi)@": false
+
+properties:
+ compatible:
+ enum:
+ - usb955,cf11
+ - usb424,4940
+ - usb174c,2214
+
+ reg:
+ description: Port number on the parent hub or host controller.
+ maxItems: 1
+
+ "#address-cells":
+ enum: [1, 2]
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^interface@[0-9a-f]{1,2}(,[0-9a-f]{1,2})?$":
+ type: object
+ description: |
+ Interface node for the interface that carries the LSTP channels. The
+ configuration component of the unit address is omitted for
+ configuration 1.
+
+ status = "disabled" disables the interface, and with it every
+ channel below it.
+
+ $ref: "#/$defs/channels"
+
+ properties:
+ compatible:
+ pattern: "^usbif[0-9a-f]{1,4},[0-9a-f]{1,4}\\.config[0-9a-f]{1,2}\\.[0-9a-f]{1,2}$"
+
+ reg:
+ description: Interface number, then configuration value.
+ maxItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ required:
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+ unevaluatedProperties: false
+
+$defs:
+ channels:
+ patternProperties:
+ "^spi@[0-9a-f]+$":
+ $ref: /schemas/spi/nvidia,lstp-spi.yaml#
+
+ "^i2c@[0-9a-f]+$":
+ $ref: /schemas/i2c/nvidia,lstp-i2c.yaml#
+
+ "^gpio@[0-9a-f]+$":
+ $ref: /schemas/gpio/nvidia,lstp-gpio.yaml#
+
+ "^serial@[0-9a-f]+$":
+ type: object
+ description: |
+ UART channel.
+
+ The device firmware sets the baud rate, framing, parity and flow
+ control and reports them to the host; the host cannot change them.
+
+ properties:
+ compatible:
+ const: nvidia,lstp-uart
+
+ reg:
+ description: Channel ID reported by the device firmware.
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+ additionalProperties: false
+
+ "^ipmi@[0-9a-f]+$":
+ type: object
+ description: |
+ IPMI message channel, on a device attached to a BMC. The device
+ firmware terminates the managed host's IPMI transport, passes each
+ request to the BMC over this channel and returns the BMC's response.
+
+ properties:
+ compatible:
+ const: nvidia,lstp-ipmi
+
+ reg:
+ description: Channel ID reported by the device firmware.
+ maxItems: 1
+
+ required:
+ - compatible
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - "#address-cells"
+ - "#size-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hub@1 {
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Three interfaces; the LSTP channels are on interface 2. */
+ device@3 {
+ compatible = "usb955,cf11";
+ reg = <3>;
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ interface@2 {
+ compatible = "usbif955,cf11.config1.2";
+ reg = <2 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ spi@1 {
+ compatible = "nvidia,lstp-spi";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <18750000>;
+ };
+ };
+
+ i2c@2 {
+ compatible = "nvidia,lstp-i2c";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@48 {
+ compatible = "ti,tmp102";
+ reg = <0x48>;
+ };
+ };
+
+ gpio@3 {
+ compatible = "nvidia,lstp-gpio";
+ reg = <3>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "LED", "INT";
+ };
+
+ ipmi@4 {
+ compatible = "nvidia,lstp-ipmi";
+ reg = <4>;
+ };
+
+ serial@5 {
+ compatible = "nvidia,lstp-uart";
+ reg = <5>;
+ };
+ };
+ };
+ };
+ };
+
+ - |
+ usb {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Class 0, one interface: a combined node carries the channels. */
+ device@2 {
+ compatible = "usb424,4940";
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ i2c@1 {
+ compatible = "nvidia,lstp-i2c";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ gpio@2 {
+ compatible = "nvidia,lstp-gpio";
+ reg = <2>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index a45adf95d36d..3eaae7388a69 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19573,6 +19573,7 @@ S: Supported
F: Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml
F: Documentation/devicetree/bindings/i2c/nvidia,lstp-i2c.yaml
F: Documentation/devicetree/bindings/spi/nvidia,lstp-spi.yaml
+F: Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
NVIDIA VRS RTC DRIVER
M: Shubhi Garg <shgarg@nvidia.com>
--
2.43.0
^ permalink raw reply related [flat|nested] 16+ messages in thread* Re: [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter
2026-10-12 17:36 ` [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter Adrian Ambrozewicz
@ 2026-10-12 17:47 ` sashiko-bot
2026-10-13 6:13 ` Krzysztof Kozlowski
2026-10-13 6:17 ` Krzysztof Kozlowski
2 siblings, 0 replies; 16+ messages in thread
From: sashiko-bot @ 2026-10-12 17:47 UTC (permalink / raw)
To: Adrian Ambrozewicz; +Cc: devicetree, conor+dt, linux-usb, robh
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] dt-bindings: missing required interrupt-controller properties for GPIO variant
--
commit e512df165fd25f0219b3ca663151d385bd684eb0
Author: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
dt-bindings: usb: Add NVIDIA LSTP USB adapter
This commit adds the device tree bindings for the NVIDIA LSTP USB adapter. The
device multiplexes multiple channels over one USB interface and reports its
channels itself. The bindings allow describing peripherals on the buses, GPIO
lines, and LEDs that cannot be reported automatically.
> diff --git a/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml b/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
> new file mode 100644
> index 0000000000000..62b21051ab20e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
[ ... ]
> + i2c@2 {
> + compatible = "nvidia,lstp-i2c";
> + reg = <2>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + temperature-sensor@48 {
> + compatible = "ti,tmp102";
> + reg = <0x48>;
> + };
> + };
> +
> + gpio@3 {
> + compatible = "nvidia,lstp-gpio";
> + reg = <3>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + gpio-line-names = "LED", "INT";
> + };
[Severity: Low]
Does this example omit the mandatory interrupt controller properties for this
GPIO variant?
The Device Tree Bindings guidelines state that when a hardware variant acts as
an interrupt controller, it must define the capabilities in the required
properties list. It appears the schema in
Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml incorrectly
classifies these as dependent instead of required:
Documentation/devicetree/bindings/gpio/nvidia,lstp-gpio.yaml:
dependentRequired:
interrupt-controller: ["#interrupt-cells"]
"#interrupt-cells": [interrupt-controller]
required:
- compatible
- reg
- gpio-controller
- "#gpio-cells"
Since the schema permits incomplete node definitions, this example can pass
dt_binding_check validation silently despite omitting the mandatory
interrupt-controller and #interrupt-cells properties.
> +
> + ipmi@4 {
> + compatible = "nvidia,lstp-ipmi";
> + reg = <4>;
> + };
[ ... ]
> + i2c@1 {
> + compatible = "nvidia,lstp-i2c";
> + reg = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + };
> +
> + gpio@2 {
> + compatible = "nvidia,lstp-gpio";
> + reg = <2>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
[Severity: Low]
Does this example also omit the mandatory interrupt-related properties?
Similar to the previous example, this node is missing the interrupt-controller
and #interrupt-cells properties required for a hardware variant with interrupt
controller capabilities.
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261012-lstp-usb-adapter-v1-0-aambrozewicz@nvidia.com?part=4
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter
2026-10-12 17:36 ` [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter Adrian Ambrozewicz
2026-10-12 17:47 ` sashiko-bot
@ 2026-10-13 6:13 ` Krzysztof Kozlowski
2026-10-13 6:17 ` Krzysztof Kozlowski
2 siblings, 0 replies; 16+ messages in thread
From: Krzysztof Kozlowski @ 2026-10-13 6:13 UTC (permalink / raw)
To: Adrian Ambrozewicz, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Donald Shannon, linux-usb, devicetree, linux-kernel
On 12/10/2026 19:36, Adrian Ambrozewicz wrote:
> Add the binding for the NVIDIA LSTP USB adapter. The device multiplexes
> SPI, I2C, GPIO, IPMI and UART channels over the bulk endpoints of one
> interface and reports its channels itself, so it needs no device tree
> to work. A node describes what the device cannot report: peripherals on
> its buses, GPIO line names and hogs, and LEDs.
>
> Channel nodes go under the device node or under the interface node, as
> usb-device.yaml lays out for the device's descriptors. The GPIO, I2C
> and SPI channels reference their own schemas. The IPMI and UART channel
> nodes are defined here and carry only compatible, reg and status; they
> exist for status = "disabled", which keeps a channel the firmware
> reports from being used.
>
> Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
> ---
> .../devicetree/bindings/usb/nvidia,lstp.yaml | 280 ++++++++++++++++++
> MAINTAINERS | 1 +
> 2 files changed, 281 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
>
> diff --git a/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml b/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
> new file mode 100644
> index 000000000000..62b21051ab20
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/nvidia,lstp.yaml
> @@ -0,0 +1,280 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +# SPDX-FileCopyrightText: Copyright (c) 2026 NVIDIA CORPORATION & AFFILIATES. All rights reserved.
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/usb/nvidia,lstp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NVIDIA LSTP USB Multi-Function Device
> +
> +maintainers:
> + - Adrian Ambrozewicz <aambrozewicz@nvidia.com>
> + - Donald Shannon <donalds@nvidia.com>
> +
> +description: |
> + The NVIDIA LSTP (Low-Speed Transport Protocol) device is a USB device
> + that exposes function channels (SPI, I2C, GPIO, IPMI, UART) over one USB
> + interface. Channel traffic is multiplexed over the bulk endpoints of
> + that interface.
> +
> + The device reports its channels, their types and their IDs itself, so
> + it needs no device tree to work. A node adds only what the device
> + cannot report: peripherals on its SPI and I2C buses, GPIO line names
> + and hogs, and LEDs. As for any USB device, a node is matched to the
> + device by position alone, each level by the port number in reg, so a
> + node suits only an LSTP device hard-wired on the board.
> +
> + Each channel node is matched to a firmware-reported channel by reg (the
> + channel ID) and compatible (the channel type). A channel without a node
> + is still usable. A channel whose node has status = "disabled" is not
> + used at all.
> +
> + Where the channel nodes go follows the rules for USB device and
> + interface nodes in usb-device.yaml, which depend on the device's
> + descriptors and not on its compatible:
You again explain bindings. Description explains hardware, not repeats
schema.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter
2026-10-12 17:36 ` [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter Adrian Ambrozewicz
2026-10-12 17:47 ` sashiko-bot
2026-10-13 6:13 ` Krzysztof Kozlowski
@ 2026-10-13 6:17 ` Krzysztof Kozlowski
2 siblings, 0 replies; 16+ messages in thread
From: Krzysztof Kozlowski @ 2026-10-13 6:17 UTC (permalink / raw)
To: Adrian Ambrozewicz, Greg Kroah-Hartman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Donald Shannon, linux-usb, devicetree, linux-kernel
On 12/10/2026 19:36, Adrian Ambrozewicz wrote:
> + - $ref: /schemas/usb/usb-device.yaml#
> + - $ref: "#/$defs/channels"
> + - if:
> + properties:
> + "#address-cells":
> + const: 1
> + then:
> + patternProperties:
> + "^interface@": false
> + else:
> + patternProperties:
> + "^(spi|i2c|gpio|serial|ipmi)@": false
No, compatible, not presence of properties defines whether device has
SPI or not.
Also, allOf is placed after required, see other schemas or example-schema.
> +
> +properties:
> + compatible:
> + enum:
> + - usb955,cf11
> + - usb424,4940
> + - usb174c,2214
> +
> + reg:
> + description: Port number on the parent hub or host controller.
> + maxItems: 1
> +
> + "#address-cells":
> + enum: [1, 2]
> +
> + "#size-cells":
> + const: 0
> +
> +patternProperties:
> + "^interface@[0-9a-f]{1,2}(,[0-9a-f]{1,2})?$":
> + type: object
Your example is either incomplete or this is unnecessary. Assuming your
example is complete, then you have one interface, thus this node is
pointless. What's more, your top level compatible EXACTLY defines all
this, thus none of your properties are needed as they are implied by the
top-level compatible.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers
2026-10-12 17:35 [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Adrian Ambrozewicz
` (3 preceding siblings ...)
2026-10-12 17:36 ` [PATCH 04/11] dt-bindings: usb: Add NVIDIA LSTP USB adapter Adrian Ambrozewicz
@ 2026-10-13 11:37 ` Greg Kroah-Hartman
2026-10-13 11:39 ` Greg Kroah-Hartman
5 siblings, 0 replies; 16+ messages in thread
From: Greg Kroah-Hartman @ 2026-10-13 11:37 UTC (permalink / raw)
To: Adrian Ambrozewicz
Cc: Donald Shannon, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Lee Jones, Pavel Machek,
Andi Shyti, Mark Brown, Jiri Slaby, Corey Minyard,
Rafael J. Wysocki, Len Brown, Jonathan Corbet, Ilpo Järvinen,
Sakari Ailus, Hans de Goede, Lixu Zhang, Danilo Krummrich,
Johan Hovold, Oliver Neukum, Quan Nguyen, Andrew Jeffery,
linux-usb, devicetree, linux-gpio, linux-leds, linux-i2c,
linux-spi, linux-serial, openipmi-developer, linux-acpi,
linux-doc, driver-core, linux-kernel
On Mon, Oct 12, 2026 at 08:35:58PM +0300, Adrian Ambrozewicz wrote:
> This series adds drivers for the NVIDIA LSTP USB adapter: a USB core
> driver and GPIO, LED, I2C, SPI, UART and BMC-side IPMI function drivers,
> with their device tree bindings, an ACPI description document and the
> sysfs ABI.
Why would a USB device have anything to do with device tree?
> What LSTP is
> ------------
>
> LSTP (Low-Speed Transport Protocol or Low-Speed Tunnelling Protocol) is
> a vendor-specific USB interface (class 0xff, subclass 0x3f) that
> multiplexes several low-speed "channels" over one pair of bulk
> endpoints. It is implemented by NVIDIA's SMA, an MCU (0955:cf11), and
> by other vendors' parts: two hub/bridge chips have it built in
> (0424:4940, 174c:2214). Boards use it to
> reach SPI flash, I2C sensors, GPIOs and LEDs, a UART and a host-to-BMC
> IPMI path, on both BMCs and host systems.
Cute, but that's a total abuse of the USB standard. Why wasn't this
implemented by the proper "each channel is a USB interface" model
instead? Have the firmware engineers there not read the USB spec?
> The channel types are SPI host, I2C host, GPIO (with interrupts and LED
> pins), UART, IPMI and MMIO. Channel 0 is the control channel: at probe
> the driver reads the channel table from it, which gives each channel's
> ID, type and configuration. The set of channels is decided by the
> firmware, so the same VID:PID carries different channels on different
> boards. No firmware description is needed for the channels to work.
Again cute, but that's not how USB devices are supposed to work, why
would we want to do this at all?
> Series layout
> -------------
>
> 1 dt-bindings: gpio: Add NVIDIA LSTP GPIO
> 2 dt-bindings: i2c: Add NVIDIA LSTP I2C
> 3 dt-bindings: spi: Add NVIDIA LSTP SPI
> 4 dt-bindings: usb: Add NVIDIA LSTP USB adapter
USB devices do not have DT bindings. It's a dynamic bus, with
self-describing devices, don't make the mistake of thinking this is
giong to work.
> 5 usb: misc: Add NVIDIA LSTP USB adapter driver
> 6 gpio: Add NVIDIA LSTP GPIO driver
> 7 leds: Add NVIDIA LSTP LED driver
> 8 i2c: Add NVIDIA LSTP I2C driver
> 9 spi: Add NVIDIA LSTP SPI driver
> 10 tty: Add NVIDIA LSTP UART driver
> 11 ipmi: Add NVIDIA LSTP IPMI BMC driver
So you have a custom "bus" for a single USB device/interface? Ick,
again, why? Please do this the "proper" way in your firmware and do
this one-device-per-usb-interface like the rest of the world does
please.
Doing it that way will not cost any more hardware pins at all, it's all
handled in firmware, and as you all have complete control over the
firmware, you can fix this up now to do things properly.
> Patch 4 $refs the schemas from patches 1-3, so it comes last among the
> bindings; it also defines the serial@N and ipmi@N channel nodes inline.
> The MAINTAINERS entry starts in patch 1 and gains each later patch's
> files. Patch 5 carries:
> - the core in drivers/usb/misc/;
> - include/linux/usb/lstp.h for the function drivers;
> - the sysfs ABI file;
> - Documentation/driver-api/usb/lstp.rst;
> - Documentation/firmware-guide/acpi/lstp.rst.
>
> Patches 6 and 8-11 each depend only on patch 5; patch 7 (LEDs) also
> needs patch 6, whose GPIO driver hands the LED pins to it.
>
> Why the auxiliary bus, and why not MFD
> --------------------------------------
Neither is ok for USB devices, that's not an argument either way.
Please go talk to some people with USB spec experience on how to make a
multi-function device correctly. This way sure does not look like it at
all.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers
2026-10-12 17:35 [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Adrian Ambrozewicz
` (4 preceding siblings ...)
2026-10-13 11:37 ` [PATCH 00/11] Add NVIDIA LSTP USB adapter drivers Greg Kroah-Hartman
@ 2026-10-13 11:39 ` Greg Kroah-Hartman
5 siblings, 0 replies; 16+ messages in thread
From: Greg Kroah-Hartman @ 2026-10-13 11:39 UTC (permalink / raw)
To: Adrian Ambrozewicz
Cc: Donald Shannon, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, Bartosz Golaszewski, Lee Jones, Pavel Machek,
Andi Shyti, Mark Brown, Jiri Slaby, Corey Minyard,
Rafael J. Wysocki, Len Brown, Jonathan Corbet, Ilpo Järvinen,
Sakari Ailus, Hans de Goede, Lixu Zhang, Danilo Krummrich,
Johan Hovold, Oliver Neukum, Quan Nguyen, Andrew Jeffery,
linux-usb, devicetree, linux-gpio, linux-leds, linux-i2c,
linux-spi, linux-serial, openipmi-developer, linux-acpi,
linux-doc, driver-core, linux-kernel
On Mon, Oct 12, 2026 at 08:35:58PM +0300, Adrian Ambrozewicz wrote:
> This series adds drivers for the NVIDIA LSTP USB adapter: a USB core
> driver and GPIO, LED, I2C, SPI, UART and BMC-side IPMI function drivers,
> with their device tree bindings, an ACPI description document and the
> sysfs ABI.
>
> What LSTP is
> ------------
>
> LSTP (Low-Speed Transport Protocol or Low-Speed Tunnelling Protocol) is
> a vendor-specific USB interface (class 0xff, subclass 0x3f) that
> multiplexes several low-speed "channels" over one pair of bulk
> endpoints. It is implemented by NVIDIA's SMA, an MCU (0955:cf11), and
> by other vendors' parts: two hub/bridge chips have it built in
> (0424:4940, 174c:2214). Boards use it to
> reach SPI flash, I2C sensors, GPIOs and LEDs, a UART and a host-to-BMC
> IPMI path, on both BMCs and host systems.
Also, if you really want to do this in a dynamic way, use greybus, as
that is EXPLICITLY what it was designed for, and is patent-free (i.e.
unencumbered, and we already support it in the kernel.) Please don't
reinvent the wheel/spec just because no one did any prior-art
research...
thanks,
greg k-h
^ permalink raw reply [flat|nested] 16+ messages in thread