From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Mark Lord <liml@rtr.ca>, Richard Purdie <rpurdie@rpsys.net>,
LKML <linux-kernel@vger.kernel.org>,
Dominik Brodowski <linux@dominikbrodowski.net>,
bzolnier@gmail.com, linux-ide@vger.kernel.org
Subject: Re: [RFC/BUG?] ide_cs's removable status
Date: Wed, 21 Sep 2005 20:29:32 +0100 [thread overview]
Message-ID: <20050921192932.GB13246@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1127327243.18840.34.camel@localhost.localdomain>
On Wed, Sep 21, 2005 at 07:27:23PM +0100, Alan Cox wrote:
> On Mer, 2005-09-21 at 13:21 -0400, Mark Lord wrote:
> > In the case of CF cards in ide-cs, removing the card is equivalent
> > to removing the entire IDE controller, not just the media.
>
> It isn't the same as removing the entire PCMCIA controller layer. As far
> as PCMCIA is concerned there has been no change. Thus we have no media
> change event and we need ->removable = 1
>
> If the PCMCIA card disappeared each time it would be different
Last time I checked, with CF cards the media was an inherent part of
the CF card and is not changable without removing the card, opening
it, getting out the soldering iron... or alternatively plugging in
a different CF card.
Of course, PCMCIA will detect removal of the CF card provided the
PCMCIA hardware is working. PCMCIA will also detect a CF card which
has been changed while the system has been suspended _provided_ the
CIS does not match the previous cards CIS. It'll even do this if
you use cardctl suspend/cardctl resume.
However, if you suspend your system, remove your CF card, put it in
a different machine, use it (note: by doing this it could _already_
be in an inconsistent state), and put it back in the original machine
before resuming it, the cache on the original machine will disagree
with what is on the card. But then you have done something silly
already by taking media in an inconsistent state to another machine
- and modified that inconsistent filesystem state.
It sounds like you know of a case where this isn't true - maybe a bug
report. Can you expand on it?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2005-09-21 19:29 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-21 16:15 [RFC/BUG?] ide_cs's removable status Richard Purdie
2005-09-21 16:57 ` Alan Cox
2005-09-21 17:21 ` Mark Lord
2005-09-21 18:27 ` Alan Cox
2005-09-21 18:46 ` Richard Purdie
2005-09-22 0:18 ` Alan Cox
2002-01-01 5:18 ` Pavel Machek
2005-09-21 19:29 ` Russell King [this message]
2005-09-21 21:52 ` Richard Purdie
2005-09-22 0:06 ` Alan Cox
2005-09-22 0:10 ` Alan Cox
2005-09-22 10:22 ` Russell King
2005-09-22 13:39 ` Alan Cox
2005-09-22 13:29 ` Russell King
2005-09-22 14:41 ` Alan Cox
2005-09-22 14:21 ` Richard Purdie
2005-09-22 14:36 ` Russell King
2005-09-22 15:08 ` Alan Cox
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=20050921192932.GB13246@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bzolnier@gmail.com \
--cc=liml@rtr.ca \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@dominikbrodowski.net \
--cc=rpurdie@rpsys.net \
/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;
as well as URLs for NNTP newsgroup(s).