Re: pcmcia and buses

[Tobias Weingartner <weingart@natasha.brandonu.ca>]

On Thursday, December 11, Jim Rees wrote:
> I'm trying to get pcmcia to work and need some architectural advice.  I
> really don't understand how buses work.
> 
> The problem is that if you turn off a device, then try to turn it back on,
> the machine either panics (ep) or refuses to use the device (pccom).  This
> is because pcmcia_configure calls the bus probe routine at power on
> (actually at probe time), but the device has already been probed once.  The
> ep driver sees that the bus space has already been mapped and panics in the
> attach routine.  The pccom device just refuses to proceed (I don't know why
> yet).

You will find a lot of "problems" with attaching and "removing" devices.  For
one, the driver (I know of no other way) would have to release all the bus
mappings, and aquire them again later for the "reattach".  This might mean
going through all the isa drivers that support pcmcia, and making sure they
work correctly.

I think it would be easier to probe/attach the device at boot time, and for
detach just mark it "detached".  Then on a reattach, unmark it "detached".
IE: some driver level code.  Note, I don't know how you are going to handle
devices that come on line after the machine has booted.  IE:  You shove an
ethernet device into the pcmcia slot after the machine is up and running.  I
don't know if the current code handles this case...  I suppose that if you can
reprobe the scsi busses, chances are we can make the pcmcia bus reprobe as
well.  Think of it as a bus that never looses any device, just continues adding
devices.


> pcmcia_unconfigure never actually detaches the device.  There is a comment
> in the code that says this is too hard given the complexity of the network
> code.  But then it goes ahead and tries to re-attach it anyway.

I think a real detach of a device would be very hard.  Basically all the 
drivers
and kernel services that rely on various drivers would have to be able to
remove things they added.  Flash cards, modems, networks, etc.


> I see two ways of attacking this.  The "architecturally pure" way would be
> to make detach work.  But as a lazy programmer (and by the way laziness is a
> virtue in programmers) I'm tempted to never detach, and avoid the attach
> when turning on a device that has already been attached once.

I think this way would be easier, less error prone.  Just mark the device
not present in the driver, and return error codes for people that want/try
to use it.  Then when the reattach happens, mark the device as not not present.
;-)


> Is there any reason to prefer one or the other of these methods?  I only
> care about ep and pccom, but in general do probe and attach routines do any
> kind of essential initialization that the open routine wouldn't?  Is it
> offensive to leave devices "attached" that aren't even plugged in?

I'm having similar troubles with some of the PNP code.  There is no real
"standard" about how probe/attach/open should be coded, and how they should
interact.  My problem is the probe/attach interraction.


> Actually the best thing would be to import J.T. Kohl's latest code, but I'm
> way too lazy for that.

How much better, how hard would this be?

--Toby.
*----------------------------------------------------------------------------*
| Tobias Weingartner | Email: weingart@BrandonU.Ca | Need a Unix sys-admin?  |
| 6B-1137 Lorne Ave. |-----------------------------| Send E-Mail for resume, |
| Brandon, Canada    | Unix Guru? Admin, Sys-Prgmr | and other details...    |
|----------------------------------------------------------------------------|
|      %SYSTEM-F-ANARCHISM, The operating system has been overthrown         |
*----------------------------------------------------------------------------*