2012/3/29 Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>: > 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? Yes, your explanation is very clear. I very appreciate that. And I will modify and resend it. Best Regards, Elric Fu > > 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
