On Wed, Dec 7, 2022 at 2:25 PM Benjamin Tissoires
[off-list ref] wrote:

On Wed, Dec 7, 2022 at 2:01 PM Rafael J. Wysocki [off-list ref] wrote:

quoted

On Wed, Dec 7, 2022 at 1:43 PM Bastien Nocera [off-list ref] wrote:

quoted

On Wed, 2022-12-07 at 11:19 +0100, Jiri Kosina wrote:

quoted

On Wed, 7 Dec 2022, Benjamin Tissoires wrote:

quoted

Agree, but OTOH, Rafael, your mouse is not brand new AFAICT, so I
am
worried that you won't be the only one complaining we just killed
their
mouse. So I think the even wiser solution would be to delay (and so
revert in 6.1 or 6.2) the 2 patches that enable hid++ on all
logitech
mice (8544c812e43ab7bdf40458411b83987b8cba924d and
532223c8ac57605a10e46dc0ab23dcf01c9acb43).

If we were not at -rc8 timeframe, I'd be in favor to coming up with
proper
fix still for 6.1. But as things currently are, let's just revert
those
and reschedule them with proper fix for 6.2+.

Has anyone seen any other reports?

It's not so much about how many reports, but *what* the end result is.
If the device were working-ish, that would have been OK. But here the
device is completely ignored by the kernel which basically enters the
"no regression rule".

quoted

quoted

Because, honestly, seeing work that adds support for dozens of devices
getting tossed out at the last minute based on a single report with no
opportunity to fix the problem is really frustrating.

I know, and I feel your pain as I was about to have the same last week
for HID-BPF. But as much as I hate dropping patches from the queue,
not being able to have at least a week to fix it properly ends up with
"fixes" that are broken and that might break other devices. Talking
from experience as my first fix from last week was exactly in that
category.

quoted

Well, that's why I sent patches to address this particular case
without possibly breaking anything else.

My concern is more that we now have a data point were the series broke
a device (pretty badly) and if (when) this happens shortly after 6.1
is getting released, we would have to say, oh yes, we know, so we need
to patch the kernel because our driver is buggy, and we knew it. This
is not acceptable, and I am sure that if Linus reads that thread he
would revert the 2 patches or maybe more.

Well, I agree.

quoted

Improvements can be made on top of them and the blocklist entry added
by patch [2/2] need not stay there forever, FWIW.

I need to check with Jiri, but there is a chance we can re-introduce
this in 6.2. This way we will have slightly more time to fix it in a
proper way.

Sounds good to me.