[git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Dominik Brodowski]

Linus,

a few more PCMCIA patches for 2.6.34 are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git master

The diffstat and list of changes is below, the individual diffs are sent
(at least) to the linux-pcmcia list. This patchset includes one
controversial patch, titled:

      pcmcia: disable pcmcia ioctl for !ARM, prepare for removal

Most notably, Russell King objects to it for reasons spelled out e.g. at
http://lkml.org/lkml/2008/2/27/291 . I suspect the platform he is referring
to actually does work with the PCMCIA ioctl disabled; Russell's offer from
2008 to

   "spend some time [...] working out what it requires from the ioctl
   interface - maybe we can have a cut-down ioctl interface that bolts straight
   on as an "add on" to the new controls without being too invasive, while
   still allowing its PCMCIA bits to work."
   (http://lists.infradead.org/pipermail/linux-pcmcia/2008-April/005450.html)

hasn't lead to any result so far; he has indicated he won't get to spending
time on it soon. Because of the lack of progress in this regard, and for the
other reasons spelled out in the patch, I picked up Alan's suggestion to

   "[...] push[ing] it. If it matters someone will then fix up the problem
   platform. If it isn't pushed then it lets one obscure platform stall
   progress for everyone else."
  (http://lists.infradead.org/pipermail/linux-pcmcia/2008-April/005453.html)

Please pull from that location insofar as you agree to continue with the
deprecation of the PCMCIA ioctl. Otherwise, I can prepare a branch
_without_ this controversial patch to pull from.

Thanks,
        Dominik


Dominik Brodowski (2):
      pcmcia: CodingStyle fixes
      pcmcia: disable pcmcia ioctl for !ARM, prepare for removal

Komuro (1):
      pcmcia: remove irq_list parameter from pd6729

Manuel Lauss (1):
      pcmcia: alchemy: fixup wrong comments

Michal Pecio (1):
      yenta_socket: ENE CB712 CardBus bridge needs special treatment with Echo Audio Indigo soundcards

 Documentation/feature-removal-schedule.txt |   12 +-
 drivers/pcmcia/Kconfig                     |   14 +-
 drivers/pcmcia/cardbus.c                   |    2 +-
 drivers/pcmcia/cistpl.c                    | 1908 ++++++++++++++--------------
 drivers/pcmcia/db1xxx_ss.c                 |   19 +-
 drivers/pcmcia/pd6729.c                    |   18 +-
 drivers/pcmcia/rsrc_mgr.c                  |    3 +-
 drivers/pcmcia/xxs1500_ss.c                |   16 +-
 drivers/pcmcia/yenta_socket.c              |    8 +-
 9 files changed, 973 insertions(+), 1027 deletions(-)

[PATCH 5/5] pcmcia: disable pcmcia ioctl for !ARM, prepare for removal

[Dominik Brodowski]

The PCMCIA ioctl -- deprecated for years -- suffers from insufficient
locking. As it already has been deprecated for years, with its removal
long overdue, limit it to !SMP and !PREEMPT.

Furthermore, the last legitimate use of the ioctl to be reported
relates to the ARM architecture in 2008.[1] Attempts to resolve
this issue turned out unsuccessful so far.[2] Other usages have only
been reported as hear-say. If there are any legitiate and necessary
use-cases remaining, please speak out before the end of the grace
period until 2.6.3{5,6}(-rc1).

[1] http://lists.infradead.org/pipermail/linux-pcmcia/2008-April/005440.html
    see also: http://lkml.org/lkml/2008/2/27/291
[2] http://lists.infradead.org/pipermail/linux-pcmcia/2008-April/005450.html
    http://lists.infradead.org/pipermail/linux-pcmcia/2010-January/006740.html
    see also: http://lists.infradead.org/pipermail/linux-pcmcia/2008-April/005453.html

CC: Russell King <rmk+kernel@arm.linux.org.uk>
CC: Alan Cox <alan@lxorguk.ukuu.org.uk>
CC: Robert P. J. Day <rpjday@crashcourse.ca>
CC: Jaswinder Singh Rajput <jaswinder@kernel.org>
CC: linux-kernel@vger.kernel.org
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
---
 Documentation/feature-removal-schedule.txt |   12 +++++++++---
 drivers/pcmcia/Kconfig                     |   14 ++++++++++----
 2 files changed, 19 insertions(+), 7 deletions(-)

diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 732b1fa..3e57a75 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -138,19 +138,25 @@ Who:	Mauro Carvalho Chehab <mchehab@infradead.org>
 ---------------------------
 
 What:	PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
-When:	November 2005
+When:	2.6.35/2.6.36
 Files:	drivers/pcmcia/: pcmcia_ioctl.c
 Why:	With the 16-bit PCMCIA subsystem now behaving (almost) like a
 	normal hotpluggable bus, and with it using the default kernel
 	infrastructure (hotplug, driver core, sysfs) keeping the PCMCIA
 	control ioctl needed by cardmgr and cardctl from pcmcia-cs is
-	unnecessary, and makes further cleanups and integration of the
+	unnecessary and potentially harmful (it does not provide for
+	proper locking), and makes further cleanups and integration of the
 	PCMCIA subsystem into the Linux kernel device driver model more
 	difficult. The features provided by cardmgr and cardctl are either
 	handled by the kernel itself now or are available in the new
 	pcmciautils package available at
 	http://kernel.org/pub/linux/utils/kernel/pcmcia/
-Who:	Dominik Brodowski <linux@brodo.de>
+
+	For all architectures except ARM, the associated config symbol
+	has been removed from kernel 2.6.34; for ARM, it will be likely
+	be removed from kernel 2.6.35. The actual code will then likely
+	be removed from kernel 2.6.36.
+Who:	Dominik Brodowski <linux@dominikbrodowski.net>
 
 ---------------------------
 
diff --git a/drivers/pcmcia/Kconfig b/drivers/pcmcia/Kconfig
index 0a6601c..d189e47 100644
--- a/drivers/pcmcia/Kconfig
+++ b/drivers/pcmcia/Kconfig
@@ -51,17 +51,23 @@ config PCMCIA_LOAD_CIS
 
 config PCMCIA_IOCTL
 	bool "PCMCIA control ioctl (obsolete)"
-	depends on PCMCIA
+	depends on PCMCIA && ARM && !SMP && !PREEMPT
 	default y
 	help
 	  If you say Y here, the deprecated ioctl interface to the PCMCIA
-	  subsystem will be built. It is needed by cardmgr and cardctl
-	  (pcmcia-cs) to function properly.
+	  subsystem will be built. It is needed by the deprecated pcmcia-cs
+	  tools (cardmgr, cardctl) to function properly.
 
 	  You should use the new pcmciautils package instead (see
 	  <file:Documentation/Changes> for location and details).
 
-	  If unsure, say Y.
+	  This config option will most likely be removed from kernel 2.6.35,
+	  the associated code from kernel 2.6.36.
+
+	  As the PCMCIA ioctl is not locking safe, it depends on !SMP and
+	  !PREEMPT.
+
+	  If unsure, say N.
 
 config CARDBUS
 	bool "32-bit CardBus support"
-- 
1.6.3.3

Re: [PATCH 5/5] pcmcia: disable pcmcia ioctl for !ARM, prepare for removal

[Russell King]

On Wed, Mar 03, 2010 at 09:00:48AM +0100, Dominik Brodowski wrote:
> Furthermore, the last legitimate use of the ioctl to be reported
> relates to the ARM architecture in 2008.[1] Attempts to resolve
> this issue turned out unsuccessful so far.[2] Other usages have only
> been reported as hear-say. If there are any legitiate and necessary
> use-cases remaining, please speak out before the end of the grace
> period until 2.6.3{5,6}(-rc1).

What's the point of speaking out?  You don't take any notice of people
who do, and you continue your crusade of wanting to remove it.  Please,
stop giving the impression that you give a damn of what people say about
the ioctl interface.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH 5/5] pcmcia: disable pcmcia ioctl for !ARM, prepare for removal

[Dominik Brodowski]

Russell,

On Sat, May 15, 2010 at 03:24:10PM +0100, Russell King wrote:
> On Wed, Mar 03, 2010 at 09:00:48AM +0100, Dominik Brodowski wrote:
> > Furthermore, the last legitimate use of the ioctl to be reported
> > relates to the ARM architecture in 2008.[1] Attempts to resolve
> > this issue turned out unsuccessful so far.[2] Other usages have only
> > been reported as hear-say. If there are any legitiate and necessary
> > use-cases remaining, please speak out before the end of the grace
> > period until 2.6.3{5,6}(-rc1).
> 
> What's the point of speaking out?  You don't take any notice of people
> who do, and you continue your crusade of wanting to remove it.  Please,
> stop giving the impression that you give a damn of what people say about
> the ioctl interface.

The _only_ person who really has spoken out is you. All my requests to
actually see source code or actual use cases (e.g. which parts of the ioctl
do actually get called) did not lead to _anything_. Over the past years,
I've sent you quite some mails where I specifically asked you for such
input, as it's you who speaks out against the PCMCIA ioctl removal.

If you or anyone else sends me _substantiated_ information regarding
continuing use cases for new kernels and the PCMCIA ioctl, I'm more than
willing to re-think the plan to remove it. If all I receive are accusations,
unsubstantiated or unfounded guesses, I will stick with this plan.

Best,
	Dominik

Re: [PATCH 5/5] pcmcia: disable pcmcia ioctl for !ARM, prepare for removal

[Russell King]

On Sat, May 15, 2010 at 04:37:05PM +0200, Dominik Brodowski wrote:
> Russell,
> 
> On Sat, May 15, 2010 at 03:24:10PM +0100, Russell King wrote:
> > On Wed, Mar 03, 2010 at 09:00:48AM +0100, Dominik Brodowski wrote:
> > > Furthermore, the last legitimate use of the ioctl to be reported
> > > relates to the ARM architecture in 2008.[1] Attempts to resolve
> > > this issue turned out unsuccessful so far.[2] Other usages have only
> > > been reported as hear-say. If there are any legitiate and necessary
> > > use-cases remaining, please speak out before the end of the grace
> > > period until 2.6.3{5,6}(-rc1).
> > 
> > What's the point of speaking out?  You don't take any notice of people
> > who do, and you continue your crusade of wanting to remove it.  Please,
> > stop giving the impression that you give a damn of what people say about
> > the ioctl interface.
> 
> The _only_ person who really has spoken out is you. All my requests to
> actually see source code or actual use cases (e.g. which parts of the ioctl
> do actually get called) did not lead to _anything_.

See the source code?  You clearly haven't been reading what I've been
saying to you on the subject if you think I can produce source code.
I've already explained this to you several times, but it seems to be
constantly ignored.

Don't you think that if I had the source code, then there wouldn't be
this problem in the first place - it would be possible to fix the
offending programs myself.

There's maybe one person who _may_ still have the source code - Vince
Sanders - and despite asking many times for it, I've had zero progress
on it.

Maybe I should have walked away with a copy of the source myself - but
it wasn't practical to take a copy of several GB of build system across
a 512kbps ADSL connection as it was back then.

I'm sorry that you find it soo hard to accept what I've been saying over
the last few years on this, but it seems that you only have one interest
and that's to remove the ioctl no matter what anyone says.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [PATCH 5/5] pcmcia: disable pcmcia ioctl for !ARM, prepare for removal

[Dominik Brodowski]

Russell,

On Sat, May 15, 2010 at 03:46:39PM +0100, Russell King wrote:
> On Sat, May 15, 2010 at 04:37:05PM +0200, Dominik Brodowski wrote:
> > Russell,
> > 
> > On Sat, May 15, 2010 at 03:24:10PM +0100, Russell King wrote:
> > > On Wed, Mar 03, 2010 at 09:00:48AM +0100, Dominik Brodowski wrote:
> > > > Furthermore, the last legitimate use of the ioctl to be reported
> > > > relates to the ARM architecture in 2008.[1] Attempts to resolve
> > > > this issue turned out unsuccessful so far.[2] Other usages have only
> > > > been reported as hear-say. If there are any legitiate and necessary
> > > > use-cases remaining, please speak out before the end of the grace
> > > > period until 2.6.3{5,6}(-rc1).
> > > 
> > > What's the point of speaking out?  You don't take any notice of people
> > > who do, and you continue your crusade of wanting to remove it.  Please,
> > > stop giving the impression that you give a damn of what people say about
> > > the ioctl interface.
> > 
> > The _only_ person who really has spoken out is you. All my requests to
> > actually see source code or actual use cases (e.g. which parts of the ioctl
> > do actually get called) did not lead to _anything_.
> 
> See the source code?  You clearly haven't been reading what I've been
> saying to you on the subject if you think I can produce source code.
> I've already explained this to you several times, but it seems to be
> constantly ignored.

That's why there is the _other_ alternative: "actual use cases (e.g. which
parts of the ioctl do actually get called)". For this, you only need to be
able to update/modify the kernel. More than two years ago, you signalised
to do exactly this:

