On Fri, Dec 16, 2022 at 05:00:30PM +0000, Biju Das wrote: > > Hello Biju, > > > > Do you need to take the ch->lock before checking ch->is_busy to ensure it > > does not change? > > priv->count_is_enabled[count->id]-> true means channel is held by counter. > So pwm won't be able to change the state ch->is_busy. > > priv->count_is_enabled[count->id]-> false and if there is contention for ch->busy > whoever is first calling rz_mtu3_request_channel() will get the channel. > among pwm_request and counter_enable. > > So I think it is safe here. Please correct me if I am missing something. > > static inline bool rz_mtu3_request_channel(struct rz_mtu3_channel *ch) > { > bool is_idle; > > mutex_lock(&ch->lock); > is_idle = !ch->is_busy; > if (is_idle) > ch->is_busy = true; > mutex_unlock(&ch->lock); > > return is_idle; > } Okay seems safe then. If the respective count_is_enabled will only be true when the respective channel is held by the counter, is there a need to check ch->is_busy, or would checking count_is_enabled alone suffice? William Breathitt Gray
Attachment:
signature.asc
Description: PGP signature