linux-kernel - Re: [PATCH v1 1/2] firmware: sysfb: Unorphan sysfb files

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aF5w4QTbSkebYbk2@smile.fi.intel.com>
Date: Fri, 27 Jun 2025 13:22:25 +0300
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Javier Martinez Canillas <javierm@...hat.com>
Cc: linux-kernel@...r.kernel.org,
	Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
	Maxime Ripard <mripard@...nel.org>,
	Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH v1 1/2] firmware: sysfb: Unorphan sysfb files

On Fri, Jun 27, 2025 at 11:19:34AM +0200, Javier Martinez Canillas wrote:
> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> writes:
> > On Fri, Jun 27, 2025 at 10:50:48AM +0200, Javier Martinez Canillas wrote:
> >> Andy Shevchenko <andriy.shevchenko@...ux.intel.com> writes:

> >> > The commit d391c5827107 ("drivers/firmware: move x86 Generic
> >> > System Framebuffers support") moved some code to the common
> >> > folders and effectively orphaned it without any reason. Put
> >> > it back under DRM MISC record.
> >> 
> >> What do you mean that it was "orphaned without any reason" ? There were no
> >> regex matchs for the old file paths in MAINTAINERS either before that commit.
> >
> > There were maintainers for that code before. The change in question dropped that.
> >
> > [((bf44e8cecc03...))]$ scripts/get_maintainer.pl -f arch/x86/kernel/sysfb*
> > Thomas Gleixner <tglx@...utronix.de> (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
> > Ingo Molnar <mingo@...hat.com> (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
> > Borislav Petkov <bp@...en8.de> (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
> > x86@...nel.org (maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
> > "H. Peter Anvin" <hpa@...or.com> (reviewer:X86 ARCHITECTURE (32-BIT AND 64-BIT))
> > linux-kernel@...r.kernel.org (open list:X86 ARCHITECTURE (32-BIT AND 64-BIT))
> >
> > [((d391c5827107...))]$ scripts/get_maintainer.pl -f drivers/firmware/sysfb*
> > linux-kernel@...r.kernel.org (open list)
> 
> That's just because there is an entry for arch/x86/. The problem then is
> that there isn't an entry for drivers/firmware. It was orphaned then just
> because it was moved to a directory that has no entry in MAINTAINERS.
> 
> > See the difference?
> 
> There is no need to have such a rude tone.

It wasn't meant to be rude, sorry. The point is that any change in
drivers/firmware/sysfb* and respective include are not visible to (any)
maintainers, they just might be sent for a luck of somebody to pick
them up by browsing the LKML for such things.

...

> >> > +F:	drivers/firmware/sysfb*.c
> >
> >> I would prefer these to be in the "DRM DRIVER FOR FIRMWARE FRAMEBUFFERS"
> >> entry instead of "DRM DRIVERS" since the former is what has most of the
> >> code for the sysfb infrastructure.
> >
> > Then do it, please, fix the above.
> 
> Part of the review process is to give feedback to patch authors. I don't
> understand why you expect me to fix an issue you brought up just because
> I ask you to rework your patch a little.

In my humble opinion, the author of the patch that makes the problem appear
can help to fix that as well. Are my expectations too high?

In any case, this was an ad-hoc patch due to the second one, so this one
may be considered as a administrative bug report.

-- 
With Best Regards,
Andy Shevchenko