public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
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:53 UTC|newest]

Thread overview: 38+ 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
     [not found] ` <1364316746-8702-2-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-26 16:53   ` [RFCv1 01/11] arm: mvebu: move L2 cache initialization in init_early() Arnd Bergmann
2013-03-26 17:02     ` Thomas Petazzoni
2013-03-27  1:53   ` Rob Herring
     [not found] ` <1364316746-8702-3-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-26 16:54   ` [RFCv1 02/11] irqchip: move IRQ driver for Armada 370/XP Arnd Bergmann
2013-03-26 17:05 ` [RFCv1 00/11] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-03-26 17:18   ` Arnd Bergmann
2013-03-26 17:21     ` Thomas Petazzoni
     [not found] ` <1364316746-8702-8-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-26 17:07   ` [RFCv1 07/11] irqchip: armada-370-xp: add MSI support to interrupt controller driver Arnd Bergmann
2013-03-26 17:17     ` Thomas Petazzoni
2013-03-26 18:38       ` Arnd Bergmann
2013-03-26 20:46         ` Thomas Petazzoni
2013-03-26 21:10           ` Arnd Bergmann
2013-03-26 21:37             ` Thomas Petazzoni
2013-03-26 21:53               ` Arnd Bergmann [this message]
2013-03-26 21:14           ` Jason Gunthorpe
2013-03-26 21:41             ` Thomas Petazzoni
2013-03-26 18:02   ` Jason Gunthorpe
2013-03-26 21:16     ` Thomas Petazzoni
2013-03-26 21:31       ` Arnd Bergmann
2013-03-26 21:47         ` Thomas Petazzoni
2013-03-26 21:55       ` Jason Gunthorpe
2013-03-26 22:04         ` Arnd Bergmann
2013-03-26 22:06         ` Thomas Petazzoni
2013-03-26 22:26           ` Jason Gunthorpe
2013-03-26 21:15   ` Arnd Bergmann
2013-03-26 21:42     ` Thomas Petazzoni
2013-04-04  9:16 ` [RFCv1 00/11] MSI support for Marvell EBU PCIe driver Ezequiel Garcia
2013-04-04  9:29   ` Thomas Petazzoni
     [not found] ` <1364316746-8702-9-git-send-email-thomas.petazzoni@free-electrons.com>
2013-04-08 22:28   ` [RFCv1 08/11] PCI: Introduce new MSI chip infrastructure Bjorn Helgaas
2013-04-09  8:11     ` Andrew Murray
2013-04-09  8:22       ` Thierry Reding
2013-04-09  8:25         ` Andrew Murray
2013-04-09  8:18     ` Thierry Reding
     [not found] ` <1364316746-8702-10-git-send-email-thomas.petazzoni@free-electrons.com>
2013-03-27 10:07   ` [RFCv1 09/11] pci: mvebu: add MSI support Andrew Murray
2013-04-08 22:29   ` Bjorn Helgaas
2013-05-30 12:15     ` Thierry Reding
2013-05-30 18:13       ` Bjorn Helgaas

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$(echo .)de \
    --cc=linux-arm-kernel@lists$(echo .)infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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