lkml.org 
[lkml]   [2007]   [Nov]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] PCMCIA: prevent auto insert during resume.
    On Thu, Nov 01, 2007 at 06:56:29PM +0000, Russell King wrote:
    > On Thu, Nov 01, 2007 at 06:37:41PM +0000, Russell King wrote:
    > > On Thu, Nov 01, 2007 at 03:53:59PM +0100, Rodolfo Giometti wrote:
    > > > On Mon, Oct 29, 2007 at 07:24:15PM +0000, Pavel Machek wrote:
    > > > > On Fri 2007-10-26 19:18:57, Rodolfo Giometti wrote:
    > > > > > On Fri, Oct 26, 2007 at 06:00:31PM +0100, Russell King wrote:
    > > > > >
    > > > > > > > > > Also if you didn't eject the socket, at resume the device will be
    > > > > > > > > > powered up again, my patch just prevents that a pre-powered off device
    > > > > > > > > > to be turned on at resume time.
    > > > > > > > > >
    > > > > > > > > > However you should consider that some embedded systems have fixed
    > > > > > > > > > PCMCIA devices that can't be removed so there are no reasons to detect
    > > > > > > > > > them after resume, nobody can change them. :)
    > > > > > > > > >
    > > > > > > > > > Also battery powered devices can go very frequently to sleep and the
    > > > > > > > > > current behavior force the user to switch off the unused device each
    > > > > > > > > > time the system resumes from sleep.
    > > > > > > > >
    > > > > > > > > I realise that. I do work on embedded devices, and this behaviour is
    > > > > > > > > explicitly there to support embedded devices.
    > > > > > > > >
    > > > > > > > > I've suggested a workable solution to you which allows both of us to
    > > > > > > > > have the behaviour we both desire from the system. That sounds like
    > > > > > > > > a negotiated solution to me...
    > > > > > > >
    > > > > > > > Do you mean to switch off the socket from userland? It could be a
    > > > > > > > solution but in this case the device is powered on each time even if
    > > > > > > > for a short delay...
    > > > > > >
    > > > > > > If it's a permanent device, and you've powered it down via pccardctl,
    > > > > > > then you've powered it down from userland. So record that it's been
    > > > > > > powered down from userland. Then, on resume, if it's been powered down
    > > > > > > from userland, don't try to re-power it on resume.
    > > > > >
    > > > > > But the userland doesn't re-power it on resume... it's the kernel
    > > > > > itself whos re-powers the device on resume. So the userland can only
    > > > > > power down the device again.
    > > > >
    > > > > I think Russell means: at a flag into kernel. If user powers down the
    > > > > device, set the flag. If flag is set during resume, avoid powering up
    > > > > the device.
    > > >
    > > > That's exactly what my patch does! :)
    > > >
    > > > If the user does 'eject' the device is not powered on at resume.
    > > >
    > > > Currently, with out the patch, if you do an 'eject' to power down the
    > > > device, then you go to sleep and resume, the device is powered up
    > > > again and you have to do a new 'eject' to power it down.
    > > >
    > > > My patch fixes this behaviour.
    > >
    > > Let's be absolutely clear about this. The patch in your original post
    > > does *NOT* do that. It *completely* removes the possibility of powering
    > > up a device inserted into the PCMCIA slot before resuming without
    > > unplugging and replugging it by removing the code which detects an
    > > inserted card on resume.
    > >
    > > And let's also be clear about something else. You _were_ crystal clear
    > > on that aspect of it from your last mail on the subject since you were
    > > asking for names of attributes to set and clear such a flag. I didn't
    > > respond because I'm not going to hold your hand with such obvious
    > > issues - if you need that level of support, it will be far faster for
    > > me to write the damned patch myself.
    >
    > Oh, and I'd like to make another thing clear - let's get the roles of
    > responsibility right.
    >
    > I'm the ex-PCMCIA maintainer who had a requirement for the current
    > behaviour on my embedded ARM devices with classical PCMCIA sockets.
    >
    > Dominik is the current PCMCIA maintainer who gets to say what goes in,
    > how things should be designed, etc.

    Ok.

    > You're the guy coming along with a different requirement for a device
    > using the PCMCIA subsystem in a non-classical way (non-pluggable PCMCIA)
    > and finding that the subsystem doesn't work in a good way with that
    > setup, and suggesting we break classical PCMCIA setups to make it
    > work.

    Maybe I'm one of that guys... but _in_ _my_ _humble_ _opinion_ the
    currently behaviour of PCMCIA subsystem doesn't fit well low power
    requirements for battery powered devices. Powered down devices should
    remain off through a suspend/resume. Maybe PCMCIA subsystem needs some
    modifications? :)

    However I just proposed a patch. If you think it's not useful or
    correct or whatever you think about it, please, don't use it.

    Ciao,

    Rodolfo

    --

    GNU/Linux Solutions e-mail: giometti@enneenne.com
    Linux Device Driver giometti@gnudd.com
    Embedded Systems giometti@linux.it
    UNIX programming phone: +39 349 2432127
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-11-06 10:09    [W:0.078 / U:1.668 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site