linux-kernel - Re: [PATCH v4 6/7] hwmon: Add Nuvoton NCT6694 HWMON support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOoeyxWvRzHRVLW-U=nemfUpoF5pcO_bDmvg4U-wVqkFp=V=Yg@mail.gmail.com>
Date: Mon, 13 Jan 2025 11:00:07 +0800
From: Ming Yu <a0282524688@...il.com>
To: Simon Horman <horms@...nel.org>
Cc: tmyu0@...oton.com, lee@...nel.org, linus.walleij@...aro.org, brgl@...ev.pl, 
	andi.shyti@...nel.org, mkl@...gutronix.de, mailhol.vincent@...adoo.fr, 
	andrew+netdev@...n.ch, davem@...emloft.net, edumazet@...gle.com, 
	kuba@...nel.org, pabeni@...hat.com, wim@...ux-watchdog.org, 
	linux@...ck-us.net, jdelvare@...e.com, alexandre.belloni@...tlin.com, 
	linux-kernel@...r.kernel.org, linux-gpio@...r.kernel.org, 
	linux-i2c@...r.kernel.org, linux-can@...r.kernel.org, netdev@...r.kernel.org, 
	linux-watchdog@...r.kernel.org, linux-hwmon@...r.kernel.org, 
	linux-rtc@...r.kernel.org
Subject: Re: [PATCH v4 6/7] hwmon: Add Nuvoton NCT6694 HWMON support

Dear Simon,

Thank you for your comments,

Simon Horman <horms@...nel.org> 於 2025年1月6日 週一 下午9:51寫道：
>
...
> > +static int nct6694_pwm_read(struct device *dev, u32 attr, int channel,
> > +                         long *val)
> > +{
> > +     struct nct6694_hwmon_data *data = dev_get_drvdata(dev);
> > +     unsigned char pwm_en;
> > +     int ret;
> > +
> > +     guard(mutex)(&data->lock);
> > +
> > +     switch (attr) {
> > +     case hwmon_pwm_enable:
> > +             pwm_en = data->hwmon_en.pwm_en[channel / 8];
> > +             *val = !!(pwm_en & BIT(channel % 8));
> > +
> > +             return 0;
> > +     case hwmon_pwm_input:
> > +             ret = nct6694_read_msg(data->nct6694, NCT6694_RPT_MOD,
> > +                                    NCT6694_PWM_IDX(channel),
> > +                                    sizeof(data->rpt->fin),
> > +                                    &data->rpt->fin);
> > +             if (ret)
> > +                     return ret;
> > +
> > +             *val = data->rpt->fin;
>
> Hi Ming Yu,
>
> *val is host byte order, but fin is big endian.
> Elsewhere in this patch this seems to be handled using,
> which looks correct to me:
>
>                 *val = be16_to_cpu(data->rpt->fin);
>
> Flagged by Sparse.
>

Yes, it needs to be fixed to be16_to_cpu(). I'll make the modification
in the next patch.

> > +
> > +             return 0;
> > +     case hwmon_pwm_freq:
> > +             *val = NCT6694_FREQ_FROM_REG(data->hwmon_en.pwm_freq[channel]);
> > +
> > +             return 0;
> > +     default:
> > +             return -EOPNOTSUPP;
> > +     }
> > +}
>
> ...
>
> > +static int nct6694_fan_write(struct device *dev, u32 attr, int channel,
> > +                          long val)
> > +{
> > +     struct nct6694_hwmon_data *data = dev_get_drvdata(dev);
> > +     int ret;
> > +
> > +     guard(mutex)(&data->lock);
> > +
> > +     switch (attr) {
> > +     case hwmon_fan_enable:
> > +             if (val == 0)
> > +                     data->hwmon_en.fin_en[channel / 8] &= ~BIT(channel % 8);
> > +             else if (val == 1)
> > +                     data->hwmon_en.fin_en[channel / 8] |= BIT(channel % 8);
> > +             else
> > +                     return -EINVAL;
> > +
> > +             return nct6694_write_msg(data->nct6694, NCT6694_HWMON_MOD,
> > +                                      NCT6694_HWMON_CONTROL,
> > +                                      sizeof(data->msg->hwmon_ctrl),
> > +                                      &data->hwmon_en);
> > +     case hwmon_fan_min:
> > +             ret = nct6694_read_msg(data->nct6694, NCT6694_HWMON_MOD,
> > +                                    NCT6694_HWMON_ALARM,
> > +                                    sizeof(data->msg->hwmon_alarm),
> > +                                    &data->msg->hwmon_alarm);
> > +             if (ret)
> > +                     return ret;
> > +
> > +             val = clamp_val(val, 1, 65535);
> > +             data->msg->hwmon_alarm.fin_ll[channel] = (u16)cpu_to_be16(val);
>
> cpu_to_be16() returns a 16bit big endian value.
> And, AFAIKT, the type of data->msg->hwmon_alarm.fin_ll[channel] is __be16.
>
> So the cast above seems both unnecessary and misleading.
>
> Also flagged by Sparse,
>

Understood. Fix it in v5.

> ...

Best regards,
Ming