public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Conor Dooley <conor@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
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, 1 Aug 2024 16:09:49 +0100	[thread overview]
Message-ID: <20240801-palpitate-swinger-7bc8ae8deaaf@spud> (raw)
In-Reply-To: <87le1k8oq2.ffs@tglx>

[-- Attachment #1: Type: text/plain, Size: 3454 bytes --]

On Mon, Jul 29, 2024 at 12:41:25PM +0200, Thomas Gleixner wrote:
> On Tue, Jul 23 2024 at 12:27, Conor Dooley wrote:
> > +
> > +struct mpfs_irq_mux_bank_config {
> > +	u32 mask;
> > +	u8 shift;
> > +};
> 
> Please see:
> 
>   https://www.kernel.org/doc/html/latest/process/maintainer-tip.html
> 
> vs. coding style.
> 
> > +/*
> > + * Returns an unsigned long, where a set bit indicates the corresponding
> > + * interrupt is in non-direct/muxed mode for that bank/GPIO controller.
> > + */
> > +static inline unsigned long mpfs_irq_mux_get_muxed_irqs(struct mpfs_irq_mux *priv,
> > +							unsigned int bank)
> > +{
> > +	unsigned long mux_config = priv->mux_config, muxed_irqs = -1;
> > +	struct mpfs_irq_mux_bank_config bank_config = mpfs_irq_mux_bank_configs[bank];
> > +
> > +	/*
> > +	 * 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?

> > +	 * Invert the bits in the configuration register, so that set bits
> > +	 * equate to non-direct mode, for GPIO controller 2.
> > +	 */
> > +	if (bank == 2u)
> > +		mux_config = ~mux_config;
> > +
> 
> > +static int mpfs_irq_mux_nondirect_alloc(struct irq_domain *d, unsigned int virq,
> > +					struct irq_fwspec *fwspec, struct mpfs_irq_mux *priv)
> > +{
> > +	unsigned int bank = fwspec->param[0] / MPFS_MAX_IRQS_PER_GPIO;
> > +
> > +	if (bank > 2)
> > +		return -EINVAL;
> > +
> > +	priv->nondirect_irqchips[bank].domain = d;
> > +
> > +	irq_domain_set_hwirq_and_chip(d, virq, fwspec->param[0],
> > +				      &mpfs_irq_mux_nondirect_irq_chip, priv);
> > +	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?

>+static void mpfs_irq_mux_nondirect_handler(struct irq_desc *desc)
>+{
>+	struct mpfs_irq_mux_irqchip *irqchip_data = irq_desc_get_handler_data(desc);
>+	struct mpfs_irq_mux *priv = container_of(irqchip_data, struct mpfs_irq_mux,
>+						 nondirect_irqchips[irqchip_data->bank]);
>+	unsigned long muxed_irqs;
>+	int pos;
>+
>+	chained_irq_enter(irq_desc_get_chip(desc), desc);
>+
>+	muxed_irqs = mpfs_irq_mux_get_muxed_irqs(priv, irqchip_data->bank);
>+
>+	for_each_set_bit(pos, &muxed_irqs, MPFS_MAX_IRQS_PER_GPIO)
>+		generic_handle_domain_irq(irqchip_data->domain, irqchip_data->offset + pos);
>+
>+	chained_irq_exit(irq_desc_get_chip(desc), desc);
>+}

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?

Cheers,
Conor.

> > +					 &priv->nondirect_irqchips[bank]);

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

  reply	other threads:[~2024-08-01 15:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 11:27 [RFC v7 0/6] PolarFire SoC GPIO support Conor Dooley
2024-07-23 11:27 ` [RFC v7 1/6] dt-bindings: gpio: fix microchip,mpfs-gpio interrupt descriptions Conor Dooley
2024-07-24 13:25   ` Krzysztof Kozlowski
2024-07-24 14:29     ` Conor Dooley
2024-07-23 11:27 ` [RFC v7 2/6] dt-bindings: interrupt-controller: document PolarFire SoC's gpio interrupt mux Conor Dooley
2024-07-24 13:27   ` Krzysztof Kozlowski
2024-07-24 14:21     ` Conor Dooley
2024-07-23 11:27 ` [RFC v7 3/6] irqchip: add mpfs " Conor Dooley
2024-07-29 10:41   ` Thomas Gleixner
2024-08-01 15:09     ` Conor Dooley [this message]
2024-08-01 18:49       ` Thomas Gleixner
2024-08-02  8:08         ` Conor Dooley
2024-08-02 10:40           ` Thomas Gleixner
2024-07-23 11:27 ` [RFC v7 4/6] gpio: mpfs: add polarfire soc gpio support Conor Dooley
2024-08-05  8:00   ` Linus Walleij
2024-08-05  8:04   ` Linus Walleij
2024-08-06 17:18     ` Conor Dooley
2024-08-07 16:55       ` Linus Walleij
2024-08-07 17:22         ` Conor Dooley
2024-10-16  9:56     ` Conor Dooley
2024-10-16 10:29       ` Conor Dooley
2024-10-16 19:26         ` Linus Walleij
2024-10-16 19:42           ` Conor Dooley
2024-10-22 16:28             ` Conor Dooley
2024-10-23  9:58               ` Linus Walleij
2024-10-16 19:25       ` Linus Walleij
2024-07-23 11:27 ` [RFC v7 5/6] gpio: mpfs: pass gpio line number as irq data Conor Dooley
2024-08-05  8:11   ` Linus Walleij
2024-08-06 17:24     ` Conor Dooley
2024-07-23 11:27 ` [RFC v7 6/6] riscv: dts: microchip: update gpio interrupts to better match the SoC Conor Dooley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240801-palpitate-swinger-7bc8ae8deaaf@spud \
    --to=conor@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=conor.dooley@microchip.com \
    --cc=daire.mcnamara@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=maz@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=robh@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox