Date: Wed, 28 Mar 2018 16:33:40 -0400 From: Lee D <embaudarm@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? Message-ID: <CANC_bnPxsV6Wp%2BDGD7Q4gcAg3SkkPqL3=ir9yRKjbjnnCqpq1A@mail.gmail.com> In-Reply-To: <1521383420.99081.87.camel@freebsd.org> References: <CANC_bnOVAb7R%2Bc_8x66Gz5A1nNjJQ8NXpkaF4A85N0gnEjyO%2Bw@mail.gmail.com> <1521383420.99081.87.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Mar 18, 2018 at 10:30 AM, Ian Lepore <ian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANC_bnPxsV6Wp%2BDGD7Q4gcAg3SkkPqL3=ir9yRKjbjnnCqpq1A>