Date: Wed, 25 Mar 2015 12:18:04 -0500 From: Jason Harmening <jason.harmening@gmail.com> To: freebsd-arch@freebsd.org Cc: freebsd-drivers@freebsd.org Subject: Proposed rewrite of iic(4) Message-ID: <CAM=8qaky0mN3K3D=WWGgBJJ%2BROHM5Nv1gLNiwRar2RABNYNjXg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi everyone, I am attempting to tackle the big issues with iic(4)...the limitations on read/write length, the limit of only one open fd at a time, and the need to issue I2CSTART before read(2)/write(2) can work. I want to do this in a way that doesn't break existing applications such as i2c(8). Along with that, I have some fixes for iicbus_request_bus() and iicbus_release_bus(): --right now, iicbus_request_bus() can fall through and succeed if the requesting device already owns the bus, making it "device-recursive" if you will. Having multiple threads on iic(4) wouldn't work with that scheme, and it is also problematic because iicbus_release_bus() is not device-recursive. --if the call to IICBUS_CALLBACK in iicbus_request_bus() fails but the following call to iicbus_poll() succeeds, then IICBUS_CALLBACK won't be called again --Holding the iicbus mtx across IICBUS_CALLBACK seems dangerous. In fact, it looks like there are several drivers that could have issues with that: --lpbb and gpioiic can sleep in their IICBB_CALLBACK if IIC_WAIT is passed --bktr/bktr_i2c.c grabs Giant in its IICBB_CALLBACK, which can sleep and also seems prone to LOR if the iicbus mtx is held. The review is at https://reviews.freebsd.org/D2140 if you want to chime in and poke holes :) --Jason
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM=8qaky0mN3K3D=WWGgBJJ%2BROHM5Nv1gLNiwRar2RABNYNjXg>