On Fri, Jan 31, 2020 at 04:59:44PM +0000, Sergei Miroshnichenko wrote:
> On Thu, 2020-01-30 at 15:26 -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 29, 2020 at 06:29:20PM +0300, Sergei Miroshnichenko
> > wrote:
> > > When movable BARs are enabled, and if a bridge contains a device
> > > with fixed
> > > (IORESOURCE_PCI_FIXED) or immovable BARs, the corresponding windows
> > > can't
> >
> > What is the difference between fixed (IORESOURCE_PCI_FIXED) and
> > immovable BARs? I'm hesitant to add a new concept ("immovable") with
> > a different name but very similar meaning.
> >
> > I understand that in the case of bridge windows, you may need to
> > track
> > only part of the window, as opposed to a BAR where the entire BAR has
> > to be either fixed or movable, but I think adding a new term will be
> > confusing.
>
> I thought the term "fixed BAR" has some legacy scent, and those marked
> with flag IORESOURCE_PCI_FIXED are fixed forever. But a BAR may become
> movable after rmmod-ing its driver that didn't support movable BARs.
>
> Still, the IORESOURCE_PCI_FIXED is used just a few times in the kernel,
> so the "fixed BAR" term is probably not so well-established, so I don't
> mind referring all non-movables as "fixed": both marked with the flag
> and not. Will change all of them in v8.
Yeah, "fixed" is a relatively new idea and not part of the actual
spec. And you're right that "immovable" is slightly different because
sometimes it's a consequence of lack of driver support.
This probably isn't a big deal either way. I think there are two
cases: (a) IORESOURCE_PCI_FIXED resources (i.e., legacy things that
can't be changed because they don't have BARs) and (b) BARs that can't
be changed because there's a driver bound that doesn't support moving
them. Either way, we have to treat them the same for resource
allocation, so I'm not sure it's worth differentiating at this level.
Bjorn
