[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230721054955.4rzcgawqjeunlnm4@pengutronix.de>
Date: Fri, 21 Jul 2023 07:49:55 +0200
From: Uwe Kleine-König <u.kleine-koenig@...gutronix.de>
To: Thierry Reding <thierry.reding@...il.com>
Cc: Guiting Shen <aarongt.shen@...il.com>,
claudiu.beznea@...rochip.com, nicolas.ferre@...rochip.com,
alexandre.belloni@...tlin.com,
linux-arm-kernel@...ts.infradead.org, linux-pwm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6] pwm: atmel: Enable clk when pwm already enabled in
bootloader
On Thu, Jul 20, 2023 at 05:12:30PM +0200, Thierry Reding wrote:
> On Sun, Jul 16, 2023 at 10:06:52AM +0800, Guiting Shen wrote:
> > +static int atmel_pwm_enable_clk_if_on(struct atmel_pwm_chip *atmel_pwm, bool on)
> > +{
> > + unsigned int i, cnt = 0;
> > + int ret = 0;
> > + u32 sr;
> > +
> > + sr = atmel_pwm_readl(atmel_pwm, PWM_SR) & PWM_SR_ALL_CH_MASK;
> > + if (!sr)
> > + return 0;
> > +
> > + cnt = bitmap_weight((unsigned long *)&sr, atmel_pwm->chip.npwm);
>
> Tiny nit here: not sure if that cast is safe to do. You've got a 32-bit
> variable, but if you cast &sr to unsigned long * on a 64-bit machine it
> would cause hweight64() to get called and that would then read 64 bits
> from a 32-bit variable. This probably works most of the time because we
> don't read any of the upper bits, but it is strictly an illegal access
> and could be unaligned as well.
While relevance of BE systems ceases slowly, such a machine would
evaluate the wrong bits.
> Should we just turn sr into an unsigned long to be safe here?
yes please.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists