From: Hans de Goede <hdegoede@redhat.com>
To: Guenter Roeck <linux@roeck-us.net>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: linux-usb@vger.kernel.org
Subject: Re: [PATCH 2/6] usb: typec: tcpm: Move locking into tcpm_queue_vdm()
Date: Fri, 24 Jul 2020 17:03:51 +0200 [thread overview]
Message-ID: <8d7e0bc9-9872-ffc0-b95a-e9ca12308f22@redhat.com> (raw)
In-Reply-To: <edd1ea84-679e-0e7b-f615-c9cd8c58bcdc@roeck-us.net>
Hi,
Thank you for the reviews.
On 7/15/20 5:41 PM, Guenter Roeck wrote:
> On 7/15/20 6:22 AM, Hans de Goede wrote:
>> Various callers (all the typec_altmode_ops) take the port-lock just for
>> the tcpm_queue_vdm() call.
>>
>> Rename the raw (unlocked) tcpm_queue_vdm() call to
>> tcpm_queue_vdm_unlocked() and add a new tcpm_queue_vdm() helper which takes
>> the lock, so that its callers don't have to do this themselves.
>>
>> This is a preparation patch for fixing an AB BA lock inversion between the
>> tcpm code and some altmode drivers.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/usb/typec/tcpm/tcpm.c | 27 ++++++++++++++-------------
>> 1 file changed, 14 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
>> index fc6455a29c74..30e997d6ea1e 100644
>> --- a/drivers/usb/typec/tcpm/tcpm.c
>> +++ b/drivers/usb/typec/tcpm/tcpm.c
>> @@ -958,9 +958,11 @@ static void tcpm_queue_message(struct tcpm_port *port,
>> /*
>> * VDM/VDO handling functions
>> */
>> -static void tcpm_queue_vdm(struct tcpm_port *port, const u32 header,
>> - const u32 *data, int cnt)
>> +static void tcpm_queue_vdm_unlocked(struct tcpm_port *port, const u32 header,
>> + const u32 *data, int cnt)
>
> The new function name is misleading. I think tcpm_queue_vdm_locked()
> would be a much better name. Alternatively, consider keeping tcpm_queue_vdm()
> as is and add tcpm_queue_vdm_unlocked().
At first I was a bit surprised by your comment, because I'm sure I have seen the
unlocked pattern used before, in the same way as I'm using it. But upon checking
it indeed seems that most of the time it is used in the way you suggest using it
including in the usb subsys. So I will make the requested changes for v2 of the
patchset.
Regards,
Hans
>
>> {
>> + WARN_ON(!mutex_is_locked(&port->lock));
>> +
>> port->vdo_count = cnt + 1;
>> port->vdo_data[0] = header;
>> memcpy(&port->vdo_data[1], data, sizeof(u32) * cnt);
>> @@ -971,6 +973,14 @@ static void tcpm_queue_vdm(struct tcpm_port *port, const u32 header,
>> mod_delayed_work(port->wq, &port->vdm_state_machine, 0);
>> }
>>
>> +static void tcpm_queue_vdm(struct tcpm_port *port, const u32 header,
>> + const u32 *data, int cnt)
>> +{
>> + mutex_lock(&port->lock);
>> + tcpm_queue_vdm_unlocked(port, header, data, cnt);
>> + mutex_unlock(&port->lock);
>> +}
>> +
>> static void svdm_consume_identity(struct tcpm_port *port, const __le32 *payload,
>> int cnt)
>> {
>> @@ -1249,7 +1259,7 @@ static void tcpm_handle_vdm_request(struct tcpm_port *port,
>> rlen = tcpm_pd_svdm(port, payload, cnt, response);
>>
>> if (rlen > 0)
>> - tcpm_queue_vdm(port, response[0], &response[1], rlen - 1);
>> + tcpm_queue_vdm_unlocked(port, response[0], &response[1], rlen - 1);
>> }
>>
>> static void tcpm_send_vdm(struct tcpm_port *port, u32 vid, int cmd,
>> @@ -1263,7 +1273,7 @@ static void tcpm_send_vdm(struct tcpm_port *port, u32 vid, int cmd,
>> /* set VDM header with VID & CMD */
>> header = VDO(vid, ((vid & USB_SID_PD) == USB_SID_PD) ?
>> 1 : (PD_VDO_CMD(cmd) <= CMD_ATTENTION), cmd);
>> - tcpm_queue_vdm(port, header, data, count);
>> + tcpm_queue_vdm_unlocked(port, header, data, count);
>> }
>>
>> static unsigned int vdm_ready_timeout(u32 vdm_hdr)
>> @@ -1506,13 +1516,10 @@ static int tcpm_altmode_enter(struct typec_altmode *altmode, u32 *vdo)
>> struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
>> u32 header;
>>
>> - mutex_lock(&port->lock);
>> header = VDO(altmode->svid, vdo ? 2 : 1, CMD_ENTER_MODE);
>> header |= VDO_OPOS(altmode->mode);
>>
>> tcpm_queue_vdm(port, header, vdo, vdo ? 1 : 0);
>> - mutex_unlock(&port->lock);
>> -
>> return 0;
>> }
>>
>> @@ -1521,13 +1528,10 @@ static int tcpm_altmode_exit(struct typec_altmode *altmode)
>> struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
>> u32 header;
>>
>> - mutex_lock(&port->lock);
>> header = VDO(altmode->svid, 1, CMD_EXIT_MODE);
>> header |= VDO_OPOS(altmode->mode);
>>
>> tcpm_queue_vdm(port, header, NULL, 0);
>> - mutex_unlock(&port->lock);
>> -
>> return 0;
>> }
>>
>> @@ -1536,10 +1540,7 @@ static int tcpm_altmode_vdm(struct typec_altmode *altmode,
>> {
>> struct tcpm_port *port = typec_altmode_get_drvdata(altmode);
>>
>> - mutex_lock(&port->lock);
>> tcpm_queue_vdm(port, header, data, count - 1);
>> - mutex_unlock(&port->lock);
>> -
>> return 0;
>> }
>>
>>
>
next prev parent reply other threads:[~2020-07-24 15:03 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-15 13:22 [PATCH 0/6] usb: typec: tcpm: Fix AB BA lock inversion between tcpm and alt-mode drivers Hans de Goede
2020-07-15 13:22 ` [PATCH 1/6] usb: typec: tcpm: Move mod_delayed_work(&port->vdm_state_machine) call into tcpm_queue_vdm() Hans de Goede
2020-07-15 15:36 ` Guenter Roeck
2020-07-15 13:22 ` [PATCH 2/6] usb: typec: tcpm: Move locking " Hans de Goede
2020-07-15 15:41 ` Guenter Roeck
2020-07-24 15:03 ` Hans de Goede [this message]
2020-07-15 13:22 ` [PATCH 3/6] usb: typec: tcpm: Refactor tcpm_handle_vdm_request payload handling Hans de Goede
2020-07-15 15:52 ` Guenter Roeck
2020-07-15 13:22 ` [PATCH 4/6] usb: typec: tcpm: Refactor tcpm_handle_vdm_request Hans de Goede
2020-07-15 15:58 ` Guenter Roeck
2020-07-24 15:31 ` Hans de Goede
2020-07-15 13:23 ` [PATCH 5/6] usb: typec: tcpm: Fix AB BA lock inversion between tcpm code and the alt-mode drivers Hans de Goede
2020-07-15 16:05 ` Guenter Roeck
2020-07-24 15:56 ` Hans de Goede
2020-07-15 13:23 ` [PATCH 6/6] usb: typec: tcpm: Add WARN_ON ensure we are not tryong to send 2 VDM packets at the same time Hans de Goede
2020-07-15 16:06 ` Guenter Roeck
2020-07-24 15:59 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8d7e0bc9-9872-ffc0-b95a-e9ca12308f22@redhat.com \
--to=hdegoede@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=linux-usb@vger.kernel.org \
--cc=linux@roeck-us.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).