From: Raag Jadav <raag.jadav@intel.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
jani.nikula@linux.intel.com
Cc: airlied@gmail.com, simona@ffwll.ch, lucas.demarchi@intel.com,
rodrigo.vivi@intel.com, lina@asahilina.net,
michal.wajdeczko@intel.com, christian.koenig@amd.com,
intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
dri-devel@lists.freedesktop.org, himal.prasad.ghimiray@intel.com,
aravind.iddamsetty@linux.intel.com, anshuman.gupta@intel.com,
alexander.deucher@amd.com, andrealmeid@igalia.com,
amd-gfx@lists.freedesktop.org, kernel-dev@igalia.com
Subject: Re: [PATCH v8 1/4] drm: Introduce device wedged event
Date: Sat, 26 Oct 2024 18:27:11 +0300 [thread overview]
Message-ID: <Zx0KT2QIBQyJC7xB@black.fi.intel.com> (raw)
In-Reply-To: <ZxuvJ1Hhv4nt9oSH@smile.fi.intel.com>
On Fri, Oct 25, 2024 at 05:45:59PM +0300, Andy Shevchenko wrote:
> On Fri, Oct 25, 2024 at 12:08:50PM +0300, Jani Nikula wrote:
> > On Fri, 25 Oct 2024, Raag Jadav <raag.jadav@intel.com> wrote:
>
> ...
>
> > > +/*
> > > + * Available recovery methods for wedged device. To be sent along with device
> > > + * wedged uevent.
> > > + */
> > > +static const char *const drm_wedge_recovery_opts[] = {
> > > + [ffs(DRM_WEDGE_RECOVERY_REBIND) - 1] = "rebind",
> > > + [ffs(DRM_WEDGE_RECOVERY_BUS_RESET) - 1] = "bus-reset",
> > > +};
> > > +static_assert(ARRAY_SIZE(drm_wedge_recovery_opts) == ffs(DRM_WEDGE_RECOVERY_BUS_RESET));
> >
> > This might work in most cases, but you also might end up finding that
> > there's an arch and compiler combo out there that just won't be able to
> > figure out ffs() at compile time, and the array initialization fails.
>
> We have ilog2() macro for such cases, but it is rather fls() and not ffs(),
> and I have no idea why ffs() even being used here, especially in the index
> part of the array assignments. It's unreadable.
I initially had __builtin_ffs() in mind which is even more ugly.
> > If that happens, you'd have to either convert back to an enum (and call
> > the wedge event function with BIT(DRM_WEDGE_RECOVERY_REBIND) etc.), or
Which would confuse the users since that's not how enums are normally used.
> > make this a array of structs mapping the macro values to strings and
> > loop over it.
Why not just switch() it?
for_each_set_bit(opt, &method, size) {
switch (BIT(opt)) {
case DRM_WEDGE_RECOVERY_REBIND:
recovery = "rebind";
break;
case DRM_WEDGE_RECOVERY_BUS_RESET:
recovery = "bus-reset";
break;
}
...
}
I know we'll have to update it with new additions, but it'd be much simpler,
atleast compared to introducing and maintaining a new struct.
> > Also, the main point of the static assert was to ensure the array is
> > updated when a new recovery option is added, and there's no out of
> > bounds access. That no longer holds, and the static assert is pretty
> > much useless. You still have to manually find and update this.
With above in place this won't be needed.
Raag
next prev parent reply other threads:[~2024-10-26 15:51 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 8:48 [PATCH v8 0/4] Introduce DRM device wedged event Raag Jadav
2024-10-25 8:48 ` [PATCH v8 1/4] drm: Introduce " Raag Jadav
2024-10-25 9:08 ` Jani Nikula
2024-10-25 14:45 ` Andy Shevchenko
2024-10-26 15:27 ` Raag Jadav [this message]
2024-10-28 8:50 ` Jani Nikula
2024-10-26 6:15 ` kernel test robot
2024-10-26 10:10 ` kernel test robot
2024-10-25 8:48 ` [PATCH v8 2/4] drm/doc: Document " Raag Jadav
2024-10-29 9:51 ` Christian König
2024-11-01 4:26 ` Raag Jadav
2024-10-25 8:48 ` [PATCH v8 3/4] drm/xe: Use " Raag Jadav
2024-10-25 8:48 ` [PATCH v8 4/4] drm/i915: " Raag Jadav
2024-10-25 9:09 ` ✓ CI.Patch_applied: success for Introduce DRM device wedged event (rev6) Patchwork
2024-10-25 9:09 ` ✗ CI.checkpatch: warning " Patchwork
2024-10-25 9:10 ` ✓ CI.KUnit: success " Patchwork
2024-10-25 9:27 ` ✓ CI.Build: " Patchwork
2024-10-25 9:30 ` ✓ CI.Hooks: " Patchwork
2024-10-25 9:32 ` ✗ CI.checksparse: warning " Patchwork
2024-10-25 9:56 ` ✗ CI.BAT: failure " Patchwork
2024-10-25 10:08 ` ✗ Fi.CI.CHECKPATCH: warning " Patchwork
2024-10-25 10:08 ` ✗ Fi.CI.SPARSE: " Patchwork
2024-10-25 10:28 ` ✓ Fi.CI.BAT: success " Patchwork
2024-10-25 14:44 ` ✗ Fi.CI.IGT: failure " Patchwork
2024-10-26 19:57 ` ✗ CI.FULL: " Patchwork
2024-10-29 11:20 ` 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=Zx0KT2QIBQyJC7xB@black.fi.intel.com \
--to=raag.jadav@intel.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=andrealmeid@igalia.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=anshuman.gupta@intel.com \
--cc=aravind.iddamsetty@linux.intel.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--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=kernel-dev@igalia.com \
--cc=lina@asahilina.net \
--cc=lucas.demarchi@intel.com \
--cc=michal.wajdeczko@intel.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.