Re: linux-next: build failure in the hid tree

[Derek John Clark]

On Sun, Mar 8, 2026 at 3:09 AM Jiri Kosina <jikos@xxxxxxxxxx> wrote:
>
> On Thu, 5 Mar 2026, Derek John Clark wrote:
>
> > > > > b53ccf3f72653c8a843188ffa2edd4bc2443686d HID: hid-lenovo-go: Add OS Mode Toggle
> > > > > 1d466a1adbf40e55501d766322d665de3a822b6e HID: hid-lenovo-go: Add Calibration Settings
> > > > > 557d5b34d52974bf4e43c459cbf50bed5615ead4 HID: hid-lenovo-go: Add RGB LED control interface
> > > > > f0119d450f1d4a5cc2ef2b38c2b522f902698a38 HID: hid-lenovo-go: Add FPS Mode DPI settings
> > > > > a8a9ca568ce547634e80e999013ac9f123acff1d HID: hid-lenovo-go: Add Rumble and Haptic Settings
> > > > > b2fd12c205b5a533ba2b1c5ffad669d08d52ce12 HID: hid-lenovo-go: Add Feature Status Attributes
> > > > > 3bb54f568ecc35be7675eef5303a47e14aba54bc HID: hid-lenovo-go: Add Lenovo Legion Go Series HID Driver
> > > > >
> > > > > I've left them for today but will take more action on Monday, probably
> > > > > reverts.
> > > >
> > > > I'll just drop the branch from for-next for now, and will let Mark and
> > > > Derek look into this and send followup fixes.
> > >
> > > Seems like both drivers are polluting a lot of global namespace actually.
> > > I normally catch this using sparse, but my installation doesn't work
> > > currently because of [1], so I missed it.
> > >
> > > Derek, Mark -- you need to add a lot of 'static' all over the place :) The
> > > for-7.1/lenovo branch stays out of for-next for now, please send a fixed
> > > version and we'll put it in for-7.1/lenovo-v2.
> > >
> > > [1] https://lwn.net/Articles/1006379/
> > >
> > > Thanks,
> >
> > Jiri,
> >
> > Sorry for the delayed response. Since your email there has been a lot
> > of activity from other contributors on top of my latest version in the
> > HID tree,
>
> Hi Derek,
>
> sorry for belated response, I was off for a week.
>
> Also there was a lot of warnings coming out of the kernel test robot, hope
> you've seen them?

Yes, I'm very motivated to push the fixes so I can stop getting them
at this point.

> > so I'm looking for guidance on the best way forward. I can either add a
> > patch after those to keep attribution identical while fixing the issues,
> > or I can include the changes in a new version of the series and add
> > co-developed-by tags.
>
> For the ones that really do break build (like many of the allyesconfig
> ones), I'd suggest you just incorporate the changes and use Reported-by:
> or Co-developed-by: tags in the name of bisectability.
>
> Other fixes can be put on top of the series.

Sounds good, that should be simple enough to do. I'll submit the
cosmetic ones as part of the next series version then so I can handle
and rebasing conflicts.

Thanks,
Derek

> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>