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/[email protected] >>> 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 [email protected] 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
