[pvrusb2] Ability to fully reset a PVRUSB2 Device

[Mike Isely]

Patch to be posted here shortly.  Sorry that it's been a week; I've been 
time-slicing this with other (unrelated) tasks.  I expect that the patch 
will apply cleanly to any recent kernel version, since the surrounding 
code has been largely unchanged for so long.

If you haven't already done so, I recommend you pick the kernel you want 
to use and fetch / recompile it now.  Then once it is built all you will 
need to do it apply the patch and run "make modules", which will go very 
quickly since it's just one source file in an ocean of sources that 
would need to rebuild.

Note: The kernel build system properly manages its dependency tree, 
which said another way, means that you can use the -j option to the make 
command to parallelize and potentially massively speed up the build 
process.  I generally use a -j setting that is roughly 2x the number of 
cores on the system where I am building.

While there are ways around having to build everything first - back when 
I distributed up-to-date standalone versions of the driver there was a 
process for building it just using kernel headers - probably the easiest 
for you right now is just to get a good kernel compilation environment 
set up first.

  -Mike


On Tue, 22 Oct 2019, Diego Rivera wrote:

> 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
> 

-- 

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