Messages in this thread | | | Date | Fri, 26 Apr 2024 12:43:15 -0700 | Subject | Re: [PATCH net v2 3/3] net: bcmgenet: synchronize UMAC_CMD access | From | Doug Berger <> |
| |
On 4/26/2024 11:19 AM, Florian Fainelli wrote: > On 4/25/24 15:27, Doug Berger wrote: >> The UMAC_CMD register is written from different execution >> contexts and has insufficient synchronization protections to >> prevent possible corruption. Of particular concern are the >> acceses from the phy_device delayed work context used by the >> adjust_link call and the BH context that may be used by the >> ndo_set_rx_mode call. >> >> A spinlock is added to the driver to protect contended register >> accesses (i.e. reg_lock) and it is used to synchronize accesses >> to UMAC_CMD. >> >> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file") >> Cc: stable@vger.kernel.org >> Signed-off-by: Doug Berger <opendmb@gmail.com> > > Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> > > As a bug fix this is totally fine. I believe there could be an > improvement made in 'net-next' whereby we introduce an > unimac_rmw_locked() or something that essentially does: > > void unimac_rmw_locked(struct bcmgenet_priv *priv, u32 offset, u32 > mask_clear, u32 mask_set) > { > u32 reg; > spin_lock_bh(&priv->reg_lock); > reg = bcmgenet_umac_readl(priv, offset); > reg &= ~mask_clear; > reg |= mask_set; > bcmgenet_umac_writel(priv, reg, offset); > spin_unlock_bh(&priv->reg_lock); > } > > At least a couple of callers could benefit from it. Thanks! The only issue I see is enforcing the 2us delay in reset_umac(). A scenario where a different context might attempt to modify UMAC_CMD during that window is admittedly contrived, but the approach of this commit provides better protection.
-Doug
| |