On 11/17/21 7:35 AM, Greg Kroah-Hartman wrote:
On Tue, Nov 16, 2021 at 08:58:15PM +0100, Marek Vasut wrote:
On 11/16/21 7:35 PM, Greg Kroah-Hartman wrote:
On Tue, Nov 16, 2021 at 06:41:08PM +0100, Szabolcs Sipos wrote:
On 10/11/21 09:44, Greg Kroah-Hartman wrote:
On Sun, Oct 10, 2021 at 10:59:06PM +0200, Marek Vasut wrote:
Hello everyone,
The following new device USB ID has landed in linux-next recently:
4fd6d4907961 ("Bluetooth: btusb: Add support for TP-Link UB500 Adapter")
It would be nice if it could be backported to stable. I verified it works on
5.14.y as a simple cherry-pick .
A patch needs to be in Linus's tree before we can add it to the stable
releases. Please let us know when it gets there and we will be glad to
pick it up.
thanks,
greg k-h
Hello Greg,
The patch has reached Linus's tree:
4fd6d4907961 ("Bluetooth: btusb: Add support for TP-Link UB500 Adapter")
Could you please add it to stable (5.15.y)?
I will queue it up for the next set of kernels after the current ones are
released.
btw while you're bringing it up, is there some sure-fire method I can use to
verify the patch is in Linus tree, besides having a separate checkout of
that tree ?
Without the tree/branch checked out? Not that I know of, sorry.
I have a local checkout of Linus tree, except I also have other remotes
in it, that's what I meant.
I usually have both Linus tree as origin and next in one git tree, so I was
wondering if there is a recommended way to avoid mistakes like the one I
made above (and checking at git.kernel.org apparently also has its
downsides).
Having both in one git tree is fine. Just switch between branches (one
that tracks Linus's and one that tracks linux-next) and you can see what
is happening in each of them.
I can do some "git log linus/master | grep the-commit" , but that does
not seem to be the most efficient approach, or is it ?
There's other "tricks" to see if patches have been added to branches by
adding them to a branch and then rebasing and seeing the end result, but
those get tricky to try to explain in simple emails...
Some sort of git-cherry-pick and git-rebase ?
All right
