Hi David, I asked you to send a patchset that only contains critical bug fixes, and this isn't what I'm looking for. What I want is a patchset containing only fixes that should be marked for stable, e.g. bug fixes only. Patches marked for stable should fix a crash, or some issue that causes the xHCI driver to behave differently than the EHCI driver WRT the upper layers (i.e. device drivers). In general, when you create a patchset that contains both bug fixes that should be bound for stable, and cleanups or optimizations, you need to put the bug fix patches as the very first patches in the patchset. So, the patchset I was looking for should only contain: > [7/9] xhci: Add support for URB_ZERO_PACKET to queue_bulk_sg_tx() Along with any bug fixes or critical patches you've sent me in the past. The rest of this patchset includes a mix of cleanups and optimizations: > [1/9] xhci: Remove debug code > [2/9] xhci: Minor cleanups to queue_bulk_sg_tx() > [3/9] xhci: Use a fast upper bound for the number of TRB for a SG request. > [4/9] xhci: Simplify setting of TRB type and flags in queue_bulk_sg_tx() > [5/9] xhci: Move fragment length calculation to top of loop in > queue_bulk_sg_tx() > [6/9] xhci: Use a much simpler algorithm for td_size on 1.0 hosts > [8/9] xhci: Common up setup of normal and scatter-gather transfers > [9/9] xhci: Add num_trbs_for_buf() to count trbs needed for a buffer > fragment Patch 1 is not a bug fix, as I've expressed before, although I still want to see it go into 3.14. I'm uninterested in optimizing the SG list TRB counting at this point in time, so I'm not interested in taking patches 3-5, and probably the rest of the patches as well. I'll be blunt here. The xHCI driver mostly Just Works. There's a few new features coming up, there's always going to be bugs to fix, and we're fixing some long-standing issues that cause a few devices to not work. But in general, the driver is pretty stable. I'm uninterested in making sweeping architectural changes to the driver at this point in time. That means I'm really not interested in your shadow ring idea, or trying to eliminate kmallocs in IRQ, etc. I'm allergic to any large driver cleanups at this point in time that have the potential to de-stablize the driver. I am interested in bug fixes, fixing long-standing issues, and supporting new features. I might be interested in performance patches, but they would have to come with hard numbers. Basically, I'm not interested in change for change sake. You seem to want to make large architectural changes, so maybe the xHCI driver isn't the right driver for you to work on. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
