On Thu, Aug 25, 2016 at 08:39:24PM +0200, Bjørn Mork wrote: > Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes: > > On Thu, Aug 25, 2016 at 07:14:52AM +0200, Rafał Miłecki wrote: > >> > >> Good question. I would like to extend this USB port trigger in the > >> future by reacting to USB activity. This involves playing with URBs > >> and I believe that at that point it'd be getting too much USB specific > >> to /rule them all/. > > > > Oh that's never going to work, sorry. USB "activity" happens deep in > > USB host controller hardware, not up at the kernel level at all. It's > > just too fast, and would take up too much CPU to do it otherwise. Heck, > > even old UHCI 1.1 USB controllers did this. > > > > USB "activity" happens all the time, look at a USB bus analyzer if you > > want to see what goes on. Teasing out what is "real data" and what is > > just "normal bus activity" is impossible at the kernel level, > > OK, I am going to play stupid again: Does this mean that usbmon is > impossible? Hah, nice try :) I guess when I think "USB activity" I think about the lower layers of frames and acks and naks on the bus. But maybe because I have just recently been doing a lot of work down at the EHCI frame timing layer for some strange hardware... But you are right, if all you care about is the data that the host sees, then yes, you could do something like usbmon to "tickle" a led if you want to. Odds are, someone's already done this for a raspberry pi :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
