From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yijing Wang Subject: Re: [PATCH v6 10/30] PCI: Introduce pci_host_bridge_list to manage host bridges Date: Mon, 16 Mar 2015 09:28:16 +0800 Message-ID: <550631B0.2030709@huawei.com> References: <1425868467-9667-1-git-send-email-wangyijing@huawei.com> <1425868467-9667-11-git-send-email-wangyijing@huawei.com> <20150312025537.GD10949@google.com> <55018E90.9030301@huawei.com> <20150312195651.GD7346@google.com> <55025955.3020000@huawei.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: linux-alpha-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Bjorn Helgaas Cc: Jiang Liu , "linux-pci@vger.kernel.org" , Yinghai Lu , "linux-kernel@vger.kernel.org" , Marc Zyngier , linux-arm , Russell King , "x86@kernel.org" , Thomas Gleixner , Benjamin Herrenschmidt , Rusty Russell , Tony Luck , "linux-ia64@vger.kernel.org" , "David S. Miller" , Guan Xuetao , linux-alpha@vger.kernel.org, linux-m68k@lists.linux-m68k.org, Liviu Dudau , Arnd Bergmann , Geert Uytterhoeven >> Currently, if platform does not know the end bus number (not provide the bus resource), >> we will update the max bus number returned by pci_scan_child_bus() to the bus resource end, >> and I think this is reasonable. I consider to introduce a flag to identify the bus resource >> which end bus number is undefined, then we could force all pci_scan_root_bus() etc. callers >> to provide the bus resource, and we could process the bus resource end according the bus resource flag. >> Also then we could reduce the bus argument which is the same as busn_res->start. >> I would try to provide draft patch, then we could discuss it more clearly. > > Without having seen a patch, my inclination is to avoid a flag because > flags change the behavior of the code you call, which makes that code > harder to follow. Maybe we could require these platforms to > explicitly update the ending bus number after scanning the bus. OK, agree, thanks for your suggestion :) > > Bjorn > > . > -- Thanks! Yijing