RFC: pca953 new platform specific changes

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

I'm awaiting some documentation to confirm, but as I understand it the accelerometer connects one of its interrupt lines to one of the pins on the first PCA9555, which is then connected to SMB ALERT, which if I understand is somehow tied to an ACPI GPE (0x0B)).

I have a hacked together set of patches to support this device which do some horrible things to the pca953x driver. I'm trying to clean these up and handle the platform changes properly in order to get them upstreamed. I'd like to let you know what I'm attempting up front in case you have any preference regarding the implementation as I'm new to the GPIO subsystem and driver writing.

Key:
o Platform specific properties
[ ] My approach to support them

For this platform:
o Only IO 0,1,3,4,6, and 15 can be written to on the first PCA555 (0x20) [ ] Add output bitbmask to platform data
[ ] Don't allow the output_direction function to vary from this if
provided
o All pins have a specified function
[ ] Add Pin names to platform data
o Pin assignments vary slightly based on board revision, read from 2nd PCA555
[ ] ? Provide a function to perform the test to the platform data ?
o The accelerometer needs to have its interrupt line set to open-drain The current hack does this in a new pca53x detect function [ ] ? Move this to a platform data function for the accelerometer ?
o This device needs a GPE handler rather than a traditional irq thread [ ] Provide GPE or IRQ data in the platform data, choose which to setup based on that (rather large blocks of ifdefs per platform in the driver).
o Only the fist PCA555 has accessory input lines on this device, so the second should not get an interrupt handler setup.
[ ] Setup different platform data based on I2C device address with
appropriate GPE/IRQ data in the platform data setup

Does this approach seem appropriate?

Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

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