linux-kernel - Re: RFC: pca953 new platform specific changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACRpkdbq+EPO8xZRgL3d3XNZMAKKB_i5BZJjYF1T2HTu3Up=yg@mail.gmail.com>
Date:	Thu, 5 Jul 2012 15:18:56 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Darren Hart <dvhart@...ux.intel.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Eric Miao <eric.miao@...vell.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Linus Walleij <linus.walleij@...ricsson.com>,
	Rob Herring <rob.herring@...xeda.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Srinidhi KASAGAR <srinidhi.kasagar@...ricsson.com>
Subject: Re: RFC: pca953 new platform specific changes

On Thu, Jun 21, 2012 at 4:43 AM, Darren Hart <dvhart@...ux.intel.com> wrote:

> I'm working on support for a device which combines a pair of PCA9555
> gpio chips with an LIS331DLH accelerometer on an I2C bus.

What we usually do in these cases is create a root device of MFD
class (see drivers/mfd/* for examples) which spawns children, in this
case two PCA9555 and one LIS331DLH devices. The MFD device
typically gets to funnel all requests to (e.g.) read and write registers
on the subdevices.

Now since IIUC, the PCA9555 already has a driver which sits directly
on I2C, and I think my friend Srinidhi is working on a IIO driver for
the LIS331DLH (maybe I confused named, tell me if I misunderstood)
and each of these may be parked directly on top of I2C, they need
different bus backends.

In the pca953x the register reads/writes are already nicely split off
into functions named pca953x_read_reg()/pca953x_write_reg()
so as a first step split out the I2C bus adoption and whatever
goes into that layer as a separate file named
drivers/gpio/gpio-pca953x-i2c.c[.h].

Then as a second step abstract the register read+write functions
totally and have the I2C portions fill in a vtable when calling up
to the main driver, so the main portion of the driver has no clue
it is sitting on I2C, this is all abstracted away and hidden.

Then as a third step add your MFD backend which provides an
MFD funnel to the same functions by providing another set
of functions to the vtable, that will not talk to the I2C bus but to
your MFD funnel, so instead of probing to the I2C bus, it will
probe from an MFD cell instatiated from the MFD funnel driver.

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/