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: >> > > >> >> > > >> Hi, >> > > >> >> > > >> 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)"); >> > > >> > +} >> > > >> >> > > >> this is problematic. By default, we're all using 115200 8N1 baud >> > > >> rate. This message alone prints anywhere from 50 to 100 characters (I >> > > >> didn't really count properly, these are rough numbers), and that takes: >> > > >> >> > > >> n50chars_time = 50 / (115200 / 10) = 4.3ms >> > > >> n100chars_time = 100 / (115200 / 10) = 8.6ms >> > > >> >> > > >> Considering you have 30ms to reply with Power Request after GoodCRC, 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. >> > > >> > > I can actually see this causing problems ;-) With this pr_info(), >> > > sometimes tSenderReply times out and Source gives a HardReset. Without >> > > pr_info(), type-c analyzer tells me we reply in less than 1ms. >> > > >> > > > What is wrong is that this isn't using dev_info(). >> > > >> > > right, that too. >> > > >> > > -- >> > > balbi >> > >> > When we don't have a struct device pointer for this driver, >> >> 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. -- balbi