[PATCH v3 0/2] Support active-high alert polarity for LM75

[PATCH v3 0/2] Support active-high alert polarity for LM75

[Markus Stockhausen]

The LM75 configuration register allows to switch the alert polarity.
In default mode the alert output pin is active-low. There are hardware
designs that use this alert output for an hardware assisted automatic
fan speed control. E.g. the D-Link DGS-1250 implements

- temperature below Tmax threshold -> alert pin low -> fan slow speed
- temperature above Tmax threshold -> alert pin high -> fan high speed

Provide a devicetree configuration option and a driver enhancement to
support these hardware designs.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>

---

Changes in v3
- Add Acked-by from Conor Dooley for devicetree commit
- Use device_property_read_bool()
- Match documentation and always overwrite clr_mask during setup
  to enforce default polarity active-low

Changes in v2
- Carve out AS6200 polarity fix into separate series
- Rename devicetree prefix from lm75 to ti

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

[Markus Stockhausen]

The LM75 alert pin is asserted based on the value of alert polarity bit of
the configuration register. The device/driver default is 0 which means alert
pin is configured to be active-low. A value of 1 maps to inverted (active-high).

Add an optional boolean property "ti,alert-polarity-active-high" to
override the alert pin polarity. When absent, the default active-low
polarity is kept.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
 Documentation/devicetree/bindings/hwmon/lm75.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/hwmon/lm75.yaml b/Documentation/devicetree/bindings/hwmon/lm75.yaml
index 0b9fda81e3ec..b48bf3fd721f 100644
--- 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:
+    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
+
 required:
   - compatible
   - reg
-- 
2.54.0

[PATCH v3 2/2] hwmon: (lm75) Support active-high alert polarity

[Markus Stockhausen]

LM75 devices supported by this driver support configurable active-high
alert polarity. This is already documented in the devicetree description.
Add support for it to the driver.

Follow documentation and defensively enforce active-low if property is
not set. This avoids possible inconsistencies for future devices with
wrong parametrization. No API breakage as all current devices have
their parameters set to active-low.

Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
---
 drivers/hwmon/lm75.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
index 8b74cc314196..391e6dfcc6b2 100644
--- a/drivers/hwmon/lm75.c
+++ b/drivers/hwmon/lm75.c
@@ -123,7 +123,9 @@ struct lm75_data {
 
 static const u8 lm75_sample_set_masks[] = { 0 << 5, 1 << 5, 2 << 5, 3 << 5 };
 
-#define LM75_SAMPLE_CLEAR_MASK	(3 << 5)
+#define LM75_ALERT_POLARITY_HIGH_8_BIT	(BIT(2))
+#define LM75_ALERT_POLARITY_HIGH_16_BIT	(BIT(2) << 8)
+#define LM75_SAMPLE_CLEAR_MASK		(3 << 5)
 
 /* The structure below stores the configuration values of the supported devices.
  * In case of being supported multiple configurations, the default one must
@@ -725,6 +727,7 @@ static void lm75_remove(void *data)
 static int lm75_generic_probe(struct device *dev, const char *name,
 			      enum lm75_type kind, int irq, struct regmap *regmap)
 {
+	u16 clr_mask, pol_mask, set_mask;
 	struct device *hwmon_dev;
 	struct lm75_data *data;
 	int status, err;
@@ -762,8 +765,18 @@ static int lm75_generic_probe(struct device *dev, const char *name,
 		return err;
 	data->orig_conf = status;
 
-	err = lm75_write_config(data, data->params->set_mask,
-				data->params->clr_mask);
+	/* Enforce polarity active-low (default) or active-high (devicetree) */
+	if (!data->params->config_reg_16bits)
+		pol_mask = LM75_ALERT_POLARITY_HIGH_8_BIT;
+	else
+		pol_mask = LM75_ALERT_POLARITY_HIGH_16_BIT;
+
+	clr_mask = data->params->clr_mask | pol_mask;
+	set_mask = data->params->set_mask & ~pol_mask;
+	if (device_property_read_bool(dev, "ti,alert-polarity-active-high"))
+		set_mask |= pol_mask;
+
+	err = lm75_write_config(data, set_mask, clr_mask);
 	if (err)
 		return err;
 
-- 
2.54.0

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

[sashiko-bot]

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

Re: [PATCH v3 2/2] hwmon: (lm75) Support active-high alert polarity

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] The 16-bit polarity mask incorrectly targets a reserved bit instead of the alert polarity bit due to endianness.
- [High] Destructive overwrite of firmware-configured polarity introduces a backwards compatibility regression.
- [High] Pre-existing bug: `set_mask` default configurations are silently ignored by regmap update logic.
- [Medium] The patch contradicts and breaks the intended active-high default behavior of as6200 sensors.
--

commit 7a0047595dac47959119e869942835475ae3f348
Author: Markus Stockhausen <markus.stockhausen@gmx.de>

hwmon: (lm75) Support active-high alert polarity

This commit adds support for configuring the active-high alert polarity for
LM75 devices using the ti,alert-polarity-active-high devicetree property. It
also enforces the default polarity if the property is missing.

