From: Javier Martinez Canillas <javierm@redhat.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: linux-kernel@vger.kernel.org,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <mripard@kernel.org>,
Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH v1 1/2] firmware: sysfb: Unorphan sysfb files
Date: Fri, 27 Jun 2025 13:37:17 +0200 [thread overview]
Message-ID: <87frflbeky.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <aF53djlieUNF_-aV@smile.fi.intel.com>
Andy Shevchenko <andriy.shevchenko@linux.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
next prev parent reply other threads:[~2025-06-27 11:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 17:18 [PATCH v1 0/2] firmware: sysfb: Unorphan and fix header Andy Shevchenko
2025-06-26 17:19 ` [PATCH v1 1/2] firmware: sysfb: Unorphan sysfb files Andy Shevchenko
2025-06-27 8:50 ` Javier Martinez Canillas
2025-06-27 9:02 ` Andy Shevchenko
2025-06-27 9:19 ` Javier Martinez Canillas
2025-06-27 10:22 ` Andy Shevchenko
2025-06-27 10:33 ` Javier Martinez Canillas
2025-06-27 10:50 ` Andy Shevchenko
2025-06-27 11:37 ` Javier Martinez Canillas [this message]
2025-06-26 17:19 ` [PATCH v1 2/2] firmware: sysfb: Don't use "proxy" headers Andy Shevchenko
2025-06-27 8:51 ` Javier Martinez Canillas
2025-06-27 10:35 ` Andy Shevchenko
2025-06-27 8:38 ` [PATCH v1 0/2] firmware: sysfb: Unorphan and fix header Thomas Zimmermann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87frflbeky.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=tzimmermann@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®