Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965335Ab2EQW72 (ORCPT ); Thu, 17 May 2012 18:59:28 -0400 Received: from mail-ob0-f174.google.com ([209.85.214.174]:44867 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030346Ab2EQW70 convert rfc822-to-8bit (ORCPT ); Thu, 17 May 2012 18:59:26 -0400 MIME-Version: 1.0 In-Reply-To: <1337290826.7033.10.camel@trivette.site> References: <1334276935-11258-1-git-send-email-vivien.didelot@savoirfairelinux.com> <1334276935-11258-4-git-send-email-vivien.didelot@savoirfairelinux.com> <20120517210633.400633E0621@localhost> <1337290826.7033.10.camel@trivette.site> From: Grant Likely Date: Thu, 17 May 2012 16:59:05 -0600 X-Google-Sender-Auth: AcUBFEVLBL4i0NkLCj8g9jYhVIM Message-ID: Subject: Re: [PATCH v6 3/3] gpio: TS-5500 GPIO support To: Vivien Didelot Cc: x86@kernel.org, Jerome Oufella , Ingo Molnar , Thomas Gleixner , "H. Peter Anvin" , linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org, Guenter Roeck , Jean Delvare , Linus Walleij Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2704 Lines: 52 On Thu, May 17, 2012 at 3:40 PM, Vivien Didelot wrote: > On Thu, 2012-05-17 at 15:06 -0600, Grant Likely wrote: >> > ?arch/x86/include/asm/ts5500.h | ? 62 ++++++++ >> >> Why the separate header file? ?What will use these defines? ?I >> normally expect driver-specific defines to be in the driver .c file >> directly; particularly for things like gpio drivers which should be a >> generic interface that doesn't need to export symbols. > > Should an intermediate driver directly use values for GPIOs instead of > these symbols? For example, how should a temperature sensor plugged on > this platform refer to inputs and outputs? Tell me more about this platform. Where does the data about connections come from? Is it a purpose-built embedded system? Is the GPIO controller described in ACPI? (probably not since GPIOs were only added to ACPI in v5) Does the end-user attach her own hardware to the board like the temperature sensor you describe? If so, is that hardware driven by kernel drivers or user-space drivers? For userspace drivers you can get information about the GPIO number assignments from /sys, but it isn't well documented and can probably be improved. If it is kernelspace, then you really need a way to add data about the platform to the kernel at runtime. Having it statically compiled in isn't a very good solution. I would recommend injecting configuration data into the kernel from userspace. You could invent something, but that wouldn't be very portable. Xilinx has done some work on this using Flattened Device Tree and the firmware loading infrastructure. The kernel requests a .dtb (device tree blob) from userspace and uses that to configure devices. That may do the job for you. GPIO and platform device infrastructure already have FDT support which will help you here. I expect it could be done with an ACPI fragment too, but I just don't know of anybody having done any work in this area. That probably isn't the answer you want though since I assume you just need to get something that works rather than investing a whole bunch of time on generic infrastructure. What I would recommend is for your platform setup code to use a notifier to wait for the BUS_NOTIFY_BOUND_DRIVER event and then register the temperature sensor with the correct gpio number at that time (because once you have a reference to the gpio controller you can calculate the assigned gpio numbers). g. -- 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/