Re: [PATCH v3 05/40] misc/mei/hdcp: Notifier chain for mei cldev state change

[Ramalingam C <ramalingam.c@intel.com>]

On Tuesday 03 April 2018 09:00 PM, Daniel Vetter wrote:
> On Tue, Apr 03, 2018 at 07:27:18PM +0530, Ramalingam C wrote:
>> Notifier Chain is defined to inform all its clients about the mei
>> client device state change. Routine is defined for the clients to
>> register and unregister for the notification on state change.
>>
>> v2:
>>    Rebased.
>> v3:
>>    Notifier chain is adopted for cldev state update [Tomas]
>>
>> Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
> For managing interactions between multiple drivers notifier chains are
> fairly problematic. The main reason is the locking embedded in the
> notifier chain. To make things safe, that lock must be held everytime we
> add/remove any part of the link, and when calling any callback. Usually
> that means you get a neat deadlock sooner or later, because the
> load/unload code has inverse paths compared to normal operation.
>
> Notifiers also not not provide a clean way to handle suspend/resume
> ordering.
Recording the IRC discussion here:

As Daniel Vetter suggested, with notifiers to mei client device binding 
status, I have tested
the I915 and mei_hdcp modules as inbuild and as modules at suspend and 
resume of them.

During the experiment, CONFIG_PROVE_LOCKING was enabled. No issue was 
observed due to the
usecase of the notifier here. Notifier was used here just to inform the 
I915 that mei client device is no more.
So that I915 will stop any ongoing HDCP2.2 protection and reject any 
further request.

Hence Planning to continue with same shape of the patch on v4. If any 
erroneous scenario is detected
we will work on the alternate solution.

