Re: [PATCH] CE2 support added to xe driver
"M. Warner Losh" <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.mobile |
|---|---|
| Message-ID | <[email protected]> |
In message: <[email protected]> Scott Mitchell <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mobile To unsubscribe, send any mail to "[email protected]"