On Tue, Aug 13, 2024 at 08:45:19AM +0300, Raag Jadav wrote:
> On Mon, Aug 12, 2024 at 04:15:14PM +0300, Andy Shevchenko wrote:
> > On Mon, Aug 12, 2024 at 01:45:38PM +0530, Raag Jadav wrote:
...
> > > +static int
> > > +hwm_fan_read(struct hwm_drvdata *ddat, u32 attr, long *val)
> > > +{
> > > + struct i915_hwmon *hwmon = ddat->hwmon;
> > > + struct hwm_fan_info *fi = &ddat->fi;
> > > + u64 rotations, time_now, time;
> > > + intel_wakeref_t wakeref;
> > > + u32 reg_val, pulses;
> > > + int ret = 0;
> > > +
> > > + if (attr != hwmon_fan_input)
> > > + return -EOPNOTSUPP;
> > > +
> > > + wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
> > > + mutex_lock(&hwmon->hwmon_lock);
> > > +
> > > + reg_val = intel_uncore_read(ddat->uncore, hwmon->rg.fan_speed);
> > > + time_now = get_jiffies_64();
> >
> > > + /* Handle HW register overflow */
> > > + if (reg_val >= fi->reg_val_prev)
> > > + pulses = reg_val - fi->reg_val_prev;
> > > + else
> > > + pulses = UINT_MAX - fi->reg_val_prev + reg_val;
> >
> > Isn't it the abs_diff() reimplementation?
>
> Not exactly. This is specific to 32 bit register overflow, so we count
> from max value.
I see. But since you have the both variables of u32, why:
1) UINT_MAX?
2) Not simply using
pulses = reg_val - fi->reg_val_prev;
which will wrap over correctly?
Note, in your case (in comparison to the wrap over variant) the off-by-one is
present. Is it on purpose?
--
With Best Regards,
Andy Shevchenko
