linux-kernel - Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

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:   Mon, 17 Jan 2022 11:19:50 +0100
From:   Javier Martinez Canillas <javierm@...hat.com>
To:     Daniel Vetter <daniel@...ll.ch>, Helge Deller <deller@....de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        "airlied@...il.com" <airlied@...il.com>
Cc:     linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

On 1/17/22 11:02, Daniel Vetter wrote:

[snip]

>>  FRAMEBUFFER LAYER
>> -L:     dri-devel@...ts.freedesktop.org
>> +M:     Helge Deller <deller@....de>
>>  L:     linux-fbdev@...r.kernel.org
>> -S:     Orphan
> 
> Maybe don't rush maintainer changes in over the w/e without even bothering
> to get any input from the people who've been maintaining it before.
> 
> Because the status isn't entirely correct, fbdev core code and fbcon and
> all that has been maintained, but in bugfixes only mode. And there's very
> solid&important reasons to keep merging these patches through a drm tree,
> because that's where all the driver development happens, and hence also
> all the testing (e.g. the drm test suite has some fbdev tests - the only
> automated ones that exist to my knowledge - and we run them in CI). So
> moving that into an obscure new tree which isn't even in linux-next yet is
> no good at all.
> 
> Now fbdev driver bugfixes is indeed practically orphaned and I very much
> welcome anyone stepping up for that, but the simplest approach there would
> be to just get drm-misc commit rights and push the oddball bugfix in there
> directly. But also if you want to do your own pull requests to Linus for
> that I don't care and there's really no interference I think, so
> whatever floats.
>

I second that getting commit rights in drm-misc and pushing the changes
there makes much more sense than keeping a separate tree for fbdev.

Not only for the fbdev core and fbcon but also for fbdev drivers. There
is common for fbdev drivers bugs to be exposed after DRM changes, so it
is more convenient to push fixes for these through the same tree as well.

As an example, just last week I had to fix issues in the vga16fb driver
that started to occur after a change to support simpledrm in aarch64:

https://lore.kernel.org/all/20220111131601.u36j6grsvnir5gvp@houat/T/

If there is a separate tree for fbdev, then this would require to do
some coordination, share and merge immutable branches, etc for no
clear benefit.

Best regards,-- 
Javier Martinez Canillas
Linux Engineering
Red Hat