Thread (22 messages) 22 messages, 5 authors, 2025-01-13

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

From: Ming Yu <hidden>
Date: 2025-01-13 03:00:19
Also in: linux-can, linux-gpio, linux-hwmon, linux-i2c, linux-rtc, linux-watchdog, lkml

Dear Simon,

Thank you for your comments,

Simon Horman [off-list ref] 於 2025年1月6日 週一 下午9:51寫道:
...
quoted
+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.
quoted
+
+             return 0;
+     case hwmon_pwm_freq:
+             *val = NCT6694_FREQ_FROM_REG(data->hwmon_en.pwm_freq[channel]);
+
+             return 0;
+     default:
+             return -EOPNOTSUPP;
+     }
+}
...
quoted
+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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help