Hi Tvrtko, > > > > + } > > > > + > > > > + intel_gt_sysfs_pm_remove(gt, root); > > > > + kobject_put(root); > > > > > > Maybe stick to the same terminology regarding root and parent. > > > > yes. > > > > > Get/put on the parent looks unbalanced. Both register and unregister take > > > a > > > reference and only unregister releases it. But do you even need a > > > reference? > > > > why? I take it here: > > > > static inline struct kobject *gt_to_parent_obj(struct intel_gt *gt) > > { > > return kobject_get(>->i915->drm.primary->kdev->kobj); > > } > > > > at the beginning (when the driver is loaded) and I release it at > > the end (when the driver is unloaded). Am I not seeing something? > > Gt_to_parent_obj at the top of intel_gt_sysfs_register balances out with the > put at the end of the same function. What balances out gt_to_parent_obj from > intel_gt_sysfs_register?
And... you are right! either nothing or too many :) > > > I am also tempted by the _once alternative, but then it makes less sense > > > to > > > include name & pid. > > > > It's true, it can be an unrelenting message, and I thought of it, > > but if the user is resilient at reading out from the wrong > > directory, why shouldn't I :) > > Because we always try to avoid emitting spammy logs when they can be easily > triggered by userspace. Can we do rate limit? I think that could work well > with logging the process name & pid. yes, if two people suggested the same thing, most probably that's the right thing to do. > Also, we need an entry in Documentation/ABI/obsolete/. I was waiting this patch to get in shape before adding the interface to obsolete. I will include it in the next patch. Thanks a lot for the review, Andi _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx