Messages in this thread Patch in this message | | | Date | Tue, 22 Nov 2022 18:54:00 +0000 | From | "Russell King (Oracle)" <> | Subject | Re: [PATCH net v2] net: stmmac: Set MAC's flow control register to reflect current settings |
| |
On Tue, Nov 22, 2022 at 06:40:33PM +0000, Russell King (Oracle) wrote: > On Tue, Nov 22, 2022 at 02:39:35PM +0800, Goh, Wei Sheng wrote: > > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c > > index c25bfecb4a2d..369db308b1dd 100644 > > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c > > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c > > @@ -748,6 +748,9 @@ static void dwmac4_flow_ctrl(struct mac_device_info *hw, unsigned int duplex, > > if (fc & FLOW_RX) { > > pr_debug("\tReceive Flow-Control ON\n"); > > flow |= GMAC_RX_FLOW_CTRL_RFE; > > + } else { > > + pr_debug("\tReceive Flow-Control OFF\n"); > > + flow &= ~GMAC_RX_FLOW_CTRL_RFE; > > } > > writel(flow, ioaddr + GMAC_RX_FLOW_CTRL); > > This doesn't look correct to me. The function starts off: > > unsigned int flow = 0; > > flow is not written to before the context above. So, the code you've > added effectively does: > > flow = 0 & ~GMAC_RX_FLOW_CTRL_RFE; > > which is still zero. So, I don't think this hunk is meaningful apart > from adding the pr_debug().
It also should be noted that it looks like:
dwxgmac2_core.c::dwxgmac2_flow_ctrl() is definitely buggy - it will only set flow control, never clearing it.
dwmac100_core.c::dwmac100_flow_ctrl() looks potentially buggy - always enabling flow control irrespective of anything.
The other two implmentations look sane to me.
-- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
| |