Re: Re: [PATCH v2 07/10] pinctrl: ambarella: add Ambarella pin controller

(Page Konstantin)

On Tue, Aug 11, 2026 at 6:11 PM Rob Herring <[email protected]> wrote:
> On Mon, Aug 10, 2026 at 2:42 PM Linus Walleij <[email protected]> wrote:
> > On Mon, Aug 10, 2026 at 6:02 AM Long Zhao <[email protected]> wrote:
> >
> > > Thanks for the review. I will rework this to reuse the PL061 driver with
> > > per-variant register offsets, and evaluate modeling each GPIO bank as a
> > > separate DT entity. The duplicated GPIO implementation will be removed.
> >
> > Thanks Long, I think it will be easier if you break out the pin control
> > bindings and driver from the patch series and work on it separately,
> > the same with the serial driver at least.
> >
> > I understand this can be hard to test on the hardware, I usually
> > put a few patches "underneath" the b4 cover letter, and then the
> > b4 send-email will only send the cover letter and the patches
> > on top.
>
> The problem with that advice is then 'base-commit' is useless.
>
> Maybe b4 could learn an 'ignore the top N commits" or "only track the
> first N commits".

I honestly don't even know what the base-commit is for so that's
I have blissfully ignored this problem...

So the summa summarum is that the current behaviour kind
of encourages people to do large patch bombs for a new SoC
since due to base-commit and the fact that developers tend
to need to boot test the series (and it won't boot without some
other SoC-enablement patches) the series must be kept
toghether.

That explains why it feels like I see *more* of those patch
bombs these days.

My initial stance would be that a useless base-commit is
the lesser evil in cases like this.

Konstantin, what's your take on this dilemma?

Yours,
Linus Walleij