Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined?

[Lee D]

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.

So thanks!

Lee