[Intel-gfx] [PATCH 2/2] drm/i915: use size_t instead of u32 for stolen memory size variables

[Joonas Lahtinen]

On Fri, 2017-09-29 at 10:40 +0100, Chris Wilson wrote:
> Quoting Joonas Lahtinen (2017-09-29 10:23:10)
> > On Tue, 2017-09-26 at 21:13 +0100, Chris Wilson wrote:
> > > Quoting Paulo Zanoni (2017-09-26 20:29:08)
> > > > Stolen memory pointers are dma_addr_t, which means they can be 64 bit
> > > > things. By using u32 we leave room for bugs in case we ever get huge
> > > > amounts of stolen memory. By using size_t we don't risk running into
> > > > those problems.
> > > > 
> > > > Cc: Chris Wilson <chris at chris-wilson.co.uk>
> > > > Signed-off-by: Paulo Zanoni <paulo.r.zanoni at intel.com>
> > > > ---
> > > >  drivers/char/agp/intel-gtt.c           | 10 +++++-----
> > > >  drivers/gpu/drm/i915/i915_gem_gtt.c    |  2 +-
> > > >  drivers/gpu/drm/i915/i915_gem_gtt.h    |  6 +++---
> > > >  drivers/gpu/drm/i915/i915_gem_stolen.c | 19 +++++++++----------
> > > >  include/drm/intel-gtt.h                |  2 +-
> > > >  5 files changed, 19 insertions(+), 20 deletions(-)
> > > > 
> > > > diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
> > > > index 9b6b602..a1db230 100644
> > > > --- a/drivers/char/agp/intel-gtt.c
> > > > +++ b/drivers/char/agp/intel-gtt.c
> > > > @@ -80,7 +80,7 @@ static struct _intel_private {
> > > >         unsigned int needs_dmar : 1;
> > > >         phys_addr_t gma_bus_addr;
> > > >         /*  Size of memory reserved for graphics by the BIOS */
> > > > -       unsigned int stolen_size;
> > > > +       size_t stolen_size;
> > > 
> > > What is size_t? How does that correspond to a physical or dma addr?
> > > You either meant kernel_size_t or unsigned long, or a proper type for
> > > the address space.
> > 
> > We're using phys_addr_t + size_t in early-quirks.c too, so we want to
> > keep both places consistent. If we're using something else than size_t,
> > then we should update both places (it's still on my todo to get rid of
> > the code duplication).
> > 
> 
> Re duplication: move the discovery into early-quirks and export the
> resource_t ?

Might be an idea, the biggest hurdle is that now early quirks are
__init so if you don't load i915, they have no impact on resident code
size, they get overridden. So pretty much any way will increase either
resident code or data memory size, so I've so far been looking to just
share the codebase some way. Because the code applies to _all_ x86.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation