linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: kbuild test robot <lkp@intel.com>
To: Jon Derrick <jonathan.derrick@intel.com>
Cc: kbuild-all@01.org, linux-pci@vger.kernel.org,
	Bjorn Helgaas <helgaas@kernel.org>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Keith Busch <keith.busch@intel.com>,
	Jon Derrick <jonathan.derrick@intel.com>
Subject: Re: [PATCH 2/2] PCI/VMD: Set up firmware-first if capable
Date: Tue, 16 Oct 2018 10:25:13 +0800	[thread overview]
Message-ID: <201810161036.YC66JqPQ%fengguang.wu@intel.com> (raw)
In-Reply-To: <1539650888-3792-3-git-send-email-jonathan.derrick@intel.com>

[-- Attachment #1: Type: text/plain, Size: 7948 bytes --]

Hi Jon,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on pci/next]
[also build test ERROR on v4.19-rc8 next-20181012]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Jon-Derrick/VMD-fixes-for-4-20/20181016-085809
base:   https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git next
config: x86_64-randconfig-x019-201841 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
        # save the attached .config to linux build tree
        make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/pci//controller/vmd.c: In function 'vmd_enable_domain':
>> drivers/pci//controller/vmd.c:743:15: error: 'struct pci_dev' has no member named 'aer_cap'; did you mean 'ats_cap'?
       if (rpdev->aer_cap)
                  ^~~~~~~
                  ats_cap

