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]

Message-ID: <20141120120850.GD9162@bart.dudau.co.uk>
Date:	Thu, 20 Nov 2014 12:08:51 +0000
From:	Liviu Dudau <liviu@...au.co.uk>
To:	Tomasz Nowicki <tomasz.nowicki@...aro.org>
Cc:	Arnd Bergmann <arnd@...db.de>,
	linux-arm-kernel@...ts.infradead.org,
	Tony Luck <tony.luck@...el.com>,
	Russell King <linux@....linux.org.uk>,
	linux-pci@...r.kernel.org, x86@...nel.org,
	linux-kernel@...r.kernel.org, Xinwei Hu <huxinwei@...wei.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Thierry Reding <thierry.reding@...il.com>,
	Suravee.Suthikulpanit@....com,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Yijing Wang <wangyijing@...wei.com>,
	linux-ia64@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Wuyun <wuyun.wu@...wei.com>, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [RFC PATCH 00/16] Refine PCI host bridge scan interfaces

On Thu, Nov 20, 2014 at 12:54:48PM +0100, Tomasz Nowicki wrote:
> On 17.11.2014 15: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.
> >
> >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.
> >
> >As a general approach, I'd rather see generic helper functions
> >being exported by the PCI core that a driver may or may not
> >call.
> >The way you split the interface between things that happen
> >before scanning the buses (pci_create_host_bridge) and
> >the actual scanning (__pci_create_root_bus, pci_scan_child_bus)
> >seems very helpful and I think we can expand that concept further:
> >
> >- The normal pci_create_host_bridge() function can contain
> >   all of the DT scanning functions (finding bus/mem/io resources,
> >   finding the msi-parent), while drivers that don't depend on DT
> >   for this information can call the same function and fill the
> >   same things after they have the pci_host_bridge pointer.
> 
> How about finding PCI domain number (in the DT way) within
> pci_create_host_bridge() too ?

It is an idea worth pursuing for the 99% of the cases. I would like
to understand the 1% of the time when we want a domain number to be
shared between two host bridges or the time when we want more than
one domain per bridge.

Is that possible? Is it useful? Is it already in practice?

Best regards,
Liviu

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

-- 
-------------------
   .oooO
   (   )
    \ (  Oooo.
     \_) (   )
          ) /
         (_/

 One small step
   for me ...

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