| I'll spend some time this coming weekend working out precisely what it
| requires from the ioctl interface - maybe we can have a cut-down ioctl
| interface that bolts straight on as an "add on" to the new controls
| without being too invasive, while still allowing its PCMCIA bits to
| work.

[ http://lists.infradead.org/pipermail/linux-pcmcia/2008-April/005450.html ]

I haven't heard anything about the result of this experiment, even though
asking a number of times (e.g.
http://lists.infradead.org/pipermail/linux-pcmcia/2010-January/006740.html ).

Best,
	Dominik

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Russell King]

On Wed, Mar 03, 2010 at 08:59:44AM +0100, Dominik Brodowski wrote:
> Please pull from that location insofar as you agree to continue with the
> deprecation of the PCMCIA ioctl. Otherwise, I can prepare a branch
> _without_ this controversial patch to pull from.

So you believe that disabling the button in the graphical environment
to allow PCMCIA cards to be removed (such as CF cards) - leaving the
user to merely pull out the CF card, while the FS is mounted, is a
good idea?

Sounds to me like a data loss scenario.

User APIs changing always breaks stuff.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Dominik Brodowski]

Russell,

On Wed, Mar 03, 2010 at 08:30:11AM +0000, Russell King wrote:
> On Wed, Mar 03, 2010 at 08:59:44AM +0100, Dominik Brodowski wrote:
> > Please pull from that location insofar as you agree to continue with the
> > deprecation of the PCMCIA ioctl. Otherwise, I can prepare a branch
> > _without_ this controversial patch to pull from.
> 
> So you believe that disabling the button in the graphical environment
> to allow PCMCIA cards to be removed (such as CF cards) - leaving the
> user to merely pull out the CF card, while the FS is mounted, is a
> good idea?

