All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	linux-pci@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
	Lior Amsalem <alior@marvell.com>, Andrew Lunn <andrew@lunn.ch>,
	Jason Cooper <jason@lakedaemon.net>,
	Maen Suleiman <maen@marvell.com>,
	Ezequiel Garcia <ezequiel.garcia@free-electrons.com>,
	Gregory Clement <gregory.clement@free-electrons.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Grant Likely <grant.likely@linaro.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 4/8] irqchip: armada-370-xp: implement MSI support
Date: Tue, 18 Jun 2013 14:11:41 +0200	[thread overview]
Message-ID: <20130618141141.614d08b7@skate> (raw)
In-Reply-To: <20130618112604.GD6322@mithrandir>

Dear Thierry Reding,

On Tue, 18 Jun 2013 13:26:04 +0200, Thierry Reding wrote:

> > As I replied to Grant, of_find_device_by_node() returns NULL, I believe
> > because the all IRQ controller driver initialization is done pretty
> > early, before the of_platform_populate() call is made, so there is no
> > platform_device associated with the IRQ controller node at the time the
> > armada_370_xp_mpic_of_init() function is called.
> > 
> > Do you see another approach, especially in relation to your comment on
> > PATCH 2/8 ?
> 
> Hmmm, that's too bad. The only other possibility that I see is that you
> could associate the struct device at a later point when it becomes
> available, but looking at the irqchip driver it doesn't look like you
> get notification of that either. I suppose you could add a
> platform_driver to it and hook things up in its .probe() callback, but
> I'm not sure if that's in line with how the irqchip was designed. Adding
> Grant Likely and Thomas Gleixner on Cc, maybe they have better advice.

If we do hook the MSI stuff in a ->probe() callback, then we'd have a
dependency between the ->probe() of the PCIe driver and the ->probe()
of the IRQ controller driver. In order for the PCIe ->probe() to
succeed, it needs the MSI controller to be registered, which wouldn't
appear until the ->probe() of the IRQ controller driver gets called. A
typical case of platform device dependency where the two platform
devices don't have a bus -> child dependency. Could be handled by a
-EPROBE_DEFER trick, though.

> Looking at other irqchip drivers I find it a bit odd to see how they're
> structured, though. We've been preaching for years that drivers should
> be well-encapsulated and told everybody it was bad to use globals and
> they should be associating driver-specific data with each instance of a
> device. Then comes along irqchip and all of a sudden it's okay to use
> globals again. It feels a bit fragile.

Yes, I've seen this as well, and I'm thinking of doing some
improvements in this area if there's some interest. But I believe this
is fairly separate from the specific discussion of this patch set.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

WARNING: multiple messages have this Message-ID (diff)
From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 4/8] irqchip: armada-370-xp: implement MSI support
Date: Tue, 18 Jun 2013 14:11:41 +0200	[thread overview]
Message-ID: <20130618141141.614d08b7@skate> (raw)
In-Reply-To: <20130618112604.GD6322@mithrandir>

Dear Thierry Reding,

On Tue, 18 Jun 2013 13:26:04 +0200, Thierry Reding wrote:

> > As I replied to Grant, of_find_device_by_node() returns NULL, I believe
> > because the all IRQ controller driver initialization is done pretty
> > early, before the of_platform_populate() call is made, so there is no
> > platform_device associated with the IRQ controller node at the time the
> > armada_370_xp_mpic_of_init() function is called.
> > 
> > Do you see another approach, especially in relation to your comment on
> > PATCH 2/8 ?
> 
> Hmmm, that's too bad. The only other possibility that I see is that you
> could associate the struct device at a later point when it becomes
> available, but looking at the irqchip driver it doesn't look like you
> get notification of that either. I suppose you could add a
> platform_driver to it and hook things up in its .probe() callback, but
> I'm not sure if that's in line with how the irqchip was designed. Adding
> Grant Likely and Thomas Gleixner on Cc, maybe they have better advice.

If we do hook the MSI stuff in a ->probe() callback, then we'd have a
dependency between the ->probe() of the PCIe driver and the ->probe()
of the IRQ controller driver. In order for the PCIe ->probe() to
succeed, it needs the MSI controller to be registered, which wouldn't
appear until the ->probe() of the IRQ controller driver gets called. A
typical case of platform device dependency where the two platform
devices don't have a bus -> child dependency. Could be handled by a
-EPROBE_DEFER trick, though.

