Re: [PATCH 2/2] drm/i915: Function per early graphics quirk

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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? :)

> 
> > 
> > -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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux