lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 1 Nov 2007 15:53:59 +0100
From:	Rodolfo Giometti <giometti@...eenne.com>
To:	Pavel Machek <pavel@....cz>
Cc:	linux-pcmcia@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCMCIA: prevent auto insert during resume.

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.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail:    giometti@...eenne.com
Linux Device Driver                             giometti@...dd.com
Embedded Systems                     		giometti@...ux.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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