> Looking at other irqchip drivers I find it a bit odd to see how they're
> structured, though. We've been preaching for years that drivers should
> be well-encapsulated and told everybody it was bad to use globals and
> they should be associating driver-specific data with each instance of a
> device. Then comes along irqchip and all of a sudden it's okay to use
> globals again. It feels a bit fragile.

Yes, I've seen this as well, and I'm thinking of doing some
improvements in this area if there's some interest. But I believe this
is fairly separate from the specific discussion of this patch set.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

  reply	other threads:[~2013-06-18 12:11 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-06 16:41 [PATCH v2 0/8] MSI support for Marvell EBU PCIe driver Thomas Petazzoni
2013-06-06 16:41 ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 1/8] PCI: Introduce new MSI chip infrastructure Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-18 22:46   ` Bjorn Helgaas
2013-06-18 22:46     ` Bjorn Helgaas
2013-06-19 11:42     ` Thomas Petazzoni
2013-06-19 11:42       ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 2/8] PCI: Add registry of MSI chips Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-12 10:33   ` Thierry Reding
2013-06-12 10:33     ` Thierry Reding
2013-06-18 22:48   ` Bjorn Helgaas
2013-06-18 22:48     ` Bjorn Helgaas
2013-06-19 11:42     ` Thomas Petazzoni
2013-06-19 11:42       ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 3/8] irqchip: armada-370-xp: properly request resources Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 4/8] irqchip: armada-370-xp: implement MSI support Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-11 13:37   ` Grant Likely
2013-06-11 13:37     ` Grant Likely
2013-06-18  8:42     ` Thomas Petazzoni
2013-06-18  8:42       ` Thomas Petazzoni
2013-06-18 10:15       ` Grant Likely
2013-06-18 10:15         ` Grant Likely
2013-06-18 10:36         ` Thomas Petazzoni
2013-06-18 10:36           ` Thomas Petazzoni
2013-06-12 10:42   ` Thierry Reding
2013-06-12 10:42     ` Thierry Reding
2013-06-18  8:43     ` Thomas Petazzoni
2013-06-18  8:43       ` Thomas Petazzoni
2013-06-18 11:26       ` Thierry Reding
2013-06-18 11:26         ` Thierry Reding
2013-06-18 12:11         ` Thomas Petazzoni [this message]
2013-06-18 12:11           ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 5/8] arm: mvebu: the MPIC now provides MSI controller features Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 6/8] pci: mvebu: add support for MSI Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-18 22:57   ` Bjorn Helgaas
2013-06-18 22:57     ` Bjorn Helgaas
2013-06-06 16:41 ` [PATCH v2 7/8] arm: mvebu: indicate that this platform supports MSI Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-06 16:41 ` [PATCH v2 8/8] arm: mvebu: link PCIe controllers to the MSI controller Thomas Petazzoni
2013-06-06 16:41   ` Thomas Petazzoni
2013-06-06 17:17 ` [PATCH v2 0/8] MSI support for Marvell EBU PCIe driver Jason Cooper
2013-06-06 17:17   ` Jason Cooper
2013-06-07  8:14   ` Thomas Petazzoni
2013-06-07  8:14     ` Thomas Petazzoni
2013-06-07 14:47     ` Jason Cooper
2013-06-07 14:47       ` Jason Cooper
2013-06-06 18:51 ` Jason Cooper
2013-06-06 18:51   ` Jason Cooper
2013-06-07  8:23   ` Thomas Petazzoni
2013-06-07  8:23     ` Thomas Petazzoni
2013-06-07 15:08     ` Jason Cooper
2013-06-07 15:08       ` Jason Cooper
2013-06-07 17:00       ` Thomas Petazzoni
2013-06-07 17:00         ` Thomas Petazzoni
2013-06-18  8:56 ` Thomas Petazzoni
2013-06-18  8:56   ` 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=20130618141141.614d08b7@skate \
    --to=thomas.petazzoni@free-electrons.com \
    --cc=alior@marvell.com \
    --cc=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=ezequiel.garcia@free-electrons.com \
    --cc=grant.likely@linaro.org \
    --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=maen@marvell.com \
    --cc=tglx@linutronix.de \
    --cc=thierry.reding@gmail.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.