Re: [PATCH v2 2/6] hwmon: (max6697) Drop platform data support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 7/24/24 08:41, Tzung-Bi Shih wrote:
On Wed, Jul 24, 2024 at 07:25:31AM -0700, Guenter Roeck wrote:
On 7/24/24 06:03, Tzung-Bi Shih wrote:
On Tue, Jul 23, 2024 at 08:44:43AM -0700, Guenter Roeck wrote:
+	if (data->type != max6581) {
+		if (of_property_read_bool(node, "resistance-cancellation") &&
+		    chip->valid_conf & MAX6697_CONF_RESISTANCE) {
+			confreg |= MAX6697_CONF_RESISTANCE;
+			factor = 1;
+		}
+	} else {
+		if (of_property_read_u32(node, "resistance-cancellation", &vals[0])) {
+			if (of_property_read_bool(node, "resistance-cancellation"))
+				vals[0] = 0xfe;
+			else
+				vals[0] = 0;
+		}
+
+		factor = hweight8(vals[0] & 0xfe);

It doesn't AND with 0xfe originally.


Yes, but the original code uses the value in
	factor += hweight8(pdata->resistance_cancellation >> 1);
	ret = i2c_smbus_write_byte_data(client, MAX6581_REG_RESISTANCE,
                                         pdata->resistance_cancellation >> 1);
which is effectively the same. I can't just use
	factor = hweight8(vals[0] >> 1);
because, unlike resistance_cancellation, val[] is an u32 array which would
not auto-mask the upper bits.

If you are worrying about:
* MSB, it should be fine as it should only prepend 0s for right shift on
   unsigned.
* BIT(8), other `val[0] >> 1` should also share the same concern.

BIT(8) is the concern. Yes, you are correct, I'll change the code to

	val[0] &= 0xfe;
	factor = hweight8(vals[0]);
	...

In practice it doesn't matter since bit 7 isn't used by the chip,
but that isn't a reason for the bad code.

Thanks a lot for noticing!

Guenter








[Index of Archives]     [LM Sensors]     [Linux Sound]     [ALSA Users]     [ALSA Devel]     [Linux Audio Users]     [Linux Media]     [Kernel]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux