[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <hgq3sqxuav3z3fgxyighfgqan6hliu2bev7bthgrmzlwsjecmv@7bxor6zucgct>
Date: Fri, 30 Jan 2026 23:54:00 +0100
From: Uwe Kleine-König <ukleinek@...nel.org>
To: Frank Li <Frank.li@....com>
Cc: "Viorel Suman (OSS)" <viorel.suman@....nxp.com>,
Sascha Hauer <s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>, linux-pwm@...r.kernel.org, imx@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pwm: imx-tpm: keep channel state instead of counting
On Fri, Jan 30, 2026 at 12:41:22PM -0500, Frank Li wrote:
> On Fri, Jan 30, 2026 at 04:37:20PM +0200, Viorel Suman (OSS) wrote:
> > @@ -166,6 +166,10 @@ static int pwm_imx_tpm_get_state(struct pwm_chip *chip,
> >
> > /* get channel status */
> > state->enabled = FIELD_GET(PWM_IMX_TPM_CnSC_ELS, val) ? true : false;
> > + if (state->enabled)
> > + tpm->enabled_channels |= BIT(pwm->hwpwm);
> > + else
> > + tpm->enabled_channels &= ~BIT(pwm->hwpwm);
>
> Do you have lock for RMW? or you should atomic_or() and atomic_and()
.get_state() is called under the chip lock, so the locking should be
fine.
Best regards
Uwe
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists