linux-kernel - Re: [PATCH v5 3/4] 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]

Date:	Tue, 10 Mar 2015 17:46:46 -0500
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Ray Jui <rjui@...adcom.com>
Cc:	Arnd Bergmann <arnd@...db.de>, Hauke Mehrtens <hauke@...ke-m.de>,
	Paul Bolle <pebolle@...cali.nl>,
	Florian Fainelli <f.fainelli@...il.com>,
	Dmitry Torokhov <dtor@...gle.com>,
	Anatol Pomazau <anatol@...gle.com>,
	Scott Branden <sbranden@...adcom.com>,
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	bcm-kernel-feedback-list@...adcom.com, devicetree@...r.kernel.org,
	Rob Herring <robh@...nel.org>,
	Yijing Wang <wangyijing@...wei.com>
Subject: Re: [PATCH v5 3/4] pci: iproc: Add Broadcom iProc PCIe support

On Tue, Mar 10, 2015 at 03:22:36PM -0700, Ray Jui wrote:
> Hi Bjorn,
> 
> On 3/10/2015 2:40 PM, Bjorn Helgaas wrote:
> > [+cc Rob, Yijing]
> > 
> > On Mon, Mar 09, 2015 at 05:38:05PM -0700, Ray Jui wrote:
> >> This adds the support for Broadcom iProc PCIe controller
> >>
> >> pcie-iproc.c servers as the common core driver, and front-end bus
> >> interface needs to be added to support different bus interfaces
> >>
> >> pcie-iproc-pltfm.c contains the support for the platform bus interface
> >>
> >> Signed-off-by: Ray Jui <rjui@...adcom.com>
> >> Reviewed-by: Scott Branden <sbraden@...adcom.com>
> >> ---
> >>  drivers/pci/host/Kconfig            |   17 ++
> >>  drivers/pci/host/Makefile           |    2 +
> >>  drivers/pci/host/pcie-iproc-pltfm.c |  108 +++++++++++
> >>  drivers/pci/host/pcie-iproc.c       |  351 +++++++++++++++++++++++++++++++++++
> >>  drivers/pci/host/pcie-iproc.h       |   42 +++++
> >>  5 files changed, 520 insertions(+)
> >>  create mode 100644 drivers/pci/host/pcie-iproc-pltfm.c
> >>  create mode 100644 drivers/pci/host/pcie-iproc.c
> >>  create mode 100644 drivers/pci/host/pcie-iproc.h
> >>
> >> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> >> index 7b892a9..f4d9c90 100644
> >> --- a/drivers/pci/host/Kconfig
> >> +++ b/drivers/pci/host/Kconfig
> >> @@ -106,4 +106,21 @@ config PCI_VERSATILE
> >>  	bool "ARM Versatile PB PCI controller"
> >>  	depends on ARCH_VERSATILE
> >>  
> >> +config PCIE_IPROC
> >> +	tristate "Broadcom iProc PCIe controller"
> >> +	help
> >> +	  This enables the iProc PCIe core controller support for Broadcom's
> >> +	  iProc family of SoCs. An appropriate bus interface driver also needs
> >> +	  to be enabled
> >> +
> >> +config PCIE_IPROC_PLTFM
> >> +	tristate "Broadcom iProc PCIe platform bus driver"
> >> +	depends on ARCH_BCM_IPROC || COMPILE_TEST
> >> +	depends on OF
> >> +	select PCIE_IPROC
> >> +	default ARCH_BCM_IPROC
> >> +	help
> >> +	  Say Y here if you want to use the Broadcom iProc PCIe controller
> >> +	  through the generic platform bus interface
> > 
> > Do you anticipate additional front-end bus interfaces?  If not, and maybe
> > even if you do, you might squash everything into pcie-iproc.c.  Then you
> > only need one file (no .h file needed) and the package is a little
> > simpler.  I think it's pretty common to have multiple driver registration
> > methods in the same file (OF, PCI, ACPI, etc.)  And I think it's common to
> > have those methods guarded by the generic config symbol (CONFIG_PCI,
> > CONFIG_OF, etc.) rather than defining new ones specific to the driver.
> 
> Yes I do expect Hauke (CCed) to add BCMA bus front end support later.
> 
> I still think having the front end bus driver separated is cleaner and
> may be less troublesome for Hauke to add BCMA support in the future. But
> if you strongly favor having everything stuffed in one single file, I
> can make that change. Please let me know.

OK, just leave it as-is.

> >> +#define INVALID_ACCESS_OFFSET 0xffffffff
> >> +static u32 iproc_pcie_cfg_base(struct iproc_pcie *pcie, int busno,
> >> +			       unsigned int devfn, int where)
> >> +{
> >> +	int slot = PCI_SLOT(devfn);
> >> +	int fn = PCI_FUNC(devfn);
> >> +	u32 val;
> >> +
> > 
> > Would you mind adding a comment to the effect that
> > CFG_IND_ADDR_OFFSET/CFG_IND_DATA_OFFSET and
> > CFG_ADDR_OFFSET/CFG_DATA_OFFSET are protected by pci_lock?
> > 
> > They obviously need a mutex, and while I don't have any plans to
> > change it, I'm not completely 100% sure that pci_lock is the best
> > place for it.
> 
> Sorry I don't get what you want me to do here. Do you want me to add
> some comment to explain that the struct pci_ops read/write callbacks are
> already protected at the upper layer by the pci_lock spinlock and
> therefore no lock is required in this driver?

Nothing fancy; something like this that "git grep pci_lock" will find:

  /* addr/data must used atomically and are protected by pci_lock */

Bjorn
--
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/