On Thu, Sep 04, 2025 at 11:19:48AM +0800, Yibo Dong wrote: > On Thu, Sep 04, 2025 at 12:24:17AM +0200, Andrew Lunn wrote: > > > struct mucse_mbx_info { > > > + struct mucse_mbx_stats stats; > > > + u32 timeout; > > > + u32 usec_delay; > > > + u16 size; > > > + u16 fw_req; > > > + u16 fw_ack; > > > + /* lock for only one use mbx */ > > > + struct mutex lock; > > > /* fw <--> pf mbx */ > > > u32 fw_pf_shm_base; > > > u32 pf2fw_mbox_ctrl; > > > > > +/** > > > + * mucse_obtain_mbx_lock_pf - Obtain mailbox lock > > > + * @hw: pointer to the HW structure > > > + * > > > + * This function maybe used in an irq handler. > > > + * > > > + * Return: 0 if we obtained the mailbox lock or else -EIO > > > + **/ > > > +static int mucse_obtain_mbx_lock_pf(struct mucse_hw *hw) > > > +{ > > > + struct mucse_mbx_info *mbx = &hw->mbx; > > > + int try_cnt = 5000; > > > + u32 reg; > > > + > > > + reg = PF2FW_MBOX_CTRL(mbx); > > > + while (try_cnt-- > 0) { > > > + mbx_ctrl_wr32(mbx, reg, MBOX_PF_HOLD); > > > + /* force write back before check */ > > > + wmb(); > > > + if (mbx_ctrl_rd32(mbx, reg) & MBOX_PF_HOLD) > > > + return 0; > > > + udelay(100); > > > + } > > > + return -EIO; > > > +} > > > > If there is a function which obtains a lock, there is normally a > > function which releases a lock. But i don't see it. > > > > The lock is relased when send MBOX_CTRL_REQ in mucse_write_mbx_pf: > > mbx_ctrl_wr32(mbx, ctrl_reg, MBOX_CTRL_REQ); > > Set MBOX_PF_HOLD(bit3) to hold the lock, clear bit3 to release, and set > MBOX_CTRL_REQ(bit0) to send the req. req and lock are different bits in > one register. So we send the req along with releasing lock (set bit0 and > clear bit3). > Maybe I should add comment like this? > > /* send the req along with releasing the lock */ > mbx_ctrl_wr32(mbx, ctrl_reg, MBOX_CTRL_REQ); As i said, functions like this come in pairs. obtain/release, lock/unlock. When reading code, you want to be able to see both of the pair in a function, to know the unlock is not missing. The kernel even has tools which will validate all paths through a function releasing locks. Often error paths get this wrong. So please make this a function, give it a name which makes it obvious it is the opposite of mucse_obtain_mbx_lock_pf(). Andrew