All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Russell King <linux@arm.linux.org.uk>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	devicetree-discuss@lists.ozlabs.org,
	Lior Amsalem <alior@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
	Jason Cooper <jason@lakedaemon.net>,
	Maen Suleiman <maen@marvell.com>,
	Thierry Reding <thierry.reding@avionic-design.de>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Olof Johansson <olof@lixom.net>,
	Tawfik Bayouk <tawfik@marvell.com>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Mitch Bradley <wmb@firmworks.com>,
	Andrew Murray <andrew.murray@arm.com>
Subject: Re: [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver
Date: Tue, 26 Mar 2013 21:53:53 +0000	[thread overview]
Message-ID: <201303262153.53698.arnd@arndb.de> (raw)
In-Reply-To: <20130326223748.242f0046@skate>

On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> On Tue, 26 Mar 2013 21:10:15 +0000, Arnd Bergmann wrote:
> 
> > > To which children? Only to the main-intc children? If so,
> > > armada_370_xp_mpic_of_init() would be called with a 'device_node *'
> > > that points to the main-intc, correct? Then it would have to go back up
> > > in the Device Tree to find the msi node? It's doable of course, but
> > > sounds strange, no?
> > 
> > I was thinking of registering two init functions as well.
> 
> But then which of the two init functions would do the of_iomap() (or
> whatever ioremap()ing function you use) ?

I agree this is where it get a little fishy, hence my preference to
use a single node.

> Remember, the very reason what we have one driver for both interrupt
> controllers is because the registers are completely mixed. So to me
> it's really the case of one device providing two features, like a
> device that would be both an Ethernet interface and a SPI controller.
> You have a single ->probe() function that gets called when the device
> is detected, and this ->probe() function registers both an Ethernet
> interface and a SPI controller.b
> 
> To me, the case we have here is really identical: we have one single set
> of registers that provide multiple features.

The problem here is that the irq subsystem makes certain assumptions
about one device node being the controller and mapping to a single
irq domain, so you'd have to cheat one way or another. Using the
sub-nodes the way you do in your patch is bending the rules for
the device tree binding, which I think is more problematic than
bending the rules for the code. Regarding the call to of_iomap(),
you could work around it by having a static variable in the driver
that remembers the mmio address and gets set by whichever device node
init function gets called first.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver
Date: Tue, 26 Mar 2013 21:53:53 +0000	[thread overview]
Message-ID: <201303262153.53698.arnd@arndb.de> (raw)
In-Reply-To: <20130326223748.242f0046@skate>

On Tuesday 26 March 2013, Thomas Petazzoni wrote:
> On Tue, 26 Mar 2013 21:10:15 +0000, Arnd Bergmann wrote:
> 
> > > To which children? Only to the main-intc children? If so,
> > > armada_370_xp_mpic_of_init() would be called with a 'device_node *'
> > > that points to the main-intc, correct? Then it would have to go back up
> > > in the Device Tree to find the msi node? It's doable of course, but
> > > sounds strange, no?
> > 
> > I was thinking of registering two init functions as well.
> 
> But then which of the two init functions would do the of_iomap() (or
> whatever ioremap()ing function you use) ?

I agree this is where it get a little fishy, hence my preference to
use a single node.

> Remember, the very reason what we have one driver for both interrupt
> controllers is because the registers are completely mixed. So to me
> it's really the case of one device providing two features, like a
> device that would be both an Ethernet interface and a SPI controller.
> You have a single ->probe() function that gets called when the device
> is detected, and this ->probe() function registers both an Ethernet
> interface and a SPI controller.b
> 
> To me, the case we have here is really identical: we have one single set
> of registers that provide multiple features.

The problem here is that the irq subsystem makes certain assumptions
about one device node being the controller and mapping to a single
irq domain, so you'd have to cheat one way or another. Using the
sub-nodes the way you do in your patch is bending the rules for
the device tree binding, which I think is more problematic than
bending the rules for the code. Regarding the call to of_iomap(),
you could work around it by having a static variable in the driver
that remembers the mmio address and gets set by whichever device node
init function gets called first.

	Arnd

  reply	other threads:[~2013-03-26 21:54 UTC|newest]

Thread overview: 100+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-26 16:52 [RFCv1 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-03-26 16:52 ` Thomas Petazzoni
2013-03-26 16:52 ` Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 01/11] arm: mvebu: move L2 cache initialization in init_early() Thomas Petazzoni
2013-03-26 16:53   ` Arnd Bergmann
2013-03-26 16:53     ` Arnd Bergmann
2013-03-26 16:53     ` Arnd Bergmann
2013-03-26 17:02     ` Thomas Petazzoni
2013-03-26 17:02       ` Thomas Petazzoni
2013-03-26 17:02       ` Thomas Petazzoni
2013-03-27  1:53   ` Rob Herring
2013-03-27  1:53     ` Rob Herring
2013-03-26 16:52 ` [RFCv1 02/11] irqchip: move IRQ driver for Armada 370/XP Thomas Petazzoni
2013-03-26 16:52   ` Thomas Petazzoni
2013-03-26 16:54   ` Arnd Bergmann
2013-03-26 16:54     ` Arnd Bergmann
2013-03-26 16:54     ` Arnd Bergmann
2013-03-26 16:52 ` [RFCv1 03/11] irqchip: armada-370-xp: move IRQ handler to avoid forward declaration Thomas Petazzoni
2013-03-26 16:52   ` Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 04/11] irqchip: armada-370-xp: slightly cleanup irq controller driver Thomas Petazzoni
2013-03-26 16:52   ` Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 05/11] arm: mvebu: do not duplicate the mpic alias Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 06/11] irqchip: armada-370-xp: use a separate mpic node Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver Thomas Petazzoni
2013-03-26 17:07   ` Arnd Bergmann
2013-03-26 17:07     ` Arnd Bergmann
2013-03-26 17:17     ` Thomas Petazzoni
2013-03-26 17:17       ` Thomas Petazzoni
2013-03-26 18:38       ` Arnd Bergmann
2013-03-26 18:38         ` Arnd Bergmann
2013-03-26 18:38         ` Arnd Bergmann
2013-03-26 20:46         ` Thomas Petazzoni
2013-03-26 20:46           ` Thomas Petazzoni
2013-03-26 21:10           ` Arnd Bergmann
2013-03-26 21:10             ` Arnd Bergmann
2013-03-26 21:10             ` Arnd Bergmann
2013-03-26 21:37             ` Thomas Petazzoni
2013-03-26 21:37               ` Thomas Petazzoni
2013-03-26 21:53               ` Arnd Bergmann [this message]
2013-03-26 21:53                 ` Arnd Bergmann
2013-03-26 21:14           ` Jason Gunthorpe
2013-03-26 21:14             ` Jason Gunthorpe
2013-03-26 21:41             ` Thomas Petazzoni
2013-03-26 21:41               ` Thomas Petazzoni
2013-03-26 18:02   ` Jason Gunthorpe
2013-03-26 18:02     ` Jason Gunthorpe
2013-03-26 21:16     ` Thomas Petazzoni
2013-03-26 21:16       ` Thomas Petazzoni
2013-03-26 21:31       ` Arnd Bergmann
2013-03-26 21:31         ` Arnd Bergmann
2013-03-26 21:47         ` Thomas Petazzoni
2013-03-26 21:47           ` Thomas Petazzoni
2013-03-26 21:55       ` Jason Gunthorpe
2013-03-26 21:55         ` Jason Gunthorpe
2013-03-26 22:04         ` Arnd Bergmann
2013-03-26 22:04           ` Arnd Bergmann
2013-03-26 22:06         ` Thomas Petazzoni
2013-03-26 22:06           ` Thomas Petazzoni
2013-03-26 22:26           ` Jason Gunthorpe
2013-03-26 22:26             ` Jason Gunthorpe
2013-03-26 21:15   ` Arnd Bergmann
2013-03-26 21:15     ` Arnd Bergmann
2013-03-26 21:42     ` Thomas Petazzoni
2013-03-26 21:42       ` Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure Thomas Petazzoni
2013-04-08 22:28   ` Bjorn Helgaas
2013-04-08 22:28     ` Bjorn Helgaas
2013-04-09  8:11     ` Andrew Murray
2013-04-09  8:11       ` Andrew Murray
2013-04-09  8:11       ` Andrew Murray
2013-04-09  8:22       ` Thierry Reding
2013-04-09  8:22         ` Thierry Reding
2013-04-09  8:22         ` Thierry Reding
2013-04-09  8:25         ` Andrew Murray
2013-04-09  8:25           ` Andrew Murray
2013-04-09  8:25           ` Andrew Murray
2013-04-09  8:18     ` Thierry Reding
2013-04-09  8:18       ` Thierry Reding
2013-03-26 16:52 ` [RFCv1 09/11] pci: mvebu: add MSI support Thomas Petazzoni
2013-03-27 10:07   ` Andrew Murray
2013-03-27 10:07     ` Andrew Murray
2013-03-27 10:07     ` Andrew Murray
2013-04-08 22:29   ` Bjorn Helgaas
2013-04-08 22:29     ` Bjorn Helgaas
2013-05-30 12:15     ` Thierry Reding
2013-05-30 12:15       ` Thierry Reding
2013-05-30 18:13       ` Bjorn Helgaas
2013-05-30 18:13         ` Bjorn Helgaas
2013-03-26 16:52 ` [RFCv1 10/11] arm: mvebu: enable MSI support in DT Thomas Petazzoni
2013-03-26 16:52 ` [RFCv1 11/11] arm: mvebu: enable PCI MSI support in defconfig Thomas Petazzoni
2013-03-26 17:05 ` [RFCv1 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-03-26 17:05   ` Thomas Petazzoni
2013-03-26 17:18   ` Arnd Bergmann
2013-03-26 17:18     ` Arnd Bergmann
2013-03-26 17:21     ` Thomas Petazzoni
2013-03-26 17:21       ` Thomas Petazzoni
2013-04-04  9:16 ` Ezequiel Garcia
2013-04-04  9:16   ` Ezequiel Garcia
2013-04-04  9:29   ` Thomas Petazzoni
2013-04-04  9:29     ` Thomas Petazzoni

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=201303262153.53698.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=alior@marvell.com \
    --cc=andrew.murray@arm.com \
    --cc=andrew@lunn.ch \
    --cc=bhelgaas@google.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregory.clement@free-electrons.com \
    --cc=jason@lakedaemon.net \
    --cc=jgunthorpe@obsidianresearch.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=maen@marvell.com \
    --cc=olof@lixom.net \
    --cc=tawfik@marvell.com \
    --cc=thierry.reding@avionic-design.de \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=wmb@firmworks.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.