On Mon, 26 Jan 2026, Bjorn Helgaas wrote:

> On Fri, Dec 19, 2025 at 07:40:15PM +0200, Ilpo Järvinen wrote:
> > The calculation of bridge window head alignment is done by
> > calculate_mem_align() [*]. With the default bridge window alignment, it
> > is used for both head and tail alignment.
> > 
> > The selected head alignment does not always result in tight-fitting
> > resources (gap at d4f00000-d4ffffff):
> > 
> >     d4800000-dbffffff : PCI Bus 0000:06
> >       d4800000-d48fffff : PCI Bus 0000:07
> >         d4800000-d4803fff : 0000:07:00.0
> >           d4800000-d4803fff : nvme
> >       d4900000-d49fffff : PCI Bus 0000:0a
> >         d4900000-d490ffff : 0000:0a:00.0
> >           d4900000-d490ffff : r8169
> >         d4910000-d4913fff : 0000:0a:00.0
> >       d4a00000-d4cfffff : PCI Bus 0000:0b
> >         d4a00000-d4bfffff : 0000:0b:00.0
> >           d4a00000-d4bfffff : 0000:0b:00.0
> >         d4c00000-d4c07fff : 0000:0b:00.0
> >       d4d00000-d4dfffff : PCI Bus 0000:15
> >         d4d00000-d4d07fff : 0000:15:00.0
> >           d4d00000-d4d07fff : xhci-hcd
> >       d4e00000-d4efffff : PCI Bus 0000:16
> >         d4e00000-d4e7ffff : 0000:16:00.0
> >         d4e80000-d4e803ff : 0000:16:00.0
> >           d4e80000-d4e803ff : ahci
> >       d5000000-dbffffff : PCI Bus 0000:0c
> > 
> > This has not been caused problems (for years) with the default bridge
> > window tail alignment that grossly over-estimates the required tail
> > alignment leaving more tail room than necessary. With the introduction
> > of relaxed tail alignment that leaves no extra tail room whatsoever,
> > any gaps will immediately turn into assignment failures.
> > 
> > Introduce head alignment calculation that ensures no gaps are left and
> > apply the new approach when using relaxed alignment. We may want to
> > consider using it for the normal alignment eventually, but as the first
> > step, solve only the problem with the relaxed tail alignment.
> > 
> > ([*] I don't understand the algorithm in calculate_mem_align().)
> > 
> > Fixes: 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]")
> 
> check_commits complains that this SHA1 doesn't exist:
> 
>   In commit
> 
>     a21a27a0e893 ("PCI: Rewrite bridge window head alignment function")
> 
>   Fixes tag
> 
>     Fixes: 5d0a8965aea9 ("[PATCH] 2.5.14: New PCI allocation code (alpha, arm, parisc) [2/2]")
> 
>   has these problem(s):
> 
>     - Target SHA1 does not exist
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5d0a8965aea9
> does find it, but says it's not reachable.
> 
> It's so old (2002) that I'm not sure it's worth including it as a
> Fixes: tag.

Hi,

The commit is in the history repo, and yes, even the git web ui for some 
reason says it's not reachable by any branch:

https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=5d0a8965aea93bd799ebcd671e562d90f3ec2711

...But it's part of a tag for sure:

$ git describe --contains 5d0a8965aea93bd799ebcd671e562d90f3ec2711
v2.5.15~11^2~5^2~10

The composition in the history repo is strange, things don't always appear 
properly linear for some reason there but I've found that commit by going 
backwards with git annotate code-line-shaid^ in a "loop" until I came 
back to commit that introduced it. Maybe this entire lineage of commits is 
headed only by a tag, dunno.

Many things in the resource fitting and assignment algorithm lead back to 
that same commit BTW (and its commit message isn't very helpful in 
explaining why things were made the way they were).

If you don't want to put it into a Fixes tag, could you put that history 
repo URL into a Link tag instead. I do find it relevant where this came 
from.

-- 
 i.