Re: [PATCH v1 2/2] HID: logitech-hidpp: Add Bluetooth Mouse M336/M337/M535 to unhandled_hidpp_devices[]

[Benjamin Tissoires]

On Wed, Dec 7, 2022 at 2:01 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote:
>
> On Wed, Dec 7, 2022 at 1:43 PM Bastien Nocera <hadess@xxxxxxxxxx> wrote:
> >
> > On Wed, 2022-12-07 at 11:19 +0100, Jiri Kosina wrote:
> > > On Wed, 7 Dec 2022, Benjamin Tissoires wrote:
> > >
> > > > 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".

> >
> > 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.

>
> 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.

>
> 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.

Cheers,
Benjamin