[pvrusb2] Ability to fully reset a PVRUSB2 Device

Diego Rivera diego.rivera.cr at gmail.com
Tue Oct 22 09:32:45 CDT 2019


This is excellent news, Mike!!!
I'd very much like that patch, please! It's been YEARS since I've recompiled a kernel, so this will
be a fun trip down memory lane!
How long do you think till this patch gets merged into the mainline kernels? Is that even a
reasonable aspiration? Asking for a friend 😄
As for the I2C thing, the driver can be blacklisted so that's one workaround.
Cheers!
On Mon, 2019-10-21 at 20:19 -0500, Mike Isely wrote:
> Update...
> So the kernel oops is happening because the driver is trying to tear down state for a V4L2 radio
> device - except there was no radio device configured so the tear-down ended up dereferencing
> through a null pointer.  Boom.
> I backtracked through the code to figure out "why now", and I could not find a reason.  From what
> I can tell this bug has likely been there for about 11 years.  The code which bypasses setup of
> the radio device takes that path if there's no radio support configured for the hardware - which
> is sadly the case for the HVR-1950 - and git blame shows that area of code last modified in
> 2008.  (That makes sense because that's about when the HVR-1950 was added.)  Best I can figure
> that some other happenstance had to have prevented the kernel from blowing up on this
> pointer.  FWIW, it's actually trying to dereference an offset from null, but the distance to the
> offset is still small enough that it should fit in the first virtual page address and thus be
> detected.
> Anyway, I made a change to the two places in the code where this matters, basically don't touch
> the radio data structure if it isn't there, and now the kernel oops is gone.
> This also explains why I could not reproduce the problem before - because the different device I
> was trying has a working radio in it that can be operated by the pvrusb2 driver.  Thus this
> condition did not arise.
> There's still other strangeness to figure out, namely the sysfs teardown problem and implementing
> *something* to keep a userspace I2C client from jamming up the pvrusb2 driver.  But this is
> progress.
> Obviously I will get this pushed.  I can send you a source patch if you'd like to try rebuilding
> the module on your end.  Since we're not running identical kernels I can't just send you the
> binary.
>   -Mike
-- 



Diego Rivera

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
URL: <http://www.isely.net/pipermail/pvrusb2/attachments/20191022/62858873/attachment.sig>


More information about the pvrusb2 mailing list