PCMCIA: prevent auto insert during resume.
PATCH 1/1 PCMCIA: prevent auto insert during resume.
If a socket has been ejected before sleeping, at resume time it shouldn't be awaked.
--- drivers/pcmcia/cs.c | 7 +++---- 1 files changed, 3 insertions(+), 4 deletions(-)
drivers/pcmcia/cs.c +3 -4
@@ -562,10 +562,8 @@ static int socket_resume(struct pcmcia_socket *skt) skt->ops->init (skt); skt->ops->set_socket (skt, &skt->socket); -if (!(skt->state &SOCKET_PRESENT )) { - skt->state &= ~SOCKET_SUSPEND ; -return socket_insert (skt); - } +if (!(skt->state &SOCKET_PRESENT )) + goto resume_exit; ret =socket_setup (skt,SS_COMA , resume_delay);if (ret ==CS_SUCCESS ) {
@@ -599,6 +597,7 @@ static int socket_resume(struct pcmcia_socket *skt)socket_shutdown (skt); } +resume_exit: skt->state &= ~SOCKET_SUSPEND ;return CS_SUCCESS ;
Signature · 1 line
1.5.2.5
Quoted 2 lines · Rodolfo Giometti
If a socket has been ejected before sleeping, at resume time it shouldn't be awaked.
Conversely, if a card has been inserted into an empty slot prior to resuming, it should be detected. Removing this check prevents that happening, which sucks for at least embedded devices.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 7 lines · Russell King
Quoted 2 lines · Rodolfo Giometti
If a socket has been ejected before sleeping, at resume time it shouldn't be awaked.
Conversely, if a card has been inserted into an empty slot prior to resuming, it should be detected. Removing this check prevents that happening, which sucks for at least embedded devices.
You can use "pccardctl insert" to do it. :)
On battery powered device I should prevent power lost, so if I power down a device I'd like it should remain off even after resume.
Why the system should power it on automagically? Just for detection?
Ciao,
Rodolfo
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
Quoted 10 lines · Rodolfo Giometti
Quoted 7 lines · Russell King
Quoted 2 lines · Rodolfo Giometti
If a socket has been ejected before sleeping, at resume time it shouldn't be awaked.
Conversely, if a card has been inserted into an empty slot prior to resuming, it should be detected. Removing this check prevents that happening, which sucks for at least embedded devices.
You can use "pccardctl insert" to do it. :)
Not on a battery powered device with a graphical interface.
Quoted 2 lines
On battery powered device I should prevent power lost, so if I power down a device I'd like it should remain off even after resume.
In which case you need to remember why it was powered down and act accordingly.
Quoted 1 line
Why the system should power it on automagically? Just for detection?
When you bring the battery device out of resume, and you've inserted a card, you want it to be detected. Your change means you have to wait until the system has finished resuming before you plug the card in, which practically is a pain in the butt and actually leads to user errors. IOW:
"I plugged my wireless card in after I pressed the power button, why wasn't it detected?"
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 2 lines · Russell King
Not on a battery powered device with a graphical interface.
This can be done by a button, menu or other graphical object. :)
Quoted 5 lines
Quoted 2 lines
On battery powered device I should prevent power lost, so if I power down a device I'd like it should remain off even after resume.
In which case you need to remember why it was powered down and act accordingly.
Yes. This have some reasons... for example, my custom board has a WiFi connected to the PCMCIA interface (which consumes a lot of power) and if the user switch off the WiFi I think he/she doesn't wish the WiFi is automagic powered on after resume... this behaviour can cause power lost if the user forgot to switch it off again.
Quoted 10 lines
Quoted 1 line
Why the system should power it on automagically? Just for detection?
When you bring the battery device out of resume, and you've inserted a card, you want it to be detected. Your change means you have to wait until the system has finished resuming before you plug the card in, which practically is a pain in the butt and actually leads to user errors. IOW:
"I plugged my wireless card in after I pressed the power button, why wasn't it detected?"
My patch doesn't affect the power on sequence, just the resume one. 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.
Ciao,
Rodolfo
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
Quoted 7 lines · Rodolfo Giometti
Quoted 6 lines · Russell King
When you bring the battery device out of resume, and you've inserted a card, you want it to be detected. Your change means you have to wait until the system has finished resuming before you plug the card in, which practically is a pain in the butt and actually leads to user errors. IOW:
Quoted 5 lines
Quoted 2 lines
"I plugged my wireless card in after I pressed the power button, why wasn't it detected?"
My patch doesn't affect the power on sequence, just the resume one.
On a lot of devices, the "power button" is the resume button. When you "turn it off" it suspends, and when you "turn it on" it resumes.
Quoted 11 lines
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...
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 8 lines · Russell King
Quoted 7 lines · Rodolfo Giometti
Quoted 6 lines · Russell King
When you bring the battery device out of resume, and you've inserted a card, you want it to be detected. Your change means you have to wait until the system has finished resuming before you plug the card in, which practically is a pain in the butt and actually leads to user errors. IOW:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
"I plugged my wireless card in after I pressed the power button, why wasn't it detected?"
My patch doesn't affect the power on sequence, just the resume one.
On a lot of devices, the "power button" is the resume button. When you "turn it off" it suspends, and when you "turn it on" it resumes.
I see. My device has two buttons.
However even in this case, if you never eject the device, then switch off (sleep), change the device into the slot and then power on (wake up), with my patch everything continues to work as before.
The differences come up only if you eject the device before power off.
Quoted 12 lines
Quoted 11 lines
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.
Quoted 6 lines
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...
Maybe we can add an entry into sysfs? Or just a module parameter? So developers can choose their preferred behaviour. :)
Thanks for your time,
Rodolfo
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
Quoted 18 lines · Rodolfo Giometti
Quoted 8 lines · Russell King
Quoted 7 lines · Rodolfo Giometti
Quoted 6 lines · Russell King
When you bring the battery device out of resume, and you've inserted a card, you want it to be detected. Your change means you have to wait until the system has finished resuming before you plug the card in, which practically is a pain in the butt and actually leads to user errors. IOW:
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
"I plugged my wireless card in after I pressed the power button, why wasn't it detected?"
My patch doesn't affect the power on sequence, just the resume one.
On a lot of devices, the "power button" is the resume button. When you "turn it off" it suspends, and when you "turn it on" it resumes.
Quoted 7 lines
I see. My device has two buttons.
However even in this case, if you never eject the device, then switch off (sleep), change the device into the slot and then power on (wake up), with my patch everything continues to work as before.
The differences come up only if you eject the device before power off.
Yes and it's extremely irritating that a plugged in card doesn't get detected.
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Is that clearer?
Quoted 2 lines
Maybe we can add an entry into sysfs? Or just a module parameter? So developers can choose their preferred behaviour. :)
Or that - probably a sysfs attribute on the pcmcia socket would be better.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 19 lines · Russell King
Quoted 19 lines
Quoted 18 lines
Quoted 11 lines
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...
Quoted 8 lines
Quoted 3 lines
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.
Sorry for not understanding your point of view. :'(
Quoted 5 lines
Quoted 2 lines
Maybe we can add an entry into sysfs? Or just a module parameter? So developers can choose their preferred behaviour. :)
Or that - probably a sysfs attribute on the pcmcia socket would be better.
Ok, but how can I do it? Can you please suggest to me the name of such attribute and where should I add it into the PCMCIA code? Also, which should be the default dehaviour? ;)
Thanks in advance,
Rodolfo
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
Quoted 7 lines · Rodolfo Giometti
Quoted 2 lines · Russell King
Or that - probably a sysfs attribute on the pcmcia socket would be better.
Ok, but how can I do it? Can you please suggest to me the name of such attribute and where should I add it into the PCMCIA code? Also, which should be the default dehaviour? ;)
My consulting rates are... Seriously, if you want me to write a patch for you, you have to pay for that.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 11 lines · Russell King
Quoted 7 lines · Rodolfo Giometti
Quoted 2 lines · Russell King
Or that - probably a sysfs attribute on the pcmcia socket would be better.
Ok, but how can I do it? Can you please suggest to me the name of such attribute and where should I add it into the PCMCIA code? Also, which should be the default dehaviour? ;)
My consulting rates are... Seriously, if you want me to write a patch for you, you have to pay for that.
O_o You misunderstand me... I just like some hints about to do it by myself.
Since (most probably) you are the one which should accept or deny my patch I simple asked to you how I should do the job in order to avoid a reject! :)
The name of the attribute, which should be its default behaviour and an hint where should I put the code (just a file name or a function one).
Thanks in advance,
Rodolfo
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
Quoted 25 lines · Rodolfo Giometti
Quoted 23 lines · Russell King
Quoted 22 lines
Quoted 12 lines
Quoted 11 lines
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.
Quoted 6 lines
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...
Quoted 8 lines
Quoted 4 lines
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.
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Quoted 31 lines · Pavel Machek
Quoted 30 lines · Rodolfo Giometti
Quoted 27 lines · Russell King
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
Quoted 42 lines · Rodolfo Giometti
Quoted 31 lines · Pavel Machek
Quoted 30 lines · Rodolfo Giometti
Quoted 27 lines · Russell King
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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! :)
Quoted 7 lines
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.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 57 lines · Russell King
Quoted 42 lines · Rodolfo Giometti
Quoted 31 lines · Pavel Machek
Quoted 30 lines · Rodolfo Giometti
Quoted 27 lines · Russell King
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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! :)
Quoted 7 lines
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.
Quoted 6 lines
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.
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.
Signature · 3 lines
Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of:
Quoted 65 lines · Russell King
Quoted 57 lines · Russell King
Quoted 42 lines · Rodolfo Giometti
Quoted 31 lines · Pavel Machek
Quoted 30 lines · Rodolfo Giometti
Quoted 27 lines · Russell King
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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! :)
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
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.
Well, this is not what the MAINTAINERS file says, btw.
Quoted 5 lines
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.
OK
Can we CC all future messages regarding this patch to Dominik, please?
Quoted 65 lines · Russell King
Quoted 57 lines · Russell King
Quoted 42 lines · Rodolfo Giometti
Quoted 31 lines · Pavel Machek
Quoted 30 lines · Rodolfo Giometti
Quoted 27 lines · Russell King
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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! :)
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
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.
Quoted 5 lines
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
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127
Quoted 49 lines · Russell King
Quoted 48 lines · Rodolfo Giometti
Quoted 31 lines · Pavel Machek
Quoted 30 lines · Rodolfo Giometti
Quoted 27 lines · Russell King
Quoted 15 lines
Quoted 15 lines
Quoted 11 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 3 lines
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.
Quoted 7 lines
Quoted 1 line
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. :)
Quoted 6 lines
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
Signature · 4 lines
GNU/Linux Solutions e-mail: [email protected] Linux Device Driver [email protected] Embedded Systems [email protected] UNIX programming phone: +39 349 2432127