linux-kernel - RE: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks

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: <EE11001F9E5DDD47B7634E2F8A612F2E1F8730EA@lhreml507-mbx>
Date:   Fri, 16 Sep 2016 09:02:15 +0000
From:   Gabriele Paoloni <gabriele.paoloni@...wei.com>
To:     Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        "liudongdong (C)" <liudongdong3@...wei.com>
CC:     Tomasz Nowicki <tn@...ihalf.com>,
        "helgaas@...nel.org" <helgaas@...nel.org>,
        "will.deacon@....com" <will.deacon@....com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
        "okaya@...eaurora.org" <okaya@...eaurora.org>,
        "jchandra@...adcom.com" <jchandra@...adcom.com>,
        "cov@...eaurora.org" <cov@...eaurora.org>,
        "dhdang@....com" <dhdang@....com>,
        "ard.biesheuvel@...aro.org" <ard.biesheuvel@...aro.org>,
        "robert.richter@...iumnetworks.com" 
        <robert.richter@...iumnetworks.com>,
        "mw@...ihalf.com" <mw@...ihalf.com>,
        "Liviu.Dudau@....com" <Liviu.Dudau@....com>,
        "ddaney@...iumnetworks.com" <ddaney@...iumnetworks.com>,
        Wangyijing <wangyijing@...wei.com>,
        "msalter@...hat.com" <msalter@...hat.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
        "jcm@...hat.com" <jcm@...hat.com>,
        "andrea.gallo@...aro.org" <andrea.gallo@...aro.org>,
        "jeremy.linton@....com" <jeremy.linton@....com>,
        "jhugo@...eaurora.org" <jhugo@...eaurora.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM quirks

Hi Lorenzo and Tomasz

Many Thanks for looking at this

> -----Original Message-----
> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi@....com]
> Sent: 15 September 2016 11:59
> To: liudongdong (C)
> Cc: Tomasz Nowicki; helgaas@...nel.org; will.deacon@....com;
> catalin.marinas@....com; rafael@...nel.org; arnd@...db.de;
> hanjun.guo@...aro.org; okaya@...eaurora.org; jchandra@...adcom.com;
> cov@...eaurora.org; dhdang@....com; ard.biesheuvel@...aro.org;
> robert.richter@...iumnetworks.com; mw@...ihalf.com;
> Liviu.Dudau@....com; ddaney@...iumnetworks.com; Wangyijing;
> msalter@...hat.com; linux-pci@...r.kernel.org; linux-arm-
> kernel@...ts.infradead.org; linaro-acpi@...ts.linaro.org;
> jcm@...hat.com; andrea.gallo@...aro.org; jeremy.linton@....com;
> Gabriele Paoloni; jhugo@...eaurora.org; linux-acpi@...r.kernel.org;
> linux-kernel@...r.kernel.org
> Subject: Re: [PATCH V6 2/5] PCI/ACPI: Check platform specific ECAM
> quirks
> 
> On Tue, Sep 13, 2016 at 07:38:39PM +0800, Dongdong Liu wrote:
> 
> [...]
> 
> > Our host bridge is non ECAM only for the RC bus config space;
> > for any other bus underneath the root bus we support ECAM access.
> >
> > RC config resource with hardcode as DEFINE_RES_MEM(0xb0070000,
> SZ_4K),
> > EP config resource we get it from MCFG table.
> > So we need to override ops, but config resource we only need to
> hardcode with RC config resource.
> >
> > Our host controller ACPI support patch can be found:
> > https://lkml.org/lkml/2016/8/31/340
> 
> Sorry I misread your code. IIUC you create an array of resources that
> represent non-ECAM config space (and incidentally contain debug
> registers to check the link status - that you need to check for every
> given config access (?)), but you still need to have an MCFG entry that

The link status check is inherited from the designware framework (see
http://lxr.free-electrons.com/source/drivers/pci/host/pcie-designware.c#L678)

However I think that in this case we can just check the link status
in our init function and return an error if the link is down

> covers the bus number subject to quirk to make sure this mechanism
> works. Correct ?

Well we need the quirks for the root bus numbers but if read this v6
quirk mechanism correctly even if we do not specify an mcfg entry for
bus 0 oci_mcfg_match_quirks() is called anyway and we can set our
special configuration space addresses for the root buses (i.e. I think
we can have a clean MCFG table with entries only for those bus ranges
that are really ECAM)  

> 
> This also means that, with the MCFG tables you have and current
> mainline kernel you are able to probe a root bridge (because the MCFG
> table covers the bus number that is not ECAM), with enumeration
> going haywire because it is trying to carry out ECAM accesses on
> non-ECAM space.

Yes correct, we cannot access the host controller configuration space
with our current MCFG table and current Linux mainline

> 
> Is my reading correct ?
> 
> Anyway, that's not stricly related to this discussion, it is time we
> converge on this patchset, we can add a domain range if that
> simplifies things.

IMO it would be better to have the domain range to avoid
a very large and repetitive static quirk array

Thanks

Gab

> 
> Thanks,
> Lorenzo
> 
> > This patch is based on RFC V5 quirk mechanism.
> >
> > Based on V6 quirk mechanism, we have to change it as below:
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > 	{ "HISI ", "HIP05 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP05 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP05 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP05 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip05_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP06 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP06 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP06 ", 0, 2, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP06 ", 0, 3, MCFG_BUS_ANY, &hisi_pcie_hip06_ops,
> >          MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP07 ", 0, 0, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > 	  MCFG_RES_EMPTY},
> > 	{ "HISI ", "HIP07 ", 0, 1, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > 	  MCFG_RES_EMPTY},
> > 	....
> >
> > 	{ "HISI ", "HIP07 ", 0, 15, MCFG_BUS_ANY, &hisi_pcie_hip07_ops,
> > 	  MCFG_RES_EMPTY},
> >
> > #endif
> >
> > struct pci_ecam_ops hisi_pci_hip05_ops = {
> > 	.bus_shift	= 20,
> > 	.init		=  hisi_pci_hip05_init,
> > 	.pci_ops	= {
> > 		.map_bus	= pci_ecam_map_bus,
> > 		.read		= hisi_pcie_acpi_rd_conf,
> > 		.write		= hisi_pcie_acpi_wr_conf,
> > 	}
> > };
> >
> > struct pci_ecam_ops hisi_pci_hip06_ops = {
> > 	.bus_shift = 20,
> > 	.init = hisi_pci_hip06_init,
> > 	.pci_ops = {
> > 		.map_bus = pci_ecam_map_bus,
> > 		.read = hisi_pcie_acpi_rd_conf,
> > 		.write = hisi_pcie_acpi_wr_conf,
> > 	}
> > };
> >
> > hisi_pci_hipxx_init function is used to get RC config resource with
> hardcode.
> > .....
> >
> > So I hope we can use MCFG_DOM_RANGE, Then I can change it as below.
> >
> > #ifdef CONFIG_PCI_HISI_ACPI
> > 	{ "HISI  ", "HIP05   ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > 	 &hisi_pcie_hip05_ops, MCFG_RES_EMPTY},
> > 	{ "HISI  ", "HIP06   ", 0, MCFG_DOM_RANGE(0, 3), MCFG_BUS_ANY,
> > 	 &hisi_pcie_hip06_ops, MCFG_RES_EMPTY},
> > 	{ "HISI  ", "HIP07   ", 0, MCFG_DOM_RANGE(0, 15), MCFG_BUS_ANY,
> > 	  &hisi_pcie_hip07_ops, MCFG_RES_EMPTY},
> > #endif
> >
> > Thanks
> > Dongdong
> > >
> > >Thanks,
> > >Tomasz
> > >
> > >.
> > >
> >