lkml.org 
[lkml]   [2010]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRE: [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



    \
     
     \ /
      Last update: 2010-11-23 13:45    [W:0.024 / U:0.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site