linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Krzysztof Wilczyński" <kw@linux.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Rob Herring <robh@kernel.org>,
	Jonathan Cameron <Jonathan.Cameron@huawei.com>,
	Jonathan Chocron <jonnyc@amazon.com>,
	Shawn Lin <shawn.lin@rock-chips.com>,
	Heiko Stuebner <heiko@sntech.de>,
	Zhou Wang <wangzhou1@hisilicon.com>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Will Deacon <will@kernel.org>,
	Robert Richter <rrichter@marvell.com>,
	Michal Simek <michal.simek@xilinx.com>,
	Toan Le <toan@os.amperecomputing.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
	Nicolas Saenz Julienne <nsaenzjulienne@suse.de>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Ray Jui <rjui@broadcom.com>,
	Scott Branden <sbranden@broadcom.com>,
	Jonathan Derrick <jonathan.derrick@intel.com>,
	David Laight <david.laight@aculab.com>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linuxppc-dev@lists.ozlabs.org,
	linux-rockchip@lists.infradead.org,
	linux-rpi-kernel@lists.infradead.org,
	bcm-kernel-feedback-list@broadcom.com
Subject: Re: [PATCH v5] PCI: Unify ECAM constants in native PCI Express drivers
Date: Mon, 30 Nov 2020 16:43:41 +0100	[thread overview]
Message-ID: <X8UTLQTXVX2iPCOn@rocinante> (raw)
In-Reply-To: <20201128183516.GA897329@bjorn-Precision-5520>

[+CC David for visibility]

Hi Bjorn,

Thank you for the review!

On 20-11-28 12:35:16, Bjorn Helgaas wrote:
[...]
> It's ironic that we don't use PCIE_ECAM_OFFSET in drivers/pci/ecam.c.
> We could do something like this, which would also let us drop
> .bus_shift completely in all the conforming implementations.  It also
> closes the hole that we didn't limit "where" to 4K for
> pci_ecam_map_bus() users.
> 
>   if (per_bus_mapping) {
>     base = cfg->winp[busn];
>     busn = 0;
>   } else {
>     base = cfg->win;
>   }
> 
>   if (cfg->ops->bus_shift) {
>     u32 bus_offset = (busn & 0xff) << cfg->ops->bus_shift;
>     u32 devfn_offset = (devfn & 0xff) << (cfg->ops->bus_shift - 8);
> 
>     where &= 0xfff;
> 
>     return base + (bus_offset | devfn_offset | where);
>   }
> 
>   return base + PCIE_ECAM_OFFSET(busn, devfn, where);
[...]

Thank you for suggesting this!  I sent v6 recently that includes this.

> >  static void __iomem *ppc4xx_pciex_get_config_base(struct ppc4xx_pciex_port *port,
> >  						  struct pci_bus *bus,
> > -						  unsigned int devfn)
> > +						  unsigned int devfn,
> > +						  int offset)
> 
> The interface change (to add "offset") could be a preparatory patch by
> itself.
> 
> But I'm actually not sure it's worth even touching this file.  This is
> the only place outside drivers/pci that includes linux/pci-ecam.h.  I
> think I might rather put PCIE_ECAM_OFFSET() and related things in
> drivers/pci/pci.h and keep it all inside drivers/pci.

Makes sense to drop it.  We can always introduce chances on PPC 4xx
platform in the future if we ever want it to leverage all the new macros
and constants.

These changes are not included in v6.

> >  static const struct pci_ecam_ops pci_thunder_pem_ops = {
> > -	.bus_shift	= 24,
> > +	.bus_shift	= THUNDER_PCIE_ECAM_BUS_SHIFT,
> >  	.init		= thunder_pem_platform_init,
> >  	.pci_ops	= {
> >  		.map_bus	= pci_ecam_map_bus,
> 
> This could be split to its own patch, no big deal either way.

Done.  v6 is now a series that includes this as a separate patch.

> >  const struct pci_ecam_ops xgene_v2_pcie_ecam_ops = {
> > -	.bus_shift	= 16,
> >  	.init		= xgene_v2_pcie_ecam_init,
> >  	.pci_ops	= {
> >  		.map_bus	= xgene_pcie_map_bus,
> 
> Thanks for mentioning this change in the cover letter.  It could also
> be split off to a preparatory patch, since it's not related to
> PCIE_ECAM_OFFSET(), which is the main point of this patch.

Done.
 
> >  static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
> >  					       unsigned int busno,
> > -					       unsigned int slot,
> > -					       unsigned int fn,
> > +					       unsigned int devfn,
> 
> This interface change *could* be a separate preparatory patch, too,
> but I'm starting to feel even more OCD than usual :)

Done.  It's a separate patch in v6, although I kept it together with the
change to introduce the PCIE_ECAM_OFFSET() macro since I was retiring the
use of PCI_SLOT() and PCI_FUNC() macros.

> > @@ -94,7 +95,7 @@ struct vmd_dev {
> >  	struct pci_dev		*dev;
> >  
> >  	spinlock_t		cfg_lock;
> > -	char __iomem		*cfgbar;
> > +	void __iomem		*cfgbar;
> 
> This type change might be worth pushing to a separate patch since the
> casting issues are not completely trivial.

Done.

The patch included in the series as part of v6 already got a review from
David Laight (thank you!) who suggests that this might not be a good
idea to do, and keeping existing type would be better.

Krzysztof

      reply	other threads:[~2020-11-30 15:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-27 10:46 [PATCH v5] PCI: Unify ECAM constants in native PCI Express drivers Krzysztof Wilczyński
2020-11-28 18:35 ` Bjorn Helgaas
2020-11-30 15:43   ` Krzysztof Wilczyński [this message]

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=X8UTLQTXVX2iPCOn@rocinante \
    --to=kw@linux.com \
    --cc=Jonathan.Cameron@huawei.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=david.laight@aculab.com \
    --cc=f.fainelli@gmail.com \
    --cc=heiko@sntech.de \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=jonnyc@amazon.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-rpi-kernel@lists.infradead.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=michal.simek@xilinx.com \
    --cc=mpe@ellerman.id.au \
    --cc=nsaenzjulienne@suse.de \
    --cc=paulus@samba.org \
    --cc=rjui@broadcom.com \
    --cc=robh@kernel.org \
    --cc=rrichter@marvell.com \
    --cc=sbranden@broadcom.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=toan@os.amperecomputing.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).