linux-kernel - Re: [RFC PATCH 0/3] staging: remove fbdev drivers

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] [day] [month] [year] [list]

Message-ID: <CAHp75VdUzTojreu=fBQSaEySVjVWAAPa4oB9adPf3bZDhmtO0g@mail.gmail.com>
Date:   Thu, 22 Dec 2016 22:36:14 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Cc:     Tomi Valkeinen <tomi.valkeinen@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Noralf Trønnes <noralf@...nnes.org>,
        Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Teddy Wang <teddy.wang@...iconmotion.com>,
        Arnaud Patard <arnaud.patard@...-net.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 0/3] staging: remove fbdev drivers

On Wed, Nov 23, 2016 at 12:05 PM, Thomas Petazzoni
<thomas.petazzoni@...e-electrons.com> wrote:
> On Wed, 23 Nov 2016 11:12:32 +0200, Tomi Valkeinen wrote:

>> Or do you mean that we should keep the drivers in staging until there's
>> a matching DRM driver, but drop any plans to move the drivers from
>> staging to drivers/video/? If so, I'm fine with that. This is an RFC,
>> mostly to raise some discussion and push people to actually write those
>> DRM drivers =).
>
> The very reason why I submitted those drivers for staging is because
> lots and lots of people were using out of tree kernel modules for these
> drivers, which was really a pain.
>
> If you now remove those drivers from staging, then those folks will be
> back in the situation they originally were, using annoying out of tree
> modules.
>
> I'm all for removing fbtft drivers progressively as a matching
> DRM-based driver is available for the same hardware. However, if there
> is no DRM-based support for a given piece of hardware supported by
> fbtft, I'd prefer if we kept the fbtft driver for this hardware.

Too many people are playing with big things, I vote +1 to *leave*
fbtft for people who prefer small on big.

-- 
With Best Regards,
Andy Shevchenko