From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from server.atrad.com.au (server.atrad.com.au [150.101.241.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 99AA921373; Thu, 4 Jan 2024 12:24:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=just42.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=just42.net Received: from marvin.atrad.com.au (marvin.atrad.com.au [192.168.0.2]) by server.atrad.com.au (8.17.2/8.17.2) with ESMTPS id 404CIq6K028017 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 4 Jan 2024 22:48:53 +1030 Date: Thu, 4 Jan 2024 22:48:52 +1030 From: Jonathan Woithe To: Igor Mammedov Cc: Ilpo =?iso-8859-1?Q?J=E4rvinen?= , linux-pci@vger.kernel.org, Bjorn Helgaas , Lorenzo Pieralisi , Rob Herring , Krzysztof =?utf-8?Q?Wilczy=C5=84ski?= , Lukas Wunner , Mika Westerberg , Andy Shevchenko , "Rafael J . Wysocki" , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/7] PCI: Solve two bridge window sizing issues Message-ID: References: <20231228165707.3447-1-ilpo.jarvinen@linux.intel.com> <20240104131210.71f44d4b@imammedo.users.ipa.redhat.com> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20240104131210.71f44d4b@imammedo.users.ipa.redhat.com> X-MIMEDefang-action: accept X-Scanned-By: MIMEDefang 2.86 on 192.168.0.1 On Thu, Jan 04, 2024 at 01:12:10PM +0100, Igor Mammedov wrote: > On Thu, 28 Dec 2023 18:57:00 +0200 > Ilpo Järvinen wrote: > > > Hi all, > > > > Here's a series that contains two fixes to PCI bridge window sizing > > algorithm. Together, they should enable remove & rescan cycle to work > > for a PCI bus that has PCI devices with optional resources and/or > > disparity in BAR sizes. > > > > For the second fix, I chose to expose find_empty_resource_slot() from > > kernel/resource.c because it should increase accuracy of the cannot-fit > > decision (currently that function is called find_resource()). In order > > to do that sensibly, a few improvements seemed in order to make its > > interface and name of the function sane before exposing it. Thus, the > > few extra patches on resource side. > > > > Unfortunately I don't have a reason to suspect these would help with > > the issues related to the currently ongoing resource regression > > thread [1]. > > Jonathan, > can you test this series on affected machine with broken kernel to see if > it's of any help in your case? Certainly, but it will have to wait until next Thursday (11 Jan 2024). I'm still on leave this week, and when at work I only have physical access to the machine concerned on Thursdays at present. Which kernel would you prefer I apply the series to? Regards jonathan