> Sorry, sounds like we're talking about a few different things here:
> 1) devices which sit in e820 reserved space (whether at < 1M or > 1M)
> 2) devices which sit in e820 ram or other space below 1M
> 3) how to hand out space from the 0-1M region
>
> Bjorn's patch fixes (3) so that regular PCI devices don't get space
> there, which makes sense.
>
> Some devices may be in the special region, but were pointed there by
> the BIOS. Generally this should be ok, so drivers requesting this
> space should be allowed to get at it, but we should avoid putting
> anything else there.
>
> And below it sounds like you're talking about (1). If so, then yes I
> guess we need a solution there, which will allow drivers to bind to
> these "reserved" devices, even though the BIOS has marked them as off
> limits, at least as far as e820 goes.
>
> So perhaps both (1) and (2) could be put into a new, special IO
> resource space, or could use a new flag, since "busy" doesn't really
> reflect what's going on there very well, as Bjorn pointed out.
>
> Jesse
Properly done, these aren't separate cases at all.
The E820 interface as specified doesn't reserve the address space below 1
MB, because it is legacy space -- which is another way of saying "everyone
already knows to reserve it." The Right Thing[TM] to do is simply to
modify the data output by E820 to reserve all non-memory space below 1 MB;
this can (and should) be done in platform-specific initialization code to
allow overrides.
Once that is done, both your (2) and (3) cases are nothing but special
subcases of (1). That's what I would like to see as the right solution,
but it is clearly too late to do that in .34.
Bjorn's solution is very attractive for .34 since it is so simple, but
it's not a complete solution.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
