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-next>] [day] [month] [year] [list]
Message-ID: <4FE28A4D.7060302@linux.intel.com>
Date:	Wed, 20 Jun 2012 19:43:25 -0700
From:	Darren Hart <dvhart@...ux.intel.com>
To:	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>
Subject: 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

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