From: Rodolfo Giometti <giometti@enneenne.com>
To: Pavel Machek <pavel@ucw.cz>,
linux-pcmcia@lists.infradead.org, linux-kernel@vger.kernel.org,
Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [PATCH] PCMCIA: prevent auto insert during resume.
Date: Tue, 6 Nov 2007 09:58:28 +0100 [thread overview]
Message-ID: <20071106085828.GK5548@enneenne.com> (raw)
In-Reply-To: <20071101183741.GA27621@flint.arm.linux.org.uk>
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.
Current status without the patch:
hostname:~# pccardctl status
Socket 0:
3.3V 16-bit PC Card
Subdevice 0 (function 0) [unbound]
hostname:~# pccardctl eject
pccard: card ejected from slot 0
hostname:~# pccardctl status
Socket 0:
no card
hostname:~# apm -s
Stopping tasks ... done.
Suspending console(s)
<<RESUME>>
hostname:~# usb0: full speed config #1: 100 mA, Ethernet Gadget, using CDC Ethernet Subset
pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
Restarting tasks ... done.
hostname:~# pccardctl status
Socket 0:
3.3V 16-bit PC Card
Subdevice 0 (function 0) [unbound]
The device into PCMCIA slot 0 is _auto_ powered up again.
(Possible) future status with the patch:
hostname:~# pccardctl status
Socket 0:
3.3V 16-bit PC Card
Subdevice 0 (function 0) [unbound]
hostname:~# pccardctl eject
pccard: card ejected from slot 0
hostname:~# pccardctl status
Socket 0:
no card
hostname:~# apm -s
Stopping tasks ... done.
Suspending console(s)
<<RESUME>>
hostname:~# usb0: full speed config #1: 100 mA, Ethernet Gadget, using CDC Ethernet Subset
Restarting tasks ... done.
pccardctl status
Socket 0:
no card
hostname:~# pccardctl insert
pccard: PCMCIA card inserted into slot 0
pcmcia: registering new device pcmcia0.0
hostname:~# pccardctl status
Socket 0:
3.3V 16-bit PC Card
Subdevice 0 (function 0) [unbound]
The device into PCMCIA slot 0 is _not_ powered up and the user should
use "pccardctl insert" to do that (on my battery powered device this
behaviour saves the battery a lot).
If you like current behaviour don't apply the patch. :)
> 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.
In the past I did some "obvious" patches and the maintainer told me:
"plase change this name" or "modify the default behaviour",
etc.. That's why I asked for. I thought it could be less time
consuming ask before then modify again after...
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
prev parent reply other threads:[~2007-11-06 8:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-26 10:51 [PATCH] PCMCIA: prevent auto insert during resume Rodolfo Giometti
2007-10-26 15:11 ` Russell King
2007-10-26 15:47 ` Rodolfo Giometti
2007-10-26 16:02 ` Russell King
2007-10-26 16:27 ` Rodolfo Giometti
2007-10-26 16:36 ` Russell King
2007-10-26 16:54 ` Rodolfo Giometti
2007-10-26 17:00 ` Russell King
2007-10-26 17:18 ` Rodolfo Giometti
2007-10-26 18:37 ` Russell King
2007-10-26 20:52 ` Rodolfo Giometti
2007-10-29 19:24 ` Pavel Machek
2007-11-01 14:53 ` Rodolfo Giometti
2007-11-01 18:37 ` Russell King
2007-11-01 18:56 ` Russell King
2007-11-01 22:43 ` Rafael J. Wysocki
2007-11-06 9:09 ` Rodolfo Giometti
2007-11-06 8:58 ` Rodolfo Giometti [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20071106085828.GK5548@enneenne.com \
--to=giometti@enneenne.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pcmcia@lists.infradead.org \
--cc=linux@dominikbrodowski.net \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.