From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

[ Upstream commit 58bfe7d8e31014d7ce246788df99c56e3cfe6c68 ]

This reverts commit 3d5f70949f1b1168fbb17d06eb5c57e984c56c58.

The quirk does not work properly, more work is needed to determine what
should be done here.

Reported-by: Oliver Neukum <oneukum@suse.com>
Cc: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
Cc: stable <stable@kernel.org>
Fixes: 3d5f70949f1b ("usb: add quirks for Lenovo OneLink+ Dock")
Link: https://lore.kernel.org/r/9a17ea86-079f-510d-e919-01bc53a6d09f@gmx.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 drivers/usb/core/quirks.c | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index 999b7c9697fc..f99a65a64588 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -437,10 +437,6 @@ static const struct usb_device_id usb_quirk_list[] = {
 	{ USB_DEVICE(0x1532, 0x0116), .driver_info =
 			USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
 
-	/* Lenovo ThinkPad OneLink+ Dock twin hub controllers (VIA Labs VL812) */
-	{ USB_DEVICE(0x17ef, 0x1018), .driver_info = USB_QUIRK_RESET_RESUME },
-	{ USB_DEVICE(0x17ef, 0x1019), .driver_info = USB_QUIRK_RESET_RESUME },
-
 	/* Lenovo USB-C to Ethernet Adapter RTL8153-04 */
 	{ USB_DEVICE(0x17ef, 0x720c), .driver_info = USB_QUIRK_NO_LPM },
 
-- 
2.35.1

I wonder, does it make sense to queue the commit (as 011/207) and 
immediately its revert (the patch below) in a single release? I doubt 
that...

The same holds for 012 (patch) + 015 (revert).

On 26. 09. 22, 12:10, Greg Kroah-Hartman wrote:
> From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> [ Upstream commit 58bfe7d8e31014d7ce246788df99c56e3cfe6c68 ]
> 
> This reverts commit 3d5f70949f1b1168fbb17d06eb5c57e984c56c58.
> 
> The quirk does not work properly, more work is needed to determine what
> should be done here.
> 
> Reported-by: Oliver Neukum <oneukum@suse.com>
> Cc: Jean-Francois Le Fillatre <jflf_kernel@gmx.com>
> Cc: stable <stable@kernel.org>
> Fixes: 3d5f70949f1b ("usb: add quirks for Lenovo OneLink+ Dock")
> Link: https://lore.kernel.org/r/9a17ea86-079f-510d-e919-01bc53a6d09f@gmx.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---
>   drivers/usb/core/quirks.c | 4 ----
>   1 file changed, 4 deletions(-)
> 
> diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
> index 999b7c9697fc..f99a65a64588 100644
> --- a/drivers/usb/core/quirks.c
> +++ b/drivers/usb/core/quirks.c
> @@ -437,10 +437,6 @@ static const struct usb_device_id usb_quirk_list[] = {
>   	{ USB_DEVICE(0x1532, 0x0116), .driver_info =
>   			USB_QUIRK_LINEAR_UFRAME_INTR_BINTERVAL },
>   
> -	/* Lenovo ThinkPad OneLink+ Dock twin hub controllers (VIA Labs VL812) */
> -	{ USB_DEVICE(0x17ef, 0x1018), .driver_info = USB_QUIRK_RESET_RESUME },
> -	{ USB_DEVICE(0x17ef, 0x1019), .driver_info = USB_QUIRK_RESET_RESUME },
> -
>   	/* Lenovo USB-C to Ethernet Adapter RTL8153-04 */
>   	{ USB_DEVICE(0x17ef, 0x720c), .driver_info = USB_QUIRK_NO_LPM },
>   

-- 
js
suse labs

On Tue, Sep 27, 2022 at 07:23:46AM +0200, Jiri Slaby wrote:
> I wonder, does it make sense to queue the commit (as 011/207) and
> immediately its revert (the patch below) in a single release? I doubt
> that...
> 
> The same holds for 012 (patch) + 015 (revert).

Yes it does, otherwise tools will pick up "hey, you forgot this patch
that should have been applied here!" all the time.  Having the patch,
and the revert, in the tree prevents that from happening.

thanks,

greg k-h

On 27. 09. 22, 7:47, Greg Kroah-Hartman wrote:
> On Tue, Sep 27, 2022 at 07:23:46AM +0200, Jiri Slaby wrote:
>> I wonder, does it make sense to queue the commit (as 011/207) and
>> immediately its revert (the patch below) in a single release? I doubt
>> that...
>>
>> The same holds for 012 (patch) + 015 (revert).
> 
> Yes it does, otherwise tools will pick up "hey, you forgot this patch
> that should have been applied here!" all the time.  Having the patch,
> and the revert, in the tree prevents that from happening.

It'd be fairly easy to fix the tools not to pick up reverted commits, right?

thanks,
-- 
js
suse labs

On Tue, Sep 27, 2022 at 08:18:26AM +0200, Jiri Slaby wrote:
> On 27. 09. 22, 7:47, Greg Kroah-Hartman wrote:
> > On Tue, Sep 27, 2022 at 07:23:46AM +0200, Jiri Slaby wrote:
> > > I wonder, does it make sense to queue the commit (as 011/207) and
> > > immediately its revert (the patch below) in a single release? I doubt
> > > that...
> > > 
> > > The same holds for 012 (patch) + 015 (revert).
> > 
> > Yes it does, otherwise tools will pick up "hey, you forgot this patch
> > that should have been applied here!" all the time.  Having the patch,
> > and the revert, in the tree prevents that from happening.
> 
> It'd be fairly easy to fix the tools not to pick up reverted commits, right?

Not really as they are usually quite "far" away from the original
commits.

But hey, if you have some scripts that can find all of that, I'm all for
it, the ones I have right now don't account for this.

thanks,

greg k-h

On 27. 09. 22, 8:31, Greg Kroah-Hartman wrote:
> On Tue, Sep 27, 2022 at 08:18:26AM +0200, Jiri Slaby wrote:
>> On 27. 09. 22, 7:47, Greg Kroah-Hartman wrote:
>>> On Tue, Sep 27, 2022 at 07:23:46AM +0200, Jiri Slaby wrote:
>>>> I wonder, does it make sense to queue the commit (as 011/207) and
>>>> immediately its revert (the patch below) in a single release? I doubt
>>>> that...
>>>>
>>>> The same holds for 012 (patch) + 015 (revert).
>>>
>>> Yes it does, otherwise tools will pick up "hey, you forgot this patch
>>> that should have been applied here!" all the time.  Having the patch,
>>> and the revert, in the tree prevents that from happening.
>>
>> It'd be fairly easy to fix the tools not to pick up reverted commits, right?
> 
> Not really as they are usually quite "far" away from the original
> commits.

Yes, but you need to deal with this only in a particular release (a 
revert has to be applied if the commit is already in some previous 
release, of course).

> But hey, if you have some scripts that can find all of that, I'm all for
> it, the ones I have right now don't account for this.

I don't know your/Sasha's scripts. But they are apparently able to find 
the revert as can we see above. So instead of direct:
   cherry-pick revert-patch-for-commit-X
it would be:
   if (PATCH=`git grep -l "[Cc]ommit X" queue-RELEASE/`)
     git rm PATCH
   else
     cherry-pick revert-patch-for-commit-X
   fi

Or am I missing something?

thanks,
-- 
js