mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Cc: monstr@monstr.eu, jason@lakedaemon.net, marc.zyngier@arm.com,
	linux-kernel@vger.kernel.org, michal.simek@xilinx.com,
	linuxppc-dev@lists.ozlabs.org, mpe@ellerman.id.au
Subject: Re: [Patch V6 2/6] irqchip: xilinx: Clean up irqdomain argument and read/write
Date: Mon, 31 Oct 2016 13:51:59 -0600 (MDT)	[thread overview]
Message-ID: <alpine.DEB.2.20.1610311335380.5011@nanos> (raw)
In-Reply-To: <1477916207-25157-3-git-send-email-Zubair.Kakakhel@imgtec.com>

On Mon, 31 Oct 2016, Zubair Lutfullah Kakakhel wrote:
> The drivers read/write function handling is a bit quirky.

Can you please explain in more detail what's quirky and why it should be
done differently, 

> And the irqmask is passed directly to the handler.

I can't make any sense out of that sentence.  Which handler? If you talk
about the write function, then I don't see a change. So what are you
talking about?

> Add a new irqchip struct to pass to the handler and
> cleanup read/write handling.

I still don't see what it cleans up. You move the write function pointer
into a data structure, which is exposed by another pointer. So you create
two levels of indirection in the hotpath. The function prototype is still
the same. So all this does is making things slower unless I'm missing
something.

> -static unsigned int (*read_fn)(void __iomem *);
> -static void (*write_fn)(u32, void __iomem *);
> +struct xintc_irq_chip {
> +	void __iomem *base;
> +	struct	irq_domain *domain;
> +	struct	irq_chip chip;

The tabs between struct and the structure name are bogus.

> +	u32	intr_mask;
> +	unsigned int (*read)(void __iomem *iomem);
> +	void (*write)(u32 data, void __iomem *iomem);

Please structure that like a table:

	void			__iomem *base;
	struct irq_domain	*domain;
	struct irq_chip		chip;
	u32			intr_mask;
	unsigned int		(*read)(void __iomem *iomem);
	void			(*write)(u32 data, void __iomem *iomem);

Can you see how that makes parsing the struct simpler, because the data
types are clearly to identify?

> +static struct xintc_irq_chip *xintc_irqc;
>  
>  static void intc_write32(u32 val, void __iomem *addr)
>  {
> @@ -54,6 +60,18 @@ static unsigned int intc_read32_be(void __iomem *addr)
>  	return ioread32be(addr);
>  }
>  
> +static inline unsigned int xintc_read(struct xintc_irq_chip *xintc_irqc,
> +					     int reg)
> +{
> +	return xintc_irqc->read(xintc_irqc->base + reg);
> +}
> +
> +static inline void xintc_write(struct xintc_irq_chip *xintc_irqc,
> +				     int reg, u32 data)
> +{
> +	xintc_irqc->write(data, xintc_irqc->base + reg);
> +}
> +
>  static void intc_enable_or_unmask(struct irq_data *d)
>  {
>  	unsigned long mask = 1 << d->hwirq;
> @@ -65,21 +83,21 @@ static void intc_enable_or_unmask(struct irq_data *d)
>  	 * acks the irq before calling the interrupt handler
>  	 */
>  	if (irqd_is_level_type(d))
> -		write_fn(mask, intc_baseaddr + IAR);
> +		xintc_write(xintc_irqc, IAR, mask);

So this whole thing makes only sense, when you want to support multiple
instances of that chip and then you need to store the xintc_irqc pointer as
irqchip data and retrieve it from there. Unless you do that, this "cleanup"
is just churn for nothing with the effect of making things less efficient.

Thanks,

	tglx

  reply	other threads:[~2016-10-31 19:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-31 12:16 [Patch V6 0/6] microblaze/PowerPC: Move irq-xilinx Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 1/6] microblaze: irqchip: Move intc driver to irqchip Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 2/6] irqchip: xilinx: Clean up irqdomain argument and read/write Zubair Lutfullah Kakakhel
2016-10-31 19:51   ` Thomas Gleixner [this message]
2016-11-01 11:05     ` Zubair Lutfullah Kakakhel
2016-11-07  9:53       ` Zubair Lutfullah Kakakhel
2016-11-09 15:53       ` Marc Zyngier
2016-11-15 11:06         ` Michal Simek
2016-10-31 12:16 ` [Patch V6 3/6] irqchip: xilinx: Rename get_irq to xintc_get_irq Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 4/6] irqchip: xilinx: Add support for parent intc Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 5/6] irqchip: xilinx: Try to fall back if xlnx,kind-of-intr not provided Zubair Lutfullah Kakakhel
2016-10-31 12:16 ` [Patch V6 6/6] powerpc/virtex: Use generic xilinx irqchip driver Zubair Lutfullah Kakakhel

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=alpine.DEB.2.20.1610311335380.5011@nanos \
    --to=tglx@linutronix.de \
    --cc=Zubair.Kakakhel@imgtec.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=marc.zyngier@arm.com \
    --cc=michal.simek@xilinx.com \
    --cc=monstr@monstr.eu \
    --cc=mpe@ellerman.id.au \
    /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

all inboxes | Powered by JetHome®