From: Raag Jadav <raag.jadav@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: airlied@gmail.com, simona@ffwll.ch, lucas.demarchi@intel.com,
thomas.hellstrom@linux.intel.com, rodrigo.vivi@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, andriy.shevchenko@linux.intel.com,
matthew.d.roper@intel.com
Subject: Re: [PATCH v5 2/4] drm: Expose wedge recovery methods
Date: Thu, 19 Sep 2024 11:38:50 +0300 [thread overview]
Message-ID: <ZuvjGpIdOgGpbBQu@black.fi.intel.com> (raw)
In-Reply-To: <87r09g9jp0.fsf@intel.com>
On Thu, Sep 19, 2024 at 10:38:51AM +0300, Jani Nikula wrote:
> On Thu, 19 Sep 2024, Raag Jadav <raag.jadav@intel.com> wrote:
> > On Tue, Sep 17, 2024 at 10:49:07AM +0300, Jani Nikula wrote:
> >> On Tue, 17 Sep 2024, Raag Jadav <raag.jadav@intel.com> wrote:
> >> > Now that we have device wedged event in place, add wedge_recovery sysfs
> >> > attribute which will expose recovery methods supported by the DRM device.
> >> > This is useful for userspace consumers in cases where the device supports
> >> > multiple recovery methods which can be used as fallbacks.
> >> >
> >> > $ cat /sys/class/drm/card0/wedge_recovery
> >> > rebind
> >> > bus-reset
> >> > reboot
> >> >
> >> > Signed-off-by: Raag Jadav <raag.jadav@intel.com>
> >> > ---
> >> > drivers/gpu/drm/drm_sysfs.c | 23 +++++++++++++++++++++++
> >> > 1 file changed, 23 insertions(+)
> >> >
> >> > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
> >> > index fb3bbb6adcd1..b88cdbfa3b5e 100644
> >> > --- a/drivers/gpu/drm/drm_sysfs.c
> >> > +++ b/drivers/gpu/drm/drm_sysfs.c
> >> > @@ -36,6 +36,8 @@
> >> > #define to_drm_minor(d) dev_get_drvdata(d)
> >> > #define to_drm_connector(d) dev_get_drvdata(d)
> >> >
> >> > +extern const char *const wedge_recovery_opts[];
> >>
> >> Data is not an interface. Please add a function for this.
> >
> > For a single user?
>
> Yes.
>
> Well, you kind of have two, and both places need to do bounds checking
> on indexing the array. You also need to do bounds checking on the string
> manipulation, you can't just strcat and assume it'll be all right.
Which would be true if we were to receive an unknown string. Here we sorta
know it offhand so we're not gonna shoot in our foot :D
Anyway, would you prefer strlcat instead?
Raag
next prev parent reply other threads:[~2024-09-19 8:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-17 4:02 [PATCH v5 0/4] Introduce DRM device wedged event Raag Jadav
2024-09-17 4:02 ` [PATCH v5 1/4] drm: Introduce " Raag Jadav
2024-09-19 7:43 ` Jani Nikula
2024-09-17 4:02 ` [PATCH v5 2/4] drm: Expose wedge recovery methods Raag Jadav
2024-09-17 7:49 ` Jani Nikula
2024-09-19 4:05 ` Raag Jadav
2024-09-19 7:38 ` Jani Nikula
2024-09-19 8:38 ` Raag Jadav [this message]
2024-09-19 9:24 ` Jani Nikula
2024-09-19 11:33 ` Raag Jadav
2024-09-19 11:39 ` Jani Nikula
2024-09-19 13:45 ` Andy Shevchenko
2024-09-20 11:18 ` Raag Jadav
2024-09-20 14:27 ` Andy Shevchenko
2024-09-17 4:02 ` [PATCH v5 3/4] drm/xe: Use device wedged event Raag Jadav
2024-09-17 4:41 ` Ghimiray, Himal Prasad
2024-09-17 6:38 ` Raag Jadav
2024-09-17 8:03 ` Ghimiray, Himal Prasad
2024-09-17 8:18 ` Aravind Iddamsetty
2024-09-17 4:02 ` [PATCH v5 4/4] drm/i915: " Raag Jadav
2024-09-17 4:09 ` ✓ CI.Patch_applied: success for Introduce DRM device wedged event (rev3) Patchwork
2024-09-17 4:10 ` ✗ CI.checkpatch: warning " Patchwork
2024-09-17 4:12 ` ✓ CI.KUnit: success " Patchwork
2024-09-17 4:35 ` ✓ CI.Build: " Patchwork
2024-09-17 4:38 ` ✓ CI.Hooks: " Patchwork
2024-09-17 4:39 ` ✗ CI.checksparse: warning " Patchwork
2024-09-17 5:24 ` ✗ CI.BAT: failure " Patchwork
2024-09-17 7:31 ` ✓ CI.FULL: success " 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=ZuvjGpIdOgGpbBQu@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