[Intel-gfx] [RFC][PATCH 43/43] WIP: drm/i915: Type safe register read/write
Chris Wilson
chris at chris-wilson.co.uk
Fri Sep 18 10:33:38 PDT 2015
On Fri, Sep 18, 2015 at 08:03:56PM +0300, ville.syrjala at linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 140076d..0589aba 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -25,16 +25,28 @@
> #ifndef _I915_REG_H_
> #define _I915_REG_H_
>
> +struct i915_reg {
> + uint32_t reg;
> +};
Fundamental objection averted. Maybe even typedef it to hide the struct,
ignornace is bliss. i915_reg_t reg; looks reasonable in this instance.
For sanity's sake could you disassemble a simple function and include the
diff in the changelog. It will be reasuring to know that gcc handles the
struct-in-register just fine.
Once upon a time the plan was to use sparse for detecting type
mismatches, hence enum plane and enum pipe, but I know I don't run make
C=1 regularly at all, so using gcc itself is a win.
The downside with this patch is that we have a lot of places that cares
about the reg.reg, and even more where we make up reg on the fly, so it
looks like we are just doing I915_WRITE(_REG(old_u32), x) i.e. more or
less subverting the extra safety, and we would still want something like
i915_write16(reg) { WARN_ON(reg & 1); }
i915_write32(reg) { WARN_ON(reg & 3); }
to catch the class of bug where we create an invalid reg address.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
More information about the Intel-gfx
mailing list