From: Benjamin Herrenschmidt <benh@kernel•crashing.org>
To: Marcelo Tosatti <marcelo.tosatti@cyclades•com>
Cc: Paul Mackerras <paulus@samba•org>,
linux-ppc-embedded <linuxppc-embedded@ozlabs•org>
Subject: Re: [RFC] handle access to non-present IO ports on 8xx
Date: Fri, 03 Jun 2005 08:11:01 +1000 [thread overview]
Message-ID: <1117750262.31082.73.camel@gaston> (raw)
In-Reply-To: <20050602170245.GA7456@logos.cnet>
On Thu, 2005-06-02 at 14:02 -0300, Marcelo Tosatti wrote:
> Hi Ben,
>
> On Thu, Jun 02, 2005 at 12:46:32PM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2005-06-01 at 13:50 -0300, Marcelo Tosatti wrote:
> >
> > Hrm... removing a PCMCIA card triggers mchecks ? that is bad... With
> > "proper" PCMCIA controllers, those are swallowed properly when the card
> > is removed. The eating of the machine check is a bit too hackish to my
> > taste... Better is to "not do that" by making sure the legacy crap isn't
> > trying to tap unexisting ports, but then, if PCMCIA is also a
> > problem...
>
> Well, cardmgr calls the driver's shutdown/close routine as soon as
> the card is removed. Some of those methods write to IO registers in
> the process (eg net/pcmcia/pcnet_cs.c).
>
> I dont see any elegant change that could be done in PCMCIA.
I know, the thing is, on platforms with a "classical" PCI<->PCMCIA
bridge, the bridge will not issue machine checks when the card is
removed. I don't know if that is possible with your HW setup, I suppose
you are hooking PCMCIA directly to the CPU IO bus ...
> One possibility that comes to mind would be to enforce the rule
> that drivers should not writeout in case of a removal event,
They can't know, they get the removal even too late. The driver may be
in the middle of writing when you remove the card. If there is no HW way
to prevent the machine check, then you'll need software recovery.
> but that does not sound feasible to me: It just looks too messy,
> however I have no good argument against it.
>
> Well, its restricted to 8xx (maybe 32-bit PPC) with PCMCIA, so its
> just not worth the trouble?
Hehe... dunno.
> Hmmm... I'll look that up. My limited testing on HW in question does not
> exhibit longer MCE delays than "twi/isync/nop" sequence - actually, it is
> always triggered during the IO access instruction itself.
I suppose the 8xx may actually be quite synchronous on IOs then...
> Where can I find information about write posting on 8xx? Is there a
> term for it used in PPC documentation? I can't find anything...
Well, do you have a store queue ? What does the 8xx manual says about
ordering & queueing of non cacheable loads & stores ? Maybe the chip is
fully synchronous on IOs ?
next prev parent reply other threads:[~2005-06-02 22:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-01 16:50 [RFC] handle access to non-present IO ports on 8xx Marcelo Tosatti
2005-06-02 2:46 ` Benjamin Herrenschmidt
2005-06-02 7:04 ` Pantelis Antoniou
2005-06-02 17:02 ` Marcelo Tosatti
2005-06-02 22:11 ` Benjamin Herrenschmidt [this message]
2005-06-03 12:08 ` Mark Chambers
2005-06-08 9:01 ` Marcelo Tosatti
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=1117750262.31082.73.camel@gaston \
--to=benh@kernel$(echo .)crashing.org \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
--cc=marcelo.tosatti@cyclades$(echo .)com \
--cc=paulus@samba$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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