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].

[1] https://lore.kernel.org/linux-pci/ZXpaNCLiDM+Kv38H@marvin.atrad.com.au/

Ilpo Järvinen (7):
  PCI: Fix resource double counting on remove & rescan
  resource: Rename find_resource() to find_empty_resource_slot()
  resource: Document find_empty_resource_slot() and resource_constraint
  resource: Use typedef for alignf callback
  resource: Handle simple alignment inside __find_empty_resource_slot()
  resource: Export find_empty_resource_slot()
  PCI: Relax bridge window tail sizing rules

 drivers/pci/bus.c       | 10 +----
 drivers/pci/setup-bus.c | 81 ++++++++++++++++++++++++++++++++++++++---
 include/linux/ioport.h  | 44 ++++++++++++++++++++--
 include/linux/pci.h     |  5 +--
 kernel/resource.c       | 69 ++++++++++++++++-------------------
 5 files changed, 150 insertions(+), 59 deletions(-)

-- 
2.30.2

On Fri, 22 Dec 2023, 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.

Hi Bjorn,

Can you consider applying this series or do you have some comments on it?

I'm a bit unsure these days if my emails even reach you successfully as I 
tend to often receive complaints from Gmail that it has blocked the emails 
I send with git send-email detecting them as "unsolicited mail".

-- 
 i.


> Unfortunately I don't have a reason to suspect these would help with
> the issues related to the currently ongoing resource regression
> thread [1].
> 
> [1] https://lore.kernel.org/linux-pci/ZXpaNCLiDM+Kv38H@marvin.atrad.com.au/
> 
> Ilpo Järvinen (7):
>   PCI: Fix resource double counting on remove & rescan
>   resource: Rename find_resource() to find_empty_resource_slot()
>   resource: Document find_empty_resource_slot() and resource_constraint
>   resource: Use typedef for alignf callback
>   resource: Handle simple alignment inside __find_empty_resource_slot()
>   resource: Export find_empty_resource_slot()
>   PCI: Relax bridge window tail sizing rules

On Tue, Mar 05, 2024 at 05:37:49PM +0200, Ilpo Järvinen wrote:
> On Fri, 22 Dec 2023, 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.
> 
> Hi Bjorn,
> 
> Can you consider applying this series or do you have some comments on it?
> 
> I'm a bit unsure these days if my emails even reach you successfully as I 
> tend to often receive complaints from Gmail that it has blocked the emails 
> I send with git send-email detecting them as "unsolicited mail".

Sorry, I'm pretty sure I receive your emails since I read via lei and
if it appears on lore with linux-pci or me in the to/cc, I should see
it.  Just a little overwhelmed and struggling to prioritize and
respond.  But thanks for the ping; I will take a look.

Bjorn