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 beagleboard+unsubscr...@googlegroups.com.
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.

Reply via email to