On 08/10/2016 09:38 AM, Timur Tabi wrote: > Florian Fainelli wrote: >>> >Is there an easy way for me to stop the RX path before I set >>> rxbuf_size? >>> > Some netif_xxx function I can call? >> napi_disable() should take care of that. > > It appears that if I call netif_stop_queue() *afer* calling > napi_disable(), I get a hang and/or TX timeout. Since emac_mac_down() > does this: > > netif_stop_queue(netdev); > napi_disable(&adpt->rx_q.napi); > > I cannot call just napi_disable() in emac_change_mtu(), because when I > then call emac_mac_down(), the first thing it does is call > netif_stop_queue(), and that's when I timeout/hang. Whatever emac_mac_down() does you can unroll it in the change_mtu callback anyway, so if this a problematic sequence you can work around it. > > Unfortunately, I cannot even do this: > > netif_stop_queue(netdev); > napi_disable(&adpt->rx_q.napi); > netif_stop_queue(netdev); > napi_disable(&adpt->rx_q.napi); > > Even though I've already called netif_stop_queue(), calling it again > causes the timeout/hang. Buf if this is really what you copy/pasted here, why do this twice anyway? > > Is this expected? I never understood why I needed to call > netif_stop_queue() before napi_disable(). I do see some drivers do not > call netif_stop_queue(). I even saw a driver that calls them in reverse > order, so I don't understand why that sequence breaks for me but not him. > Not clear how the two relate with each other here, must be specific to your driver implementation somehow. -- Florian -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
