From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gx0-f179.google.com (mail-gx0-f179.google.com [209.85.161.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 575ADB6F67 for ; Sat, 28 Jan 2012 05:43:01 +1100 (EST) Received: by ggm4 with SMTP id 4so1053328ggm.38 for ; Fri, 27 Jan 2012 10:42:57 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Fri, 27 Jan 2012 19:42:57 +0100 Message-ID: Subject: Re: Question about GPIO Lib From: Bill Gatliff To: Bruce_Leonard@selinc.com Content-Type: text/plain; charset=ISO-8859-1 Cc: linuxppc-dev@lists.ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Bruce: On Fri, Jan 27, 2012 at 5:31 AM, wrote: > > The problem is we've got a number of other things hooked up to the GPIO > pins that it would be very bad if someone from user space played with > them, like our FPGA configuration pin. =A0Some one toggles that and our b= ox > goes stupid. =A0So what I'm wondering is if there's a way, preferably via > the device tree, to limit the GPIOs that GPIO Lib exposes to user space? Sounds like you DON'T want to merely export that GPIO pin to userspace. If you have anything in kernel space doing a gpio_request() on that pin, it won't be exportable to userspace anyway. Regardless, you are probably better off implement a DEVICE_ATTR that, in its store() method, treads lightly on said pin. And then do a gpio_request() in kernel space so that users can't ever see the pin directly. Just my $0.02. b.g. --=20 Bill Gatliff bgat@billgatliff.com