linux-kernel - Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

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: <CAKMK7uF=75vCS1z4wfvEdGEaHu9-Uxpyu94Y4umbXO9ihBhbvQ@mail.gmail.com>
Date:   Wed, 26 Jan 2022 23:37:09 +0100
From:   Daniel Vetter <daniel@...ll.ch>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Javier Martinez Canillas <javierm@...hat.com>,
        Andy Shevchenko <andy@...nel.org>, linux-fbdev@...r.kernel.org,
        Michael Hennerich <michael.hennerich@...log.com>,
        Helge Deller <deller@....de>, linux-staging@...ts.linux.dev,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Phillip Potter <phil@...lpotter.co.uk>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Carlis <zhangxuezhi1@...ong.com>,
        Lee Jones <lee.jones@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

On Wed, Jan 26, 2022 at 3:24 PM Greg Kroah-Hartman
<gregkh@...uxfoundation.org> wrote:
> On Wed, Jan 26, 2022 at 03:18:14PM +0100, Javier Martinez Canillas wrote:
> > On 1/26/22 15:11, Andy Shevchenko wrote:
> > > On Wed, Jan 26, 2022 at 02:47:33PM +0100, Javier Martinez Canillas wrote:
> > >> On 1/26/22 14:27, Andy Shevchenko wrote:
> > >>> On Wed, Jan 26, 2022 at 12:18:30PM +0100, Javier Martinez Canillas wrote:
> > >>>> On 1/26/22 11:59, Helge Deller wrote:
> > >>>>> On 1/26/22 11:02, Andy Shevchenko wrote:
> > >
> > > ...
> > >
> > >>>>>> P.S. For the record, I will personally NAK any attempts to remove that
> > >>>>>> driver from the kernel. And this is another point why it's better not
> > >>>>>> to be under the staging.
> > >>>>>
> > >>>>> I agree. Same as for me to NAK the disabling of fbcon's acceleration
> > >>>>> features or even attempting to remove fbdev altogether (unless all
> > >>>>> relevant drivers are ported to DRM).
> > >>>>
> > >>>> But that will never happen if we keep moving the goal post.
> > >>>>
> > >>>> At some point new fbdev drivers should not be added anymore, otherwise
> > >>>> the number of existing drivers that need conversion will keep growing.
> > >>>
> > >>> This thread is not about adding a new driver.
> > >>
> > >> It was about adding a new drivers to drivers/video/ (taken from staging).
> > >
> > > Does it mean gates are open to take any new fbdev drivers to the staging?
> > > If not, I do not see a point here.
> > >
> >
> > Good question. I don't know really.
> >
> > But staging has always been more flexible in what's accepted there and
> > that's why some distros avoid to enable CONFIG_STAGING=y in the kernel.
>
> And that's why if you load a staging driver, it enables TAINT_CRAP in
> your runtime flags :)

fwiw I'm fine with adding new fbdev drivers to staging, that really
doesn't hurt anyone. Adding drm drivers to staging tends to be pain,
least because if we need to do any changes to helpers there's a
cross-tree cordination problem usually, and the benefit of staging
hasn't in the past really outweighted that. Plus I try for us to land
new drivers when they're good enough directly into drivers/gpu, and
not aim for perfect.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch