From owner-freebsd-arch@FreeBSD.ORG Wed Mar 25 17:18:06 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDFD178D; Wed, 25 Mar 2015 17:18:05 +0000 (UTC) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A60AF6AC; Wed, 25 Mar 2015 17:18:05 +0000 (UTC) Received: by iecvj10 with SMTP id vj10so27518705iec.0; Wed, 25 Mar 2015 10:18:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=QCuXQ7kcTZynztQBJp8U5OXG1GT9khWcfOrKVJ54Q6g=; b=yn6VRogHGFH+ZeZIYPfx4wRMwn7bqIHYo0diNsMHEIhKTpzpH+gGrM8PFja4c/qr6h aiisfjyomaaN+YGIP7Vbrp5vyh1X7yOxnQoieeGaKR6dxCr6aNuE3Mq6LyJwAQAgG+9A wR0cBIOIem5z3pElqvF8YYuV8/zqAxskmRgj1noN8xKw4DJUy4HsKkYaahVgMZVG1Al+ NqPf8X+fPE2daEyNyI8KbWGBauNn6+lXfzNUXEjQeSIzhWa8uoniKncozVl2K66bOx/2 Wfnx3uwynwpw5l2N/Vhkahn3wYeMdJOgDNPYWWAVAbBqt4YunnHbgH4UE38NX3UB/z1o yDhg== MIME-Version: 1.0 X-Received: by 10.50.36.104 with SMTP id p8mr31100337igj.16.1427303884944; Wed, 25 Mar 2015 10:18:04 -0700 (PDT) Received: by 10.36.101.18 with HTTP; Wed, 25 Mar 2015 10:18:04 -0700 (PDT) Date: Wed, 25 Mar 2015 12:18:04 -0500 Message-ID: Subject: Proposed rewrite of iic(4) From: Jason Harmening To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-drivers@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 17:18:06 -0000 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