| 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
| ||
|
Message-ID: <a3548d7a-73cb-21d5-a3d9-a0e4f07a5db5@semihalf.com>
Date: Thu, 24 Nov 2016 12:10:44 +0100
From: Tomasz Nowicki <tn@...ihalf.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: arnd@...db.de, will.deacon@....com, catalin.marinas@....com,
rafael@...nel.org, hanjun.guo@...aro.org,
Lorenzo.Pieralisi@....com, okaya@...eaurora.org,
jchandra@...adcom.com, robert.richter@...iumnetworks.com,
mw@...ihalf.com, Liviu.Dudau@....com, ddaney@...iumnetworks.com,
wangyijing@...wei.com, Suravee.Suthikulpanit@....com,
msalter@...hat.com, linux-pci@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-acpi@...r.kernel.org,
linux-kernel@...r.kernel.org, linaro-acpi@...ts.linaro.org,
jcm@...hat.com, andrea.gallo@...aro.org, dhdang@....com,
jeremy.linton@....com, liudongdong3@...wei.com, cov@...eaurora.org
Subject: Re: [PATCH V9 11/11] ARM64/PCI: Support for ACPI based PCI host
controller
On 23.11.2016 19:22, Bjorn Helgaas wrote:
> On Wed, Nov 23, 2016 at 12:21:03PM +0100, Tomasz Nowicki wrote:
>> Hi Bjorn,
>>
>> On 23.11.2016 00:13, Bjorn Helgaas wrote:
>>> Hi Tomasz,
>>>
>>> On Fri, Jun 10, 2016 at 09:55:19PM +0200, Tomasz Nowicki wrote:
>>>> Implement pci_acpi_scan_root and other arch-specific call so that ARM64
>>>> can start using ACPI to setup and enumerate PCI buses.
>>>>
>>>> Prior to buses enumeration the pci_acpi_scan_root() implementation looks
>>>> for configuration space start address (obtained through ACPI _CBA method or
>>>> MCFG interface). If succeed, it uses ECAM library to create new mapping.
>>>> Then it attaches generic ECAM ops (pci_generic_ecam_ops) which are used
>>>> for accessing configuration space later on.
>>>> ...
>>>
>>>> +static struct acpi_pci_root_ops acpi_pci_root_ops = {
>>>> + .release_info = pci_acpi_generic_release_info,
>>>> +};
>>>> +
>>>> +/* Interface called from ACPI code to setup PCI host controller */
>>>> struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>>>> {
>>>> - /* TODO: Should be revisited when implementing PCI on ACPI */
>>>> - return NULL;
>>>> + int node = acpi_get_node(root->device->handle);
>>>> + struct acpi_pci_generic_root_info *ri;
>>>> + struct pci_bus *bus, *child;
>>>> +
>>>> + ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
>>>> + if (!ri)
>>>> + return NULL;
>>>> +
>>>> + ri->cfg = pci_acpi_setup_ecam_mapping(root);
>>>> + if (!ri->cfg) {
>>>> + kfree(ri);
>>>> + return NULL;
>>>> + }
>>>> +
>>>> + acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;
>>>
>>> This has already been merged, but this isn't right, is it? We're
>>> writing a host controller-specific pointer into the single system-wide
>>> acpi_pci_root_ops, then passing it on to acpi_pci_root_create().
>>>
>>> Today, I think ri->cfg->ops->pci_ops is always &pci_generic_ecam_ops,
>> >from this path:
>>>
>>> ri->cfg = pci_acpi_setup_ecam_mapping
>>> cfg = pci_ecam_create(..., &pci_generic_ecam_ops)
>>> cfg = kzalloc(...)
>>> cfg->ops = ops # &pci_generic_ecam_ops
>>>
>>> But we're about to merge the ECAM quirks series, which will mean it
>>> may not be &pci_generic_ecam_ops. Even apart from the ECAM quirks, we
>>> should avoid this pattern of putting device-specific info in a single
>>> shared structure because it's too difficult to verify that it's
>>> correct.
>>>
>>
>> Well spotted. I agree, we need to fix this. How about this:
>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> index fb439c7..31c0e1c 100644
>> --- a/arch/arm64/kernel/pci.c
>> +++ b/arch/arm64/kernel/pci.c
>> @@ -152,33 +152,35 @@ static void
>> pci_acpi_generic_release_info(struct acpi_pci_root_info *ci)
>>
>> ri = container_of(ci, struct acpi_pci_generic_root_info, common);
>> pci_ecam_free(ri->cfg);
>> + kfree(ci->ops);
>> kfree(ri);
>> }
>>
>> -static struct acpi_pci_root_ops acpi_pci_root_ops = {
>> - .release_info = pci_acpi_generic_release_info,
>> -};
>> -
>> /* Interface called from ACPI code to setup PCI host controller */
>> struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>> {
>> int node = acpi_get_node(root->device->handle);
>> struct acpi_pci_generic_root_info *ri;
>> struct pci_bus *bus, *child;
>> + struct acpi_pci_root_ops *root_ops;
>>
>> ri = kzalloc_node(sizeof(*ri), GFP_KERNEL, node);
>> if (!ri)
>> return NULL;
>>
>> + root_ops = kzalloc_node(sizeof(*root_ops), GFP_KERNEL, node);
>> + if (!root_ops)
>> + return NULL;
>> +
>> ri->cfg = pci_acpi_setup_ecam_mapping(root);
>> if (!ri->cfg) {
>> kfree(ri);
>> + kfree(root_ops);
>> return NULL;
>> }
>>
>> - acpi_pci_root_ops.pci_ops = &ri->cfg->ops->pci_ops;
>> - bus = acpi_pci_root_create(root, &acpi_pci_root_ops, &ri->common,
>> - ri->cfg);
>> + root_ops->release_info = pci_acpi_generic_release_info;
>> + root_ops->pci_ops = &ri->cfg->ops->pci_ops;
>> + bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
>> if (!bus)
>> return NULL;
>>
>> Of course, this should be the part of ECAM quirks core patches.
>>
>> The other option we have is to remove "struct pci_ops *pci_ops;"
>> from acpi_pci_root_ops structure and pass struct pci_ops as an extra
>> argument to acpi_pci_root_create(). What do you think?
>
> I think your patch above is fine and avoids the need to change the x86 and
> ia64 code. Would you mind packaging this up with a changelog and
> signed-off-by? I can take care of putting it in the ECAM series.
>
Sure, I have just sent the patch in replay to ECAM quirks V6 patch set.
Let us know when you update your branch so we base our quirks on it.
Thanks,
Tomasz
Powered by blists - more mailing lists