[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOesGMj3urrhy83o1aD4q3K0CqOL6ZrchknmdvgHDWkahavQQA@mail.gmail.com>
Date: Fri, 2 Nov 2012 13:45:26 +0100
From: Olof Johansson <olof@...om.net>
To: Corentin Chary <corentin.chary@...il.com>
Cc: Benson Leung <bleung@...omium.org>, mjg@...hat.com,
platform-driver-x86@...r.kernel.org, linux-kernel@...r.kernel.org,
olofj@...omium.org
Subject: Re: [PATCH v2 1/1] Platform: x86: Add Chrome OS Laptop driver
On Fri, Oct 26, 2012 at 10:30 AM, Corentin Chary
<corentin.chary@...il.com> wrote:
> Looks better, but I'm curious, what is the final purpose of this driver ?
> What ABI will be exposed, who will use it ?
>
> If it is going to be bigger, it may be a good idea to convert it to a
> real platform driver (platform_drivers/platform_device stuff).
It's not a driver per se. It's platform glue that, based on the DMI
table, registers platform and i2c devices (at this time only i2c
devices).
Unfortunately there's no way to do this nicely from userspace after
boot, since there's limits to how much data you can provide with the
simpler userspace-driven i2c probing protocol.
So, there's no user-facing ABI on this, and no one is expected to use
it from userspace. It's just there to make sure that the un-probably
devices on this kind of hardware gets bound to drivers properly.
If it's converted to a platform_driver, how do you expect that to
probe, where would the platform_device be registered?
-Olof
--
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/
Powered by blists - more mailing lists