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]

Message-ID: <5ba33e10-7d75-9f9a-dfd6-c04608d230a4@gmx.de>
Date:   Tue, 18 Jan 2022 09:54:56 +0100
From:   Helge Deller <deller@....de>
To:     Jani Nikula <jani.nikula@...ux.intel.com>,
        Thomas Zimmermann <tzimmermann@...e.de>,
        Daniel Vetter <daniel@...ll.ch>
Cc:     linux-fbdev@...r.kernel.org,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        Javier Martinez Canillas <javierm@...hat.com>,
        Geert Uytterhoeven <geert@...ux-m68k.org>
Subject: Re: [PATCH] MAINTAINERS: Add Helge as fbdev maintainer

On 1/18/22 09:38, Jani Nikula wrote:
> On Mon, 17 Jan 2022, Helge Deller <deller@....de> wrote:
>> On 1/17/22 22:40, Jani Nikula wrote:
>>> On Mon, 17 Jan 2022, Thomas Zimmermann <tzimmermann@...e.de> wrote:
>>>> Seems like few people read linux-fbdev these days.
>>>
>>> How much traffic is there to linux-fbdev that is *not* Cc'd to dri-devel
>>> also?
>>
>> Doesn't seem like much traffic - which IMHO is OK for such a tree with
>> mostly just maintenance patches.
>>
>>> Do we still need a separate linux-fbdev mailing list at all?
>>
>> Yes. I want to have it seperate of dri-devel.
>> Actually I'd prefer to drop dri-devel from the list where patches
>> for fbdev are sent...
>
> Disagreed. If anything, this thread shows we can't have fbdev and drm in
> silos of their own.

Patches to fbdev usually don't affect DRM.
Patches which affect DRM needs to through to dri-devel.
In addition this would take the burden of the dri-developers to receive
unrelated fbdev driver updates and patches.

> Also, if the patches continue to get merged through drm-misc, they need
> to be sent to dri-devel.

Helge