Messages in this thread | | | From | "Nori, Sekhar" <> | Date | Tue, 23 Nov 2010 18:12:38 +0530 | Subject | RE: [PATCH v2 4/4] da850-evm: add baseboard UI expander buttons, switches and LEDs |
| |
Hi Ben,
On Mon, Nov 22, 2010 at 19:45:46, Ben Gardiner wrote: > Hi Sekhar, > > On Mon, Nov 22, 2010 at 7:00 AM, Nori, Sekhar <nsekhar@ti.com> wrote: > > Thanks for the explanation. I should have probably asked > > earlier, why do we need to prevent sysfs access of > > deep sleep enable and sw reset pins? We don't seem to be > > using them in the kernel either. > > You're welcome. > > 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.
Thanks, Sekhar
| |