From: Rodrigo Vivi <rodrigo.vivi@intel.com>
To: "Ghimiray, Himal Prasad" <himal.prasad.ghimiray@intel.com>
Cc: Tejas Upadhyay <tejas.upadhyay@intel.com>,
<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe: sysfs_ops needs to be defined on parent directory
Date: Tue, 25 Mar 2025 15:14:11 -0400 [thread overview]
Message-ID: <Z-MAg1F9_2seEgYy@intel.com> (raw)
In-Reply-To: <e91f93d2-a4e2-4304-b026-eea2f1fae13d@intel.com>
On Tue, Mar 25, 2025 at 03:18:40PM +0530, Ghimiray, Himal Prasad wrote:
>
>
> On 19-03-2025 17:43, Tejas Upadhyay wrote:
> > Currently, xe_hw_engine_sysfs_kobj_type is defining sysfs_ops
> > on wrong directory. Sysfs_ops needs to be defined on immediate
> > parent directory to be able to called on each attribute set/get.
> >
> > Fixes: 3f0e14651ab0 ("drm/xe: Runtime PM wake on every sysfs call")
> > Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com>
> > ---
> > drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c | 67 +++++++++----------
> > 1 file changed, 33 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c b/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c
> > index b53e8d2accdb..25592f178482 100644
> > --- a/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c
> > +++ b/drivers/gpu/drm/xe/xe_hw_engine_class_sysfs.c
> > @@ -492,39 +492,6 @@ static const struct attribute * const files[] = {
> > NULL
> > };
> > -static void kobj_xe_hw_engine_class_fini(void *arg)
> > -{
> > - struct kobject *kobj = arg;
> > -
> > - sysfs_remove_files(kobj, files);
> > - kobject_put(kobj);
> > -}
> > -
> > -static struct kobj_eclass *
> > -kobj_xe_hw_engine_class(struct xe_device *xe, struct kobject *parent, const char *name)
> > -{
> > - struct kobj_eclass *keclass;
> > - int err = 0;
> > -
> > - keclass = kzalloc(sizeof(*keclass), GFP_KERNEL);
> > - if (!keclass)
> > - return NULL;
> > -
> > - kobject_init(&keclass->base, &kobj_xe_hw_engine_type);
> > - if (kobject_add(&keclass->base, parent, "%s", name)) {
> > - kobject_put(&keclass->base);
> > - return NULL;
> > - }
> > - keclass->xe = xe;
> > -
> > - err = devm_add_action_or_reset(xe->drm.dev, kobj_xe_hw_engine_class_fini,
> > - &keclass->base);
> > - if (err)
> > - return NULL;
> > -
> > - return keclass;
> > -}
> > -
> > static void hw_engine_class_defaults_fini(void *arg)
> > {
> > struct kobject *kobj = arg;
> > @@ -611,6 +578,38 @@ static const struct kobj_type xe_hw_engine_sysfs_kobj_type = {
> > .sysfs_ops = &xe_hw_engine_class_sysfs_ops,
> > };
> > +static void kobj_xe_hw_engine_class_fini(void *arg)
> > +{
> > + struct kobject *kobj = arg;
> > +
> > + sysfs_remove_files(kobj, files);
> > + kobject_put(kobj);
> > +}
> > +
> > +static struct kobj_eclass *
> > +kobj_xe_hw_engine_class(struct xe_device *xe, struct kobject *parent, const char *name)
> > +{
> > + struct kobj_eclass *keclass;
> > + int err = 0;
> > +
> > + keclass = kzalloc(sizeof(*keclass), GFP_KERNEL);
> > + if (!keclass)
> > + return NULL;
> > +
> > + kobject_init(&keclass->base, &xe_hw_engine_sysfs_kobj_type);
> > + if (kobject_add(&keclass->base, parent, "%s", name)) {
> > + kobject_put(&keclass->base);
> > + return NULL;
> > + }
> > + keclass->xe = xe;
> > +
> > + err = devm_add_action_or_reset(xe->drm.dev, kobj_xe_hw_engine_class_fini,
> > + &keclass->base);
> > + if (err)
> > + return NULL;
> > +
> > + return keclass;
> > +}
> > static void hw_engine_class_sysfs_fini(void *arg)
> > {
> > struct kobject *kobj = arg;
> > @@ -640,7 +639,7 @@ int xe_hw_engine_class_sysfs_init(struct xe_gt *gt)
> > if (!kobj)
> > return -ENOMEM;
> > - kobject_init(kobj, &xe_hw_engine_sysfs_kobj_type);
> > + kobject_init(kobj, &kobj_xe_hw_engine_type);
>
>
> The patch makes sense if we need to use xe_pm_runtime_get and
> xe_pm_runtime_put to show and store the attributes. Are there any hardware
> read/writes associated with these attribute store/show operations? If not,
> why do we need pm_runtime just for software states?
>
> +Rodrigo, for his views here.
Better safe than sorry. The goal is to protect every entry point on the
upper (outer) levels that might interact with or trigger some memory operation.
>
> > err = kobject_add(kobj, gt->sysfs, "engines");
> > if (err)
>
next prev parent reply other threads:[~2025-03-25 19:14 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 12:13 [PATCH] drm/xe: sysfs_ops needs to be defined on parent directory Tejas Upadhyay
2025-03-19 12:22 ` ✓ CI.Patch_applied: success for " Patchwork
2025-03-19 12:23 ` ✓ CI.checkpatch: " Patchwork
2025-03-19 12:24 ` ✓ CI.KUnit: " Patchwork
2025-03-19 12:40 ` ✓ CI.Build: " Patchwork
2025-03-19 12:43 ` ✓ CI.Hooks: " Patchwork
2025-03-19 12:44 ` ✓ CI.checksparse: " Patchwork
2025-03-19 13:03 ` ✓ Xe.CI.BAT: " Patchwork
2025-03-19 14:05 ` ✓ Xe.CI.Full: " Patchwork
2025-03-25 9:48 ` [PATCH] " Ghimiray, Himal Prasad
2025-03-25 19:14 ` Rodrigo Vivi [this message]
2025-03-25 19:12 ` Rodrigo Vivi
2025-03-26 4:14 ` Upadhyay, Tejas
2025-03-26 14:43 ` Rodrigo Vivi
2025-03-26 14:50 ` Upadhyay, Tejas
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=Z-MAg1F9_2seEgYy@intel.com \
--to=rodrigo.vivi@intel.com \
--cc=himal.prasad.ghimiray@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=tejas.upadhyay@intel.com \
/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.