From: Guenter Roeck <linux@roeck-us.net>
To: Wenliang Yan <wenliang202407@163.com>
Cc: christophe.jaillet@wanadoo.fr, conor+dt@kernel.org,
corbet@lwn.net, jdelvare@suse.com, krzk+dt@kernel.org,
linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
robh@kernel.org
Subject: Re: [PATCH v5 2/2] hwmon:(ina238)Add support for SQ52206
Date: Mon, 24 Mar 2025 07:12:12 -0700 [thread overview]
Message-ID: <164922f5-d7d9-4e36-b0d4-5ba4c30597e3@roeck-us.net> (raw)
In-Reply-To: <20250324123852.4120-1-wenliang202407@163.com>
On 3/24/25 05:38, Wenliang Yan wrote:
> At 2025-03-23 01:25:11, "Guenter Roeck" <linux@roeck-us.net> wrote:
>> On 3/13/25 01:02, Wenliang Yan wrote:
>>> Add support for SQ52206 to the Ina238 driver. Add registers,
>>> add calculation formulas, increase compatibility, add
>>> compatibility programs for multiple chips.
>>>
>>> Signed-off-by: Wenliang Yan <wenliang202407@163.com>
>>
>> The patch unfortunately combines adding support for a new chip
>> with adding the necessary infrastructure. I finally found the time
>> to look into this further and split the changes, trying to find out
>> what actually changed. Unfortunately there are some problems.
>> Some of them are listed below.
>>
>> This is not a complete review. Also, I'll have to write module tests
>> to ensure that support for existing chips is not broken.
>>
>>> #define INA238_SHUNT_VOLTAGE_LSB 5 /* 5 uV/lsb */
>>> #define INA238_BUS_VOLTAGE_LSB 3125 /* 3.125 mV/lsb */
>>> -#define INA238_DIE_TEMP_LSB 125 /* 125 mC/lsb */
>>> +#define INA238_DIE_TEMP_LSB 1250000 /* 125 mC/lsb */
>>
>> This is not correct. The unit is 10ths of uC.
>>
>
> Since the temp_lsb of sq52206 is 7.8125 mC/LSB, in order to express it as an interger,
> my original intention was to use 7.8125*10000 to represent 7.8125 mC/lsb.
> At the same time, for the consistency of different devides, using 125 * 10000 to represent 125mC/lsb.
>
Yes, I understand. The problem here is not the code, just the comment.
>>> +#define SQ52206_BUS_VOLTAGE_LSB 3750 /* 3.75 mV/lsb */
>>> +#define SQ52206_DIE_TEMP_LSB 78125 /* 7.8125 mC/lsb */
>>>
>> ... expressed in 10ths of uC.
>>
>>> static const struct regmap_config ina238_regmap_config = {
>>> .max_register = INA238_REGISTERS,
>>> @@ -102,7 +114,20 @@ static const struct regmap_config ina238_regmap_config = {
>>> .val_bits = 16,
>>> };
>>>
>>> +enum ina238_ids { ina238, ina237, sq52206 };
>>> +
>>> +struct ina238_config {
>>> + bool has_power_highest; /* chip detection power peak */
>>> + bool has_energy; /* chip detection energy */
>>> + u8 temp_shift;
>>> + u32 power_calculate_factor; /*fixed parameters for power calculate*/
>>> + u16 config_default;
>>> + int bus_voltage_lsb; /* uV */
>>> + int temp_lsb; /* mC */
>>
>> No, this is not the temperature in mC. It is the temperature in 10th of uC.
>>
>
> This is indeed a problem, I need to handle temp_lsb appropriately.
>
Same as above. The problem is (as far as I can see) not in the code.
The comment should state the correct units.
>>> /* gain of 1 -> LSB / 4 */
>>> - *val = (regval * INA238_SHUNT_VOLTAGE_LSB) /
>>> - (1000 * (4 - data->gain + 1));
>>> + *val = (regval * INA238_SHUNT_VOLTAGE_LSB) *
>>> + data->gain / (1000 * 4);
>>
>> The slight benefit of this change is that the divisor is now a constant,
>> which may enable some compiler optimization. Still, it is not a necessary
>> change and just makes review more difficult.
>>
>
> The original formula takes effect only when gain=1 or 4, but sq52206 has a gain=2.
> The principle of this formula is the same as before.
>
Thanks for the clarification. It might make sense to separate this and the
calculation change below out into a separate patch and explain the reasoning
in the commit description.
Thanks,
Guenter
prev parent reply other threads:[~2025-03-24 14:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-13 7:54 [PATCH v5 0/2] " Wenliang Yan
2025-03-13 8:02 ` [PATCH v5 1/2] dt-bindings:Add SQ52206 to ina2xx devicetree bindings Wenliang Yan
2025-03-13 8:02 ` [PATCH v5 2/2] hwmon:(ina238)Add support for SQ52206 Wenliang Yan
2025-03-22 17:25 ` Guenter Roeck
2025-03-24 12:38 ` Wenliang Yan
2025-03-24 14:12 ` 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=164922f5-d7d9-4e36-b0d4-5ba4c30597e3@roeck-us.net \
--to=linux@roeck-us.net \
--cc=christophe.jaillet@wanadoo.fr \
--cc=conor+dt@kernel.org \
--cc=corbet@lwn.net \
--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®