linux-kernel - Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces

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, 18 Nov 2014 20:14:33 +0800
From:	Yijing Wang <wangyijing@...wei.com>
To:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
	Arnd Bergmann <arnd@...db.de>
CC:	Liviu Dudau <liviu@...au.co.uk>, Tony Luck <tony.luck@...el.com>,
	"Russell King" <linux@....linux.org.uk>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"huxinwei@...wei.com" <huxinwei@...wei.com>,
	Thierry Reding <thierry.reding@...il.com>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Wuyun <wuyun.wu@...wei.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces

On 2014/11/18 19:45, Lorenzo Pieralisi wrote:
> On Tue, Nov 18, 2014 at 11:30:11AM +0000, Arnd Bergmann wrote:
>> On Tuesday 18 November 2014 19:17:32 Yijing Wang wrote:
>>> On 2014/11/17 22:13, Arnd Bergmann wrote:
>>>> On Monday 17 November 2014 18:21:34 Yijing Wang wrote:
>>>>> This series is based Linux 3.18-rc1 and Lorenzo Pieralisi's
>>>>> arm PCI domain cleanup patches, link: 
>>>>> https://patchwork.ozlabs.org/patch/407585/
>>>>>
>>>>> Current pci scan interfaces like pci_scan_root_bus() and directly
>>>>> call pci_create_root_bus()/pci_scan_child_bus() lack flexiblity.
>>>>> Some platform infos like PCI domain and msi_chip have to be
>>>>> associated to PCI bus by some arch specific function.
>>>>> We want to make a generic pci_host_bridge, and make it hold
>>>>> the platform infos or hook. Then we could eliminate the lots
>>>>> of arch pci_domain_nr, also we could associate some platform 
>>>>> ops something like pci_get_msi_chip(struct pci_dev *dev)
>>>>> with pci_host_bridge to avoid introduce arch weak functions.
>>>>>
>>>>> This RFC version not for all platforms, just applied the new
>>>>> scan interface in x86/arm/powerpc/ia64, I will refresh other
>>>>> platforms after the core pci scan interfaces are ok.
>>>>
>>>> I think overall this is a good direction to take, in particular
>>>> moving more things into struct pci_host_bridge so we can
>>>> slim down the architecture specific code.
>>>
>>> Hi Arnd, thanks very much for your review and comments!
>>>
>>>>
>>>> I don't particularly like the way you use the 'pci_host_info'
>>>> to pass callback pointers and some of the generic information.
>>>> This duplicates some of the issues we are currently trying
>>>> to untangle in the arm32 code to make drivers easier to share
>>>> between architectures.
>>>
>>> What arm32 code you are trying to untangle for example ?
>>
>> We have a few problems that currently prevent us from using shared
>> drivers across arm32 and arm64:
>>
>> - arm32 has an architecture-defined pci_sys_data structure, but
>>   we really want to have one that is defined by the host bridge driver
>>   and that is architecture independent. Some core functions depend
>>   on this structure at the moment, which Lorenzo is trying to
>>   undo
> 
> Yes, and on this specific point I would like to understand why we
> are adding yet more pci_sys_data data in the last series that is
> already in -next:
> 
> https://lkml.org/lkml/2014/10/27/85
> 
> What does this buy us ? The cover letter says already that there *is*
> a better solution, why do not we work on that instead of adding more churn
> to arch specific code ?

In my plan, first save msi_chip in pci_sys_data, so we could remove the lots duplicate
pcibios_add_bus(), second, make a generic pci_host_bridge, and move the msi_chip in that,
so we could eliminate all MSI arch weak functions. And in arm I think it's no need to
associate msi_chip with PCI bus, because all pci devices under the same pci host bridge
share the same msi_chip.



> 
> Thanks,
> Lorenzo
> 
> .
> 


-- 
Thanks!
Yijing

--
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/