On 2/11/2017 22:49, Srinivas Pandruvada wrote:
On Thu, 2017-11-02 at 14:35 +0000, Jonathan Cameron wrote:
On Fri, 27 Oct 2017 18:27:02 +0200
Marc CAPDEVILLE <m.capdeville@xxxxxxxxxx> wrote:
On asus T100, Capella cm3218 chip is implemented as ambiant light
sensor. This chip expose an smbus ARA protocol device on standard
address 0x0c. The chip is not functional before all alerts are
acknowledged.
On asus T100, this device is enumerated on ACPI bus and the
description give tow I2C connection. The first is the connection to
the ARA device and the second gives the real address of the device.
So, on device probe,If the i2c address is the ARA address and the
device is enumerated via acpi, we lookup for the real address in
the ACPI resource list and change it in the client structure.
if an interrupt resource is given, and only for cm3218 chip,
we declare an smbus_alert device.
Signed-off-by: Marc CAPDEVILLE <m.capdeville@xxxxxxxxxx>
Wolfram - this needs input from you on how to neatly handle
an ACPI registered ARA.
There was another RFC from Alan cox
https://patchwork.ozlabs.org/patch/381773/
Wolfram just merged this from me:
[PATCH v11 00/10] Add sbs-manager with smbalert support
https://www.spinics.net/lists/devicetree/msg191947.html
Cleans up the smbus_alert driver a bit.
note: alert_edge_triggered was removed.
And for OF systems core creates the ara device.
--
Regards
Phil Reid
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