vim +743 drivers/pci//controller/vmd.c

   581	
   582	static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
   583	{
   584		struct pci_sysdata *sd = &vmd->sysdata;
   585		struct fwnode_handle *fn;
   586		struct resource *res;
   587		u32 upper_bits;
   588		unsigned long flags;
   589		LIST_HEAD(resources);
   590		resource_size_t offset[2] = {0};
   591		resource_size_t membar2_offset = 0x2000, busn_start = 0;
   592		u8 interface;
   593	
   594		/*
   595		 * Shadow registers may exist in certain VMD device ids which allow
   596		 * guests to correctly assign host physical addresses to the root ports
   597		 * and child devices. These registers will either return the host value
   598		 * or 0, depending on an enable bit in the VMD device.
   599		 */
   600		if (features & VMD_FEAT_HAS_MEMBAR_SHADOW) {
   601			u32 vmlock;
   602			int ret;
   603	
   604			membar2_offset = 0x2018;
   605			ret = pci_read_config_dword(vmd->dev, PCI_REG_VMLOCK, &vmlock);
   606			if (ret || vmlock == ~0)
   607				return -ENODEV;
   608	
   609			if (MB2_SHADOW_EN(vmlock)) {
   610				void __iomem *membar2;
   611	
   612				membar2 = pci_iomap(vmd->dev, VMD_MEMBAR2, 0);
   613				if (!membar2)
   614					return -ENOMEM;
   615				offset[0] = vmd->dev->resource[VMD_MEMBAR1].start -
   616							readq(membar2 + 0x2008);
   617				offset[1] = vmd->dev->resource[VMD_MEMBAR2].start -
   618							readq(membar2 + 0x2010);
   619				pci_iounmap(vmd->dev, membar2);
   620			}
   621		}
   622	
   623		/*
   624		 * Certain VMD devices may have a root port configuration option which
   625		 * limits the bus range to between 0-127 or 128-255
   626		 */
   627		if (features & VMD_FEAT_HAS_BUS_RESTRICTIONS) {
   628			u32 vmcap, vmconfig;
   629	
   630			pci_read_config_dword(vmd->dev, PCI_REG_VMCAP, &vmcap);
   631			pci_read_config_dword(vmd->dev, PCI_REG_VMCONFIG, &vmconfig);
   632			if (BUS_RESTRICT_CAP(vmcap) &&
   633			    (BUS_RESTRICT_CFG(vmconfig) == 0x1))
   634				busn_start = 128;
   635		}
   636	
   637		res = &vmd->dev->resource[VMD_CFGBAR];
   638		vmd->resources[0] = (struct resource) {
   639			.name  = "VMD CFGBAR",
   640			.start = busn_start,
   641			.end   = busn_start + (resource_size(res) >> 20) - 1,
   642			.flags = IORESOURCE_BUS | IORESOURCE_PCI_FIXED,
   643		};
   644	
   645		/*
   646		 * If the window is below 4GB, clear IORESOURCE_MEM_64 so we can
   647		 * put 32-bit resources in the window.
   648		 *
   649		 * There's no hardware reason why a 64-bit window *couldn't*
   650		 * contain a 32-bit resource, but pbus_size_mem() computes the
   651		 * bridge window size assuming a 64-bit window will contain no
   652		 * 32-bit resources.  __pci_assign_resource() enforces that
   653		 * artificial restriction to make sure everything will fit.
   654		 *
   655		 * The only way we could use a 64-bit non-prefechable MEMBAR is
   656		 * if its address is <4GB so that we can convert it to a 32-bit
   657		 * resource.  To be visible to the host OS, all VMD endpoints must
   658		 * be initially configured by platform BIOS, which includes setting
   659		 * up these resources.  We can assume the device is configured
   660		 * according to the platform needs.
   661		 */
   662		res = &vmd->dev->resource[VMD_MEMBAR1];
   663		upper_bits = upper_32_bits(res->end);
   664		flags = res->flags & ~IORESOURCE_SIZEALIGN;
   665		if (!upper_bits)
   666			flags &= ~IORESOURCE_MEM_64;
   667		vmd->resources[1] = (struct resource) {
   668			.name  = "VMD MEMBAR1",
   669			.start = res->start,
   670			.end   = res->end,
   671			.flags = flags,
   672			.parent = res,
   673		};
   674	
   675		res = &vmd->dev->resource[VMD_MEMBAR2];
   676		upper_bits = upper_32_bits(res->end);
   677		flags = res->flags & ~IORESOURCE_SIZEALIGN;
   678		if (!upper_bits)
   679			flags &= ~IORESOURCE_MEM_64;
   680		vmd->resources[2] = (struct resource) {
   681			.name  = "VMD MEMBAR2",
   682			.start = res->start + membar2_offset,
   683			.end   = res->end,
   684			.flags = flags,
   685			.parent = res,
   686		};
   687	
   688		sd->vmd_domain = true;
   689		sd->domain = vmd_find_free_domain();
   690		if (sd->domain < 0)
   691			return sd->domain;
   692	
   693		sd->node = pcibus_to_node(vmd->dev->bus);
   694	
   695		fn = irq_domain_alloc_named_id_fwnode("VMD-MSI", vmd->sysdata.domain);
   696		if (!fn)
   697			return -ENODEV;
   698	
   699		vmd->irq_domain = pci_msi_create_irq_domain(fn, &vmd_msi_domain_info,
   700							    x86_vector_domain);
   701		irq_domain_free_fwnode(fn);
   702		if (!vmd->irq_domain)
   703			return -ENODEV;
   704	
   705		pci_add_resource(&resources, &vmd->resources[0]);
   706		pci_add_resource_offset(&resources, &vmd->resources[1], offset[0]);
   707		pci_add_resource_offset(&resources, &vmd->resources[2], offset[1]);
   708	
   709		vmd->bus = pci_create_root_bus(&vmd->dev->dev, busn_start, &vmd_ops,
   710					       sd, &resources);
   711		if (!vmd->bus) {
   712			pci_free_resource_list(&resources);
   713			irq_domain_remove(vmd->irq_domain);
   714			return -ENODEV;
   715		}
   716	
   717		vmd_attach_resources(vmd);
   718		vmd_setup_dma_ops(vmd);
   719		dev_set_msi_domain(&vmd->bus->dev, vmd->irq_domain);
   720		pci_rescan_bus(vmd->bus);
   721	
   722		/*
   723		 * Certain VMD devices may request firmware-first error handling
   724		 * support on the domain. These domains are virtual and not described
   725		 * by ACPI and must be configured manually. VMD domains which utilize
   726		 * firmware-first may still require further kernel error handling, but
   727		 * the domain is intended to first interrupt upon error to system
   728		 * firmware before being passed back to the kernel. The system error
   729		 * handling bits in the root port control register must be enabled
   730		 * following the AER service driver configuration in order to generate
   731		 * these system interrupts.
   732		 *
   733		 * Because the root ports are not described by ACPI and _OSC is
   734		 * unsupported in VMD domains, the intent to use firmware-first error
   735		 * handling in the root ports is instead described by the VMD device's
   736		 * interface bit.
   737		 */
   738		pci_read_config_byte(vmd->dev, PCI_CLASS_PROG, &interface);
   739		if (interface == 0x1) {
   740			struct pci_dev *rpdev;
   741	
   742			list_for_each_entry(rpdev, &vmd->bus->devices, bus_list) {
 > 743				if (rpdev->aer_cap)
   744					pcie_capability_set_word(rpdev, PCI_EXP_RTCTL,
   745								 PCI_EXP_RTCTL_SECEE  |
   746								 PCI_EXP_RTCTL_SENFEE |
   747								 PCI_EXP_RTCTL_SEFEE);
   748			}
   749		}
   750	
   751		WARN(sysfs_create_link(&vmd->dev->dev.kobj, &vmd->bus->dev.kobj,
   752				       "domain"), "Can't create symlink to domain\n");
   753		return 0;
   754	}
   755	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 34656 bytes --]

  reply	other threads:[~2018-10-16  2:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-16  0:48 [PATCH 0/2] VMD fixes for 4.20 Jon Derrick
2018-10-16  0:48 ` [PATCH 1/2] PCI/VMD: Detach resources after stopping root bus Jon Derrick
2018-10-16 14:48   ` Keith Busch
2018-10-18 16:43   ` Lorenzo Pieralisi
2018-10-16  0:48 ` [PATCH 2/2] PCI/VMD: Set up firmware-first if capable Jon Derrick
2018-10-16  2:25   ` kbuild test robot [this message]
2018-10-17 14:12   ` Lorenzo Pieralisi
2018-10-17 18:16     ` Derrick, Jonathan
2018-10-17 23:01       ` Bjorn Helgaas

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=201810161036.YC66JqPQ%fengguang.wu@intel.com \
    --to=lkp@intel.com \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@intel.com \
    --cc=kbuild-all@01.org \
    --cc=keith.busch@intel.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.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 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).