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@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
