linux-kernel - Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2314573.X8TfIpVCUq@wuerfel>
Date:	Mon, 09 Mar 2015 13:35:24 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Ray Jui <rjui@...adcom.com>
Cc:	Dmitry Torokhov <dtor@...gle.com>, Paul Bolle <pebolle@...cali.nl>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	Florian Fainelli <f.fainelli@...il.com>,
	Anatol Pomazau <anatol@...gle.com>,
	Scott Branden <sbranden@...adcom.com>,
	linux-pci@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arm-kernel@...ts.infradead.org,
	bcm-kernel-feedback-list@...adcom.com, devicetree@...r.kernel.org
Subject: Re: [PATCH v3 2/3] pci: iproc: Add Broadcom iProc PCIe support

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/