From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752136AbbCPB25 (ORCPT ); Sun, 15 Mar 2015 21:28:57 -0400 Received: from szxga01-in.huawei.com ([58.251.152.64]:57907 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751538AbbCPB2x (ORCPT ); Sun, 15 Mar 2015 21:28:53 -0400 Message-ID: <550631B0.2030709@huawei.com> Date: Mon, 16 Mar 2015 09:28:16 +0800 From: Yijing Wang User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 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" , , , Liviu Dudau , "Arnd Bergmann" , Geert Uytterhoeven Subject: Re: [PATCH v6 10/30] PCI: Introduce pci_host_bridge_list to manage host bridges 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> In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.27.212] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> 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