We've moved away from using platform data in our project because it's clunky, and because we implemented the config loading that's similar to what you submitted elsewhere in this series. Furthermore, for our ARM projects specifically, we are using flattened device trees to describe our board and instantiate devices. The upside is that it means that we no longer have to modify the kernel to bring up a new board with some varied hardware. The downside is that it's impossible to setup platform data for i2c devices from the device tree. drivers/of/of_i2c.c instantiates i2c devices including the atmel touch device, and it doesn't and shouldn't know about how atmel_mxt_ts's platform data is structured. All it does is i2c_new_device on the right adapter, at the right address, and optionally pass in an irq #. On Fri, Feb 22, 2013 at 11:51 AM, Nick Dyer <nick.dyer@xxxxxxxxxxx> wrote: > Benson Leung wrote: >> This is disappointing that Atmel decided to change the bootloader >> address scheme for the 1664S family. Unfortunately, this ifdef won't >> work for situations where there are more than one Atmel device of a >> different kind on a system using this same driver. >> >> For the Chromebook Pixel, we use the same atmel_mxt_ts driver for a >> 1664S device and a 224SL. >> >> The 1664S has the pair 0x26 and 0x4a, while the 224SL has 0x25 and >> 0x4b. > > If I put a bootloader address override in the platform data will that meet > your requirements? -- Benson Leung Software Engineer, Chrom* OS bleung@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
