Re: [PATCH 1/1] dt-bindings: mfd: add ti,lm8502 combo LED + haptic controller

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The binding describes Linux driver internals (MFD structure) rather than hardware layout by creating artificial 'leds' and 'haptic' sub-nodes.
--

commit 25934ec50a44a98662b56dfb64e70a785820fdf7
Author: Herman van Hazendonk <github.com@herrie.org>

dt-bindings: mfd: add ti,lm8502 combo LED + haptic controller

This commit adds a new YAML device tree binding for the TI LM8502, an I2C
combo LED and haptic controller. The device exposes its LED and haptic
functionalities as sub-nodes of the main I2C device.

> diff --git a/Documentation/devicetree/bindings/mfd/ti,lm8502.yaml b/Documentation/devicetree/bindings/mfd/ti,lm8502.yaml
> new file mode 100644
> index 0000000000000..10f2e32a07385
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/ti,lm8502.yaml
> @@ -0,0 +1,160 @@
[ ... ]
> +description: |
> +  The TI LM8502 is an I2C combo device with ten constant-current LED
> +  outputs (D1..D10) and an internal H-bridge that drives a vibrator
> +  motor. Pin D10 is shared between the tenth LED channel and the
> +  haptic output; the haptic driver writes D10_CURRENT_CTRL = 0 at each
> +  start to mux the pin to the H-bridge path.
> +
> +  The chip is exposed in Linux as an MFD with two children:
> +    - ti,lm8502-leds   - LED-class outputs D1..D10
> +    - ti,lm8502-haptic - EV_FF / FF_RUMBLE input device

[Severity: Medium]
Does this description rely too heavily on Linux driver internals rather than
hardware layout?

Device tree bindings should generally model the physical hardware structure.
Describing how the OS software stack divides the MFD subsystems creates
long-term maintenance debt since DT bindings form a stable hardware
description ABI.

> +
> +  The parent node owns the I2C client, the chip-enable GPIO and the
> +  vcc regulator; children share access to the parent's regmap.
> +
> +properties:
> +  compatible:
> +    const: ti,lm8502
[ ... ]
> +  leds:
> +    type: object
> +    additionalProperties: false
> +    description: LED-class child for outputs D1..D10.
> +
> +    properties:
> +      compatible:
> +        const: ti,lm8502-leds

[Severity: Medium]
Is the ti,lm8502-leds compatible string strictly necessary for hardware
description?

Creating artificial sub-nodes with their own software-specific compatible
strings just to force driver matching for the Linux MFD framework violates
devicetree design principles.

The sub-functions should typically be represented as properties or direct
child nodes of the parent device without requiring separate compatible
strings, unless they are genuinely independently reusable IP blocks.

[ ... ]
> +  haptic:
> +    type: object
> +    additionalProperties: false
> +    description: FF_RUMBLE child for the internal H-bridge vibrator output.
> +
> +    properties:
> +      compatible:
> +        const: ti,lm8502-haptic

[Severity: Medium]
Similar to the leds sub-node, would it be possible to omit this artificial
compatible string and represent the haptic function without a dedicated
software-specific node?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260603080256.853037-1-github.com@herrie.org?part=1