public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: Linux Kernel List <linux-kernel@vger.kernel.org>
Cc: seanlkml@rogers.com, felipe_alfaro@linuxmail.org,
	Dominik Brodowski <linux@brodo.de>
Subject: [CFT] Hopefully fix PCMCIA boot deadlocks
Date: Mon, 14 Apr 2003 16:50:57 +0100	[thread overview]
Message-ID: <20030414165057.C22754@flint.arm.linux.org.uk> (raw)

Ok,

Here's my latest patch against 2.5.67 which introduces a proper state
machine into the PCMCIA layer for handling the sockets.  Unfortunately,
I fear that this isn't the answer for the following reasons:

* We create our own workqueue (which spawns N threads, one thread per CPU.)
  We need to use a separate thread from the keventd since we call
  PCI probe and remove methods from this thread, which are free to
  use flush_scheduled_work() - which would be another deadlock waiting
  to happen.  I think we need to go to a per-socket thread instead.

* The state machine isn't as readable as it should be.  To be quite frank,
  I think it was a mistake to code it as a state machine - IMO its
  completely unreadable.

* We allow cardbus cards to be suspended and reset as though they are
  normal PCMCIA cards.  Unfortunately, PCI drivers have no knowledge
  that these operations occur.  This also applies to older kernels, so
  this isn't really a problem that's created by this patch.

  This is even more true now that we have the capability to plug in a
  complete (possibly complex) PCI bus structure.

* There seems to be a whole bunch of setup stuff going on in
  pcmcia_register_client().  This is run each time a card device driver
  is inserted by cardmgr.  Although this has buggy for the case where
  all drivers are built in, this patch makes it more buggy; if a card
  is inserted at the time ds.ko is loaded, we kick off the asynchronous
  state machine to process the card and carry on regardless.

  However, we can not wait here - if we do wait for the state machine
  to complete, we will hit the same deadlock in the device model which
  we're hitting today.

  It appears that it would mainly affect multi-function PCMCIA cards.
  Unfortunately, I don't have any to test.

That said, it seems to work for me.

The patch can be found at

	http://patches.arm.linux.org.uk/pcmcia/pcmcia-1.diff

Now, thing is, I can't test this patch on its own; I can test it on ARM
boxen with yenta cardbus bridges, or statically mapped PCMCIA-only
sockets, but the former requires several other patches to the PCMCIA
resource subsystem to be functional.

Hence I need other peoples feedback on this patch before I push it
Linus-wards.

-- 
Russell King (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


             reply	other threads:[~2003-04-14 15:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-14 15:50 Russell King [this message]
2003-04-14 22:55 ` [CFT] Hopefully fix PCMCIA boot deadlocks Felipe Alfaro Solana
2003-04-15  2:03   ` Valdis.Kletnieks

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=20030414165057.C22754@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=felipe_alfaro@linuxmail.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@brodo.de \
    --cc=seanlkml@rogers.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox