linux-kernel - Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors against platfrom 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: <57503626.9050208@semihalf.com>
Date:	Thu, 2 Jun 2016 15:35:34 +0200
From:	Tomasz Nowicki <tn@...ihalf.com>
To:	Arnd Bergmann <arnd@...db.de>, linux-arm-kernel@...ts.infradead.org
Cc:	rafael@...nel.org, linux-pci@...r.kernel.org, will.deacon@....com,
	okaya@...eaurora.org, wangyijing@...wei.com,
	andrea.gallo@...aro.org, Lorenzo.Pieralisi@....com,
	linaro-acpi@...ts.linaro.org, ddaney@...iumnetworks.com,
	linux-acpi@...r.kernel.org, robert.richter@...iumnetworks.com,
	helgaas@...nel.org, liudongdong3@...wei.com,
	catalin.marinas@....com, Liviu.Dudau@....com, jcm@...hat.com,
	msalter@...hat.com, cov@...eaurora.org, mw@...ihalf.com,
	jchandra@...adcom.com, dhdang@....com,
	linux-kernel@...r.kernel.org, jeremy.linton@....com,
	hanjun.guo@...aro.org, Suravee.Suthikulpanit@....com
Subject: Re: [RFC PATCH 1/3] pci, acpi: Match PCI config space accessors
 against platfrom specific ECAM quirks.

On 02.06.2016 14:32, Arnd Bergmann wrote:
> On Thursday, June 2, 2016 2:07:43 PM CEST Tomasz Nowicki wrote:
>> On 02.06.2016 13:42, Arnd Bergmann wrote:
>>> On Thursday, June 2, 2016 10:41:01 AM CEST Tomasz Nowicki wrote:
>>>> +struct pci_ecam_ops *pci_mcfg_get_ops(struct acpi_pci_root *root)
>>>> +{
>>>> +       int bus_num = root->secondary.start;
>>>> +       int domain = root->segment;
>>>> +       struct pci_cfg_fixup *f;
>>>> +
>>>> +       if (!mcfg_table)
>>>> +               return &pci_generic_ecam_ops;
>>>> +
>>>> +       /*
>>>> +        * Match against platform specific quirks and return corresponding
>>>> +        * CAM ops.
>>>> +        *
>>>> +        * First match against PCI topology <domain:bus> then use OEM ID and
>>>> +        * OEM revision from MCFG table standard header.
>>>> +        */
>>>> +       for (f = __start_acpi_mcfg_fixups; f < __end_acpi_mcfg_fixups; f++) {
>>>> +               if ((f->domain == domain || f->domain == PCI_MCFG_DOMAIN_ANY) &&
>>>> +                   (f->bus_num == bus_num || f->bus_num == PCI_MCFG_BUS_ANY) &&
>>>> +                   (!strncmp(f->oem_id, mcfg_table->header.oem_id,
>>>> +                             ACPI_OEM_ID_SIZE)) &&
>>>> +                   (f->oem_revision == mcfg_table->header.oem_revision))
>>>> +                       return f->ops;
>>>> +       }
>>>> +       /* No quirks, use ECAM */
>>>> +       return &pci_generic_ecam_ops;
>>>> +}
>>>> +
>>>>    int pci_mcfg_lookup(struct acpi_pci_root *root)
>>>
>>> Can you explain the use of pci_ecam_ops instead of pci_ops here?
>>>
>>
>> I wanted to get associated bus_shift and use it to setup configuration
>> region properly before calling pci_ecam_create. Please see next patch.
>>
>
> I see. It feels really odd to do it this way though, since having a
> nonstandard bus_shift essentially means not using anything resembling
> ECAM to start with.
>
> I realize that a lot of the host bridges are not ECAM, but because
> of this, it would be more logical to have their own pci_ops instead
> of pci_ecam_ops.

Well, we have bus_shift there to express bus shift differentiation. So I 
would say we should change just structure name to prevent misunderstanding.

Thanks,
Tomasz