lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87cy7xrt9m.ffs@tglx>
Date: Thu, 11 Sep 2025 15:52:21 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Herve Codina <herve.codina@...tlin.com>
Cc: Wolfram Sang <wsa+renesas@...g-engineering.com>, Hoan Tran
 <hoan@...amperecomputing.com>, Linus Walleij <linus.walleij@...aro.org>,
 Bartosz Golaszewski <brgl@...ev.pl>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Geert Uytterhoeven <geert+renesas@...der.be>,
 Magnus
 Damm <magnus.damm@...il.com>, Saravana Kannan <saravanak@...gle.com>, Serge
 Semin <fancer.lancer@...il.com>, Phil Edworthy <phil.edworthy@...esas.com>,
 linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-renesas-soc@...r.kernel.org, Pascal
 Eberhard <pascal.eberhard@...com>, Miquel Raynal
 <miquel.raynal@...tlin.com>, Thomas Petazzoni
 <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH v2 0/8] gpio: renesas: Add support for GPIO and related
 interrupts in RZ/N1 SoC

On Thu, Sep 11 2025 at 09:04, Herve Codina wrote:
> On Tue, 09 Sep 2025 22:54:41 +0200
> Thomas Gleixner <tglx@...utronix.de> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