On Tue, Oct 04, 2022 at 11:13:37AM +0200, Linus Walleij wrote:
> On Tue, Oct 4, 2022 at 10:59 AM Conor Dooley <conor.dooley@xxxxxxxxxxxxx> wrote:
> > On Tue, Oct 04, 2022 at 10:48:38AM +0200, Linus Walleij wrote:
> > > On Fri, Sep 30, 2022 at 11:28 PM Rob Herring <robh@xxxxxxxxxx> wrote:
> > > > On Fri, 30 Sep 2022 14:14:04 +0800, Hal Feng wrote:
> > > > > From: Jianlong Huang <jianlong.huang@xxxxxxxxxxxxxxxx>
> > > > >
> > > > > Add the SoC name to make it more clear. Also the next generation StarFive
> > > > > SoCs will use "pinctrl-starfive" as the core of StarFive pinctrl driver.
> > > > > No functional change.
> > > > >
> > > > > Signed-off-by: Jianlong Huang <jianlong.huang@xxxxxxxxxxxxxxxx>
> > > > > Signed-off-by: Hal Feng <hal.feng@xxxxxxxxxxxxxxxxxxxxxx>
> > > > > ---
> > > > > .../bindings/pinctrl/starfive,jh7100-pinctrl.yaml | 2 +-
> > > > > arch/riscv/boot/dts/starfive/jh7100-beaglev-starlight.dts | 2 +-
> > > > > drivers/pinctrl/starfive/Kconfig | 2 +-
> > > > > drivers/pinctrl/starfive/Makefile | 2 +-
> > > > > .../{pinctrl-starfive.c => pinctrl-starfive-jh7100.c} | 2 +-
> > > > > .../{pinctrl-starfive.h => pinctrl-starfive-jh7100.h} | 6 +++---
> > > > > 6 files changed, 8 insertions(+), 8 deletions(-)
> > > > > rename drivers/pinctrl/starfive/{pinctrl-starfive.c => pinctrl-starfive-jh7100.c} (99%)
> > > > > rename include/dt-bindings/pinctrl/{pinctrl-starfive.h => pinctrl-starfive-jh7100.h} (98%)
> > > > >
> > > >
> > > > Reviewed-by: Rob Herring <robh@xxxxxxxxxx>
> > > >
> > > > Would be good to pull this out separately and apply for 6.1. It's kind
> > > > of messy with cross tree dependencies.
> > >
> > > OK I applied this for V6.1.
> >
> > Will this need to be done immutably so it can be pulled into the riscv
> > tree in case this gets applied as a late change for 6.1:
> > https://lore.kernel.org/linux-riscv/c5169131-486e-9808-ba48-b7abe1be6a99@xxxxxxxxxxxxx/
>
> Always one finger on the fast-forward button have we? ;)
Dunno what you mean by that mate, sorry!
I just saw the mail wanted to have the decency to reply to that fellow
& tell him to rebase after rc1 to avoid a conflict.
> Rob's point was that I should apply this for v6.1 so that exactly
> that kind of cross-dependencies and immutable branches could
> be avoided for the v6.2 development cycle.
>
> The merge window is already open, it's a bit late for completely
> new stuff I think.
History suggests otherwise, but I'd be lying if I said I disagreed.
