On 18/12/14 18:00, Srinivas Pandruvada wrote: > On Thu, 2014-12-18 at 18:54 +0100, Lars-Peter Clausen wrote: >> On 12/18/2014 06:30 PM, Srinivas Pandruvada wrote: >>> On Thu, 2014-12-18 at 18:05 +0100, Lars-Peter Clausen wrote: >>>> On 12/18/2014 05:52 PM, Srinivas Pandruvada wrote: >>>>> On Thu, 2014-12-18 at 17:28 +0100, Lars-Peter Clausen wrote: >>>>>> Added I2C to Cc. >>>>>> >>>>>> On 12/15/2014 10:19 PM, Srinivas Pandruvada wrote: >>>>>>> Using i2c auto detect feature and auto device creation feature, >>>>>>> enumerate ak8975 device, by checking their presence. >>>>>>> This is needed because when this device sits behind an i2c mux, there >>>>>>> is no way to define i2c mux in ACPI. This will enable ak8975 on >>>>>>> windows based tablets/laptops running Linux when connected via a mux. >>>>>>> Since DT model already can define an i2c mux and devices connected to >>>>>>> it, this feature is only enabled for ACPI. >>>>>>> >>>>>> >>>>>> This is quite a bit of a hack. >>>>> Why? >>>>> Auto detect is standard feature of i2c devices. This is using standard >>>>> auto detect feature provided by the framework. >>>> >>>> Auto detect is ugly, slow and unreliable, it's kind of like the last straw >>>> if nothing else works. >>> That is true here. You can't enumerate this device by ACPI. As discussed >>> before we created i2c mux in inv6050 so that we can use AK8975 in bypass >>> mode. I added some API to create i2c device on this mux, which Wolfram >>> didn't like. He wanted to enumerate using existing mechanisms. >> >> If there is only a single ACPI ID that says this is a INV6050 with a AK8975 >> attached then the way to handle this is to have a driver that binds to that id >> and creates both devices. > Which address you will create device also adapter here is i2c mux > created by inv6050? You don't know i2c address of AK8975. To know AK8975 > i2c address, even ugly hack to parse propriety vendor ACPI data, which > will change between to manufacturer. > This is odd enough, that I'd like a wider range of views on it. Wolfram - was this the approach you had in mind? >> >> - Lars >> > > -- 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