linux-kernel - Re: [v4l-dvb-maintainer] saa7134 duplicate device in module, but different device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1214525206.7150.118.camel@cunning>
Date:	Thu, 26 Jun 2008 20:06:46 -0400
From:	Ben Collins <ben.collins@...onical.com>
To:	hermann pitton <hermann-pitton@...or.de>
Cc:	Hartmut Hackmann <hartmut.hackmann@...nline.de>,
	v4l-dvb-maintainer@...uxtv.org,
	kernel list <linux-kernel@...r.kernel.org>,
	video4linux-list@...hat.com
Subject: Re: [v4l-dvb-maintainer] saa7134 duplicate device in module, but
	different device_data?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/