> Hi David,> > There is no need to do the first two bytes first. As far as I can tell > it was done to avoid having to allocate a local buffer. The initial > version of this code was writing much larger blocks at a time to the > i2c bus, so having to setup a large buffer on the stack was > undesirable. The pvrusb driver requires a much smaller buffer (FWSEND), > but the code was never changed. Now, however, the initial four-byte > write is just in the way and can be removed in favor of always writing > FWSEND-sized blocks of data.> > I've CC-ed Mike Isely, the pvrusb2 maintainer, just in case there is an > outlandish restriction I'm not aware of on that USB device requiring > the firmware load to be done this way.>

The pvrusb2 driver's FWSEND limit is an artifact of the hardware and cannot be changed. HOWEVER, in the standalone driver (not in the kernel) I have a hack implemented that can monitor and intercept such I2C operations and break them into smaller I2C transactions. I implemented this to allow the standalone driver to function correctly on some older kernels where FWSEND is too large. I can enable that hack for the kernel driver and thus lift the limit. But without it, FWSEND absolutely has to be small enough that the entire transaction (including a few bytes of transport overhead) can fit within a 64 byte URB.

I see that this change allocates a local buffer on the stack (sized by FWSEND). Though the buffer is small (48 bytes, see above paragraph), it is controlled by a macro and thus leaves open the possibility that it could be accidentally increased to a point where the stack gets overflowed. Seems like not a good idea, but either way it should not affect the pvrusb2 driver.