linux-kernel - Re: Multiple Zoran MJPEG cards and i2c misattachments

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20080601212837.GA10699@fluff.org.uk>
Date:	Sun, 1 Jun 2008 22:28:37 +0100
From:	Ben Dooks <ben@...ff.org>
To:	Martin Samuelsson <sam.linux.kernel@...il.com>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: Multiple Zoran MJPEG cards and i2c misattachments

On Sat, May 31, 2008 at 08:39:25PM +0200, Martin Samuelsson wrote:
> Hello,
> 
> I'm working on avs6eyes improvements in the current kernel. As I've
> equipped my machine with no less than three MJPEG-cards; Buz, 6 Eyes
> and DC10+, I happened to run into a bit of a snag:
> 
> saa7185, the video encoder of the Buz, and bt866, video encoder of the
> 6 Eyes, share the same i2c address, 0x88. This should not be a
> problem, because they are connected to different i2c buses, and are
> initialized separately. However, zoran_card.c, via i2c_bit_add_bus(),
> creates one i2c bus for each card in the detection loop, and makes
> them available system-wide. This means that the saa7185 driver, as the
> cards are detected in Buz, 6 Eyes, DC10+ order in my computer, is
> being requested by the zoran driver and initializes itself (not very
> much to do, as there is not yet any i2c bus). The zoran driver then
> creates bus 0, and initializes the saa7185 driver once again, it finds
> bus 0 and a chip at 0x88, which it attaches to.
> 
> Now, that bus is visible to the system. The 6 Eyes is being
> initialized, the bt866 driver loaded, and it initializes itself.
> Here's the problem: At load, the drivers automatically searches the
> system for available buses. bt866 finds bus 0, belonging to Buz, and a
> chip at 0x88, which it promptly attaches to, marking itself as in use.

Do each of the devices creating the i2c busses know what devices are
on the i2c bus at time of creation? If so then the use of the new
style driver addition and device binding would be far more appropriate
to this, as the i2c devices will be bound depending on the device list
registered at bus creation time.

> What would be a working approach to fix this situation? I'm woefully
> unaware of the i2c intricacies in the kernel, and know no immediate
> fix.
> 
> Is it possible to register i2c buses that are not visible to drivers
> you modprobe? That would prevent the initial scan of the buses, and
> the misattachments. zoran_card.c explicitly initialize the correct
> drivers after bus creation anyway.

See above, i've not had time to go through and read all the drivers
outside of drivers/i2c yet

PS, this should have probably gone to the i2c list as well, and
probably the linux-dvb list too.

-- 
Ben (ben@...ff.org, http://www.fluff.org/)

  'a smiley only costs 4 bytes'
--
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/