[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <da8ba5d8-b22e-4bdb-9a49-c89df97713a2@google.com>
Date: Thu, 22 Aug 2024 15:32:49 -0700
From: Amit Sunil Dhamne <amitsd@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: heikki.krogerus@...ux.intel.com, badhri@...gle.com,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org, kyletso@...gle.com,
rdbabiera@...gle.com
Subject: Re: [PATCH v2] usb: roles: add lockdep class key to struct
usb_role_switch
On 8/14/24 10:06 PM, Greg KH wrote:
> On Wed, Aug 14, 2024 at 09:40:55PM -0700, Amit Sunil Dhamne wrote:
>> There can be multiple role switch devices running on a platform. Given
>> that lockdep is not capable of differentiating between locks of
>> different instances, false positive warnings for circular locking are
>> reported. To prevent this, register unique lockdep key for each of the
>> individual instances.
>>
>> Signed-off-by: Amit Sunil Dhamne <amitsd@...gle.com>
>> ---
>> v1->v2
>> - Avoid usage of ifdefs.
>> ---
>> drivers/usb/roles/class.c | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/drivers/usb/roles/class.c b/drivers/usb/roles/class.c
>> index d7aa913ceb8a..9dbe9f6bea83 100644
>> --- a/drivers/usb/roles/class.c
>> +++ b/drivers/usb/roles/class.c
>> @@ -11,6 +11,7 @@
>> #include <linux/usb/role.h>
>> #include <linux/property.h>
>> #include <linux/device.h>
>> +#include <linux/lockdep.h>
>> #include <linux/module.h>
>> #include <linux/mutex.h>
>> #include <linux/slab.h>
>> @@ -33,6 +34,8 @@ struct usb_role_switch {
>> usb_role_switch_set_t set;
>> usb_role_switch_get_t get;
>> bool allow_userspace_control;
>> +
>> + struct lock_class_key key;
>> };
>>
>> #define to_role_switch(d) container_of(d, struct usb_role_switch, dev)
>> @@ -396,6 +399,11 @@ usb_role_switch_register(struct device *parent,
>>
>> sw->registered = true;
>>
>> + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> Why is this if statement needed at all?
Upon closer look it's redundant. Unfortunately, I missed the different
definitions for the lockdep API & structs based on CONFIG_LOCKDEP in hdr
file.
Will be more careful next time.
>
> Please get someone internal to your company/group to review the change
> before sending it out for others to find the obvious issues with it.
> That's what your peers are for. Please do so and get them to provide a
> reviewed-by on it before submitting it again.
Sounds good. I will send the next revision with reviewed-by signature
from a peer.
Thanks,
Amit
> thanks,
>
> greg k-h
Powered by blists - more mailing lists