From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752574AbcGSIcB (ORCPT ); Tue, 19 Jul 2016 04:32:01 -0400 Received: from mga01.intel.com ([192.55.52.88]:8855 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751280AbcGSIb5 (ORCPT ); Tue, 19 Jul 2016 04:31:57 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,388,1464678000"; d="asc'?scan'208";a="1019621986" From: Felipe Balbi To: Bin Gao , Greg Kroah-Hartman Cc: Heikki Krogerus , 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: <20160719053038.GA90550@worksta> References: <20160715021405.GB128987@worksta> <87mvljgp9n.fsf@linux.intel.com> <20160715111141.GB23645@kroah.com> <87k2gngn8z.fsf@linux.intel.com> <20160715224110.GB159605@worksta> <20160715234953.GB30372@kroah.com> <20160719053038.GA90550@worksta> User-Agent: Notmuch/0.22+58~g3a45d29 (https://notmuchmail.org) Emacs/25.0.95.2 (x86_64-pc-linux-gnu) Date: Tue, 19 Jul 2016 11:30:27 +0300 Message-ID: <87k2gif2sc.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: > On Sat, Jul 16, 2016 at 08:49:53AM +0900, Greg Kroah-Hartman wrote: >> On Fri, Jul 15, 2016 at 03:41:10PM -0700, Bin Gao wrote: >> > On Fri, Jul 15, 2016 at 02:21:48PM +0300, Felipe Balbi wrote: >> > > Greg Kroah-Hartman writes: >> > > > On Fri, Jul 15, 2016 at 01:38:12PM +0300, Felipe Balbi wrote: >> > > >>=20 >> > > >> Hi, >> > > >>=20 >> > > >> Bin Gao writes: >> > > >> > +static void print_message(int port, bool is_cmsg, u8 msg, bool= recv) >> > > >> > +{ >> > > >> > + pr_info("sink port %d: %s message %s %s\n", port, >> > > >> > + is_cmsg ? "Control" : "Data", >> > > >> > + msg_to_string(is_cmsg, msg), >> > > >> > + recv ? "received" : "sent(wait GOODCRC)"); >> > > >> > +} >> > > >>=20 >> > > >> this is problematic. By default, we're all using 115200 8N1 baud >> > > >> rate. This message alone prints anywhere from 50 to 100 character= s (I >> > > >> didn't really count properly, these are rough numbers), and that = takes: >> > > >>=20 >> > > >> n50chars_time =3D 50 / (115200 / 10) =3D 4.3ms >> > > >> n100chars_time =3D 100 / (115200 / 10) =3D 8.6ms >> > > >>=20 >> > > >> Considering you have 30ms to reply with Power Request after GoodC= RC, and >> > > >> considering you're printing several of these messages, they become >> > > >> really expensive and eat up valuable time from tSenderReply. >> > > > >> > > > printk() should be async, so it shouldn't be that big of a deal. >> > >=20 >> > > I can actually see this causing problems ;-) With this pr_info(), >> > > sometimes tSenderReply times out and Source gives a HardReset. Witho= ut >> > > pr_info(), type-c analyzer tells me we reply in less than 1ms. >> > >=20 >> > > > What is wrong is that this isn't using dev_info(). >> > >=20 >> > > right, that too. >> > >=20 >> > > --=20 >> > > balbi >> >=20 >> > When we don't have a struct device pointer for this driver, >>=20 >> Then you should fix that, as this is a driver for hardware :) > This is actualy a software stack to implement the USB PD spec. > Only the USB Type-C phy driver has a device pointer. what Greg is saying is that you should register yourself to the PD stack with something that passes along a pointer to the actual device. > The PD stack vs. USB Type-C phy driver is similar to TCP/IP stack > vs. ethernet driver in the kernel. We don't have a device pointer > for TCP/IP stack code either. This is the wrong analogy. =2D-=20 balbi --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXjeUjAAoJEIaOsuA1yqRE7s0P/0QLgQHhY/k+YUfj784DX72L fsEtgsCF492T6VUSl3biWVFf90OKSKzNX/H0ktOPQGwTzjNRWQodHj5HIv3FXWe7 0oNTMiFKLrqYP901PQK5F+3ccwnvS6W6Za3PxcQbfOpGC7bq7/KzYNHa2dSLNpXz EiimBPWeAUVoUsm8B6baE+B7O/CFI3QXnyY1A9LPHbFdsEH19gEtybatsiYFkPkm Is+Vx6RJ5DgpB8RZtx6NtnO3h+CRf9HqutHRvXjaD9hx0CZBm5kbpXLcxfUcYR/k QOI7CyXblk/7/Yyfvy0WUKCsW61/qlnPTRQLTzlYtJGXF8aiuozsw1ipaDOEdI25 mbbwurUaopO9lW6mE7tPMB3WrJEOoCECHRQyI29uWE8oGuBw98q3P0d6QbZ37Y8j a4yTDAbKFvOyd8Vjck49O8/au+Ovq0KmeIb2v+G9ch2MbQkNXZ20zp09ElbaQlwM yA89kt+O2hGDhgs2Q8cx06D2JZ0eueWYZ3+N1ExB8rQy31SCj+U1f80bw38Ki4WZ ecelyPpPChXDTEUNT7zvypIdTUFXl70dokaUEiUXcxnRhO/5JBGNpBwz8SiIqfQ6 KR7jnCBGiSg7A4O3CFvwHC0GIB8Rk6QZXd64SgB5eV9viIPHY1YNpdTET8xZQlQD mtyZB8ytx5SITdlIcbOQ =gfzO -----END PGP SIGNATURE----- --=-=-=--