On Mon, Jan 28, 2013 at 08:40:25PM +0200, Pantelis Antoniou wrote: > Hi Richard, > > Yes, I guess this was more of a drive-by patch dump - but people need this > to get PG2.0 silicon to work on am33xx. And what is PG2.0? > And no, I don't think having a non-NAPI code path is backwards, especially > when trying to debug hardware problems; the non-NAPI driver is much easier > to understand and follow, especially when there is a convoluted method > you have to follow to have the h/w acknowledge the interrupt. Special debug modes are fine to have, but not in mainline code. I suggest taking a look at the recent netdev discussion on this. Someone wanted to make napi/non-napi a DT option, and it got nixed. > Not every device can be conveniently be made to shut up so that NAPI processing > can take place at a later time. So, are you saying that the cpsw cannot work as a napi device? > The NAPI case is still broken in this driver, which OOPs under load. And does your patch fix it, or not? It would be nice to know what the problem is, and how to reproduce it. I haven't seen any OOPs on the beaglebone, but maybe I am not trying hard enough. Thanks, Richard -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
