mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Wenliang Yan <wenliang202407@163.com>
Cc: Jean Delvare <jdelvare@suse.com>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-hwmon@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/8] hwmon: (ina3221) Various improvement and add support for SQ52210
Date: Wed, 28 Jan 2026 09:41:49 -0800	[thread overview]
Message-ID: <9e9feb88-46db-4b47-a8ed-e30eb0f658c8@roeck-us.net> (raw)
In-Reply-To: <956b92bd-950b-44fc-af85-6f76ed60656f@roeck-us.net>

On Tue, Jan 27, 2026 at 10:07:50AM -0800, Guenter Roeck wrote:
> Hi,
> 
> On Mon, Jan 19, 2026 at 07:14:38AM -0500, Wenliang Yan wrote:
> > Make modifications according to the guidance provided in the reply.
> > 
> > 1.Modify the description for power[123]_input(PATCH 5).
> > 
> > 2.Re-annotate the significance of the limit value calculation
> > and the use of register masks in the sq52210_alert_limit_write.
> > Modify the calculation process to resolve arithmetic overflow issues.
> > The limit values SOL, BOL, and BUL are all stored using the upper
> > 13 bits of the register, so shifting is required. In contrast,
> > the POL value is configured by setting the lower three bits
> > to 0 directly(PATCH 6).
> > 
> > 3.Resolve arithmetic overflow issues in the ina3221_read_power(PATCH 7).
> > 
> > 4.Resolve arithmetic overflow issues in the ina3221_read_curr,
> > and validate channel indices in ina3221_write_in(PATCH 8).
> > 
> 
> AI review of the series provided the feedback below. Please fix or explain
> false positives.
> 

Another round of AI reviews below. Please address or explain.

Thanks,
Guenter

---
commit ef198f703062bc5ad58a148eb506821900c3522e
Author:     Wenliang Yan <wenliang202407@163.com>
hwmon: (ina3221) Support write/read functions for 'power' attribute

SQ52210 adds power attributes to report power data and implements
corresponding read/write functions for this purpose. This includes
reading power values, reading alert thresholds, reading alert
trigger status, and writing alert thresholds.

> diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
> index cb292fee564b..2338b3288950 100644
> --- a/drivers/hwmon/ina3221.c
> +++ b/drivers/hwmon/ina3221.c
> @@ -546,6 +553,12 @@ static int ina3221_read_power(struct device *dev, u32 attr, int channel, long *v
>  		if (ret)
>  			return ret;
>  		/* Return power in mW */
> -		*val = DIV_U64_ROUND_CLOSEST((u64)regval * (u64)ina->power_lsb_uW, 1000);
> +		*val = DIV_U64_ROUND_CLOSEST((u64)regval * (u64)ina->power_lsb_uW, 1000);
>  		return 0;

Does this return the power value in milliWatts? The hwmon ABI specifies
that power attributes should be returned in microWatts.

>  	case hwmon_power_crit_alarm:
>  		/* No actual register read if channel is disabled */
> @@ -736,6 +797,18 @@ static int ina3221_write_enable(struct device *dev, int channel, bool enable)
>  	return ret;
>  }
>  
> +static int ina3221_write_power(struct device *dev, u32 attr, int channel, long val)
> +{
> +	struct ina3221_data *ina = dev_get_drvdata(dev);
> +
> +	switch (attr) {
> +	case hwmon_power_crit:
> +		return sq52210_alert_limit_write(ina, SQ52210_ALERT_POL, channel, val);

Does this pass the value in microWatts (as received from the core) to a
function that expects milliWatts? The sq52210_alert_limit_write()
implementation multiplies the input by 1000 to convert to microWatts,
which implies it expects the input in milliWatts.

> +	default:
> +		return 0;
> +	}
> +}
> +

commit 61e453283222e7fc9439a6d5c682ce1104dd24ef
Author:     Wenliang Yan <wenliang202407@163.com>
hwmon: (ina3221) Support for writing alert limit values and modify the 'ina3221_read_value' function

SQ52210 adds power, current, and limit registers. The ina3221_read_value
function has been refactored to adapt to the new register data reading
format.

> diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
> index 4b2888be0ae2..cb292fee564b 100644
> --- a/drivers/hwmon/ina3221.c
> +++ b/drivers/hwmon/ina3221.c
> @@ -345,6 +365,17 @@ static int ina3221_read_value(struct ina3221_data *ina, unsigned int reg,
>  	case INA3221_CRIT3:
>  		*val = sign_extend32(regval >> 3, 12);
>  		break;
> +	case SQ52210_ALERT_LIMIT1:
> +	case SQ52210_ALERT_LIMIT2:
> +	case SQ52210_ALERT_LIMIT3:
> +		if (ina->alert_type_select & SQ52210_ALERT_ALL_SUL_MASK)
> +			*val = sign_extend32(regval, 15);

Does this return the unshifted register value? The standard Shunt Voltage
registers (INA3221_SHUNTx) return the value shifted right by 3.
Returning the unshifted value here causes a scaling inconsistency when
ina3221_read_curr() applies current_lsb_uA (which is based on the
shifted LSB), resulting in an 8x error in the reported current limit.

> +		else if (ina->alert_type_select & (SQ52210_ALERT_ALL_BOL_MASK
> +					| SQ52210_ALERT_ALL_BUL_MASK))
> +			*val = regval >> 3;
> +		else if (ina->alert_type_select & SQ52210_ALERT_ALL_POL_MASK)
> +			*val = regval;
> +		break;
>  	default:
>  		*val = 0;
>  		return -EOPNOTSUPP;
> @@ -443,6 +512,94 @@ static int ina3221_read_curr(struct device *dev, u32 attr,
>  	}
>  }
>  
> +static int sq52210_alert_limit_write(struct ina3221_data *ina,
> +			enum sq52210_alert_types type, int channel, long val)
> +{
> +	struct regmap *regmap = ina->regmap;

[ ... ]

> +	return ret;
> +}
> +

Is this function unused in this commit? This might cause a build warning
or error depending on the compiler configuration.

commit a0f07f4a272baa0684c7d1ebd30e585dd23a1d77
Author:     Wenliang Yan <wenliang202407@163.com>
hwmon: (ina3221) Modify write/read functions for 'in' and 'curr' attribute

Modified the relevant read/write functions for 'in' and 'curr' attributes,
adding support for crit, lcrit, crit_alarm, and lcrit_alarm features.

> diff --git a/drivers/hwmon/ina3221.c b/drivers/hwmon/ina3221.c
> index 2338b3288950..fdcd92082c02 100644
> --- a/drivers/hwmon/ina3221.c
> +++ b/drivers/hwmon/ina3221.c
> @@ -823,6 +819,10 @@ static int ina3221_write_curr(struct device *dev, u32 attr,
>  	case hwmon_curr_crit:
>  	case hwmon_curr_max:
>  		return ina3221_write_curr_shunt(ina, attr, channel, val);
> +	case hwmon_curr_lcrit:
> +		return sq52210_alert_limit_write(ina, SQ52210_ALERT_SUL, channel, val);

Does this pass the current value (in milliAmps) directly to a function
that expects a Shunt Voltage value (in microVolts)? The
sq52210_alert_limit_write() function for SQ52210_ALERT_SUL divides by
5 (implying 5uV LSB), but does not account for the shunt resistor value.
This will set an incorrect limit unless the shunt resistor happens to
be 1 mOhm.

> +	default:
> +		return 0;
> +	}
> +}
> +

      reply	other threads:[~2026-01-28 17:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-19 12:14 Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 1/8] dt-bindings: hwmon: ti,ina3221: Add SQ52210 Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 2/8] hwmon: (ina3221) Add support for SQ52210 Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 3/8] hwmon: (ina3221) Pre-calculate current and power LSB Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 4/8] hwmon: (ina3221) Support alert configuration Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 5/8] hwmon: (ina3221) Introduce power attribute and alert characteristics Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 6/8] hwmon: (ina3221) Support for writing alert limit values and modify the 'ina3221_read_value' function Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 7/8] hwmon: (ina3221) Support write/read functions for 'power' attribute Wenliang Yan
2026-01-19 12:14 ` [PATCH v5 8/8] hwmon: (ina3221) Modify write/read functions for 'in' and 'curr' attribute Wenliang Yan
2026-01-27 18:07 ` [PATCH v5 0/8] hwmon: (ina3221) Various improvement and add support for SQ52210 Guenter Roeck
2026-01-28 17:41   ` Guenter Roeck [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9e9feb88-46db-4b47-a8ed-e30eb0f658c8@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=conor+dt@kernel.org \
    --cc=corbet@lwn.net \
    --cc=devicetree@vger.kernel.org \
    --cc=jdelvare@suse.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=wenliang202407@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®