Re: [PATCH v3 1/2] dt-bindings: hwmon: lm75: Add ti,alert-polarity-active-high property

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Redundant custom devicetree property conflicts with standard 'interrupts' polarity specifier.
- [Low] Inappropriate vendor prefix ('ti,') for a generic, multi-vendor hardware feature.
--

commit 05f32bdea45ff4c95a0e00cb7fb78b2bce28fd4a
Author: Markus Stockhausen <markus.stockhausen@gmx.de>

dt-bindings: hwmon: lm75: Add ti,alert-polarity-active-high property

This commit introduces a new boolean property to configure the alert pin
polarity for LM75 hardware monitors. When specified, the alert pin
polarity is configured as active-high instead of the default active-low.

> diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml
> --- a/Documentation/devicetree/bindings/hwmon/lm75.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/lm75.yaml
> @@ -54,6 +54,13 @@ properties:
>    interrupts:
>      maxItems: 1
>  
> +  ti,alert-polarity-active-high:

This isn't a bug, but is it appropriate to use a ti prefix for a generic
hardware feature? The configuration register bit to set the overtemperature
shutdown alert polarity is a standard feature present across most compatible
parts from multiple manufacturers (like Maxim, Dallas, and ST).

Since the binding applies this property globally to all compatibles, would it
be better to use a vendor-neutral name like alert-polarity-active-high, or
use the original vendor prefix national?

> +    description: Alert pin is asserted based on the value of alert polarity
> +      bit of configuration register. Default value is normal (0 which maps to
> +      active-low). The other value is inverted (1 which maps to active-high).
> +      Specify this property to set the alert polarity to active-high.
> +    $ref: /schemas/types.yaml#/definitions/flag

Does introducing this boolean property create a dual source of truth when
used alongside the interrupts property?

The standard interrupts property inherently encodes the IRQ trigger type and
polarity (such as IRQ_TYPE_LEVEL_LOW or IRQ_TYPE_LEVEL_HIGH). If the driver
configures the hardware pin polarity strictly based on this custom property
and ignores the trigger type specified in the interrupts node, it could lead
to a direct polarity mismatch.

For example, if a user configures an active-high interrupt via the standard
interrupts specifier but omits this custom property, the driver defaults the
hardware pin to active-low, which could result in missed interrupts or
interrupt storms.

Should the driver derive the hardware polarity dynamically using
irqd_get_trigger_type() when an interrupt is provided, and perhaps only
permit this custom property to be used when operating in standalone
thermostat mode without an interrupt?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260504151020.462342-1-markus.stockhausen@gmx.de?part=1