Re: [v4l-dvb-maintainer] saa7134 duplicate device in module, butdifferent device_data?

[Ben Collins]

On Fri, 2008-06-27 at 01:56 +0200, hermann pitton wrote:
> Hello,
> 
> Am Donnerstag, den 26.06.2008, 13:24 -0400 schrieb Ben Collins:
> > In the saa7134 module, there are these two entries in
> > MODULE_DEVICE_TABLE():
> > 
> > 
> >         },{
> >                 .vendor       = PCI_VENDOR_ID_PHILIPS,
> >                 .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
> >                 .subvendor    = 0x185b,
> >                 .subdevice    = 0xc100,
> >                 .driver_data  = SAA7134_BOARD_VIDEOMATE_TV,
> >         },{
> >                 .vendor       = PCI_VENDOR_ID_PHILIPS,
> >                 .device       = PCI_DEVICE_ID_PHILIPS_SAA7133,
> >                 .subvendor    = 0x185b,
> >                 .subdevice    = 0xc100,
> >                 .driver_data  = SAA7134_BOARD_VIDEOMATE_TV_GOLD_PLUS,
> >         },{
> > 
> > Both will exactly match, and I assume only the first one will ever be
> > used, hence the second is just a wasted dupe. At least, I would assume
> > if not for the differing driver_data. Anyway to clear up this ambiguity?
> > 
> 
> there are even more devices with the same PCI device and subsystem ID
> from that vendor and the problem goes also over saa7133 and saa7135
> devices, for which we have no means to detect them as different, but the
> saa7133 does only NTSC-M system TV sound decoding and saa7135 and the
> even later saa7131e global analog TV sound.
> 
> For the early saa7133 SAA7134_BOARD_VIDEOMATE_TV we don't have eeprom
> readout data and the contributor doesn't have the card anymore.
> A request for helping out with such on the list had no result so far.
> 
> As of now, we can't try to separate them by eeprom differences, which
> would be the best attempt and is done for some other Compro products
> with similar flaws already.
> 
> Before that likely possible eeprom detection ever happens, we have two
> options left to make you feel better.
> 
> Kick both out of the auto detection and the users will get a list of
> supported devices printed out, from which they have to choose.
> 
> Leave the oldest one in and print some warnings that they have to look
> it up for their newer cards. Naming is quite consistent, except some
> early Gold Plus II variants seen first in New Zealand coming with Gold
> Plus only stickers. They also come with different tuners, latest have a
> separate silicon radio tuner and all such usual ...
> 
> Patches are always welcome.
> 
> Internally it was only a reminder for missing eeprom data to be
> investigated.

Well I was thinking that mainly, this was just a table for loading and
binding the driver with a device. In that case, only one entry is
needed. The probing would have to decide which device it is.

I'm not up for suggesting a fix, because I don't know enough about the
background. This email is just a friendly reminder that there exists
ambiguity, and at least for one of these devices, the driver isn't going
to detect it properly anyway :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/