--Ram
>
> There's two parts to do this properly.
>
> 1. Finding the other driver. Multi-part drivers are assembled nowadays
> using the component framework. We're using that already to manage the
> interaction between drm/i915 and snd-hda. If not all components are ready
> yet, then the driver load sequence must be aborted by returning
> -EPROBE_DEFER. That's going to be lots of fun, since for the mei/i915
> interaction it's probably going to be i915 that needs to abort and retry
> the driver load. But we do CI test all the abort points in our driver
> load, so should work well.
>
> 2. Handling the ordering restrictions for suspend/resume. For i915/snd-hda
> we used a early_resume/late_suspend callback trickery, but that doesn't
> really scale to multiple levels. Since we've done that device_link has
> been added. As a bonus device_link can also ensure that not only
> suspend/resume (including runtime suspend/resume) is ordered correctly,
> but also that driver bind/unbind works correctly. Still needs the
> component stuff and initial -EPROBE_DEFER, but will all least make sure
> we' only reprobe once more. See device_link_add + docs in device_link.rst.
>
> One thing I didn't check is whether we want the device linke to also
> manage runtime pm for us. It would mean that we keep the ME awake as long
> as anything is using the gpu (any display on or any rendering happening).
> That might be too much, but could also be that it won't matter (and then
> using DL_FLAG_PM_RUNTIME would simply our code).
>
> We might also need to convert the i915/snd-hda interactions to device_link
> first, since the early/late_resume/suspend hack probably doesn't interact
> too well with proper device_links.
>
> Cheers, Daniel
>
>> ---
>>   drivers/misc/mei/hdcp/mei_hdcp.c | 36 +++++++++++++++++++++++++++---
>>   include/linux/mei_hdcp.h         | 48 ++++++++++++++++++++++++++++++++++++++++
>>   2 files changed, 81 insertions(+), 3 deletions(-)
>>   create mode 100644 include/linux/mei_hdcp.h
>>
>> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
>> index b334615728a7..2811a25f8c57 100644
>> --- a/drivers/misc/mei/hdcp/mei_hdcp.c
>> +++ b/drivers/misc/mei/hdcp/mei_hdcp.c
>> @@ -31,6 +31,32 @@
>>   #include <linux/slab.h>
>>   #include <linux/uuid.h>
>>   #include <linux/mei_cl_bus.h>
>> +#include <linux/notifier.h>
>> +#include <linux/mei_hdcp.h>
>> +
>> +static BLOCKING_NOTIFIER_HEAD(mei_cldev_notifier_list);
>> +
>> +void mei_cldev_state_notify_clients(struct mei_cl_device *cldev, bool enabled)
>> +{
>> +	if (enabled)
>> +		blocking_notifier_call_chain(&mei_cldev_notifier_list,
>> +					     MEI_CLDEV_ENABLED, cldev);
>> +	else
>> +		blocking_notifier_call_chain(&mei_cldev_notifier_list,
>> +					     MEI_CLDEV_DISABLED, NULL);
>> +}
>> +
>> +int mei_cldev_register_notify(struct notifier_block *nb)
>> +{
>> +	return blocking_notifier_chain_register(&mei_cldev_notifier_list, nb);
>> +}
>> +EXPORT_SYMBOL_GPL(mei_cldev_register_notify);
>> +
>> +int mei_cldev_unregister_notify(struct notifier_block *nb)
>> +{
>> +	return blocking_notifier_chain_unregister(&mei_cldev_notifier_list, nb);
>> +}
>> +EXPORT_SYMBOL_GPL(mei_cldev_unregister_notify);
>>   
>>   static int mei_hdcp_probe(struct mei_cl_device *cldev,
>>   			  const struct mei_cl_device_id *id)
>> @@ -38,14 +64,18 @@ static int mei_hdcp_probe(struct mei_cl_device *cldev,
>>   	int ret;
>>   
>>   	ret = mei_cldev_enable(cldev);
>> -	if (ret < 0)
>> +	if (ret < 0) {
>>   		dev_err(&cldev->dev, "mei_cldev_enable Failed. %d\n", ret);
>> +		return ret;
>> +	}
>>   
>> -	return ret;
>> +	mei_cldev_state_notify_clients(cldev, true);
>> +	return 0;
>>   }
>>   
>>   static int mei_hdcp_remove(struct mei_cl_device *cldev)
>>   {
>> +	mei_cldev_state_notify_clients(cldev, false);
>>   	mei_cldev_set_drvdata(cldev, NULL);
>>   	return mei_cldev_disable(cldev);
>>   }
>> @@ -71,4 +101,4 @@ module_mei_cl_driver(mei_hdcp_driver);
>>   
>>   MODULE_AUTHOR("Intel Corporation");
>>   MODULE_LICENSE("Dual BSD/GPL");
>> -MODULE_DESCRIPTION("HDCP");
>> +MODULE_DESCRIPTION("MEI HDCP");
>> diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdcp.h
>> new file mode 100644
>> index 000000000000..3b46bebde718
>> --- /dev/null
>> +++ b/include/linux/mei_hdcp.h
>> @@ -0,0 +1,48 @@
>> +/* SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause) */
>> +/*
>> + * Copyright © 2017-2018 Intel Corporation
>> + *
>> + * Permission to use, copy, modify, distribute, and sell this software and its
>> + * documentation for any purpose is hereby granted without fee, provided that
>> + * the above copyright notice appear in all copies and that both that copyright
>> + * notice and this permission notice appear in supporting documentation, and
>> + * that the name of the copyright holders not be used in advertising or
>> + * publicity pertaining to distribution of the software without specific,
>> + * written prior permission.  The copyright holders make no representations
>> + * about the suitability of this software for any purpose.  It is provided "as
>> + * is" without express or implied warranty.
>> + *
>> + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
>> + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
>> + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
>> + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
>> + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
>> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
>> + * OF THIS SOFTWARE.
>> + *
>> + * Authors:
>> + *	Ramalingam C <ramalingam.c@intel.com>
>> + */
>> +
>> +#ifndef _LINUX_MEI_HDCP_H
>> +#define _LINUX_MEI_HDCP_H
>> +
>> +enum mei_cldev_state {
>> +	MEI_CLDEV_DISABLED,
>> +	MEI_CLDEV_ENABLED
>> +};
>> +
>> +#ifdef CONFIG_INTEL_MEI_HDCP
>> +int mei_cldev_register_notify(struct notifier_block *nb);
>> +int mei_cldev_unregister_notify(struct notifier_block *nb);
>> +#else
>> +static int mei_cldev_register_notify(struct notifier_block *nb)
>> +{
>> +	return -ENODEV;
>> +}
>> +static int mei_cldev_unregister_notify(struct notifier_block *nb)
>> +{
>> +	return -ENODEV;
>> +}
>> +#endif /* defined (CONFIG_INTEL_MEI_HDCP) */
>> +#endif /* defined (_LINUX_MEI_HDCP_H) */
>> -- 
>> 2.7.4
>>

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel