On Mon, Jan 13, 2020 at 06:21:50PM +0200, Mika Westerberg wrote:
> On Wed, Jan 08, 2020 at 01:36:04AM +0000, Nicholas Johnson wrote:
> > > Where's the patch that changes the caller so "new_size" may be smaller
> > > than "size"? I guess it must be "[3/3] PCI: Consider alignment of
> > > hot-added bridges ..." because that's the only one that makes a
> > > non-trivial change, right?
> >
> > As above, there was always a possibility of the new_size being smaller.
> > For some reason, 1M is assigned to bridges, even if nothing is below
> > them (for example, unused non hotplug bridges in a Thunderbolt dock). It
> > may be an edge case if we are low on space, but theoretically it can
> > happen.
> >
> > Also, when writing this, Mika was not interested in using hpmemsize,
> > which, when used, will cause new_size to be smaller than the current
> > size (actual size and add_size combined).
>
> Just a small correction here about my motivation. So I'm testing on a
> hardware where the BIOS assigns initial resources to the root/downstream
> ports which is the majority of Thunderbolt capable PC systems nowadays.
> Therefore the user does not need to pass any additional command line
> parameters to get the ports working properly.
>
> However, I'm of course interested in getting Linux PCI resource
> management as good as possible regardless whether the firmware/BIOS
> assigns them or not ;-)
Sorry, I was not meant to say you were not interested in getting it as
good as possible. At the time, you had a goal to achieve (which you did)
and at that point in time, it would not have been feasible to use
pci=hpmemsize or similar before my patches were applied:
c13704f5685d ("PCI: Avoid double hpmemsize MMIO window assignment")
d7b8a217521c ("PCI: Add "pci=hpmmiosize" and "pci=hpmmioprefsize" parameters")
What I was trying to say was not that you were not interested, but more
that it was not a primary motivation for you at the time. Does this
sound more accurate? Poor wording on my behalf.
