[PATCH v3 01/11] Revert "dt-bindings: mfd: syscon: Add qcom,apq8064-mmss-sfpb"

Dmitry Baryshkov dmitry.baryshkov at oss.qualcomm.com
Tue Apr 29 05:23:47 PDT 2025


On Mon, Apr 28, 2025 at 07:50:04PM +0200, Krzysztof Kozlowski wrote:
> On 28/04/2025 12:49, Dmitry Baryshkov wrote:
> > On Mon, 28 Apr 2025 at 10:09, Krzysztof Kozlowski <krzk at kernel.org> wrote:
> >>
> >> On 28/04/2025 09:07, Krzysztof Kozlowski wrote:
> >>> On Fri, Apr 25, 2025 at 08:47:01PM GMT, Dmitry Baryshkov wrote:
> >>>> For some reason Lee has mis-squashed two commits, picking up one chunk
> >>>> from the first patch and one chunk from the second one. Rather than
> >>>> trying to fix it, revert commit 2c8de7df7418 ("dt-bindings: mfd: syscon:
> >>>> Add qcom,apq8064-mmss-sfpb").
> >>>
> >>> I don't understand: that commit looks like direct, proper result for
> >>> https://lore.kernel.org/all/20250318-fix-nexus-4-v2-5-bcedd1406790@oss.qualcomm.com/
> >>> so where is squashing two commits? The diff markers have offset by few
> >>> lines, but it's still just few lines and they do not matter - there is
> >>> no diff/patch mismatch from that point of view.
> >>
> >> Ah, difference in compatibles. I see the error. Anyway, I don't think
> >> revert is correct. Just add missing compatibles.
> > 
> > Why? The commit that went in is invalid, didn't come from my patches
> > and was produced in some weird way.
> And revert is pointless if you immediately add the same changes. Just
> make the changes.
> 
> When we see a bug, we do not revert the feature and then re-add that
> feature corrected.

That depends. If the original patch went really bad, we sometimes revert
it and add a clear implementation rather than just trying to fix the
damaged state.

> 
> Instead we correct the feature.
> 
> Best regards,
> Krzysztof

-- 
With best wishes
Dmitry



More information about the linux-arm-kernel mailing list