[pvrusb2] driver status; incompatible change coming...

[Mike Isely]

More bad news and an idea...

I've implemented all the needed changes which should permit tveeprom.ko to 
scan the bus, detect the eeprom, autonomously suck out its data, ... and 
it doesn't work.  Why?  Because tveeprom's attempt to probe for my eeprom 
fails.  The probe is being attempted by the I2C core on behalf of 
tveeprom.ko; it tries a write to the chip of length zero and for some 
reason the eeprom chip fails to ack such an I2C transaction and so it 
isn't detected.  (I'm puzzled by this because the chip shouldn't even be 
able to see a length of zero until after it has acked its selection over 
I2C, but this could be something screwy with the I2C proxy mechanism as 
implemented in the 8051 firmware, in which case there's very little I can 
do about it.)  I suspect (based on e-mail here a couple days ago) that on 
some devices this detection succeeds, but obviously I can't rely on it if 
it won't work in some cases.

This really sucks.

I have however come up with a very sick - some would say demented - but 
probably very effective idea which should for now completely solve the 
problem, and give us back the ability to retrieve the device's serial 
number...

If I can somehow detect which tveeprom.ko is in use, then I can adjust the 
driver to handle it properly using the direct call method that's been in 
use all along.  Here's the idea:  The two tveeprom.ko variants expect 
different struct tveeprom definitions.  Specifically those two structs are 
different sizes and the members are laid out differently internal to the 
structure.  I can really only define one structure and must choose one or 
the other.  So here's what we do: I allocate enough storage for the 
largest possible variant of this structure, and poison it with obviously 
bad data.  Then I call the tveeprom_hauppauge_analog() as usual, passing 
in this storage as "the" tveeprom struct instance.  Upon return I inspect 
the storage and see how much of it actually changed.  That will allow 
detection of which structure was being actually used - by inference from 
how much of the space was actually touched.  Then the driver logically 
overlays the correct definition and extracts the data.  This is a 
positively SICK, DIGUSTING way of interacting with an external module, but 
we are dealing with APIs that are not staying stable, and as far as I can 
tell the "stable" way to do this (which doesn't even provide everything we 
want), doesn't even work on my PVR USB2 because the chip refuses to be 
correctly detected!

Anyway, still working on a sane way to interact with that piece of 
quicksand otherwise known as tveeprom.ko...

   -Mike


-- 
                         |         Mike Isely          |     PGP fingerprint
      Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                         |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                         |                             |