Interrupt chip driver maintainence

Interrupt chip driver maintainence

[Thomas Gleixner]

Folks!

I'm wading through my inbox full of patches for interrupt chip drivers
and I'm thoroughly annoyed. The way how this works today is not
sustainable.

Patches end up in my and Radu's inbox and all we can do is go through
them mostly on a formal basis, but it's out of our scope to look at the
correctness vs. a particular hardware. In the past I just picked up
patches when I had the gut feeling they are remotely correct, but I'm
tired of this.

I've just marked about 20 patches and patch series obsolete due to zero
feedback from the relevant architecture/SoC people who were on Cc.

And I'm going to do that from now on very consequently. If the
architecture, SoC experts can't be bothered to look after their stuff,
then don't expect me to suck all of this crap up and then deal with the
complaints when it breaks.

I'm still going to pick up obvious and simple bug fixes, but for
anything which requires deep knowledge on the underlying hardware, I'm
going to just mark them obsolete when they molded in my inbox unreviewed
by the people who understand it for six weeks.

Thanks,

        Thomas

Re: Interrupt chip driver maintainence

[Marc Zyngier]

On Fri, 04 Sep 2026 15:49:44 +0100,
Thomas Gleixner <tglx@kernel.org> wrote:
> 
> Folks!
> 
> I'm wading through my inbox full of patches for interrupt chip drivers
> and I'm thoroughly annoyed. The way how this works today is not
> sustainable.
> 
> Patches end up in my and Radu's inbox and all we can do is go through
> them mostly on a formal basis, but it's out of our scope to look at the
> correctness vs. a particular hardware. In the past I just picked up
> patches when I had the gut feeling they are remotely correct, but I'm
> tired of this.
> 
> I've just marked about 20 patches and patch series obsolete due to zero
> feedback from the relevant architecture/SoC people who were on Cc.
> 
> And I'm going to do that from now on very consequently. If the
> architecture, SoC experts can't be bothered to look after their stuff,
> then don't expect me to suck all of this crap up and then deal with the
> complaints when it breaks.
> 
> I'm still going to pick up obvious and simple bug fixes, but for
> anything which requires deep knowledge on the underlying hardware, I'm
> going to just mark them obsolete when they molded in my inbox unreviewed
> by the people who understand it for six weeks.

Works for me. I didn't expect anything else.

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.

Re: Interrupt chip driver maintainence

[Radu Rendec]

On Fri, 2026-09-04 at 16:49 +0200, Thomas Gleixner wrote:
> I'm wading through my inbox full of patches for interrupt chip drivers
> and I'm thoroughly annoyed. The way how this works today is not
> sustainable.
> 
> Patches end up in my and Radu's inbox and all we can do is go through
> them mostly on a formal basis, but it's out of our scope to look at the
> correctness vs. a particular hardware. In the past I just picked up
> patches when I had the gut feeling they are remotely correct, but I'm
> tired of this.
> 
> I've just marked about 20 patches and patch series obsolete due to zero
> feedback from the relevant architecture/SoC people who were on Cc.
> 
> And I'm going to do that from now on very consequently. If the
> architecture, SoC experts can't be bothered to look after their stuff,
> then don't expect me to suck all of this crap up and then deal with the
> complaints when it breaks.
> 
> I'm still going to pick up obvious and simple bug fixes, but for
> anything which requires deep knowledge on the underlying hardware, I'm
> going to just mark them obsolete when they molded in my inbox unreviewed
> by the people who understand it for six weeks.

I think that's fair!

For what it's worth, as a simple reviewer, I also consciously ignored
multiple patches that required knowledge of the hardware, simply
because I didn't have that knowledge.

-- 
Best regards,
Radu

Re: Interrupt chip driver maintainence

[Nam Cao]

Thomas Gleixner <tglx@kernel.org> writes:
> I'm wading through my inbox full of patches for interrupt chip drivers
> and I'm thoroughly annoyed. The way how this works today is not
> sustainable.
>
> Patches end up in my and Radu's inbox and all we can do is go through
> them mostly on a formal basis, but it's out of our scope to look at the
> correctness vs. a particular hardware. In the past I just picked up
> patches when I had the gut feeling they are remotely correct, but I'm
> tired of this.

I have hardware to test the SiFive PLIC. I also spent quite some time
staring at the specification attempting to cleanse the mess we have for
plic_irq_eoi() (which sadly yielded nothing).

I can help looking at patches. Would that help moving things forward?

Nam

Re: Interrupt chip driver maintainence

[Anup Patel]

On Fri, Sep 4, 2026 at 8:19 PM Thomas Gleixner <tglx@kernel.org> wrote:
>
> Folks!
>
> I'm wading through my inbox full of patches for interrupt chip drivers
> and I'm thoroughly annoyed. The way how this works today is not
> sustainable.
>
> Patches end up in my and Radu's inbox and all we can do is go through
> them mostly on a formal basis, but it's out of our scope to look at the
> correctness vs. a particular hardware. In the past I just picked up
> patches when I had the gut feeling they are remotely correct, but I'm
> tired of this.
>
> I've just marked about 20 patches and patch series obsolete due to zero
> feedback from the relevant architecture/SoC people who were on Cc.
>
> And I'm going to do that from now on very consequently. If the
> architecture, SoC experts can't be bothered to look after their stuff,
> then don't expect me to suck all of this crap up and then deal with the
> complaints when it breaks.
>
> I'm still going to pick up obvious and simple bug fixes, but for
> anything which requires deep knowledge on the underlying hardware, I'm
> going to just mark them obsolete when they molded in my inbox unreviewed
> by the people who understand it for six weeks.
>

I think this is a fair ask.

Currently, I am focused on reviewing and testing anything which
touches RISC-V AIA drivers. The SiFive PLIC driver on other hand
seems to have no active reivewers from RISC-V space. Few years
back I did try to actively review SiFive PLIC driver but these days
I don't have bandwidth for that.

Regards,
Anup