Intel-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Raag Jadav <raag.jadav@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: airlied@gmail.com, simona@ffwll.ch, lucas.demarchi@intel.com,
	thomas.hellstrom@linux.intel.com, rodrigo.vivi@intel.com,
	jani.nikula@linux.intel.com, joonas.lahtinen@linux.intel.com,
	tursulin@ursulin.net, lina@asahilina.net,
	intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org, himal.prasad.ghimiray@intel.com,
	francois.dugast@intel.com, aravind.iddamsetty@linux.intel.com,
	anshuman.gupta@intel.com, andi.shyti@linux.intel.com,
	matthew.d.roper@intel.com
Subject: Re: [PATCH v7 1/5] drm: Introduce device wedged event
Date: Tue, 1 Oct 2024 17:18:33 +0300	[thread overview]
Message-ID: <ZvwEubI8ldUT6TsK@black.fi.intel.com> (raw)
In-Reply-To: <ZvvmH0n_y_vVSpvR@smile.fi.intel.com>

On Tue, Oct 01, 2024 at 03:07:59PM +0300, Andy Shevchenko wrote:
> On Tue, Oct 01, 2024 at 08:08:18AM +0300, Raag Jadav wrote:
> > On Mon, Sep 30, 2024 at 03:59:59PM +0300, Andy Shevchenko wrote:
> > > On Mon, Sep 30, 2024 at 01:08:41PM +0530, Raag Jadav wrote:
> 
> ...
> 
> > > > +static const char *const drm_wedge_recovery_opts[] = {
> > > > +	[DRM_WEDGE_RECOVERY_REBIND] = "rebind",
> > > > +	[DRM_WEDGE_RECOVERY_BUS_RESET] = "bus-reset",
> > > > +	[DRM_WEDGE_RECOVERY_REBOOT] = "reboot",
> > > > +};
> > > 
> > > Place for static_assert() is here, as it closer to the actual data we test...
> > 
> > Shouldn't it be at the point of access?
> 
> No, the idea of static_assert() is in word 'static', meaning it's allowed to be
> used in the global space.
> 
> > If no, why do we care about the data when it's not being used?
> 
> What does this suppose to mean? The assertion is for enforcing the boundaries
> that are defined by different means (constant of the size and real size of
> an array).

The point was to simply not assert without an active user of the array, which is
not the case now but may be possible with growing functionality in the future.

Raag

  reply	other threads:[~2024-10-01 14:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-30  7:38 [PATCH v7 0/5] Introduce DRM device wedged event Raag Jadav
2024-09-30  7:38 ` [PATCH v7 1/5] drm: Introduce " Raag Jadav
2024-09-30 12:59   ` Andy Shevchenko
2024-10-01  5:08     ` Raag Jadav
2024-10-01 12:07       ` Andy Shevchenko
2024-10-01 14:18         ` Raag Jadav [this message]
2024-10-01 14:54           ` Andy Shevchenko
2024-10-01 16:42             ` Raag Jadav
2024-10-01 12:20   ` Michal Wajdeczko
2024-10-03 12:23     ` Raag Jadav
2024-10-08 15:02       ` Raag Jadav
2024-10-10 13:02         ` Lucas De Marchi
2024-10-11  8:47           ` Raag Jadav
2024-10-17  2:47   ` Raag Jadav
2024-10-17  7:59     ` Christian König
2024-10-17 16:43       ` Rodrigo Vivi
2024-10-18 10:58         ` Christian König
2024-10-18 12:46           ` Raag Jadav
2024-10-18 12:54             ` Christian König
2024-10-18 14:09               ` Raag Jadav
2024-10-17 19:16   ` André Almeida
2024-10-18 14:56     ` Rodrigo Vivi
2024-10-18 15:31       ` Alex Deucher
2024-10-18 17:56         ` André Almeida
2024-10-18 21:07           ` Alex Deucher
2024-10-24 17:48             ` Rodrigo Vivi
2024-10-19 19:08     ` Raag Jadav
2024-09-30  7:38 ` [PATCH v7 2/5] drm: Expose wedge recovery methods Raag Jadav
2024-09-30 13:01   ` Andy Shevchenko
2024-10-01  5:23     ` Raag Jadav
2024-09-30  7:38 ` [PATCH v7 3/5] drm/doc: Document device wedged event Raag Jadav
2024-09-30  7:38 ` [PATCH v7 4/5] drm/xe: Use " Raag Jadav
2024-09-30  7:38 ` [PATCH v7 5/5] drm/i915: " Raag Jadav
2024-09-30 22:48 ` ✗ Fi.CI.CHECKPATCH: warning for Introduce DRM device wedged event (rev5) Patchwork
2024-09-30 22:48 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-09-30 22:58 ` ✓ Fi.CI.BAT: success " Patchwork
2024-10-01  9:54 ` ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZvwEubI8ldUT6TsK@black.fi.intel.com \
    --to=raag.jadav@intel.com \
    --cc=airlied@gmail.com \
    --cc=andi.shyti@linux.intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=aravind.iddamsetty@linux.intel.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=francois.dugast@intel.com \
    --cc=himal.prasad.ghimiray@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=lina@asahilina.net \
    --cc=lucas.demarchi@intel.com \
    --cc=matthew.d.roper@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=simona@ffwll.ch \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=tursulin@ursulin.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox