Re: [RFC v7 3/6] irqchip: add mpfs gpio interrupt mux

From: Thomas Gleixner <tglx@linutronix.de>
To: Conor Dooley <conor@kernel.org>
Cc: Conor Dooley <conor.dooley@microchip.com>,
	linux-kernel@vger.kernel.org, Marc Zyngier <maz@kernel.org>,
	Daire McNamara <daire.mcnamara@microchip.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	linux-riscv@lists.infradead.org, linux-gpio@vger.kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [RFC v7 3/6] irqchip: add mpfs gpio interrupt mux
Date: Thu, 01 Aug 2024 20:49:08 +0200	[thread overview]
Message-ID: <87r0b82i57.ffs@tglx> (raw)
In-Reply-To: <20240801-palpitate-swinger-7bc8ae8deaaf@spud>

On Thu, Aug 01 2024 at 16:09, Conor Dooley wrote:
> On Mon, Jul 29, 2024 at 12:41:25PM +0200, Thomas Gleixner wrote:
>> > +	/*
>> > +	 * If a bit is set in the mux, GPIO the corresponding interrupt from
>> > +	 * controller 2 is direct and that controllers 0 or 1 is muxed.
>> 
>> This is not a coherent sentence.
>
> It should read "controller 0 or 1;s interrupt is muxed". Does that make
> more sense to you?

No: If a bit is set in the mux, GPIO the corresponding...

I'm already failing at 'GPIO'. My parser expects a verb there :)

>> > +	irq_set_chained_handler_and_data(virq, handle_untracked_irq,
>> 
>> Why does this use handle_untracked_irq()?
>
> I'll have to go and dig back in my notes as to why it is untracked. It
> was probably something like irqd_set() in handle_irq_event() blowing up
> on the irq_data being invalid (which I figure could relate back to my
> questions in the cover letter about issues with irqd_to_hwirq()) - but
> I'll double check what exactly prompted it when I get back from my
> holidays, but...
>
>> This sets up a chained handler
>> but handle_untracked_irq() is a regular interrupt handler.
>
> ...what I was likely using before was handle_simple_irq() which isn't
> chained either. You're expecting to see mpfs_irq_mux_nondirect_handler()
> here I suppose?

Yes or some other proper chained handler.

> Given you've only commented on one significant issue and two minor items,
> is it safe to conclude that the overall approach doesn't have you
> screaming and running for the hills?

I don't love it, but I don't have a better approach to deal with this.

Thanks,

        tglx