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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