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] [day] [month] [year] [list]

Message-ID: <87frflbeky.fsf@minerva.mail-host-address-is-not-set>
Date: Fri, 27 Jun 2025 13:37:17 +0200
From: Javier Martinez Canillas <javierm@...hat.com>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.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

Andy Shevchenko <andriy.shevchenko@...ux.intel.com> writes:

> On Fri, Jun 27, 2025 at 12:33:31PM +0200, Javier Martinez Canillas wrote:

[...]

>
> The problem is deeper. This is default behaviour of get_maintainer digging
> into the Git history. In the past people were complaining (a lot in some cases)
> that they were included in the threads by a mistake because they made cosmetic
> patches or the treewide change while not being interested _at all_ in looking
> after the certain file / driver. So, with --no-git-fallback it gives nothing,
> expect LKML.
>
>> In my opinion both Thomas and me have much more context and knowledge of
>> the sysfb codebase than the x86 maintainers. It was just for historical
>> reasons that the sysfb code ended in the arch/x86/ sub-directory.
>> 
>> But you are correct that dri-devel at least should also be in the Cc list.
>
> See also above. Depending on the options it may still give bad result w.o.
> explicit mention in the MAINTAINERS (or via glob).
>

Sure, I was not saying that is not worth it.

> ...
>
>> >> >> > +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.
>> 
>> That's OK, but it wasn't framed as a bug report but as a patch and that's why
>> I gave my feedback. But I'll post a patch and add a Reported-by tag from you.
>
> Sure, thanks ahead!
>

Patch sent:

https://lore.kernel.org/dri-devel/20250627113328.2703491-1-javierm@redhat.com/T/#u

>> Thomas, I think we can then only merge patch #2 and I will take care of #1.
>
> I just sent a v2 without the first patch.
>
> Thanks for review!
>

You are welcome.

> -- 
> With Best Regards,
> Andy Shevchenko
>
>

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat