From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1355DC3DA7A for ; Thu, 5 Jan 2023 13:43:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230195AbjAENnD (ORCPT ); Thu, 5 Jan 2023 08:43:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58606 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233384AbjAENnB (ORCPT ); Thu, 5 Jan 2023 08:43:01 -0500 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id ABBE93726B for ; Thu, 5 Jan 2023 05:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1672926180; x=1704462180; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=kIEXQCByY6Q78c4ODeYJKCEQoeUQjlV1WZZjm/t5PE8=; b=YsjgHLBSGmxMN4tQnYPdMcsvDc7bsPDVQ2NGa16EnCjxrxJay023X0T4 OqhkYFq03XglFXolhcdLnF8bPRg7CD/LPJyJMDdh7aGECClNcDYE6fe72 oZb51hcDbI9buh7cmPucGKEFhFTM3hA+eEfncVbiV9Z/m1iHfJz434Mlv BJcmu4Qg/EqYor/BL1h6D07QiBrB2UNGGgOc3iAZIQgioAVQq4RQI6UTQ bJ6yGkzdBqGQNwQkbt8xRWx8i0q0FcpknSDWOO4319X/dWFIabJUGRVFw I/J7Iq74TgrftJeJEFjYL2zvX/4GMDu+fHaOtoDvoteA6NRuzNGyR+WhZ g==; X-IronPort-AV: E=McAfee;i="6500,9779,10580"; a="386637257" X-IronPort-AV: E=Sophos;i="5.96,303,1665471600"; d="scan'208";a="386637257" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jan 2023 05:42:59 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10580"; a="718829709" X-IronPort-AV: E=Sophos;i="5.96,303,1665471600"; d="scan'208";a="718829709" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga008.fm.intel.com with ESMTP; 05 Jan 2023 05:42:56 -0800 Received: by black.fi.intel.com (Postfix, from userid 1001) id 5A78A162; Thu, 5 Jan 2023 15:43:29 +0200 (EET) Date: Thu, 5 Jan 2023 15:43:29 +0200 From: Mika Westerberg To: Bjorn Helgaas Cc: Bjorn Helgaas , "Rafael J . Wysocki" , Andy Shevchenko , Jonathan Cameron , Lukas Wunner , Chris Chiu , Alexander Motin , Nicholas Johnson , linux-pci@vger.kernel.org Subject: Re: [PATCH v4 1/2] PCI: Take other bus devices into account when distributing resources Message-ID: References: <20230104091635.63331-2-mika.westerberg@linux.intel.com> <20230104224809.GA1094900@bhelgaas> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org Hi, On Thu, Jan 05, 2023 at 11:12:11AM +0200, Mika Westerberg wrote: > > What happens in a topology like this: > > > > 10:00.0 non-hotplug bridge to [bus 20-3f] > > 10:01.0 non-hotplug bridge to [bus 40] > > 20:00.0 hotplug bridge > > 40:00.0 NIC > > > > where we're distributing space on "bus" 10, hotplug_bridges == 0 and > > normal_bridges == 2? Do we give half the extra space to bus 20 and > > the other half to bus 40, even though we could tell up front that bus > > 20 is the only place that can actually use any extra space? > > Yes we split it into half. Forgot to reply also that would it make sense here to look at below the non-hotplug bridges and if we find hotplug bridges, distribute the space equally between those or something like that?