On Fri, Apr 22, 2016 at 03:07:42PM +0300, Joonas Lahtinen wrote:
> On pe, 2016-04-22 at 12:55 +0100, Chris Wilson wrote:
> > On Fri, Apr 22, 2016 at 02:25:07PM +0300, Joonas Lahtinen wrote:
> > >
> > > Move graphics stolen memory related early quirk into a function to
> > > allow easy adding of other graphics quirks to fix memory maps on
> > > machines running old BIOS versions.
> > >
> > > While at it;
> > > - _funcs -> _ops to follow de facto naming
> > > - make the iteration code tad more readable
> > > - remove unused variables
> > >
> > > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxx>
> > > Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx>
> > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx>
> > > Signed-off-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
> > Mechanical again, and less quirky,
> > Reserved-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
>
> A new type of R-b? :)
I'm tired. :|
> > > -static void __init intel_graphics_stolen(int num, int slot, int func)
> > > +static void __init
> > > +intel_graphics_stolen(int num, int slot, int func,
> > > + const struct intel_early_ops *early_ops)
> > > {
> > > + phys_addr_t base;
> > > size_t size;
> > > +
> > > + size = early_ops->stolen_size(num, slot, func);
> > > + base = early_ops->stolen_base(num, slot, func, size);
> > > +
> > > + if (!size || !base)
> > > + return;
> > if (size + base < base)
> > return;
> >
> > Just in case? Hmm, not sure if the integer sizes will always be suitable
> > for the test, so probably just trust the hardware registers?
>
> (This was actually the test used by earlier version of code too.
> Intention was to not change the resulting logic that much. So I'd add
> this check as a follow-up.)
>
> I don't see how this could happen, the original hardware registers are
> unlikely to cause an overflow of the phys_addr_t. If we want to add a
> check, we should rather test against e820_end_of_ram_pfn() or so.
It can't happen. But I know better than to trust a BIOS or our own
interpretation of the guides. From off the top of my head, stolen will
always be below 4G, and doing a sanity check that it is may or may not
be worth the infuriation if it ever moves above 4G.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
