Quoting Mika Kuoppala (2018-06-08 14:42:05)
> If we are doing revision checks against a preproduction
> range, when there is already a product, it is a sign
> that there is code to be removed.
>
> Signed-off-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx>
> ---
> drivers/gpu/drm/i915/intel_chipset.h | 30 +++++++++++++++++++++-------
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_chipset.h b/drivers/gpu/drm/i915/intel_chipset.h
> index 946c889c0118..bc9ff02dc8df 100644
> --- a/drivers/gpu/drm/i915/intel_chipset.h
> +++ b/drivers/gpu/drm/i915/intel_chipset.h
> @@ -131,6 +131,12 @@
> #define IS_PREPRODUCTION_HW(dev_priv) (INTEL_REVID(dev_priv) < FIRST_PRODUCT_REVID(INTEL_INFO(dev_priv)))
> #define IS_PLATFORM_SUPPORT_ALPHA(intel_info) (FIRST_PRODUCT_REVID(intel_info) == PRODUCT_REVID_UNKNOWN)
>
> +#define BUILD_BUG_ON_REVID_LT(revid, production_revid) ({ \
BUILD_BUG_ON_PREPRODUCTION()
It doesn't look that general, or widely useful to say REVID_LT. Sort of
implies we will have REVID_GTE etc later.
> + BUILD_BUG_ON((production_revid) != PRODUCT_REVID_UNKNOWN && \
> + (revid) < (production_revid)); \
I'd prefer (!BUILD_BUG_ON_ZERO()) (Or push the
!BUILD_BUG_ON_PREPRODUCTION to the caller as that's easier to read).
That avoids the ({block}) making it less likely to cause problems.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
