[Intel-gfx] [PATCH 2/2] drm/i915: Function per early graphics quirk

[Joonas Lahtinen]

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 at chris-wilson.co.uk>
> > Cc: Mika Kuoppala <mika.kuoppala at intel.com>
> > Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com>
> > Signed-off-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> Mechanical again, and less quirky,
> Reserved-by: Chris Wilson <chris at chris-wilson.co.uk>

A new type of R-b? :)

> 
> > 
> > -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.

Regards, Joonas

> -Chris
> 
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation