linux-kernel - Re: RFC: Backport HID-logitech to 3.10?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAN+gG=FjjBFxNAKiXPu9xJQsZNOg1pOmo1_-MsvTQV4J11e6vw@mail.gmail.com>
Date:   Fri, 2 Sep 2016 11:32:06 +0200
From:   Benjamin Tissoires <benjamin.tissoires@...il.com>
To:     Simon Wood <simon@...gewell.org>
Cc:     linux-input <linux-input@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: RFC: Backport HID-logitech to 3.10?

Hi Simon,

On Thu, Sep 1, 2016 at 2:56 AM, Simon Wood <simon@...gewell.org> wrote:
> Hi all,
> I received a question regarding back-porting the support for the G29
> racing wheel to 3.10 (Android in particular), and after some collaborative
> work we determined that changes between 3.10 and 4.7 are actually pretty
> minimal and self contained.
>
> After copying the HEAD 'hid-lg.[ch]' and 'hid-lg4ff.[ch]' from 4.7, there
> is a minimal patch (example attached) required to get the build working.

Don't you need hid-logitech-hidpp too?

>
>
> My question to the list would be how this would/could be implemented, and
> how the process works as 3.10 moves through the mainline patches to reach
> current HEAD.

Not sure I understand exactly what you want from us here.

The stable rules are detailed in
Documentation/stable_kernel_rules.txt. And unfortunately, I don't
think adding these patches will be acceptable for upstream 3.10.
The rule of thumb is that if a distribution wants to backport changes,
they can have their own rules but the official stable tree is only for
fixing issues, not adding new device support, unless it's *very* small
("- New device IDs and quirks are also accepted.")

So if you need to backport the changes to the 3.10 tree, see the rules
of the distribution you are working on. Some prefer backporting full
commits only (to keep closer to upstream), others will accept some #if
LINUX_VERSION. In those case, I'd personally rather have a small
header that makes the glue between old code and new one to keep the
code closer to upstream.

Cheers,
Benjamin

>
> Any hints that anyone has would be appreciated.
> Simon.