Re: [Intel-gfx] [PATCH v5 2/6] drm/i915/pxp: add device link between i915 and mei_pxp

[Jani Nikula <jani.nikula@linux.intel.com>]

On Sun, 22 Jan 2023, "Usyskin, Alexander" <alexander.usyskin@intel.com> wrote:
>> > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> > index d50354bfb993..bef6d7f8ac55 100644
>> > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
>> > @@ -127,6 +127,10 @@ static int i915_pxp_tee_component_bind(struct
>> device *i915_kdev,
>> >  	intel_wakeref_t wakeref;
>> >  	int ret = 0;
>> >
>> > +	if (!HAS_HECI_PXP(i915) &&
>> > +	    drm_WARN_ON(&i915->drm, !device_link_add(i915_kdev,
>> tee_kdev,
>> 
>> I don't like the action here hidden behind the drm_WARN_ON.
>> Please notice that almost every use of this and other helpers like
>> this expect the param as a failure. Not an actual action. So,
>> most of lazy readers like me might ignore that the main function
>> is actually a param inside  this warn condition.
>> 
> Honestly, copy-pasted from drivers/gpu/drm/i915/display/intel_audio.c +1266
> I don't have deep knowledge of drm macros, so thought this should be ok.
> Can make it any other form that acceptable in drm tree...

Unfortunately, some pattern being present in the driver does not mean
it's a good example to be emulated. If we copy a bad pattern, it seems
more acceptable, and even more people will copy it.


BR,
Jani.

>
>> We should probably stash the link as well...
>> 
>> pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
>> 
>> so in the end below, instead of checking the HAS_HECI_PXP again
>> and use the remove version you check the dev_link and use the del
>> function.
>> 
>> something like:
>> 
>> if (pxp->dev_link)
>>    device_link_del(pxp->dev_link);
>> 
> Not sure that this simplification warrants additional clutter in struct.
>
>> Also, do you really need the WARN to see the stack when this happens
>> or you already know the callers?
>> Why not a simple drm_error msg?
>> 
>> if (!HAS_HECI_PXP(i915) {
>> 	pxp->dev_link = device_link_add(i915_kdev, tee_kdev,...);
>> 	if (!pxp->dev_link) {
>> 	   drm_error();
>> 	   return -ESOMETHING;
>> 
>> >  DL_FLAG_STATELESS)))
>> 
>> do we need the RPM in sync as well?
>> I mean:
>> 
>> DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME)))
>> 
>> ?
>
> No, the mei device should not be active all the time when i915 is active, only when pxp requires it.
>
>> 
>> > +		return -ENOMEM;
>> 
>> why ENOMEM?
> Copy-paste from i915 audio.
>
>> 
>> > +
>> >  	mutex_lock(&pxp->tee_mutex);
>> >  	pxp->pxp_component = data;
>> >  	pxp->pxp_component->tee_dev = tee_kdev;
>> > @@ -169,6 +173,9 @@ static void i915_pxp_tee_component_unbind(struct
>> device *i915_kdev,
>> >  	mutex_lock(&pxp->tee_mutex);
>> >  	pxp->pxp_component = NULL;
>> >  	mutex_unlock(&pxp->tee_mutex);
>> > +
>> > +	if (!HAS_HECI_PXP(i915))
>> > +		device_link_remove(i915_kdev, tee_kdev);
>> >  }
>> >
>> >  static const struct component_ops i915_pxp_tee_component_ops = {
>> > --
>> > 2.39.0
>> >

-- 
Jani Nikula, Intel Open Source Graphics Center