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 [off-list ref] wrote:

quoted

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