[RFC PATCH 0/9] pinctrl: sunxi: Allwinner A733 support

[Andre Przywara]

Hi,

On 8/27/26 01:07, Vinicius Pedrosa wrote:
> Hi Andre,
> 
> This series no longer applies to mainline. Patch 1/9 fails on current

Yes, naturally, this series is quite old, and we had some changes and 
fixes in pinctrl meanwhile.
I didn't find time in the last cycles, but will send an update *after*
-rc1 is released. So just a bit more patience ...

Cheers,
Andre

P.S. What was the particular purpose of you sending this email? I can't 
help to feel this is AI generated, isn't it? But the breakage is 
obvious, and as you can imagine I am well aware of my patch having been 
merged, and other patches in the vicinity which I authored or reviewed 
conflicting. In fact I regularly rebase my branches on every -rc1, I 
just didn't get around to send a new version.

> master (45c13f3f9e3b), for two separate reasons - one of them from
> outside the series, which is why I am reporting it rather than just
> fixing it locally.
> 
> Applying the series in order:
> 
>    [RFC PATCH 1/9] pinctrl: sunxi: rename SUNXI_PINCTRL_NEW_REG_LAYOUT
>      error: patch failed: drivers/pinctrl/sunxi/pinctrl-sunxi.c:1521
>      error: patch failed: drivers/pinctrl/sunxi/pinctrl-sunxi.h:88
> 
> The blocking one is your own patch 2/9. It merged as 42e06688c6cb
> ("pinctrl: sunxi: pass down flags to pinctrl routines") without 1/9, so
> sunxi_pinctrl_init_with_flags() now reads
> 
> 	pctl->flags = flags;
> 
> where 1/9 still expects
> 
> 	pctl->variant = flags & SUNXI_PINCTRL_VARIANT_MASK;
> 
> as context. A 3-way merge does not resolve it - both sides touch
> adjacent lines, so it conflicts.
> 
> The second is unrelated to your work. 70f8915ea4e9 ("pinctrl: sunxi: fix
> gpiochip_lock_as_irq() failure when pinmux is unknown") inserted
> SUN4I_FUNC_DISABLED_OLD/NEW into 1/9's header hunk context, and added a
> fifth use of SUNXI_PINCTRL_NEW_REG_LAYOUT, in
> sunxi_pinctrl_irq_request_resources(). The header hunk merges cleanly
> with -3, but that new use is not covered by the rename, so the tree then
> fails to build with an undeclared identifier.
> 
> Patches 3/9 through 9/9 apply cleanly once 1/9 is resolved.
> 
> Static reproduction only - no A733 hardware here, so nothing in this
> message says anything about whether the series works. I am not sending a
> rebase: which shape 1/9 should take now that 2/9 is in is your call.
> 
> Vinicius