All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Ray Jui <rjui@broadcom.com>
Cc: Dmitry Torokhov <dtor@google.com>,
	Paul Bolle <pebolle@tiscali.nl>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Anatol Pomazau <anatol@google.com>,
	Scott Branden <sbranden@broadcom.com>,
	linux-pci@vger.kernel.org,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	bcm-kernel-feedback-list@broadcom.com,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Date: Mon, 09 Mar 2015 13:35:24 +0100	[thread overview]
Message-ID: <2314573.X8TfIpVCUq@wuerfel> (raw)
In-Reply-To: <54F9EB42.3010804@broadcom.com>

On Friday 06 March 2015 10:00:34 Ray Jui wrote:
> > 
> 
> Although I have not tested it, but to my best knowledge there shouldn't
> be any technical issue by making the PCIe iProc driver a loadable module
> and installing the module later after the kernel finishes booting.
> 
> But I wonder why I haven't seen any PCIe host driver being allowed to be
> compiled as module? Maybe there's no obvious benefit of doing that.
> People typically opt to load slave devices as module but tend to keep
> the bus or host devices compiled in.
> 
> And to allow a PCI host driver to be compiled as module, some PCI
> functions need to have their symbols exported:
> 
> ERROR: "pci_common_swizzle" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_fixup_irqs" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_assign_unassigned_bus_resources"
> [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_remove_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_stop_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_create_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> 
> Maybe Bjorn can help to shed some light here? Should I go ahead and
> export_symbol these PCI functions and make the iProc PCI driver "tristate"?

My best guess is that no loadable driver ever tried to use these and
we should indeed just export them.

The call to pci_assign_unassigned_bus_resources could be avoided by using
pci_rescan_bus(), which would simplify the driver a little, but for
some reason, nothing else uses that, so I'm not sure about it.

The pci_remove_root_bus/pci_stop_root_bus calls are rarely used anywhere
else. Are they functional to the point where you could unload a pci
host driver that is a loadable module? If so, that would be
wonderful.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
To: Ray Jui <rjui-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
Cc: Dmitry Torokhov <dtor-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Paul Bolle <pebolle-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>,
	Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Hauke Mehrtens <hauke-5/S+JYg5SzeELgA04lAiVw@public.gmane.org>,
	Florian Fainelli
	<f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Anatol Pomazau <anatol-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Scott Branden <sbranden-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
	linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
	bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Date: Mon, 09 Mar 2015 13:35:24 +0100	[thread overview]
Message-ID: <2314573.X8TfIpVCUq@wuerfel> (raw)
In-Reply-To: <54F9EB42.3010804-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>

On Friday 06 March 2015 10:00:34 Ray Jui wrote:
> > 
> 
> Although I have not tested it, but to my best knowledge there shouldn't
> be any technical issue by making the PCIe iProc driver a loadable module
> and installing the module later after the kernel finishes booting.
> 
> But I wonder why I haven't seen any PCIe host driver being allowed to be
> compiled as module? Maybe there's no obvious benefit of doing that.
> People typically opt to load slave devices as module but tend to keep
> the bus or host devices compiled in.
> 
> And to allow a PCI host driver to be compiled as module, some PCI
> functions need to have their symbols exported:
> 
> ERROR: "pci_common_swizzle" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_fixup_irqs" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_assign_unassigned_bus_resources"
> [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_remove_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_stop_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_create_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> 
> Maybe Bjorn can help to shed some light here? Should I go ahead and
> export_symbol these PCI functions and make the iProc PCI driver "tristate"?

My best guess is that no loadable driver ever tried to use these and
we should indeed just export them.

The call to pci_assign_unassigned_bus_resources could be avoided by using
pci_rescan_bus(), which would simplify the driver a little, but for
some reason, nothing else uses that, so I'm not sure about it.

The pci_remove_root_bus/pci_stop_root_bus calls are rarely used anywhere
else. Are they functional to the point where you could unload a pci
host driver that is a loadable module? If so, that would be
wonderful.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support
Date: Mon, 09 Mar 2015 13:35:24 +0100	[thread overview]
Message-ID: <2314573.X8TfIpVCUq@wuerfel> (raw)
In-Reply-To: <54F9EB42.3010804@broadcom.com>

On Friday 06 March 2015 10:00:34 Ray Jui wrote:
> > 
> 
> Although I have not tested it, but to my best knowledge there shouldn't
> be any technical issue by making the PCIe iProc driver a loadable module
> and installing the module later after the kernel finishes booting.
> 
> But I wonder why I haven't seen any PCIe host driver being allowed to be
> compiled as module? Maybe there's no obvious benefit of doing that.
> People typically opt to load slave devices as module but tend to keep
> the bus or host devices compiled in.
> 
> And to allow a PCI host driver to be compiled as module, some PCI
> functions need to have their symbols exported:
> 
> ERROR: "pci_common_swizzle" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_fixup_irqs" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_assign_unassigned_bus_resources"
> [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_remove_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_stop_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "pci_create_root_bus" [drivers/pci/host/pcie-iproc.ko] undefined!
> 
> Maybe Bjorn can help to shed some light here? Should I go ahead and
> export_symbol these PCI functions and make the iProc PCI driver "tristate"?

My best guess is that no loadable driver ever tried to use these and
we should indeed just export them.

The call to pci_assign_unassigned_bus_resources could be avoided by using
pci_rescan_bus(), which would simplify the driver a little, but for
some reason, nothing else uses that, so I'm not sure about it.

The pci_remove_root_bus/pci_stop_root_bus calls are rarely used anywhere
else. Are they functional to the point where you could unload a pci
host driver that is a loadable module? If so, that would be
wonderful.

	Arnd

  reply	other threads:[~2015-03-09 12:35 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-06  1:01 [PATCH v3 0/3] pci: iproc: Add Broadcom iProc PCIe support Ray Jui
2015-03-06  1:01 ` Ray Jui
2015-03-06  1:01 ` Ray Jui
2015-03-06  1:01 ` [PATCH v3 1/3] pci: iProc: define iProc PCIe platform bus binding Ray Jui
2015-03-06  1:01   ` Ray Jui
2015-03-06  1:01   ` Ray Jui
2015-03-06  1:01 ` [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support Ray Jui
2015-03-06  1:01   ` Ray Jui
2015-03-06  1:01   ` Ray Jui
2015-03-06 11:00   ` Paul Bolle
2015-03-06 11:00     ` Paul Bolle
2015-03-06 11:00     ` Paul Bolle
2015-03-06 17:26     ` Ray Jui
2015-03-06 17:26       ` Ray Jui
2015-03-06 17:26       ` Ray Jui
2015-03-06 17:35       ` Dmitry Torokhov
2015-03-06 17:35         ` Dmitry Torokhov
2015-03-06 18:00         ` Ray Jui
2015-03-06 18:00           ` Ray Jui
2015-03-06 18:00           ` Ray Jui
2015-03-09 12:35           ` Arnd Bergmann [this message]
2015-03-09 12:35             ` Arnd Bergmann
2015-03-09 12:35             ` Arnd Bergmann
2015-03-09 23:45             ` Ray Jui
2015-03-09 23:45               ` Ray Jui
2015-03-09 23:45               ` Ray Jui
2015-03-06  1:01 ` [PATCH v3 3/3] ARM: dts: enable PCIe support for Cygnus Ray Jui
2015-03-06  1:01   ` Ray Jui
2015-03-06  1:01   ` Ray Jui

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=2314573.X8TfIpVCUq@wuerfel \
    --to=arnd@arndb.de \
    --cc=anatol@google.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dtor@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=hauke@hauke-m.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=pebolle@tiscali.nl \
    --cc=rjui@broadcom.com \
    --cc=sbranden@broadcom.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.