dokas@cs.umn.edu (Paul B Dokas) writes:
>  There appears to be a few very talented people working on them, but
>  from my POV, that doesn't appear to be enough.  I, for one, would
>  *love* to hack on them, but I also like to track -current and merging
>  in the Cardbus patches every time I sup (about 5 times a week) is
>  not an optimal situation.

Well, just plain sup is the wrong tool for this sort of thing.  What you
really need to do is import the changes from the sup runs into a local cvs
repository on the vendor branch and then merge your local changes in.

>+ I'm still having problems with my 3COM 3CXEM556B (10 Mb ethernet and
>  V.90 modem combo)  The kernel finds the ethernet device (ep0) and the
>  modem (com1), but the ethernet is *write-only*.  From the small hacking
>  that I've done, it appears that no interrupts are getting into epintr()

>  Now, I vaguely remember someone complaining that there were known problems
>  with sharing interrupts on multi-function PCMCIA cards.  Is this true?
>  And if so, can somebody *please* tell me where the problem is?  I'm
>  willing to spend the time to get this working.

From what I understand about the problem it seems that the code sorta
expects that each function of a multifunction device can get its own
separate interrupt, but there's only a single line from the card to the
pcmcia controller that signals interrupts, i.e. you have to share the
interrupt.

One thought I had about this is that maybe we should attach a pcmciamfc
controller or so for a multifunction card and attach the individual
functions to the mfc (and register interrupts through the mfc).  But I'm
not sure that that's the right thing to do.  And it's way to long ago that
I've read the pcmcia code.


-- 
Christoph Badura					www.netbsd.org

	Anything that can be done in O(N) can be done in O(N^2).
	-- Ralf Schuettau (after looking at a particular piece of code)