linux-kernel - Re: [PATCH] PCI: Generic Configuration Access Mechanism support

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]

Date:	Tue, 20 May 2014 20:01:01 +0530
From:	Srikanth Thokala <sthokal@...inx.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Srikanth Thokala <sthokal@...inx.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>, will.deacon@....com,
	michals@...inx.com,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>
Subject: Re: [PATCH] PCI: Generic Configuration Access Mechanism support

Hi Arnd,

On Mon, May 19, 2014 at 10:33 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Sunday 18 May 2014 19:38:45 Srikanth Thokala wrote:
>> +
>> +     if (cfg->ops->is_valid_cfg_access) {
>> +             if (!cfg->ops->is_valid_cfg_access(bus, devfn)) {
>> +                     *val = PCI_CFG_INVALID_DEVFN;
>> +                     return PCIBIOS_DEVICE_NOT_FOUND;
>> +             }
>> +     }
>
> Can you explain why this callback is needed? If the space for the
> bus is mapped, any access should just work.

As I was explaining to Will, there are some controllers which doesn't
return FF's
when a device is not found on the bus (as per the PCI specification) and
accessing such a device address from the kernel results in an external abort.
So, I added this additional logic in my driver to bypass this and
return FF's. Our IP
and even other controllers like Tegra, Renesas have similar implementation.
We cant think of a better solution and please let you us know if you
have any inputs.

Thanks
Srikanth

>
>> +
>> +/* Generic PCI CAM/ECAM Configuration Bus Operations */
>> +
>> +struct pci_cfg_bus_ops pci_cfg_cam_bus_ops = {
>> +     .bus_shift      = PCI_CFG_CAM_BUS_NUM,
>> +     .map_bus        = pci_cfg_map_bus_cam,
>> +};
>> +EXPORT_SYMBOL_GPL(pci_cfg_cam_bus_ops);
>> +
>> +struct pci_cfg_bus_ops pci_cfg_ecam_bus_ops = {
>> +     .bus_shift      = PCI_CFG_ECAM_BUS_NUM,
>> +     .map_bus        = pci_cfg_map_bus_ecam,
>> +};
>> +EXPORT_SYMBOL_GPL(pci_cfg_ecam_bus_ops);
>> +
>> +struct pci_ops pci_cfg_ops = {
>> +     .read   = pci_cfg_read,
>> +     .write  = pci_cfg_write,
>> +};
>> +EXPORT_SYMBOL_GPL(pci_cfg_ops);
>
>
> If we can find a way to remove the is_valid_cfg_access() check, we're
> probably better off removing the cfg_bus_ops as well, and exporting
> two sets of pci_ops. There will be a little more duplication here, but
> also less complexity in this module, and more importantly in the drivers
> using it.
>
>         Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/