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. Best regards, Krzysztof
