linux-kernel - Re: [GIT PULL for 2.6.37-rc1] V4L/DVB updates

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: <4CC85771.2080307@redhat.com>
Date:	Wed, 27 Oct 2010 14:46:41 -0200
From:	Mauro Carvalho Chehab <mchehab@...hat.com>
To:	Devin Heitmueller <dheitmueller@...nellabs.com>
CC:	Jiri Slaby <jirislaby@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Media Mailing List <linux-media@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Michael Krufky <mkrufky@...nellabs.com>
Subject: Re: [GIT PULL for 2.6.37-rc1] V4L/DVB updates

Em 27-10-2010 13:48, Devin Heitmueller escreveu:
> On Wed, Oct 27, 2010 at 11:41 AM, Mauro Carvalho Chehab
> 
> Have you looked at the code for how the Conexant guys got the xc5000
> firmware load to work (which uses 64 bytes at a time).  I suspect what
> *really* needs to happen is that needs to be made generic so that the
> stop bit is properly set (which would allow a single i2c transaction
> to span across multiple USB control messages).
> 
> Note that the xc5000 hack is actually two changes merged together -
> one uses a GPIO mode in certain cases to handle clock stretching
> properly (which probably has to stay there for now), and the other
> allows for larger i2c transactions.  I am referring to the latter
> change.
> 
> If we fix the cx231xx i2c master, then we can go back to the original
> 18271 config, which avoids the risk of regression for other devices.

The original code is broken, as it doesn't properly honour a max size of 8.
Even if we do some optimization at cx231xx, we still need to fix the tda18271
code, as it is trying to use more than 8 bytes on some writes.

Also, as you noticed, the way cx231xx sends large firmwares to xc5000 is a hack:
it requires to identify that the I2C device is a xc5000 and do an special
treatment for it.

We may actually move all those small_i2c logic to the bridge drivers, adding
those hacks inside the I2C adapter part, but this means that they'll need to 
have some complex-logic that are dependent on what device is connected to it,
damaging the benefits that the I2C bus abstraction brings.

Instead of polluting bridge drivers with I2C-device specific code, the proper
way seems to use parameters to adjust the maximum size, eventually flagging
the broken messages in a way that the I2C adapter won't sent a stop transaction
in the middle of a larger initialization like this one.

Cheers,
Mauro
--
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/