From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753686Ab0KWNcg (ORCPT ); Tue, 23 Nov 2010 08:32:36 -0500 Received: from na3sys009aog107.obsmtp.com ([74.125.149.197]:57265 "HELO na3sys009aog107.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752474Ab0KWNce (ORCPT ); Tue, 23 Nov 2010 08:32:34 -0500 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 23 Nov 2010 08:32:34 -0500 Message-ID: Subject: Re: [PATCH v2 4/4] da850-evm: add baseboard UI expander buttons, switches and LEDs From: Ben Gardiner To: "Nori, Sekhar" Cc: Kevin Hilman , "davinci-linux-open-source@linux.davincidsp.com" , "linux-input@vger.kernel.org" , Dmitry Torokhov , "Govindarajan, Sriramakrishnan" , Paul Mundt , "linux-kernel@vger.kernel.org" , Alexander Clouter , Chris Cordahi Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sekhar, On Tue, Nov 23, 2010 at 7:42 AM, Nori, Sekhar wrote: > On Mon, Nov 22, 2010 at 19:45:46, Ben Gardiner wrote: >> [...] >> I was assuming that those pins were not exported as gpio pins on >> purpose; I was taking the prudent approach to prevent haphazard >> toggling of sw_rst and deep_sleep_en from userspace. sw_rst because it >> could initiate a reset of the cpu when toggled and deep_sleep_en >> because it can override the behaviour of davinci_pm_enter(). >> >> I'm not sure how they would be used by existing kernel classes either. >> The sw_rst pin could be used for reset but since it is on the other >> end of an i2c bus and there is an existing implementation of reset >> using the on chip watchdog I don't think it would be benficial to >> switch. Deep_sleep_en could override the behaviour in >> davinci_pm_enter() -- _maybe_ (I don't really know) it could be used >> as a hardware-assisted suspend-blocker? But I totally guessing here. > > My preference would be to leave these pins as is > (don't call a gpio_request() on them) till someone > comes up with a use case for them. From what you > described, sysfs access cannot happen "accidently" > so someone accessing these pins from sysfs surely > knows what he is doing. No problem. I will re-spin the patch shortly with the deep_sleep_en and sw_rst pins free for use by client code. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Gardiner Subject: Re: [PATCH v2 4/4] da850-evm: add baseboard UI expander buttons, switches and LEDs Date: Tue, 23 Nov 2010 08:32:34 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Return-path: Received: from na3sys009aog107.obsmtp.com ([74.125.149.197]:57265 "HELO na3sys009aog107.obsmtp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752474Ab0KWNce (ORCPT ); Tue, 23 Nov 2010 08:32:34 -0500 In-Reply-To: Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: "Nori, Sekhar" Cc: Kevin Hilman , "davinci-linux-open-source@linux.davincidsp.com" , "linux-input@vger.kernel.org" , Dmitry Torokhov , "Govindarajan, Sriramakrishnan" , Paul Mundt , "linux-kernel@vger.kernel.org" , Alexander Clouter , Chris Cordahi Hi Sekhar, On Tue, Nov 23, 2010 at 7:42 AM, Nori, Sekhar wrote: > On Mon, Nov 22, 2010 at 19:45:46, Ben Gardiner wrote: >> [...] >> I was assuming that those pins were not exported as gpio pins on >> purpose; I was taking the prudent approach to prevent haphazard >> toggling of sw_rst and deep_sleep_en from userspace. sw_rst because it >> could initiate a reset of the cpu when toggled and deep_sleep_en >> because it can override the behaviour of davinci_pm_enter(). >> >> I'm not sure how they would be used by existing kernel classes either. >> The sw_rst pin could be used for reset but since it is on the other >> end of an i2c bus and there is an existing implementation of reset >> using the on chip watchdog I don't think it would be benficial to >> switch. Deep_sleep_en could override the behaviour in >> davinci_pm_enter() -- _maybe_ (I don't really know) it could be used >> as a hardware-assisted suspend-blocker? But I totally guessing here. > > My preference would be to leave these pins as is > (don't call a gpio_request() on them) till someone > comes up with a use case for them. From what you > described, sysfs access cannot happen "accidently" > so someone accessing these pins from sysfs surely > knows what he is doing. No problem. I will re-spin the patch shortly with the deep_sleep_en and sw_rst pins free for use by client code. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca