On Wed, Jul 24, 2024 at 10:40:20AM -0700, Guenter Roeck wrote:
> 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]);
> ...
With that,
Reviewed-by: Tzung-Bi Shih <tzungbi@xxxxxxxxxx>
Note: there is another `vals[0] >> 1` for MAX6581_REG_IDEALITY_SELECT.
