On Fri, May 18, 2007, Manu Abraham wrote: > Johannes Stezenbach wrote: > > On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote: > > > >> IMHO, it isn't possible > >> to split a read request into a single write and a single read request > >> outside of the core device. The device must be locked during both > >> transfers. If the device isn't locked, it is possible that another > >> transfer will change the slave offset before the content is read. This > >> may occur with the current implementation. > > > > If locking is necessary the drivers would need to > > handle this explicitely (I think it isn't unless ou start > > messing mith /dev/i2c concurrently). > > even if you do a concurrent operation with /dev/i2c, the i2c bus driver > read/write provides concurrency locks, afiacs. Or am i missing something ? One i2c_transfer() is atomic, if you do two (as required by stv0297) another transfer could happen in between. So intead of e.g. stv0297 send register number stv0297 read register data i2c-dev send another register number i2c-dev read register data you might get stv0297 send register number i2c-dev send another register number stv0297 read register data i2c-dev read register data I don't think there is any lock which would prevent this, is there? (The BKL might protect two i2c-dev accesses from each other, but not against the accesses from the dvb_frontend_thread.) But I also think that messing with i2c-dev on the frontend i2c bus is a debug tool and not a regular use case. Johannes _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
