Re: [PATCH v2] hwmon: (lm90) Switch channel parsing to fwnode APIs

[Guenter Roeck]

On 7/17/26 01:00, Flaviu Nistor wrote:
> On Fri, 17 Jul 2026 10:06, Flaviu Nistor wrote
> > On Fri, 17 Jul 2026 09:49, sashiko-bot wrote:
> > > Thank you for your contribution! Sashiko AI review found 2 potential issue(=
> > > s) to consider:
> > >
> > > New issues:
> > > - [Low] Incompatible pointer type causing build failure
> > >
> > > Pre-existing issues:
> > > - [Critical] Sysfs read triggers NULL pointer dereference via uninitialized=
> > > hwmon_dev
> > > --
> > >
> > > --- Patch [1]: [PATCH v2] hwmon: (lm90) Switch channel parsing to fwnode AP=
> > > Is ---
> > > commit 3d5d792e5529b3545ccefc21f7dfd9c2acecc999
> > > Author: Flaviu Nistor <flaviu.nistor@xxxxxxxxx>
> > >
> > > hwmon: (lm90) Switch channel parsing to fwnode APIs
> > >    =20
> > > This commit replaces OF property handling with fwnode APIs in the probe
> > > function to read channel properties. This improves compatibility by no long=
> > > er
> > > limiting it to Device Tree.
> > >
> > > Link: https://lore.kernel.org/all/20260713190659.4511-1-flaviu.nistor@gmail=
> > > .com/
> > >
> > > > diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
> > > > index 4b9c0ccdf2609..7d4b8e61bec51 100644
> > > > --- a/drivers/hwmon/lm90.c
> > > > +++ b/drivers/hwmon/lm90.c
> > > [ ... ]
> > > > @@ -2701,27 +2701,27 @@ static int lm90_probe_channel_from_dt(struct i2c_=
> > > client *client,
> > > [ ... ]
> > > > -=09err =3D of_property_read_s32(child, "temperature-offset-millicelsius"=
> > > > , &val);
> > > > +=09err =3D fwnode_property_read_u32(child, "temperature-offset-millicels=
> > > ius", &val);
> > >
> > > [Severity: Low]
> > > Will this cause a build failure or compiler warning?
> > >
> > > In lm90_probe_channel(), val is declared as an s32, but it is being passed
> > > to fwnode_property_read_u32() which expects a u32 pointer. This pointer typ=
> > > e
> > > mismatch can trigger a -Wincompatible-pointer-types error in modern builds.
> >
> > This is absolutely true and I can't understand how this got into the patch since
> > I have test is. I will send a v3 correcting s32 to u32.
> > Sorry for this!
> >
> > Best regards,
> > Flaviu
>
> I have double checked and there is no warning or error when building the driver.
> Please ignore my previews reply as v2 can be used. I had in mind something different
> and it looks like not a great morning start. I am sorry for the noise on the mailing list.

So how do you expect the driver to handle negative temperature offsets ?
By silently auto-converting it to s32 and hoping that the firmware core
handles it correctly ?

Yes, I know, of_property_read_s32() maps to of_property_read_u32(), but
the API at least suggests that signed values are handled correctly.
That is not the case with fwnode_property_read_u32().

Guenter