[pvrusb2] Ability to fully reset a PVRUSB2 Device

Diego Rivera diego.rivera.cr at gmail.com
Sat Sep 21 20:37:22 CDT 2019


This is good news! Any progress is good progress! Perhaps disabling that
bit somehow can provide a workaround? Maybe the whole I2C IR stack can be
disabled system-wide? My box doesn't use that, so...?

Cheers!

--

Diego Rivera

On Sat, Sep 21, 2019, 19:30 Mike Isely <isely at isely.net> wrote:

> 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
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>


More information about the pvrusb2 mailing list