On Tue, Mar 27, 2012 at 10:39:13AM +0800, Elric Fu wrote: > 2012/3/27 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>: > > On Mon, Mar 26, 2012 at 08:46:23PM +0800, Elric Fu wrote: > >> The suspend operation of VIA xHCI host have some issues and > >> hibernate operation works fine, so The XHCI_RESET_ON_RESUME > >> quirk is added for it. > >> > >> This patch should base on "xHCI: Don't write zeroed pointer > >> to xHC registers" that is released by Sarah. Otherwise, the > >> host system error will ocurr in the hibernate operation > >> process. > > > > This patch doesn't apply on top of the patch you mentioned. What's > > missing is there is no section for checking the VIA PCI vendor ID. You > > added that in your VIA firmware printing patch. > > > > What I want is this patch (by itself) to apply to my for-usb-linus-queue > > branch that is destined to be merged into 3.4. Then I can mark just > > that patch for stable. You'll need to move some of the code from the > > firmware printing patch into this patch to make it apply. So checkout > > the for-usb-linus-queue and make sure this patch applies before > > resending it. > > > > Once you've changed this patch to be first in your series, rebase the > > firmware printing patch on top of that. Resend it, and I will queue it > > for the 3.5 merge window. > > > > If you have any questions about this, don't hesitate to ask. > > Sorry, I am confused. Do you mean that you just want to apply the > firmware printing patch to 3.5, and apply this patch to your > for-usb-linus-queue branch that is prepared for 3.4? Yes. > So should I modify the patch and not let it base on the firmware > printing patch as you want to apply them to different branches? Yes. > Will the firmware printing patch not be applied to 3.4? No, it will not be applied to 3.4. I want to apply the firmware printing patch to 3.5. It's a new feature, and it should go into the next kernel release, not the current -rc. Only bug fixes should go into the current -rc. If you needed the VIA firmware to apply the reset quirk to a particular version of the firmware, then I would consider queueing the firmware printing patch for 3.4 and stable. But if you're just printing the firmware version, then I don't see why you need that information for a bug fix. It's part of the philosophy of how the kernel release process works. The latest stable kernel (currently 3.3) gets released, and then the 3.4 merge window opens. Greg KH sends any new USB features to Linus during this time. Over the next 2-3 months, we we stabilize those features over each successive release candidate (-rc) version. We don't introduce new features in the middle of an -rc process. Greg KH has already sent the USB feature pull request for 3.4, so we can't get any new features into 3.4. That's why the firmware printing patch needs to go into 3.5, because it isn't a bug fix, it's a feature. Makes sense? Sarah -- 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
