[{"id":3682070,"web_url":"http://patchwork.ozlabs.org/comment/3682070/","msgid":"","list_archive_url":null,"date":"2026-04-24T15:04:19","subject":"Re: [PATCH] PCI: Fix resizable bar fails due to bridge memory\n region","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Fri, 24 Apr 2026, Maarten Lankhorst wrote:\n\n> I encountered a problem that I have on my system, where I cannot resize\n> the bar because one of the bridges has a \n\nYou're missing words from here. But I can guess you've that extra BAR on \nin-card the bridge.\n\n> If I take a look at the topology, the GPU shares the memory region with a bridge,\n> \n> +-[0000:64]-+-00.0-[65-68]----00.0-[66-68]--+-01.0-[67]----00.0\n> \n> The specific bridge likely causing a failure is:\n> \n> 65:00.0 PCI bridge: Intel Corporation Device e2ff (rev 01) (prog-if 00 [Normal decode])\n> Flags: bus master, fast devsel, latency 0, IRQ 32, IOMMU group 1\n> Memory at 382400000000 (64-bit, prefetchable) [size=8M]\n> ....\n> \n> Which causes upstream bridge 64:00.0 initially to allocate the region\n> [38fe0000000-38ff0000000) for the GPU, and [382ff0000000..382ff07fffff]\n> for the bridge device.\n> \n> Bridge 64 is big enough for 1 BMG with a 32 GB bar and the second 8 MB allocation:\n> pci_bus 0000:64: resource 9 [mem 0x382000000000-0x382fffffffff window] (64GB window)\n> \n> The reason for failure is that bridge 65 has a 8 MB memory region assigned,\n\n> and previously it was ignored when reallocating.\n\nWhat does this mean? I don't think it was ever ignored while \nreallocating??\n\nNote that kernel has become much more verbose in explaining why things \nfail so perhaps the added message is confusing you (they won't appear in \nthe old kernels).\n\n> Failing case:\n> xe 0000:67:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB\n> xe 0000:67:00.0: BAR 2 [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]: was not released (still contains assigned resources)\n> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space\n> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign\n> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space\n> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign\n> pcieport 0000:64:00.0: PCI bridge to [bus 65-68]\n> pcieport 0000:64:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]\n> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]\n> pcieport 0000:66:01.0: PCI bridge to [bus 67]\n> pcieport 0000:66:01.0: bridge window [mem 0xd7000000-0xd81fffff]\n> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]\n> \n> Working with the patch below:\n> xe 0000:67:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB\n> xe 0000:67:00.0: BAR 2 [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> pcieport 0000:65:00.0: BAR 0 [mem 0x382ff0000000-0x382ff07fffff 64bit pref]: releasing\n> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]: releasing\n> pcieport 0000:64:00.0: bridge window [mem 0x382000000000-0x3824007fffff 64bit pref]: assigned\n> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n> pcieport 0000:65:00.0: BAR 0 [mem 0x382400000000-0x3824007fffff 64bit pref]: assigned\n> pcieport 0000:66:01.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n> xe 0000:67:00.0: BAR 2 [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n> pcieport 0000:64:00.0: PCI bridge to [bus 65-68]\n> pcieport 0000:64:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> pcieport 0000:64:00.0: bridge window [mem 0x382000000000-0x3824007fffff 64bit pref]\n> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n> pcieport 0000:66:01.0: PCI bridge to [bus 67]\n> pcieport 0000:66:01.0: bridge window [mem 0xd7000000-0xd81fffff]\n> pcieport 0000:66:01.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n> xe 0000:67:00.0: [drm] BAR2 resized to 16384MiB\n> \n> \n> Signed-off-by: Maarten Lankhorst \n> ---\n> I'm not 100% this is the correct fix, I don't know why the bridge itself has\n> a memory region, why the kernel allocates it and when it's supposed to\n> be used. Not a PCI expert. :-)\n\nI don't know why it is there either. Nothing in the portdrv really uses it \nfor anything. There is patchset somewhere lying around which adds a quirk \nthat releases the \"extra\" BAR.\n\n> ---\n> \n> diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c\n> index 61f769aaa2f6c..98692dccc4721 100644\n> --- a/drivers/pci/setup-bus.c\n> +++ b/drivers/pci/setup-bus.c\n> @@ -2258,6 +2258,7 @@ static int pbus_reassign_bridge_resources(struct pci_bus *bus, struct resource *\n> \tunsigned long type = res->flags;\n> \tstruct pci_dev_resource *dev_res;\n> \tstruct pci_dev *bridge = NULL;\n> +\tstruct resource *r;\n> \tLIST_HEAD(added);\n> \tLIST_HEAD(failed);\n> \tunsigned int i;\n> @@ -2286,6 +2287,21 @@ static int pbus_reassign_bridge_resources(struct pci_bus *bus, struct resource *\n> \t\t\t\t res_name, res);\n> \t\t}\n> \n> +\t\tpci_dev_for_each_resource(bridge, r, i) {\n> +\t\t\tif (!resource_assigned(r) || r->child)\n> +\t\t\t\tcontinue;\n> +\n> +\t\t\tif ((r->flags & IORESOURCE_TYPE_BITS) !=\n> +\t\t\t (type & IORESOURCE_TYPE_BITS))\n> +\t\t\t\tcontinue;\n\nThis should check if the bridge window is the same or not.\n\nBut it may not be wise to do this for any bridge without any \ndiscrimination.\n\n> +\t\t\tret = pci_dev_res_add_to_list(saved, bridge, r, 0, 0);\n> +\t\t\tif (ret)\n> +\t\t\t\treturn ret;\n> +\n> +\t\t\tpci_release_resource(bridge, i);\n> +\t\t}\n> +\n> \t\tbus = bus->parent;\n> \t}\n> \n>","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=dI3FTkiT;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=2600:3c09:e001:a7::12fc:5321; helo=sto.lore.kernel.org;\n envelope-from=linux-pci+bounces-53144-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"dI3FTkiT\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=198.175.65.10","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from sto.lore.kernel.org (sto.lore.kernel.org\n [IPv6:2600:3c09:e001:a7::12fc:5321])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g2GTG47Byz1yDD\n\tfor ; Sat, 25 Apr 2026 01:04:34 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sto.lore.kernel.org (Postfix) with ESMTP id 0CB9B300616D\n\tfor ; Fri, 24 Apr 2026 15:04:31 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 7214F283CBF;\n\tFri, 24 Apr 2026 15:04:28 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [198.175.65.10])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C081282F3F\n\tfor ; Fri, 24 Apr 2026 15:04:25 +0000 (UTC)","from fmviesa007.fm.intel.com ([10.60.135.147])\n by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 24 Apr 2026 08:04:26 -0700","from ijarvine-mobl1.ger.corp.intel.com (HELO localhost)\n ([10.245.245.120])\n by fmviesa007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 24 Apr 2026 08:04:23 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777043068; cv=none;\n b=UjMVZslpFTVTYqDPzUGyOZB0SVzQiJTzbfnKV52zCZafqURzt8SmZtijCS6RlME7+RAc+htn6KmZXI4aTcmKPgL6J2qBd5uu9rn6HQa8JaW7P1cYwMKDWGzgin3qK/r/sWsCTrDM+LTjmpUz6DZWotQK/3wl4TZugG6YA69XKwY=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777043068; c=relaxed/simple;\n\tbh=1lbVp4nw/QPjFwcNSunCqFJAvHfz2Q2S4JYVL49zZBA=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=cfcIOib55hVIeO6f7wusfEu6jG2lY0xAyg8Xazepv3FE/62vsu6J7RY6RWPpxB3g4ZDBZ0GiF+LoV1cVSc2JEerObyHLud7RQJ+qS15/ufZe+jOA0rFDHkmZO+WSA04ScoAW8EuU7qC/xX03AJCHGqbJcVI5q/qlEtuEvGFXOmo=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=dI3FTkiT; arc=none smtp.client-ip=198.175.65.10","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1777043066; x=1808579066;\n h=from:date:to:cc:subject:in-reply-to:message-id:\n references:mime-version;\n bh=1lbVp4nw/QPjFwcNSunCqFJAvHfz2Q2S4JYVL49zZBA=;\n b=dI3FTkiTEkhh2ZLmUAFA+vbgWVa0ZAU3ocwkG04m6QdhVTS+/tRc+pZP\n jiY1iXS5PC9m6S8jdrhzenzxYqyVarYYUBCS+TbD9VGUS03nqAzvtsIPh\n 79gKg3EjkYNnVwKPV3zTBGG8EqCQAw5n5QwwdMzubtq1PpxLGhAVyn8iQ\n b9HyamtTlFo9fIUZvmu6zLkPjirVOQzId6iLhkQyetXaAhxf1oe86djOy\n BL7c3fkFkzIFg2VQAK5Qm7lGrGGEAuFuEpouOPzieP20QZglYCPJBx8W7\n Yra5r9cZr0+zZYz84bzwYUtPTyGDjAfI8Y+xdRbmS/8+SmDfx7F6KJPqv\n w==;","X-CSE-ConnectionGUID":["LkSD6UjtSV+4Nh8yVs4hKw==","dT6pl3rkS0y34TB9ihqQxQ=="],"X-CSE-MsgGUID":["AvxuHbrZSGKPSYs3BgApog==","guOF/7lGTLSWqGrhKFPeNw=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11766\"; a=\"95437048\"","E=Sophos;i=\"6.23,196,1770624000\";\n d=\"scan'208\";a=\"95437048\"","E=Sophos;i=\"6.23,196,1770624000\";\n d=\"scan'208\";a=\"229775204\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ","Date":"Fri, 24 Apr 2026 18:04:19 +0300 (EEST)","To":"Maarten Lankhorst ","cc":"linux-pci@vger.kernel.org, Bjorn Helgaas ,\n \"intel-xe@lists.freedesktop.org\" ","Subject":"Re: [PATCH] PCI: Fix resizable bar fails due to bridge memory\n region","In-Reply-To":"<7f673ce8-fa00-47aa-a50f-812ae5073279@lankhorst.se>","Message-ID":"","References":"<7f673ce8-fa00-47aa-a50f-812ae5073279@lankhorst.se>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII"}},{"id":3682091,"web_url":"http://patchwork.ozlabs.org/comment/3682091/","msgid":"<92850c9a-808e-47b9-ae5f-fa10c4bda3ce@lankhorst.se>","list_archive_url":null,"date":"2026-04-24T16:03:07","subject":"Re: [PATCH] PCI: Fix resizable bar fails due to bridge memory region","submitter":{"id":93251,"url":"http://patchwork.ozlabs.org/api/people/93251/","name":"Maarten Lankhorst","email":"dev@lankhorst.se"},"content":"Hey,\n\nDen 2026-04-24 kl. 17:04, skrev Ilpo Järvinen:\n> On Fri, 24 Apr 2026, Maarten Lankhorst wrote:\n> \n>> I encountered a problem that I have on my system, where I cannot resize\n>> the bar because one of the bridges has a \n> \n> You're missing words from here. But I can guess you've that extra BAR on \n> in-card the bridge.\n> \n>> If I take a look at the topology, the GPU shares the memory region with a bridge,\n>>\n>> +-[0000:64]-+-00.0-[65-68]----00.0-[66-68]--+-01.0-[67]----00.0\n>>\n>> The specific bridge likely causing a failure is:\n>>\n>> 65:00.0 PCI bridge: Intel Corporation Device e2ff (rev 01) (prog-if 00 [Normal decode])\n>> Flags: bus master, fast devsel, latency 0, IRQ 32, IOMMU group 1\n>> Memory at 382400000000 (64-bit, prefetchable) [size=8M]\n>> ....\n>>\n>> Which causes upstream bridge 64:00.0 initially to allocate the region\n>> [38fe0000000-38ff0000000) for the GPU, and [382ff0000000..382ff07fffff]\n>> for the bridge device.\n>>\n>> Bridge 64 is big enough for 1 BMG with a 32 GB bar and the second 8 MB allocation:\n>> pci_bus 0000:64: resource 9 [mem 0x382000000000-0x382fffffffff window] (64GB window)\n>>\n>> The reason for failure is that bridge 65 has a 8 MB memory region assigned,\n> \n>> and previously it was ignored when reallocating.\n> \n> What does this mean? I don't think it was ever ignored while \n> reallocating??\n> \n> Note that kernel has become much more verbose in explaining why things \n> fail so perhaps the added message is confusing you (they won't appear in \n> the old kernels).\n> \n>> Failing case:\n>> xe 0000:67:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB\n>> xe 0000:67:00.0: BAR 2 [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n>> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n>> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n>> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]: was not released (still contains assigned resources)\n>> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n>> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n>> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n>> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n>> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n>> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n>> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n>> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n>> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space\n>> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign\n>> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space\n>> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign\n>> pcieport 0000:64:00.0: PCI bridge to [bus 65-68]\n>> pcieport 0000:64:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n>> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]\n>> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n>> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n>> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]\n>> pcieport 0000:66:01.0: PCI bridge to [bus 67]\n>> pcieport 0000:66:01.0: bridge window [mem 0xd7000000-0xd81fffff]\n>> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]\n>>\n>> Working with the patch below:\n>> xe 0000:67:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB\n>> xe 0000:67:00.0: BAR 2 [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n>> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n>> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n>> pcieport 0000:65:00.0: BAR 0 [mem 0x382ff0000000-0x382ff07fffff 64bit pref]: releasing\n>> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]: releasing\n>> pcieport 0000:64:00.0: bridge window [mem 0x382000000000-0x3824007fffff 64bit pref]: assigned\n>> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n>> pcieport 0000:65:00.0: BAR 0 [mem 0x382400000000-0x3824007fffff 64bit pref]: assigned\n>> pcieport 0000:66:01.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n>> xe 0000:67:00.0: BAR 2 [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n>> pcieport 0000:64:00.0: PCI bridge to [bus 65-68]\n>> pcieport 0000:64:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n>> pcieport 0000:64:00.0: bridge window [mem 0x382000000000-0x3824007fffff 64bit pref]\n>> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n>> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n>> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n>> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n>> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n>> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n>> pcieport 0000:66:01.0: PCI bridge to [bus 67]\n>> pcieport 0000:66:01.0: bridge window [mem 0xd7000000-0xd81fffff]\n>> pcieport 0000:66:01.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n>> xe 0000:67:00.0: [drm] BAR2 resized to 16384MiB\n>>\n>>\n>> Signed-off-by: Maarten Lankhorst \n>> ---\n>> I'm not 100% this is the correct fix, I don't know why the bridge itself has\n>> a memory region, why the kernel allocates it and when it's supposed to\n>> be used. Not a PCI expert. :-)\n> \n> I don't know why it is there either. Nothing in the portdrv really uses it \n> for anything. There is patchset somewhere lying around which adds a quirk \n> that releases the \"extra\" BAR.\n\nThank you, I've taken a look at that patch series. It looks like patch 1/2\nwould help a lot.\n\nI'm wondering if it will completely fix the issue, it is still possible\nthat in the same config I have 2 identical cards, where resizing might\nwork, but when GPU1's VRAM BAR is already bound, it might be unable\nto resize GPU2's VRAM BAR for the same reason as this patch.\n\nWhat would be the best way to handle this case?\n\nKind regards,\n~Maarten Lankhorst","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=lankhorst.se header.i=@lankhorst.se header.a=rsa-sha256\n header.s=default header.b=CH9UZO0X;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-53146-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=lankhorst.se header.i=@lankhorst.se\n header.b=\"CH9UZO0X\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=141.105.120.124","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=lankhorst.se","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=lankhorst.se"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g2HnL5xDlz1yDD\n\tfor ; Sat, 25 Apr 2026 02:03:34 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id 41577300A630\n\tfor ; Fri, 24 Apr 2026 16:03:13 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 69AB1363086;\n\tFri, 24 Apr 2026 16:03:12 +0000 (UTC)","from lankhorst.se (unknown [141.105.120.124])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A37F3385B6\n\tfor ; Fri, 24 Apr 2026 16:03:10 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777046592; cv=none;\n b=st5SsxTJ/JpMXKium6drHxnCuJ2IsIlbXel5BQ6a6vCf4o+KexSqFZXo8tpXIBIgKUBpDRjrxVjn74xflUAHzJQoMNAU+5lStZg+po1NPfpGwEP0cLBKrNdt4zI1u7dUfjlAXz7sAhaLzh7PTQoh2N4RISzonkR2IZThKHqT2qA=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777046592; c=relaxed/simple;\n\tbh=74wcFbX31LLTacwW895+s9BGxUexxeBqrZLsskclhjI=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=rlGVAM7w9F5UbKmi1CRUZqlMXy3WSv/X80DhFFHhmlRNxlGOPt+iBgzsH3xDjET66uh25t1v5TaCQJln7VNohJTP6Rn3n5YE0NJbISbyxVHkeO10hO/uAi9yhtFb8yW3gQTefbuSB7GU+fZ5zbVW9PWqa+PSRgiJqxjZOysJ7fM=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=lankhorst.se;\n spf=pass smtp.mailfrom=lankhorst.se;\n dkim=pass (2048-bit key) header.d=lankhorst.se header.i=@lankhorst.se\n header.b=CH9UZO0X; arc=none smtp.client-ip=141.105.120.124","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=lankhorst.se;\n\ts=default; t=1777046588;\n\tbh=74wcFbX31LLTacwW895+s9BGxUexxeBqrZLsskclhjI=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=CH9UZO0X1+XHI59fG6jZ5leDMZbWLvQzKekAPJKLC7wrhPA8HoYb4ZUOBW9052Bg6\n\t K8vv+A6IeuEg19lZW6QPj/U9cas++lt0UICZH1Quou12GNent9c6dSWFShXfglT3SL\n\t ru09AvlhnUewhEZpeaBBInfF4zmGmfx39puux2rEs6tpS6tkwn2vWwuZaEfTz6fS9l\n\t h5yg7/8Bap/rzmAwcEGcG+Kqi5iHXogNeg0dyCiLAggrg+ygMX/IMolK8NTYpy7Jiu\n\t DNyCuWuoe6mZG9/oH93rB5iujvildeyvJLHNZ5Z3ZeXzFXawcUFkaFO7SwBjBbYND/\n\t 6564Tx5xXr9Jg==","Message-ID":"<92850c9a-808e-47b9-ae5f-fa10c4bda3ce@lankhorst.se>","Date":"Fri, 24 Apr 2026 18:03:07 +0200","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH] PCI: Fix resizable bar fails due to bridge memory region","To":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ","Cc":"linux-pci@vger.kernel.org, Bjorn Helgaas ,\n \"intel-xe@lists.freedesktop.org\" ","References":"<7f673ce8-fa00-47aa-a50f-812ae5073279@lankhorst.se>\n ","Content-Language":"en-US","From":"Maarten Lankhorst ","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit"}},{"id":3682158,"web_url":"http://patchwork.ozlabs.org/comment/3682158/","msgid":"<990a7758-46eb-3fc8-2714-a2b117720241@linux.intel.com>","list_archive_url":null,"date":"2026-04-24T17:42:48","subject":"Re: [PATCH] PCI: Fix resizable bar fails due to bridge memory\n region","submitter":{"id":83553,"url":"http://patchwork.ozlabs.org/api/people/83553/","name":"Ilpo Järvinen","email":"ilpo.jarvinen@linux.intel.com"},"content":"On Fri, 24 Apr 2026, Maarten Lankhorst wrote:\n> Den 2026-04-24 kl. 17:04, skrev Ilpo Järvinen:\n> > On Fri, 24 Apr 2026, Maarten Lankhorst wrote:\n> > \n> >> I encountered a problem that I have on my system, where I cannot resize\n> >> the bar because one of the bridges has a \n> > \n> > You're missing words from here. But I can guess you've that extra BAR on \n> > in-card the bridge.\n> > \n> >> If I take a look at the topology, the GPU shares the memory region with a bridge,\n> >>\n> >> +-[0000:64]-+-00.0-[65-68]----00.0-[66-68]--+-01.0-[67]----00.0\n> >>\n> >> The specific bridge likely causing a failure is:\n> >>\n> >> 65:00.0 PCI bridge: Intel Corporation Device e2ff (rev 01) (prog-if 00 [Normal decode])\n> >> Flags: bus master, fast devsel, latency 0, IRQ 32, IOMMU group 1\n> >> Memory at 382400000000 (64-bit, prefetchable) [size=8M]\n> >> ....\n> >>\n> >> Which causes upstream bridge 64:00.0 initially to allocate the region\n> >> [38fe0000000-38ff0000000) for the GPU, and [382ff0000000..382ff07fffff]\n> >> for the bridge device.\n> >>\n> >> Bridge 64 is big enough for 1 BMG with a 32 GB bar and the second 8 MB allocation:\n> >> pci_bus 0000:64: resource 9 [mem 0x382000000000-0x382fffffffff window] (64GB window)\n> >>\n> >> The reason for failure is that bridge 65 has a 8 MB memory region assigned,\n> > \n> >> and previously it was ignored when reallocating.\n> > \n> > What does this mean? I don't think it was ever ignored while \n> > reallocating??\n> > \n> > Note that kernel has become much more verbose in explaining why things \n> > fail so perhaps the added message is confusing you (they won't appear in \n> > the old kernels).\n> > \n> >> Failing case:\n> >> xe 0000:67:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB\n> >> xe 0000:67:00.0: BAR 2 [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> >> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> >> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> >> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]: was not released (still contains assigned resources)\n> >> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> >> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> >> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> >> pcieport 0000:65:00.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> >> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> >> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> >> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: can't assign; no space\n> >> pcieport 0000:66:01.0: bridge window [mem size 0x400000000 64bit pref]: failed to assign\n> >> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space\n> >> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign\n> >> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: can't assign; no space\n> >> xe 0000:67:00.0: BAR 2 [mem size 0x400000000 64bit pref]: failed to assign\n> >> pcieport 0000:64:00.0: PCI bridge to [bus 65-68]\n> >> pcieport 0000:64:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> >> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]\n> >> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n> >> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> >> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]\n> >> pcieport 0000:66:01.0: PCI bridge to [bus 67]\n> >> pcieport 0000:66:01.0: bridge window [mem 0xd7000000-0xd81fffff]\n> >> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]\n> >>\n> >> Working with the patch below:\n> >> xe 0000:67:00.0: [drm] Attempting to resize bar from 256MiB -> 16384MiB\n> >> xe 0000:67:00.0: BAR 2 [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> >> pcieport 0000:66:01.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> >> pcieport 0000:65:00.0: bridge window [mem 0x382fe0000000-0x382fefffffff 64bit pref]: releasing\n> >> pcieport 0000:65:00.0: BAR 0 [mem 0x382ff0000000-0x382ff07fffff 64bit pref]: releasing\n> >> pcieport 0000:64:00.0: bridge window [mem 0x382fe0000000-0x382ff07fffff 64bit pref]: releasing\n> >> pcieport 0000:64:00.0: bridge window [mem 0x382000000000-0x3824007fffff 64bit pref]: assigned\n> >> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n> >> pcieport 0000:65:00.0: BAR 0 [mem 0x382400000000-0x3824007fffff 64bit pref]: assigned\n> >> pcieport 0000:66:01.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n> >> xe 0000:67:00.0: BAR 2 [mem 0x382000000000-0x3823ffffffff 64bit pref]: assigned\n> >> pcieport 0000:64:00.0: PCI bridge to [bus 65-68]\n> >> pcieport 0000:64:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> >> pcieport 0000:64:00.0: bridge window [mem 0x382000000000-0x3824007fffff 64bit pref]\n> >> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n> >> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> >> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n> >> pcieport 0000:65:00.0: PCI bridge to [bus 66-68]\n> >> pcieport 0000:65:00.0: bridge window [mem 0xd7000000-0xd83fffff]\n> >> pcieport 0000:65:00.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n> >> pcieport 0000:66:01.0: PCI bridge to [bus 67]\n> >> pcieport 0000:66:01.0: bridge window [mem 0xd7000000-0xd81fffff]\n> >> pcieport 0000:66:01.0: bridge window [mem 0x382000000000-0x3823ffffffff 64bit pref]\n> >> xe 0000:67:00.0: [drm] BAR2 resized to 16384MiB\n> >>\n> >>\n> >> Signed-off-by: Maarten Lankhorst \n> >> ---\n> >> I'm not 100% this is the correct fix, I don't know why the bridge itself has\n> >> a memory region, why the kernel allocates it and when it's supposed to\n> >> be used. Not a PCI expert. :-)\n> > \n> > I don't know why it is there either. Nothing in the portdrv really uses it \n> > for anything. There is patchset somewhere lying around which adds a quirk \n> > that releases the \"extra\" BAR.\n> \n> Thank you, I've taken a look at that patch series. It looks like patch 1/2\n> would help a lot.\n\nI should one day find time to finish that series, Bjorn didn't like how \nthe code didn't \"disable\" BAR.\n\nI did some (unset) work towards placing the BARs outside the bridge \nwindow but my algorithm was quite basic (just found min & max window\naddresses and put BAR outside of that range but then I thought maybe I \nshould add the possiblity for placing the BAR into the gap in the middle to\nallow placement of a large BAR in cases where 32-bit mmio blocks low-end + \n64-bit mmio range blocking the top of the address space.\n\n> I'm wondering if it will completely fix the issue, it is still possible\n> that in the same config I have 2 identical cards, where resizing might\n> work, but when GPU1's VRAM BAR is already bound, it might be unable\n> to resize GPU2's VRAM BAR for the same reason as this patch.\n\nIt is always possible to find cases where a sibling pins the shared bridge \nwindow in place.\n\n> What would be the best way to handle this case?\n\nThe best way is to size them into the largest possible sizes right from \nthe beginning. But when doing that, nothing must break (introducing \nregressions is not okay) so it kernel must be able to graciously fallback \nto smaller sizes when there isn't enough space available for the largest \nsize.\n\nWhat makes it complicated is that sizing and assignment are done very much \nseparately, so retrying with a smaller size is complicated. I'm working \ntoward this kind of solution but there are various things that have to be \nfixed first.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linux-pci@vger.kernel.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256\n header.s=Intel header.b=RDM06/2r;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org\n (client-ip=172.234.253.10; helo=sea.lore.kernel.org;\n envelope-from=linux-pci+bounces-53154-incoming=patchwork.ozlabs.org@vger.kernel.org;\n receiver=patchwork.ozlabs.org)","smtp.subspace.kernel.org;\n\tdkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=\"RDM06/2r\"","smtp.subspace.kernel.org;\n arc=none smtp.client-ip=192.198.163.13","smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com","smtp.subspace.kernel.org;\n spf=pass smtp.mailfrom=linux.intel.com"],"Received":["from sea.lore.kernel.org (sea.lore.kernel.org [172.234.253.10])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1) server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g2L1t31NRz1y2d\n\tfor ; Sat, 25 Apr 2026 03:44:34 +1000 (AEST)","from smtp.subspace.kernel.org (conduit.subspace.kernel.org\n [100.90.174.1])\n\tby sea.lore.kernel.org (Postfix) with ESMTP id CA707301E6C9\n\tfor ; Fri, 24 Apr 2026 17:43:00 +0000 (UTC)","from localhost.localdomain (localhost.localdomain [127.0.0.1])\n\tby smtp.subspace.kernel.org (Postfix) with ESMTP id 2FEC61D5AD4;\n\tFri, 24 Apr 2026 17:43:00 +0000 (UTC)","from mgamail.intel.com (mgamail.intel.com [192.198.163.13])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby smtp.subspace.kernel.org (Postfix) with ESMTPS id 069883624CE\n\tfor ; Fri, 24 Apr 2026 17:42:57 +0000 (UTC)","from orviesa007.jf.intel.com ([10.64.159.147])\n by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 24 Apr 2026 10:42:57 -0700","from ijarvine-mobl1.ger.corp.intel.com (HELO localhost)\n ([10.245.245.120])\n by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384;\n 24 Apr 2026 10:42:53 -0700"],"ARC-Seal":"i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;\n\tt=1777052580; cv=none;\n b=XEDE5GDk6DenhHdFDBM15sjDW1hgcdNsnLySAZwJ1Hk1KvuY7u666xtv7F8y8qA3m3psX8ZDbnXP+eGz+zTBad3tPQsOqlCyIGH/SzwLaGE8TjYRl1u3ZtCm52OfwdsplPYr7a55X2ev3+dLeb74zZEf4ijN6KffvgcDBWnwKoM=","ARC-Message-Signature":"i=1; a=rsa-sha256; d=subspace.kernel.org;\n\ts=arc-20240116; t=1777052580; c=relaxed/simple;\n\tbh=ie4CDtYFrQRyD464W2OX/4dxxPPunGjCi3qEovTZ4jQ=;\n\th=From:Date:To:cc:Subject:In-Reply-To:Message-ID:References:\n\t MIME-Version:Content-Type;\n b=ubOhFxkB0LfYEMjhxQ5iyTgipUXyqPa5dUB5ltY0nDRYrRanZcgEiGjL0CldBKsDTAynX7ZhF4nqqc2n/vS3cptAenqxXL5ejGExswEQrJAT40mc9AoWOkDMp3/R7JJV4UlQ0/edOr82cD6eUNco4xeAjxf18NxBZkrNpqrdyEg=","ARC-Authentication-Results":"i=1; smtp.subspace.kernel.org;\n dmarc=pass (p=none dis=none) header.from=linux.intel.com;\n spf=pass smtp.mailfrom=linux.intel.com;\n dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com\n header.b=RDM06/2r; arc=none smtp.client-ip=192.198.163.13","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple;\n d=intel.com; i=@intel.com; q=dns/txt; s=Intel;\n t=1777052578; x=1808588578;\n h=from:date:to:cc:subject:in-reply-to:message-id:\n references:mime-version;\n bh=ie4CDtYFrQRyD464W2OX/4dxxPPunGjCi3qEovTZ4jQ=;\n b=RDM06/2rdGVlWsRZM51FCMkOb5nI5ewbSUFesQrl6j2lGQmfURFH/KmJ\n r+pC8KdoLctb3OMDbEKevUsG1QG7ZR1RZIy0voXPATEcrsuj+lYrL+RrQ\n f5LXH7/VRbphyRyuw6JOvI2G8pI7bX138TrTq+ITIKVkh/gW4QhIya9ZD\n y5eWN0bHpHhbjJ1KxhPwrsNPtpYLPbKDDrRmxjlODsufygxHeTG1Tduoq\n JwTjGLJ1C1yPhOlgXdGo5inxFaK8Ox7m7rrYV7hsbwbVyq4MrlrhXiY/V\n +nB9/heGKqL2DaKKXkw/FaPNI1c7ukgFn1PjmLlpYvby0nr3aaXIAVkFX\n A==;","X-CSE-ConnectionGUID":["vTZ8AwI+QT2Pya1L2BQflA==","g1/LdeG0QjeSSjdwDQW49g=="],"X-CSE-MsgGUID":["CbMe6SXlSL2z21Icgu7RFQ==","UTG05WiiRnCYoygpNdHrcQ=="],"X-IronPort-AV":["E=McAfee;i=\"6800,10657,11766\"; a=\"80620183\"","E=Sophos;i=\"6.23,197,1770624000\";\n d=\"scan'208\";a=\"80620183\"","E=Sophos;i=\"6.23,197,1770624000\";\n d=\"scan'208\";a=\"233307013\""],"X-ExtLoop1":"1","From":"=?utf-8?q?Ilpo_J=C3=A4rvinen?= ","Date":"Fri, 24 Apr 2026 20:42:48 +0300 (EEST)","To":"Maarten Lankhorst ","cc":"linux-pci@vger.kernel.org, Bjorn Helgaas ,\n \"intel-xe@lists.freedesktop.org\" ","Subject":"Re: [PATCH] PCI: Fix resizable bar fails due to bridge memory\n region","In-Reply-To":"<92850c9a-808e-47b9-ae5f-fa10c4bda3ce@lankhorst.se>","Message-ID":"<990a7758-46eb-3fc8-2714-a2b117720241@linux.intel.com>","References":"<7f673ce8-fa00-47aa-a50f-812ae5073279@lankhorst.se>\n \n <92850c9a-808e-47b9-ae5f-fa10c4bda3ce@lankhorst.se>","Precedence":"bulk","X-Mailing-List":"linux-pci@vger.kernel.org","List-Id":"","List-Subscribe":"","List-Unsubscribe":"","MIME-Version":"1.0","Content-Type":"multipart/mixed; boundary=\"8323328-1684128750-1777052568=:958\""}}]