On Thu, Sep 11 2025 at 09:04, Herve Codina wrote:
> On 2025年9月09日 22:54:41 +0200
> Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>
>> On Tue, Sep 09 2025 at 22:51, Thomas Gleixner wrote:
>> > On Tue, Sep 09 2025 at 14:00, Herve Codina wrote:
>> >> Patch 5 (new in v2)
>> >> - Convert irqchip/ls-extirq to use for_each_of_imap_item
>> >>
>> >> Patch 6 (new in v2)
>> >> - Convert irqchip/renesas-rza1 to use for_each_of_imap_item
>> >
>> > How are those two patches related to adding GPIO support?
>> >
>> > AFAICT, they are completely unrelated and just randomly sprinkled into
>> > this series, but I might be missing something.
>>
>> Ah. I missed that this iterator got introduced in this series. Did you
>> check whether that creates any conflicts against pending irqchip
>> patches?
>>
>
> Indeed, I have a conflict in my patch 6 with 40c26230a1bf ("irqchip: Use int
> type to store negative error codes").
>
> I can rebase my next iteration on top of 40c26230a1bf and mention this commit
> in my next iteration cover letter but an immutable tag and referencing this
> tag in the cover letter should be better.
No. Don't do that.
> What is the best approach?
Just base it on upstream and mentioning the conflict in the cover
letter. For actual merging, if it's ready before the merge window, we
can sort it out by:
1) You putting patch (3-6) in front of the queue
2) Me picking up these 4 patches into a separate branch based on rc1
or later, which gets tagged and is consumable by the GPIO
maintainers.
Then I can merge that branch into irq/drivers and resolve the
conflict, which is trivial enough
Alternatively GPIO folks pick up the whole lot and sort the conflict out
with -next and Linus themself. No real preference from my side.
Thanks,
tglx