Sounds like another goofy TI I2C (USB-C part?) slave interface. Two thoughts ...
Is the part smart enough to send a "STOP" after it has transferred the (variable) length read? Or does it just keep going? If the part is smart enough to send a stop when it is done, wrap an error handler around a [equal to maximum} byte read transfer, and let it exit gracefully on the error condition when the part sends a "premature" stop. Then process what it gave you. Worst case, you always read the full maximum length buffer and process according to the initial byte length given. Reference: https://www.kernel.org/doc/Documentation/i2c/dev-interface --- Graham == On Monday, February 12, 2018 at 7:36:54 PM UTC-6, Andrew P. Lentvorski wrote: > > Looking at the driver at: > https://github.com/torvalds/linux/blob/master/drivers/i2c/busses/i2c-davinci.c > > It looks like i2c_davinci_isr() only terminates a read via > terminate_read() which doesn't seem to have an exit path for completion > without STOP. > > It would be nice if somebody with more experience than me could verify > this, as I'm going to have to go to a bit-banged driver otherwise. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/7e233048-376f-4cf3-ae03-5345c372eba6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
