lkml.org 
[lkml]   [2024]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH net v2 3/3] net: bcmgenet: synchronize UMAC_CMD access
From
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

\
 
 \ /
  Last update: 2024-05-27 18:06    [W:0.091 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site