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]
Date:   Wed, 26 Jan 2022 11:47:20 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Thomas Zimmermann <tzimmermann@...e.de>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Phillip Potter <phil@...lpotter.co.uk>,
        Lee Jones <lee.jones@...aro.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Carlis <zhangxuezhi1@...ong.com>, linux-kernel@...r.kernel.org,
        linux-staging@...ts.linux.dev, linux-fbdev@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Michael Hennerich <michael.hennerich@...log.com>,
        Helge Deller <deller@....de>, Andy Shevchenko <andy@...nel.org>
Subject: Re: [PATCH v1 0/4] fbtft: Unorphan the driver for maintenance

On Wed, Jan 26, 2022 at 12:02:36PM +0200, Andy Shevchenko wrote:
> On Wed, Jan 26, 2022 at 10:52 AM Thomas Zimmermann <tzimmermann@...e.de> wrote:
> >
> > Hi
> >
> > Am 25.01.22 um 21:21 schrieb Andy Shevchenko:
> > > Since we got a maintainer for fbdev, I would like to
> > > unorphan fbtft (with the idea of sending PRs to Helge)
> > > and move it out of staging since there is no more clean
> > > up work expected and no more drivers either.
> > >
> > > Thoughts?
> 
> Thanks for sharing yours, my answers below.
> 
> > But why? We already have DRM drivers for some of these devices.
> 
> No, we do not (only a few are available).
> 
> > Porting
> > the others to DRM is such a better long-term plan.  OTOH, as no one has
> > shown up and converted them, maybe they should be left dead or removed
> > entirely.
> 
> As I mentioned above there are devices that nobody will take time to
> port to a way too complex DRM subsystem. But the devices are cheap and
> quite widespread in the embedded world. I'm in possession of 3 or 4
> different models and only 1 is supported by tiny DRM.

Great, then let's just move the 2 models that you do not have support
for in DRM, not the whole lot.  When we have real users for the drivers,
we can move them out of staging, but until then, dragging all of them
out does not make sense.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