linux-kernel - Re: [PATCH 0/2] Platform: x86: chromeos_laptop

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-prev] [day] [month] [year] [list]

Date:	Sun, 4 Aug 2013 21:05:50 -0700
From:	Benson Leung <bleung@...omium.org>
To:	Martin Nordholts <enselic@...il.com>
Cc:	Matthew Garrett <matthew.garrett@...ula.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"platform-driver-x86@...r.kernel.org" 
	<platform-driver-x86@...r.kernel.org>, adurbin@...omium.org,
	Olof Johansson <olofj@...omium.org>,
	Axel Lin <axel.lin@...ics.com>
Subject: Re: [PATCH 0/2] Platform: x86: chromeos_laptop - Deferred Probing

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@...il.com> 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@...omium.org
--
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/