Re: [hwmon-next PATCH v4 3/4] hwmon: (adt7470) Expose fan control via PWM framework
Uwe Kleine-König <[email protected]> Wed, 29 Jul 2026 23:34:37 +0200
| Newsgroups | org.kernel.vger.linux-pwm,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-hwmon,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <ampxIhULPHehuh-W@monoceros> |
--4izvw3qpe3fpglq6
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hwmon-next PATCH v4 3/4] hwmon: (adt7470) Expose fan control
via PWM framework
MIME-Version: 1.0
Hello Luiz,
On Wed, Jul 29, 2026 at 04:05:56PM -0300, Luiz Angelo Daros de Luca wrote:
> > Here the right thing is (untested):
> >
> > if (!wf->period_length_ns) {
> > wfhw->val =3D 0;
> > return 0;
> > }
> >
> > actual_period =3D NSEC_PER_SEC / data->pwm_freq;
> >
> > if (wf->duty_length_ns >=3D actual_period)
> > val =3D ADT7470_PWM_MAX;
> > else
> > val =3D mul_u64_u64_div_u64(wf->duty_length_ns, ADT7470=
_PWM_MAX, actual_period);
> >
> > return (actual_period < wf->period_length_ns) ? 0 : 1;
>=20
> Uwe, thank you for the waveform callbacks snippet. It was much
> cleaner. I only had to make one small mathematical adjustment to the
> actual_period calculation in tohw() to satisfy CONFIG_PWM_DEBUG.
>=20
> When using a truncating division (NSEC_PER_SEC / data->pwm_freq), it
> triggered a "Wrong rounding" error during testing:
>=20
> pwm pwmchip0: Wrong rounding: requested 714285/714286 [+0], result
> 714286/714286 [+0]
>=20
> For example, at 1400 Hz, the truncating division gives an
> actual_period of 714285 ns. If the framework requests a duty cycle of
> 714285 ns and a period of 714286 ns, the evaluation (714285 * 255) /
> 714285 yields a register value of 255. When read back in fromhw()
> (which correctly rounds the period up to 714286 ns), the resulting
> duty cycle becomes 714286 ns. Since 714286 > 714285, CONFIG_PWM_DEBUG
> rightfully complains about the duty cycle inflation.
>=20
> To ensure the calculated register value is strictly rounded down, I
> changed the actual_period denominator in tohw() to use
> DIV_ROUND_UP_ULL(NSEC_PER_SEC, data->pwm_freq). Maximizing the
> denominator guarantees the resulting duty cycle fraction never
> inflates, effectively passing all strict debug checks.
right, for the calculation of actual_period an uprounding division must
be used.
Best regards
Uwe
--4izvw3qpe3fpglq6
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmpqcesACgkQj4D7WH0S
/k4M/Qf9FUh8r/Mos5Xlhds3O4AozIeptjPDjVQinaOBMDcTpvpIKWGiYJPR1ZOa
V+DtOcZXGmh+9tCqZBKMDXLqlpwp+6Ln6NQ5h8n8gs5mZQBKMn2N8VT0ZtRyl8+F
gl7BgU2Cj/roFgQwcMP9tfArvRRZecQgHGCVytDB1JyX8cN4fBIwosa70AuuXBHl
tLldpU77Xnj4LHkfo60iLWHrOwjhpervElLiG3H+6zlRrZBNBXMkJjHRo8JY0wJu
xbHZ/cbxMmvjF/7WHKJBoKQaeWfY9izCpJDi1wuVVTieHJL6F36ysWFsBPhDY2P3
JC1yu7ANKYAyqGrzM6k8diEbnTYRHA==
=sWH3
-----END PGP SIGNATURE-----
--4izvw3qpe3fpglq6--