On Fri, 30 Nov 2012 16:23:46 +0000 David Woodhouse <dw...@infradead.org> wrote:
> On Fri, 2012-11-30 at 12:10 +0000, David Woodhouse wrote: > > In that case I think we're fine. I'll just do the same thing in > > br2684_push(), fix up the comment you just corrected, and we're all > > good. > > OK, here's an update to me my patch 8/17 'br2684: don't send frames on > not-ready vcc'. It takes the socket lock and does fairly much the same > thing as your pppoatm version. It returns NETDEV_TX_BUSY and stops the > queue if the socket is locked, and it gets woken from the ->release_cb > callback. > > I've dropped your Acked-By: since it's mostly new, but feel free to give > me a fresh one. With this I think we're done. > > Unless Chas has any objections, I'll ask Dave to pull it... no objections. i think this deals with my concerns. as for splitting the close functions, from one of your previous messages: >Really, what we're saying is that *one* of the driver or protocol close >functions needs to be split, and we need to do DPD or PDP. Since the >device driver *can* abort/flush the TX queue and also any pending RX >being handled by a tasklet, I think it makes most sense to keep it in >the middle, with the protocol being handled first and last... which is >the current order, as long as we consider setting ATM_VF_CLOSE to be the >first part. i believe this is essentially already done with the release_cb() implementation right? that is splitting the protocol detach/shutdown into two parts. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/