Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757964Ab2KBNcJ (ORCPT ); Fri, 2 Nov 2012 09:32:09 -0400 Received: from mail-bk0-f46.google.com ([209.85.214.46]:41611 "EHLO mail-bk0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752568Ab2KBNcF (ORCPT ); Fri, 2 Nov 2012 09:32:05 -0400 MIME-Version: 1.0 In-Reply-To: References: <1341961393-17728-1-git-send-email-bleung@chromium.org> <1351200081-19349-1-git-send-email-bleung@chromium.org> <1351200081-19349-2-git-send-email-bleung@chromium.org> Date: Fri, 2 Nov 2012 13:32:03 +0000 Message-ID: Subject: Re: [PATCH v2 1/1] Platform: x86: Add Chrome OS Laptop driver From: Corentin Chary To: Olof Johansson Cc: Benson Leung , Matthew Garrett , "platform-driver-x86@vger.kernel.org" , LKML , olofj@chromium.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2152 Lines: 49 On Fri, Nov 2, 2012 at 1:09 PM, Olof Johansson wrote: > On Fri, Nov 2, 2012 at 2:03 PM, Corentin Chary wrote: >> On Fri, Nov 2, 2012 at 12:45 PM, Olof Johansson wrote: >>> On Fri, Oct 26, 2012 at 10:30 AM, Corentin Chary >>> 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? >> >> I guess I would check dmi in the module init method, and then use the >> probe callback of platform_create_bundle to do more probing if >> necessary. > > Maybe I'm dense but I don't see how that could possibly be better than > what the code does today. It would just add more overhead and clutter > by creating a unnecessary dummy device/driver setup just to, in the > end, register the same i2c devices. > Well that was the point of "If it is going to be bigger". Of course, as long as it only register those i2c devices, it doesn't really matter. -- Corentin Chary http://xf.iksaif.net -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/