[ There have been several, seemingly-independent mentions of cardbus
support here over the past few weeks.  I understand that Jason has
some code or something from somebody, that may be not-ridiculously-far
from working, maybe he should mention it? ]

Ken Hornstein <kenh@cmf.nrl.navy.mil> writes:
> The documentation for the CardBus chips that I have can handle PC Card
> chips as well (you can either talk to the PC Card configuration registers
> in PCI space, or it can decode the ISA configuration range and pretend
> to be a 82365-compatible device).  Basically, you plug in your CardBus/
> PC Card into the socket, and the controller automagically figures out
> what kind of card it is.

Yup.


> I'm wondering if it make sense to create a seperate "cardbus" bus, or
> just teach the PCMICA bus about a different type of cards with a
> special "cardbus" bit set somewhere.  I think doing two different buses
> (pcmcia and cardbus) might be weird, since they really are the same
> hardware.  But perhaps at insert/probe time a card could be
> automagically attached to the "correct" bus (cardbus or pcmcia), so
> that might make sense.

The CardBus _controller_ hardware is generally a superset of the
PCMCIA hardware.  (I'm not sure if it's required that it be a
superset, but i don't think i've seen a cardbus implementation which
doesn't support the ExCA registers.)  The CardBus _card_ hardware, on
the other hand, may be entirely different.  I mean, why build a
cardbus card unless you want DMA, etc.

There are also "interesting" differences in the way the cards need to
be configured, in the way that CIS is accessed, and in several other
areas.


> Basically, CardBus doesn't look that hard, but I'm not sure how to
> organize it all :-/

Right now, things basically look like:

	ctlr* at parentbus? ...
	pcmcia* at ctlr? ... slot ?
	ep* at pcmcia? ...

where, if i recall, 'pcmcia' is a statically configured representation
of that slot, configured by virtue of the fact that the controller driver
knows that there's a card slot there.

What I think you want is:

	ctlr* at parentbus? ...
	pcmcia* at ctlr? ... slot ?
	cardbus* at ctlr? ... slot ?

	ep* at pccard? ...		# 3com elink3 PCMCIA
	ewhatever* at cardbus? ...	# 3com cardbus ethernet

where the 'pcmcia' and 'cardbus' nodes are _dynamic_ representations
of the card in the slot.


That is, right now, if you've got a PCIC and have all wildcarded
entries in your config file (so you get a 'complete' set of attached
PCMCIA slots), you will always end up with something like:

	pcic0 at isa0 port ...
	pcic0: ... has sockets A and B
	pcmcia0 at pcic0 controller 0 socket 0
	pcmcia1 at pcic0 controller 0 socket 1

I'd say that when you should just have:

	pcic0 at isa0 port ...

then, when you insert a pcmcia card, you get:

	pcmcia0 at pcic0 controller 0 socket 0

and if the card, or the card's functions, are recognized, then you
additionally get:

	ep0 at pcmcia0 function 0
	xx0 at pcmcia0 function 1

etc.

When the card is removed, ep0... _and_ pcmcia0 should go away.


This obviously extends to cardbus, because you can then attach a
'pcmcia' or 'cardbus' device as child to the controller based on the
type of the card detected by the controller.

That also has the property that you want, which is if a card's there
and unknown, it has an entry which can be manipulated, and the
presence of that entry implies the presence of a card.

the pcmcia/cardbus nodes would be responsible to doing the
device-type-specific programming and cis frobbing necessary.


In terms of source organization, you basically have three classes of code:
	* pcmcia-specific code (including pcmcia driver attachments)
	* cardbus-specific code (including cardbus driver attachments)
	* common code shared by both.

You could split the first two into separate directories, but there'd
be some common code that would have to live somewhere, which probably
isn't large enough to deserve its own directory and would be annoying
to name.  Or, i suppose, you could just dump it all into the pcmcia
directory.


cgd