In which graphical environment specifically?`Which graphical environment
failed to update how to issue card removal events[1] even though the old
interface has been marked as deprecated since July 2005, and clear and bold
warnings have been visible in dmesg since September 2005?

Thanks,
	Dominik

[1] Either
# echo 1 > /sys/class/pcmcia_socket/pcmcia_socket{0,1,...}/card_eject
or, if pcmciautils are used,
# pccardctl eject [socket]

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Alan Cox]

> So you believe that disabling the button in the graphical environment
> to allow PCMCIA cards to be removed (such as CF cards) - leaving the
> user to merely pull out the CF card, while the FS is mounted, is a
> good idea?

Do any graphical environments even support the ancient user space
pcmcica helper stuff ? I can't find any evidence they do but I realise
Russell you get to deal with assorted crazy ARM embedded setups.

Alan

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]

> Do any graphical environments even support the ancient user space
> pcmcica helper stuff ? I can't find any evidence they do but I realise
> Russell you get to deal with assorted crazy ARM embedded setups.

FWIW, a few months ago I searched the web for the warning about the usage of
the deprectaed pcmcia-ioctls. The vast majority came from Debian's discover
which seems to be no issue according to:

http://article.gmane.org/gmane.linux.kernel/885286

The other occurences I found have been fixed meanwhile. (I understand that I
might have missed rare cases this way)

Regards,

   Wolfram

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Russell King]

On Fri, Mar 05, 2010 at 12:07:46PM +0000, Alan Cox wrote:
> > So you believe that disabling the button in the graphical environment
> > to allow PCMCIA cards to be removed (such as CF cards) - leaving the
> > user to merely pull out the CF card, while the FS is mounted, is a
> > good idea?
> 
> Do any graphical environments even support the ancient user space
> pcmcica helper stuff ? I can't find any evidence they do but I realise
> Russell you get to deal with assorted crazy ARM embedded setups.

I believe so - the platform I have is based around the Open Embedded
stuff, and there's a button on the desktop which communicates with the
kernel via the PCMCIA ioctls.  One of the things it offers is to allow
media (eg, CF) to be safely ejected without ending up pulling the card
out while the FS is still mounted.

If the button can't communicate with the kernel PCMCIA driver, it doesn't
know that a CF card is in place, so it can't offer to eject the media.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Peter Stuge]

Russell King wrote:
> > Do any graphical environments even support the ancient user space
> > pcmcica helper stuff ?
> 
> I believe so - the platform I have is based around the Open Embedded
> stuff, and there's a button on the desktop which communicates with the
> kernel via the PCMCIA ioctls.  One of the things it offers is to allow
> media (eg, CF) to be safely ejected without ending up pulling the card
> out while the FS is still mounted.

So if you upgrade that system to a kernel without that call I guess
you may have to either also upgrade that GUI software, or install a
.so to wrap ioctl() and provide backwards compatibility for the app?


//Peter

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Pavel Machek]

Hi!

> > So you believe that disabling the button in the graphical environment
> > to allow PCMCIA cards to be removed (such as CF cards) - leaving the
> > user to merely pull out the CF card, while the FS is mounted, is a
> > good idea?
> 
> Do any graphical environments even support the ancient user space
> pcmcica helper stuff ? I can't find any evidence they do but I realise

Yes; qtopia shipped with zaurus sl-5500 (collie), and very probably
opie and gpe...

Sharp needed operating system for the handheld, and yes it supported
all the hw.

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Dominik Brodowski]

Hey,

On Wed, Mar 10, 2010 at 09:45:46PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > So you believe that disabling the button in the graphical environment
> > > to allow PCMCIA cards to be removed (such as CF cards) - leaving the
> > > user to merely pull out the CF card, while the FS is mounted, is a
> > > good idea?
> > 
> > Do any graphical environments even support the ancient user space
> > pcmcica helper stuff ? I can't find any evidence they do but I realise
> 
> Yes; qtopia shipped with zaurus sl-5500 (collie), and very probably
> opie and gpe...
> 
> Sharp needed operating system for the handheld, and yes it supported
> all the hw.

So qtopia still uses the PCMCIA ioctl? Or is it some custom add-on code by
zaurus? I'd very much like to see some more source code, what parts of
the IOCTL it uses etc. pp. Or at least some pointers...

Thanks,
	Dominik

Re: [git pull] more PCMCIA updates for 2.6.34 (including ioctl deprecation)

[Pavel Machek]

On Wed 2010-03-10 22:00:15, Dominik Brodowski wrote:
> Hey,
> 
> On Wed, Mar 10, 2010 at 09:45:46PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > So you believe that disabling the button in the graphical environment
> > > > to allow PCMCIA cards to be removed (such as CF cards) - leaving the
> > > > user to merely pull out the CF card, while the FS is mounted, is a
> > > > good idea?
> > > 
> > > Do any graphical environments even support the ancient user space
> > > pcmcica helper stuff ? I can't find any evidence they do but I realise
> > 
> > Yes; qtopia shipped with zaurus sl-5500 (collie), and very probably
> > opie and gpe...
> > 
> > Sharp needed operating system for the handheld, and yes it supported
> > all the hw.
> 
> So qtopia still uses the PCMCIA ioctl? Or is it some custom add-on code by
> zaurus? I'd very much like to see some more source code, what parts of
> the IOCTL it uses etc. pp. Or at least some pointers...

Well, Alan asked about "any graphical environments even support the
ancient user space pcmcica helper stuff", and yes I believe there are
some. I probably have one on ancient collie that's lying
somewhere. Not sure about sources, I never used those heavily.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html