> > > > > +struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
> > > > > + const char *name)
> > > > > +{
> > > > > + struct kobject *kobj = &dev->kobj;
> > > > > +
> > > > > + /*
> > > > > + * We are interested at knowing from where the interface
> > > > > + * has been called, whether it's called from gt/ or from
> > > > > + * the parent directory.
> > > > > + * From the interface position it depends also the value of
> > > > > + * the private data.
> > > > > + * If the interface is called from gt/ then private data is
> > > > > + * of the "struct intel_gt *" type, otherwise it's * a
> > > > > + * "struct drm_i915_private *" type.
> > > > > + */
> > > > > + if (!is_object_gt(kobj)) {
> > > > > + struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> > > > > +
> > > > > + pr_devel_ratelimited(DEPRECATED
> > > > > + "%s (pid %d) is accessing deprecated %s "
> > > > > + "sysfs control, please use gt/gt<n>/%s instead\n",
> > > > > + current->comm, task_pid_nr(current), name, name);
> > > > > + return to_gt(i915);
> > > > > + }
> > > > > +
> > > > > + return kobj_to_gt(kobj);
> > > > It took some time for me to understand what is going on here.
> > > > We have dev argument which sometimes can point to "struct device", sometimes
> > > > to "struct kobj_gt", but it's type suggests differently, quite ugly.
> > > > I wonder if wouldn't be better to use __ATTR instead of DEVICE_ATTR* as in
> > > > case of intel_engines_add_sysfs. This way abstractions would look better,
> > > > hopefully.
> > > How would it help?
> > >
> > > The difference is that I'm adding twice different interfaces with
> > > the same name and different location (i.e. different object). The
> > > legacy intrefaces inherit the object from drm and I'm preserving
> > > that reference.
> > >
> > > While the new objects would derive from the previous and they are
> > > pretty much like intel_engines_add_sysfs().
> >
> > I was not clear on the issue. Here in case of 'id' attribute it is defined
> > as device_attribute, but in kobj_type.sysfs_ops you assign formally
> > incompatible &kobj_sysfs_ops.
>
> 'kobj_sysfs_ops' is of the type 'kobj_type'.
>
> > kobj_sysfs_ops expects kobj_attribute! Fortunately kobj_attribute is 'binary
> > compatible' with device_attribute and kobj is at beginning of struct device
> > as well, so it does not blow up, but I wouldn't say it is clean solution :)
> > If you look at intel_engines_add_sysfs you can see that all attributes are
> > defined as kobj_attribute.
>
> That's exactly the approach I use in the next patches for the
> power management files, I use "struct kobj_gt" wrapped around
> "struct kobject". But I'm using that only for the GT files.
>
> Are you, btw, suggesting to use this same approache also for the
> legacy files that for now have a pointer to the drm kobject? This
> way I would need to add more information, like the pointer to
> i915 and gt_id. This way I wouldn't need the files above that
> look hacky to you. Is this what you mean?
Still this wouldn't solve it because I am merging the legacy
interfaces to an existing kobject and creating new kobjects for
the new interfaces that go under gt. I would need some other
ugly hack to have things coming around.
Unless I misunderstood you.
Andi
