summaryrefslogtreecommitdiffstats
path: root/include/soc/imx
diff options
context:
space:
mode:
authorVladimir Oltean <vladimir.oltean@nxp.com>2023-04-15 19:05:46 +0200
committerJakub Kicinski <kuba@kernel.org>2023-04-18 04:01:18 +0200
commit3ff468ef987e38740de9ca0a811c55e11bfb2141 (patch)
tree60565f28595c1d6ec5c5e15902ba63db420820de /include/soc/imx
parentnet: mscc: ocelot: export a single ocelot_mm_irq() (diff)
downloadlinux-3ff468ef987e38740de9ca0a811c55e11bfb2141.tar.xz
linux-3ff468ef987e38740de9ca0a811c55e11bfb2141.zip
net: mscc: ocelot: remove struct ocelot_mm_state :: lock
Unfortunately, the workarounds for the hardware bugs make it pointless to keep fine-grained locking for the MAC Merge state of each port. Our vsc9959_cut_through_fwd() implementation requires ocelot->fwd_domain_lock to be held, in order to serialize with changes to the bridging domains and to port speed changes (which affect which ports can be cut-through). Simultaneously, the traffic classes which can be cut-through cannot be preemptible at the same time, and this will depend on the MAC Merge layer state (which changes from threaded interrupt context). Since vsc9959_cut_through_fwd() would have to hold the mm->lock of all ports for a correct and race-free implementation with respect to ocelot_mm_irq(), in practice it means that any time a port's mm->lock is held, it would potentially block holders of ocelot->fwd_domain_lock. In the interest of simple locking rules, make all MAC Merge layer state changes (and preemptible traffic class changes) be serialized by the ocelot->fwd_domain_lock. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'include/soc/imx')
0 files changed, 0 insertions, 0 deletions