> hwmon: (lm75) Support active-high alert polarity
> 
> LM75 devices supported by this driver support configurable active-high
> alert polarity. This is already documented in the devicetree description.
> Add support for it to the driver.
> 
> Follow documentation and defensively enforce active-low if property is
> not set. This avoids possible inconsistencies for future devices with
> wrong parametrization. No API breakage as all current devices have
> their parameters set to active-low.

Is it accurate that all current devices have their parameters set to active-low?

Looking at the device_params array, the as6200 configuration sets
.set_mask = 0x94C0, which has the positive polarity bit set. By clearing this
bit when the devicetree property is not present, could this break the
established default behavior for as6200 sensors?

> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index f1a1e5b888f64..af2d6cf370496 100644
> --- a/drivers/hwmon/lm75.c
> +++ b/drivers/hwmon/lm75.c
> @@ -123,7 +123,9 @@ struct lm75_data {
>  
>  static const u8 lm75_sample_set_masks[] = { 0 << 5, 1 << 5, 2 << 5, 3 << 5 };
>  
> -#define LM75_SAMPLE_CLEAR_MASK	(3 << 5)
> +#define LM75_ALERT_POLARITY_HIGH_8_BIT	(BIT(2))
> +#define LM75_ALERT_POLARITY_HIGH_16_BIT	(BIT(2) << 8)

Will this 16-bit mask target the correct bit?

For 16-bit devices, the driver reads the configuration register using
i2c_smbus_read_word_data(). Since LM75-compatible sensors send the Most
Significant Byte (MSB) first, the original 8-bit configuration (containing
the polarity bit) ends up in the lower 8 bits of the returned integer, while
the extended configuration is in the upper 8 bits.

By defining LM75_ALERT_POLARITY_HIGH_16_BIT as (BIT(2) << 8), does this
erroneously target a reserved bit in the extended configuration byte instead
of the actual alert polarity bit?

> +#define LM75_SAMPLE_CLEAR_MASK		(3 << 5)
>  
>  /* The structure below stores the configuration values of the supported devices.
>   * In case of being supported multiple configurations, the default one must

[ ... ]

> @@ -762,8 +765,18 @@ static int lm75_generic_probe(struct device *dev, const char *name,
>  		return err;
>  	data->orig_conf = status;
>  
> -	err = lm75_write_config(data, data->params->set_mask,
> -				data->params->clr_mask);
> +	/* Enforce polarity active-low (default) or active-high (devicetree) */
> +	if (!data->params->config_reg_16bits)
> +		pol_mask = LM75_ALERT_POLARITY_HIGH_8_BIT;
> +	else
> +		pol_mask = LM75_ALERT_POLARITY_HIGH_16_BIT;
> +
> +	clr_mask = data->params->clr_mask | pol_mask;
> +	set_mask = data->params->set_mask & ~pol_mask;
> +	if (device_property_read_bool(dev, "ti,alert-polarity-active-high"))
> +		set_mask |= pol_mask;

By always including pol_mask in clr_mask, will this actively clear the
polarity bit for all devices without the devicetree property?

Prior to this patch, the polarity bit was not included in clr_mask, allowing
the driver to inherit an active-high polarity if it was already correctly
initialized by a bootloader. Could this new behavior break existing working
embedded setups that rely on bootloader defaults?

> +
> +	err = lm75_write_config(data, set_mask, clr_mask);

Are the set_mask bits actually being applied here?

Looking at lm75_write_config(), it uses regmap_update_bits():

drivers/hwmon/lm75.c:lm75_write_config() {
	return regmap_update_bits(data->regmap, LM75_REG_CONF,
				  clr_mask | LM75_SHUTDOWN, set_mask);
}

Since regmap_update_bits() only modifies the bits explicitly defined in its
mask argument, any bits in set_mask that are not also in clr_mask will be
silently ignored. Should the mask argument be updated to include set_mask
(e.g., clr_mask | set_mask | LM75_SHUTDOWN) to ensure all intended
configuration bits are written?

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

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

[Guenter Roeck]

On Mon, May 04, 2026 at 05:10:19PM +0200, Markus Stockhausen wrote:
> The LM75 alert pin is asserted based on the value of alert polarity bit of
> the configuration register. The device/driver default is 0 which means alert
> pin is configured to be active-low. A value of 1 maps to inverted (active-high).
> 
> Add an optional boolean property "ti,alert-polarity-active-high" to
> override the alert pin polarity. When absent, the default active-low
> polarity is kept.
> 
> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>

Applied, after shortening description line length to 75 columns.

Thanks,
Guenter

Re: [PATCH v3 2/2] hwmon: (lm75) Support active-high alert polarity

[Guenter Roeck]

On Mon, May 04, 2026 at 05:10:20PM +0200, Markus Stockhausen wrote:
> LM75 devices supported by this driver support configurable active-high
> alert polarity. This is already documented in the devicetree description.
> Add support for it to the driver.
> 
> Follow documentation and defensively enforce active-low if property is
> not set. This avoids possible inconsistencies for future devices with
> wrong parametrization. No API breakage as all current devices have
> their parameters set to active-low.
> 
> Signed-off-by: Markus Stockhausen <markus.stockhausen@gmx.de>

Applied.

Thanks,
Guenter