From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751777AbcGRHIk (ORCPT ); Mon, 18 Jul 2016 03:08:40 -0400 Received: from mga03.intel.com ([134.134.136.65]:9095 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751531AbcGRHIi (ORCPT ); Mon, 18 Jul 2016 03:08:38 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,382,1464678000"; d="asc'?scan'208";a="735824918" From: Felipe Balbi To: Bin Gao Cc: Heikki Krogerus , Greg Kroah-Hartman , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Bin Gao , Chandra Sekhar Anagani Subject: Re: [PATCH 1/2] usb: typec: Add USB Power Delivery sink port support In-Reply-To: <20160715234957.GC159605@worksta> References: <20160715021405.GB128987@worksta> <87zipjgy6n.fsf@linux.intel.com> <20160715234957.GC159605@worksta> User-Agent: Notmuch/0.22+58~g3a45d29 (https://notmuchmail.org) Emacs/25.0.95.2 (x86_64-pc-linux-gnu) Date: Mon, 18 Jul 2016 10:07:24 +0300 Message-ID: <877fcjh1ar.fsf@linux.intel.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Bin Gao writes: >> > +int pd_sink_queue_msg(struct pd_sink_msg *msg) >> > +{ >> > + unsigned long flags; >> > + struct pd_sink_port *port; >> > + >> > + if (msg->port < 0 || msg->port >=3D MAX_NR_SINK_PORTS) { >> > + pr_err("Invalid port number\n"); >> > + return -EINVAL; >> > + } >> > + >> > + port =3D sink_ports[msg->port]; >> > + >> > + spin_lock_irqsave(&port->rx_lock, flags); >> > + list_add_tail(&msg->list, &port->rx_list); >> > + spin_unlock_irqrestore(&port->rx_lock, flags); >> > + >> > + queue_work(port->rx_wq, &port->rx_work); >>=20 >> can we really queue several messages at a time? It seems unfeasible to >> me. It's not like we can queue several power request in a role. Why do >> you need this workqueue? Why don't you process message here, in place? > Some Type-C chargers send two messages in a short duration(less than 1 ms= ), > e.g. a SOURCE_CAPABILITY follows the previous SOURCE_CAPABILITY, or a > GET_SINK_CAPABILITY follows a previous SOURCE_CAPABILITY, etc. Queuing > message to PD stack by Type-C phy driver typically happens in a interrupt > context. So in this case a nested interrupt may happen. Our whole PD > stack while processing one message is not re-entrant so the nested > interrupt would cause a problem. keep interrupts masked for as long as necessary until your message is processed. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXjIAsAAoJEIaOsuA1yqREZ9gP/1mVzabxDXgO5g6Ve+CQ0a+J JAyP6+Hsz8iHNaak6WRSdNOSeeaPb4h5ICaGXcQdQSf6UG+UP2VstwWUPBq1gr4M v2EuQHj/3hPjOt2VF/Qc6O+2Z4hqT7t5Zgd3O9jmUKbzcJ/SiAXdeGmmYhuyOMnp oH/S/GLWXnXeJM7dbP1Qu8Q8wMX3sDkvkMfLDSdGEpdD3as1bMtC7QeliyBwMG7d 2ZkZ+J8NrleyWR8qzplZilVFSGMcnrL7WKXQ4tGi4W5to/nNiAwv2th2VJFV2ehQ u/bOwh0crfSo1QT7WoKs3Q16Lux+Grhc1wqxy1PtMT3Pj0MLYb9HhWvcZil+QHOF 4iILwkOZnnkf1Er42K1Nw3RpOPpYd6A3K/jM2xBXhADXm9uNd+QB8t/28SSqOjJ1 KUcJYHcrQ35eRupXHpKxQ7VTi0UnLRub3/eUK5gg7CTsYD0H6vBNazsXfYp1RZ/Y 8VpqyiPZkzXIibtRGyil3uDs5gI/bZMxkLT5ZwLS+fYbfpQBncRyaBox+a8hLRCD oDMue9yyg8NyaQ10zuEeNlRS5Nu+wfn0dcy/ydpP/Hc/mQh3IOVeCeK/gfMBPACO dlsgSzVfVy+w0J+gyhq8aWzKMt3/8ts8WMFsvnGcEnTrq4/d5cHVqBGEsq4d9INZ BeeINupnellnAT1d5hYp =DrMe -----END PGP SIGNATURE----- --=-=-=--