Re: [PATCH 1/2] drm/mediatek/hdmi: Use syscon_regmap_lookup_by_phandle_args

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Il 13/01/25 15:31, Krzysztof Kozlowski ha scritto:
On 13/01/2025 15:27, Krzysztof Kozlowski wrote:
On 13/01/2025 14:58, AngeloGioacchino Del Regno wrote:
Il 13/01/25 14:05, Krzysztof Kozlowski ha scritto:
On 13/01/2025 13:41, AngeloGioacchino Del Regno wrote:
Il 12/01/25 14:47, Krzysztof Kozlowski ha scritto:
Use syscon_regmap_lookup_by_phandle_args() which is a wrapper over
syscon_regmap_lookup_by_phandle() combined with getting the syscon
argument.  Except simpler code this annotates within one line that given
phandle has arguments, so grepping for code would be easier.

There is also no real benefit in printing errors on missing syscon
argument, because this is done just too late: runtime check on
static/build-time data.  Dtschema and Devicetree bindings offer the
static/build-time check for this already.


I agree with this change but can you please rebase it over [1]?

The same code got migrated to mtk_hdmi_common.c instead :-)

[1]:
https://lore.kernel.org/r/20250108112744.64686-1-angelogioacchino.delregno@xxxxxxxxxxxxx
My is 2-patch cleanup, your is 34 patch rework and new features with
existing build reports, so rebase is not reasonable. It would make this
2-patch cleanup wait for many cycles.

If adding the `#include <linux/bitfield.h>` line to a file would take
*many cycles*, that'd be a bit weird, wouldn't it? :-)
It's not about include, it is about rebase. If I rebase on 34-patchset,
that's my dependency and this work cannot be merged before yours is.

And yours already have kbuild reports, so there will be v5, maybe v6 etc.


Although "NO!!!! No more huge patch bombs to
linux-kernel@xxxxxxxxxxxxxxx people!" was removed, but its spirit is
kind of still valid and requesting to rebase cleanups on top of patch
bombs with new features is just not reasonable.


I understand Krzysztof, but since my 34-patchset should be ready and I don't
expect to send any v6 for how it is right now, your patch would make it
necessary to send yet another patchbomb on my side... we're kind-of in the
same situation here, and I feel like we're making a big issue out of something
that should not really be a problem.

I'm sorry about this situation, and I feel like this doesn't really depend
on me, as much as it doesn't really depend on you... let's just see what CK
thinks about this, or else, I don't know how to make this easier on all of
us - me, you and the maintainer.

If it felt like me being rude in any way, that wasn't my intention, btw.

I can offer to rebase this patch on my own keeping your authorship, if that
makes things easier.

Cheers,
Angelo



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux