linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Jon Derrick <jonathan.derrick@intel.com>
Cc: Sasha Levin <sashal@kernel.org>,
	Keith Busch <keith.busch@intel.com>,
	Bjorn Helgaas <helgaas@kernel.org>,
	linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI/VMD: Fix config addressing with bus offsets
Date: Fri, 21 Jun 2019 15:28:15 +0100	[thread overview]
Message-ID: <20190621142803.GA21807@e121166-lin.cambridge.arm.com> (raw)
In-Reply-To: <20190611211538.29151-1-jonathan.derrick@intel.com>

[dropped CC stable]

On Tue, Jun 11, 2019 at 03:15:38PM -0600, Jon Derrick wrote:
> VMD config space addressing relies on mapping the BDF of the target into
> the VMD config bar. When using bus number offsets to number the VMD
> domain, the offset needs to be ignored in order to correctly map devices
> to their config space.
> 
> Fixes: 2a5a9c9a20f9 ("PCI: vmd: Add offset to bus numbers if necessary")
> Cc: <stable@vger.kernel.org> # v4.19
> Cc: <stable@vger.kernel.org> # v4.18

Hi Jon,

that's not how stable should be handled. You should always start
by fixing mainline and if there are backports to be fixed too you
should add patch dependencies in the CC area, see:

Documentation/process/stable-kernel-rules.rst

Never add stable to the CC list in the email header, only in the
commit log.

When your patch hits mainline it will trickle back into stable,
if you specified dependencies as described above there is nothing
to do.

Thanks,
Lorenzo

> Signed-off-by: Jon Derrick <jonathan.derrick@intel.com>
> ---
>  drivers/pci/controller/vmd.c | 16 +++++++++-------
>  1 file changed, 9 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> index fd2dbd7..a59afec 100644
> --- a/drivers/pci/controller/vmd.c
> +++ b/drivers/pci/controller/vmd.c
> @@ -94,6 +94,7 @@ struct vmd_dev {
>  	struct resource		resources[3];
>  	struct irq_domain	*irq_domain;
>  	struct pci_bus		*bus;
> +	u8			busn_start;
>  
>  #ifdef CONFIG_X86_DEV_DMA_OPS
>  	struct dma_map_ops	dma_ops;
> @@ -465,7 +466,8 @@ static char __iomem *vmd_cfg_addr(struct vmd_dev *vmd, struct pci_bus *bus,
>  				  unsigned int devfn, int reg, int len)
>  {
>  	char __iomem *addr = vmd->cfgbar +
> -			     (bus->number << 20) + (devfn << 12) + reg;
> +			     ((bus->number - vmd->busn_start) << 20) +
> +			     (devfn << 12) + reg;
>  
>  	if ((addr - vmd->cfgbar) + len >=
>  	    resource_size(&vmd->dev->resource[VMD_CFGBAR]))
> @@ -588,7 +590,7 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  	unsigned long flags;
>  	LIST_HEAD(resources);
>  	resource_size_t offset[2] = {0};
> -	resource_size_t membar2_offset = 0x2000, busn_start = 0;
> +	resource_size_t membar2_offset = 0x2000;
>  
>  	/*
>  	 * Shadow registers may exist in certain VMD device ids which allow
> @@ -630,14 +632,14 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  		pci_read_config_dword(vmd->dev, PCI_REG_VMCONFIG, &vmconfig);
>  		if (BUS_RESTRICT_CAP(vmcap) &&
>  		    (BUS_RESTRICT_CFG(vmconfig) == 0x1))
> -			busn_start = 128;
> +			vmd->busn_start = 128;
>  	}
>  
>  	res = &vmd->dev->resource[VMD_CFGBAR];
>  	vmd->resources[0] = (struct resource) {
>  		.name  = "VMD CFGBAR",
> -		.start = busn_start,
> -		.end   = busn_start + (resource_size(res) >> 20) - 1,
> +		.start = vmd->busn_start,
> +		.end   = vmd->busn_start + (resource_size(res) >> 20) - 1,
>  		.flags = IORESOURCE_BUS | IORESOURCE_PCI_FIXED,
>  	};
>  
> @@ -705,8 +707,8 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
>  	pci_add_resource_offset(&resources, &vmd->resources[1], offset[0]);
>  	pci_add_resource_offset(&resources, &vmd->resources[2], offset[1]);
>  
> -	vmd->bus = pci_create_root_bus(&vmd->dev->dev, busn_start, &vmd_ops,
> -				       sd, &resources);
> +	vmd->bus = pci_create_root_bus(&vmd->dev->dev, vmd->busn_start,
> +				       &vmd_ops, sd, &resources);
>  	if (!vmd->bus) {
>  		pci_free_resource_list(&resources);
>  		irq_domain_remove(vmd->irq_domain);
> -- 
> 1.8.3.1
> 

  reply	other threads:[~2019-06-21 14:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-11 21:15 [PATCH] PCI/VMD: Fix config addressing with bus offsets Jon Derrick
2019-06-21 14:28 ` Lorenzo Pieralisi [this message]
2019-06-24 18:12   ` Derrick, Jonathan
2019-07-22 16:02   ` Derrick, Jonathan
2019-07-23  9:32     ` Lorenzo Pieralisi
2019-07-23 15:12       ` Derrick, Jonathan
2019-07-24 11:11         ` Lorenzo Pieralisi
2019-07-24 17:47           ` Derrick, Jonathan
  -- strict thread matches above, loose matches on Subject: below --
2019-06-07 20:00 Jon Derrick
     [not found] ` <20190610151839.EC55620862@mail.kernel.org>
2019-06-10 15:34   ` Derrick, Jonathan

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=20190621142803.GA21807@e121166-lin.cambridge.arm.com \
    --to=lorenzo.pieralisi@arm.com \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=keith.busch@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=sashal@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).