[PATCH v8 1/4] drm: Introduce device wedged event
Raag Jadav
raag.jadav at intel.com
Sat Oct 26 15:27:11 UTC 2024
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 at 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
More information about the Intel-gfx
mailing list