[lkml]   [2016]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH V3] leds: trigger: Introduce an USB port trigger
On Thu, Aug 25, 2016 at 08:39:24PM +0200, Bjørn Mork wrote:
> Greg KH <> 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 :)


greg k-h

 \ /
  Last update: 2016-09-17 09:57    [W:0.058 / U:1.928 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site