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

[xavier.gnata at free.fr]

> The pvrusb2 driver has been calling directly into the eeprom parsing code
> within tveeprom.c in order to detect various things about the tuner.
> Unfortunately with kernel version 2.6.14, tveeprom.c between kernel
> version 2.6.14 and ivtv version 0.4.0 have now diverged far enough that I
> can't keep the driver compatible with both at the same time.  The core
> problem is that both versions of tveeprom.c's parsing function work with a
> "struct tveeprom" type and the struct definitions are incompatibly
> different between the two.  There's no way to support both anymore.

Ok. It is not really a bad new or at least not a surpise.

> There is another way to get eeprom information out of tveeprom.c.  Rather
> than calling directly into it, the driver can operate it just like another
> chip level driver (e.g. tuner.ko, msp3400.ko, etc).  The interface for
> this style of operation is more stable and remains compatible.
> Unfortunately, this more stable interface provides less information; it
> provides no means for retrieving the device's serial number, and sysfs
> uses that in constructing the path to the sysfs control interface.

This is a bad news :(

> At this point I don't think I have any choice.  In order to support 2.6.14
> with some semblence of sanity while still playing nice with ivtv, I have
> to switch the driver over towards using tveeprom.ko like another I2C chip
> driver, but in doing so I will lose the ability to retrieve the device's
> serial number.

Are we sure the API is quite stable now? I mean : Is there a chance to be able
to read the serial using this API say in 2.6.15? Ok my question is quite
non-sense because kernel API are moving so fast...never mind ;)

  I can use the unit number (just an instance ID starting at
> 'a' or zero as devices are found) in place of the serial number for
> constructing that sysfs path.  So instead of "/sys/class/pvrusb2/sn-XXXX"
> (where "XXXX" is the serial number) the sysfs path would become something
> like "/sys/class/pvrusb2/unit-uu" (where "uu" becomes just a letter or
> number which increments with the number of tuners in use).

Sounds good fot me :)

> Anyone have any opinion on this?  I imagine the only ones who would really
> be affected are those trying multiple tuners, but even in that case it
> will still be possible to continue using multiple tuners.

Yep. Can anyone test that with more than only one card?

> I've already committed a whole bunch of minor tweaks needed for operation
> in the 2.6.14 kernel, and I have a number of changes that need to happen
> in the driver for this to work.  The tveeprom.c that's part of the 2.6.14
> kernel sources indeed expects to be able to read the entire eeprom in a
> single call (see earlier thread today) and I'll have to emulate that with
> the pvrusb2 driver's I2C adapter.  Also, I need to adjust the driver to
> not require the serial number anymore, and most of pvrusb2-eeprom.c will
> have to be rewritten.

> Hopefully I can get it all done tomorrow.
 Do noy forget to jhave some rest at WE :)

After that is all in place, then the pvrusb2 driver should work correctly under
> the 2.6.14 kernel and/or with ivtv 0.4.0.

I'm haapy to hear that because my wifi card in now supported in kernel 2.6.14
(It used to work with 2.6.13 but the patch was not in the official kernel
sources) ;)

Xavier.