Date: Wed, 01 Dec 1999 21:39:30 -0800 From: Mike Smith <msmith@freebsd.org> To: Warner Losh <imp@village.org> Cc: mobile@FreeBSD.ORG Subject: Re: cvs commit: src/sys/pccard pccard.c src/sys/isa sio.c src/sys/dev/ed if_ed_pccard.c src/sys/dev/ep if_ep_pccard.c Message-ID: <199912020539.VAA00927@mass.cdrom.com> In-Reply-To: Your message of "Wed, 01 Dec 1999 18:31:43 MST." <199912020131.SAA05695@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> In message <199912020119.RAA03619@mass.cdrom.com> Mike Smith writes:
> : No. As I keep saying, the device is _not_ gone until the driver lets it
> : go. The child is in complete control of this, and can easily call a bus
> : method to verify whether it should give up on I/O even _before_ it's
> : notified by the parent that the hardware is gone.
>
> So long as we can do it in such a way that we don't have a race here.
This actually becomes much more complex when you bring CardBus into the
picture, as I believe (correct me if I'm wrong, since you have the spec
there) that it uses level-triggered interrupts. In this case, the device
interrupt handler can't return (well, it can, but it will be immediately
re-entered).
This really makes it imperative for the interrupt handler itself to be
able to test for the hardware. The logic should probably go something
like:
dev_intr()
{
for(;;) {
if (sc->device_is_removable && !bus_device_present()) {
revoke_device(); /* disables interrupt */
return;
}
if (!device_needs_attention(sc))
return;
...
The device's removability and physical status should probably also be
checked anywhere that the code decides that the device is misbehaving.
In the _same_context_ the device's interrupt needs to be disconnected and
the driver's internal state for the device revoked.
Once the handler returns the bus status mechanism will probably catch the
device leaving and call the detach routine, which will note that the
device has already been revoked (if it cares, I guess) and clean up
properly.
You could also refcount the softc so that while it's in use by another
context it can't be deleted, and then drop the refcount when you detect
the device has gone away. Then you'd clean up the softc anytime you went
to drop the refcount and noticed it was already zero.
Oh, and I forgot with the CardBus thing above; if the slot is sharing an
interrupt with someone else, you're probably screwed as well. (Unless the
bus lets you call back into it to disable a slot once you've detected
that it's gone.)
Hmm, thinking about it more, that would suggest that the "right" thing
would be a bus method that is the equivalent of our current slot poll -
the device driver checks the slot if it thinks the peripheral is acting
up; the bus code can then call the detach routine, kill the interrupt
off, etc. and the driver gets a return value that it can test in order to
decide whether the device has been killed off. That would avoid all the
mess with reference counting, etc. and only leave code elsewhere in the
driver that's using the softc. You'd have to mask interrupts for that. 8(
> This also assumes that the outb/inb aren't blocking, which I don't
> think they are based on what I know about the how non pccard systems
> work.
I can't imagine any scenario in which they could block.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org
\\ and he'll hate you for a lifetime. \\ msmith@cdrom.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912020539.VAA00927>