[pvrusb2] Ability to fully reset a PVRUSB2 Device

[Mike Isely]

On Sat, 21 Sep 2019, Diego Rivera wrote:

> Thanks for the update!
> It occurred to me: what if for #3, instead of the driver not handling the error, it's simply
> expecting a different/new (type of) error to be raised in order to go through a code path that leads
> to it not getting borked? Bah ... I'm sure you've thought of this ☺
> Cheers!

Well anything is possible.  However EIO is generally understood to mean 
"I/O error" which in fact this is.

I just added a dump_stack() call after detecting the error, and the 
guilty component is the I2C IR chip-level driver (the thing that watches 
the IR port and figures out what buttons you press on the remote).  
It's coming from a call to get_key_haup_common() which is in 
ir-kbd-i2c.c. That code is not written with any loop, but it pretty 
clearly itself returns -EIO to its caller if the I2C transfer attempt 
fails (for any reason).  The caller can only be get_key_haup() but it 
looks like the compiler optimized that away so it isn't showing up in 
the stack trace.  Stack frames above that point "look" like it might be 
coming from userspace, so - on the Ubuntu system where I'm playing with 
this, a userspace IR daemon might be in play here.  It might be the 
thing pounding on the pvrusb2 driver - in this scenario.

I'm not familiar with that i2c kbd driver but there are a lot of avenues 
to look at here.  For example, I can probably disable away that whole 
thing so I can turn my attention to #1.  I also have several different 
pvrusb2 devices here and they each have different IR designs which may 
cause different upstream behavior.  Like I said, a number of avenues 
here.

  -Mike

-- 

Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8