Re: [PATCH v2] drm/i915/pxp: don't start pxp without mei_pxp bind

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 8/9/2022 5:42 PM, Juston Li wrote:
pxp will not start correctly until after mei_pxp bind completes and
intel_pxp_init_hw() is called.

This fixes a race condition during bootup where we observed a small
window for pxp commands to be sent before mei_pxp bind completed.

Changes since v1:
- check pxp_component instead of pxp_component_added (Daniele)
- pxp_component needs tee_mutex (Daniele)
- return -EAGAIN so caller knows to retry (Daniele)

Sorry for the follow up, but I have reflected on this a bit more and I was thinking that maybe it would be better to wait a bit for the component to be bound, instead of immediately failing the call. Do you have a measure of how long after your failure you see the component bind complete? The wait would make sense only if relatively short (< 1s).

Daniele

Signed-off-by: Juston Li <justonli@xxxxxxxxxx>
---
  drivers/gpu/drm/i915/pxp/intel_pxp.c | 8 ++++++++
  1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 15311eaed848..8b395ebc430a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -187,6 +187,14 @@ int intel_pxp_start(struct intel_pxp *pxp)
  	if (!intel_pxp_is_enabled(pxp))
  		return -ENODEV;
+ mutex_lock(&pxp->tee_mutex);
+	/* check if mei_pxp is bound */
+	if (!pxp->pxp_component) {
+		mutex_unlock(&pxp->tee_mutex);
+		return -EAGAIN;
+	}
+	mutex_unlock(&pxp->tee_mutex);
+
  	mutex_lock(&pxp->arb_mutex);
if (pxp->arb_is_valid)




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux