Hi Martin,
I commented on your patch, but I want to add a little bit more in response here.
On Thu, Jul 18, 2013 at 9:13 AM, Martin Nordholts <enselic@xxxxxxxxx> wrote:
> One downside with the solution in this set of patches is that more
> lines are added to the driver.
> By making use of the i2c_driver.detect() mechanism like in my patch,
> we can actually reduce the number of lines in the driver.
>
It looks like the vast majority of the savings in number of lines of
code in your patch is from removing the board specific enumeration of
peripherals.
For example, in my patch, I have a data structure that describes the
chromebook pixel thusly :
static struct chromeos_laptop chromebook_pixel = {
.i2c_peripherals = {
/* Touch Screen. */
{ .add = setup_atmel_1664s_ts, I2C_ADAPTER_PANEL },
/* Touchpad. */
{ .add = setup_atmel_224s_tp, I2C_ADAPTER_VGADDC },
/* Light Sensor. */
{ .add = setup_isl29018_als, I2C_ADAPTER_PANEL },
},
};
And so on for every other board that the driver supports. It
explicitly describes the small set of devices that are known to exist
on a particular system, and describes precisely which bus it lives on.
That way, we can use i2c_new_probed_device.
Your patch removes these, and instead, makes one list of all devices
that the driver supports across all systems that pass the dmi check.
Your driver then uses detect in sort of a shotgun approach for all
supported i2c adapters. The approach may work for Pixel, but as I
mentioned in my other email, it causes failed probes on other systems.
It would be my preference to continue to use i2c_new_probed_device,
and explicitly describe each Chromebook system
--
Benson Leung
Software Engineer, Chrom* OS
bleung@xxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
