Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined?
embaudarm at gmail.com
Wed Mar 28 20:34:22 UTC 2018
On Sun, Mar 18, 2018 at 10:30 AM, Ian Lepore <ian at freebsd.org> wrote:
> Nostop is an ivar of the child device, so iicbus_get_nostop() is formed
> by the IICBUS_ACCESSOR macro in iicbus.h.
> Now for the bad news: don't use it. It doesn't work. It's 100% a bug
> in the code that maybe kinda-sorta seemed to work for whoever added it,
> because accidentally the right garbage was on the stack in the local
> nostop var. The generic transfer code doesn't check that the accessor
> failed so it ends up using stack garbage for nostop. The reason
> there's g'teed to be no such ivar is because the code is asking the
> wrong device, and it doesn't even have a handle to the right child
> device to get the info it wants.
> So the bottom line is, write your transfer routine to work however it
> has to work. That might mean ignoring the stop/nostop flags and just
> doing whatever your hardware does. Like if a write transaction is
> handled by the hardware by putting the slave address and the offse-
> within-slave values into registers and it does a write of the offset
> then a read from the slave and you get no control over whether it does
> that as two transactions or as 1 transaction with a repeat-start
> between the read and write, then just silently do it that way.
> I had forgotten about the nostop mess, which I discovered some time
> last year. It really needs to be fixed the right way, which is to
> remove the nostop hack, remove all uses of the NOSTOP flag everywhere
> in the code, and make the default behavior that all back-to-back
> operations in the same array of cmds handed to a single transfer call
> have implicit repeat-start behavior when changing slave or direction.
> We could add a specific STOP flag to force a stop/start between two
> commands, but even that's not really needed.
> The only example of a transfer-only driver I know of offhand is the rpi
> driver (arm/broadcom/bcm2835/bcm2835_bsc.c). Unfortunately, bugs in
> the rpi silicon complicate the code and make it a messy example.
> -- Ian
First let me apologize for taking so long to respond.
What you've told me is actually good news as far as I am concerned,
that I can just do what needs to be done in my driver.
More information about the freebsd-hackers