>It's not obvious to me how you mean this statement, but a naive
>interpretation leads to something like:
>
>cbb at whatever
>pcic at cbb

Nope.  What's meant is more like:

   cbb at whatever:  cardbus, pcmcia
   pcic at whatever: pcmcia

with child pcmcia devices attaching via pcmcia?, and cardbus devices
attaching via cardbus?.

Hayakawa-san's point is to avoid duplcating the cis-tuple and pcmcia
functionality almost verbatim, once for pcic bridges and once for
cardbus bridges.  IF that means we need to add callback methods via
the parent bridge to access ExCA(?) or whatever registers, fine.  If a
cardbus bridge is set so that it won't do PCMCIA, then I guess we
don't support pcmcia (16-bit) cards on it. ? Or do we need a
pcmcia-device register-access layer that does a CardBus dance?

One of the design goals here -- one which everyone who's mentioned it
seems to share -- is to get /away/ from fixing device names to
specific slots, and to attach them to a given card, irrespective of
which slot that card may currently be in.  And that's the point where
I think purely slot-based architectures just dont cut it.

That aside (I cant tell what your take is), I dont think there's
really much disagreement here. I dont like attaching
<# slots> x <# drivers> at boot time any more than you or Ted.


If (and it's an if) we can rerun autoconfig uration for a given slot,
in a kernel thread, in response to an interrupt generated at
card-insertion time, then most (all?) of the attach-tme problems
simply go away. The big issue left is:

      a) where and how to keep the state to make a device
         (e.g. NIC with a given MAC address) attach with the same
	  name when its re-inserted, regardless of wheter its
	  in the same slot,
and
      b) whether struct devices go away  completely on detach,
         or whether htey hang around in some `phantom' state.

I'm not too unhappy with a bit in the struct device which says `device
gone away'.  A naive implementation would die horribly if someone
unplugs a hotswap card and re-inserts under a different parent --
e.g., a desktop with mutilple pci/eisa-to-pcmcia bridges.

Can you see a cleaner way to keep the `phantom device' state around--
say, a global list of pointers to temporary copies of the device softc?