[PATCH] CE2 support added to xe driver

[M. Warner Losh]

In message: <20030424125226.GB89997 at tuatara.fishballoon.org>
            Scott Mitchell <scott+freebsd at fishballoon.org> writes:
: On Wed, Apr 23, 2003 at 09:28:47PM -0600, M. Warner Losh wrote:
: > Oh wait, looking at the CIS for the Xircom CreditCard Ethernet+Modem
: > 28.8, CEM28, 3.00 that I have shows that it is just a modem.
: > 
: > Looking at the code:
: > 
: > 	bus_space_write_1(bst, bsh, DINGO_ECOR, DINGO_ECOR_IRQ_LEVEL |
: > 						DINGO_ECOR_INT_ENABLE |
: > 						DINGO_ECOR_IOB_ENABLE |
: > 						DINGO_ECOR_ETH_ENABLE);
: > Set 0x800 to 0x47 (This looks a lot like MFC cards: Enable function,
: >    enable I/O and enable IRQ, but the startup software writes 0x41)
: > 	ioport = bus_get_resource_start(dev, SYS_RES_IOPORT, sc->port_rid);
: > 	bus_space_write_1(bst, bsh, DINGO_EBAR0, ioport & 0xff);
: > 	bus_space_write_1(bst, bsh, DINGO_EBAR1, (ioport >> 8) & 0xff);
: > Set 0x80a and 0x80c to the ioport we want to use.  This corresponds to
: > the I/O base registers in the standard.
: > 
: > 	bus_space_write_1(bst, bsh, DINGO_DCOR0, DINGO_DCOR0_SF_INT);
: > 0x820 to 0x1 (enable function, if it follows the MFC)
: > 	bus_space_write_1(bst, bsh, DINGO_DCOR1, DINGO_DCOR1_INT_LEVEL |
: > 						 DINGO_DCOR1_EEDIO);
: > 0x822 to 0xc (comments don't correspond to the standard meanings)
: > 	bus_space_write_1(bst, bsh, DINGO_DCOR2, 0x00);
: > 	bus_space_write_1(bst, bsh, DINGO_DCOR3, 0x00);
: > 	bus_space_write_1(bst, bsh, DINGO_DCOR4, 0x00);
: 
: I'm hoping that something similar to this, along with an offset to the base
: address used in the XE_IN* and XE_OUT* macros, will be enough to get these
: cards working.  They're really just earlier iterations of the Dingo (CEM56)
: hardware, so I'd expect a similar hack to be effective.  The DINGO_DCOR*
: registers are Dingo-specific; I'll have to reread the Xircom docs to find
: out exactly what's going on there.  Very likely that code will be redundant
: on the older cards.

OK.  It looks like there needs to be some non-standard way of dealing
with these things.  I'm thinking that the pccard code might want to
provide a good way to easily do this.

: >  89 08 04 06 00 80 c7 7f 31 3d
: > >>> Vendor Specific tuple
: 
: Notice that the MAC address is for some reason in tuple 89 on this card (my
: CEM28 is exactly the same).  Another quirk will be required there...

I don't know about a quirk, but maybe a way to grab a CIS of a given
type.  Would save having to use the CIS scanning code in this
driver...

Warner