summaryrefslogtreecommitdiffstats
path: root/sys/dev/pccard
Commit message (Collapse)AuthorAgeFilesLines
* Belkin F5D5020 is an OEM'd card from RACORE based on the AX88190imp2005-02-221-0/+1
| | | | | | chipset. Add support for this card. Office Max has them on sale and I was surprised that we didn't have it in our supported list when I plugged it in...
* memspace is set to some value by masking off bits. When these bitsimp2005-02-171-4/+3
| | | | | | | | | | | | | | are equal to PCCARD_TPCE_FS_MEMSPACE_NONE, memspace will be zero, so testing for this case inside of the if statement results in dead code. We'd fail to set a value to zero that's already zero (since it is initialized to 0 indirectly) with this code being there. Well, except in the very rare case that we have a card that has a defualt entry that includes a memory space followed by one that has no memory space (these are extremely rare, I don't recall ever having seen one :-). Fix this by setting num_memspace to 0 in a more appropriate place. Submitted by: Coverity Prevent analysis tool
* Add an XXX comment about string quoting.imp2005-02-161-0/+1
|
* Remove more deadwood that never got implemented in NEWCARD, since NEWCARDimp2005-02-151-15/+0
| | | | | went a different direction than was anticipated when these compatibility shims were added.
* o It turns out that most of the ne-2000 cards that I have got real unhappyimp2005-02-141-4/+3
| | | | | | | | | with the latest changes. They actually have valid ROM data at location 0 of memory, just like a real NE-2000 ISA card. Use this data, if the ROM passes a few basic tests, as an additional source for the MAC address. Prefer the CIS over this source, but have it take precidence over falling back to reading the attribtue memory. o Minor cleanup of a few devices that we match on based on CIS string.
* Remove card_get_function. It looks like it was intended to be aimp2005-02-141-9/+0
| | | | | | | | | bridge between OLDCARD and NEWCARD for drivers to inquire after the function number (eg, 0, 1, 2). Nobody ever used it, so retire it with honors. NEWCARD never implemented it, and the same information can be obtained by the pccard_get_function_number(). MFC After: 3 days
* Remove DLINK_3, its unused. Remove NETGEAR FA410TX, since it is theimp2005-02-091-3/+0
| | | | | | | same as the LINKSYS COMBO_ECARD (which also seems to be the same as another linksys product that also has a modem, but I can't find that one at the moment). Remove the PCM100, since it is now no longer used.
* Sort PANASONIC products numericallyimp2005-02-031-1/+1
|
* The two PLANEX cards listed in pccarddevs, identified only by theirimp2005-02-011-12/+11
| | | | | | | | | | | | | | | | | | CIS, weren't actually used anywhere (other than the generic PC Card code when certain variables are defined). They aren't used in NetBSD either. Make things simpler by removing them. Change PLANEX_2 to PLANEX and tweak wi and owi to use that instead. The PLANEX id seems to actually be pci ID assigned to planex, not its pcmcia id. Ooops. I don't know if this is a reporting error from where this entry came from, or if it is a mistake on PLANEX's part. I suspect the latter, as ACTIONTEC and NEWMEDIA made the same mistake (although new media may be because it uses an advansys chip inside). Make a note of this in the file. The 0xc entires may be JEITA assigned, so note that as well. # This leaves just 3 entries that are totally unknown: airvast, archos # and edimax although the arivast number is the same assigned to # avertec in usb...
* The Olicom OC2220 has an ID of 0x101, not 0x2220 as I previouslyimp2005-01-291-1/+1
| | | | | | | | | thought. I'm unsure why I thought this was the case, but it definitely isn't for this card. If another card with the other ID makes an appearance, then we'll add a second entry for it. # With this change my Olicom OC2220 is now working again, since I make # this commit with that device. :-)
* Add back support for D-LINK DMR-650TX, and all the other OEMd versionsimp2005-01-271-1/+1
| | | | | | | of this card (evidentally MultiMobile also sold this card as MT5634ZLXI/E). Reported by: Bastian Brinkman
* Move 143 back to its rightful owner: Grey Cell systems, which OEMd enet cardsimp2005-01-271-4/+4
|
* Turns out that Digital's DEPCM-BA and I-O Data PCLATE are both OEMimp2005-01-251-6/+6
| | | | | | | | | versions of the Racore PC Card Ethernet card. Rearrange to reflect this reality. This ejects IODATA from 0x1bf, which belongs to Racore. Thanks to Wilko for providing me with a dumpcis for the DEPCM card. Also, added Nextcom Nexthawk card from NetBSD
* Unbreak the Digital DEPCM-BA. Since it doesn't seem to have a properimp2005-01-251-1/+2
| | | | | manufacturer ID, we need to use -1 rather than 0x100 when matching. Do this by defining and using DIGITAL2 .
* Remove dummy vendor id for DIGITAL now that we have the real one.phk2005-01-251-1/+0
|
* Minor whitespace cleanupimp2005-01-251-10/+16
| | | | | Add Digitial vendor ID (from NetBSD) Add Anycom vendor and products (from NetBSD)
* Add NEXTCOM NEXTHAWK ethernet card.imp2005-01-251-2/+6
| | | | From NetBSD
* There have been a substantial number of changes to this file from theimp2005-01-241-1/+28
| | | | NetBSD original, so add our copyright notice as well.
* Add an entry for Magic Ram, Inc's ETHERNET PC CARD 933926 card I justimp2005-01-241-0/+9
| | | | | won on ebay. Also, add a pointer to the PCMCIA's web site for the registered tuples (== manufacturer ID's).
* Ignore the expected function number.imp2005-01-241-5/+0
| | | | | | | | | | | NetBSD went this route a while ago. FreeBSD originally tried this to cope with multifunction cards. However, it turns out that we're better off not worrying about the function number, and instead worry about the function type for the function. This has worked well in NetBSD, and all FreeBSD's relevant drivers have been converted. # I'll rework the macros that specify them shortly, as soon as I can # come up with a good, compatible way to deal...
* u_intXX_t -> uintXX_timp2005-01-242-15/+15
|
* Some older PC Cards have a weird format for FUNCE tuples. They appearimp2005-01-212-2/+15
| | | | | | | | | as type 0, rather than the usualy type 4. Assume that this format is from an old standard and go with it. The Fujitsu FMV-186A and Silicom Ethernet cards I have both have tuples with this format, and they are both pretty old cards. # if somebody knows for sure, please let me know.
* Use Intersil chip names for the symbols, since many makers use theimp2005-01-201-2/+3
| | | | intersil IDs but their own name in the CIS.
* Minor tweaks to properly order things.imp2005-01-201-4/+4
|
* Fix spelling errorimp2005-01-191-1/+1
| | | | submitted by: Anders Hanssen
* Go ahead and match on CIS3 and CIS4 strings as well. These are NULLimp2005-01-171-1/+14
| | | | | | | | | for the vast majority of our cards. However, they are critically needed to distinguish different fe based PC Cards (the FMV-182 from the 182A) which need to be treated differently (the ethernet address is loaded not from the standard CIS-based ethernet tuples, but from differing locations in attribute space based on the version string in CIS3. This should have no impact for other users of this function.
* Tweaks to the name of this card, based on input from Sean Shapira.imp2005-01-101-1/+1
|
* Add Eagle NE200 Ethernet LAN MBH10302 card. This appears to be a feimp2005-01-101-0/+1
| | | | | | card, and works with that driver. However, Eagle is using Fujitsu's vendor number and a product code of 4, which seems a little odd. Still, there's no conflicts...
* Start each of the license/copyright comments with /*-, minor shuffle of linesimp2005-01-068-8/+8
|
* Shame on me. I screwed up product ID for the 3COM Bluetooth PC-Card.emax2004-09-091-1/+1
| | | | | | It's 0x0040 not 0x0400. MFC after: 3 days
* Some cards don't have the info entries in the CIS, so vendorstr and/orimp2004-08-161-7/+21
| | | | | | | | | prodstr may be NULL when fetched. For the default device description, guard against this and return the numeric IDs instead when this happens. For the matching routines, and consider NULL to not match those entries that aren't NULL w/o calling strcmp. Early patches by: Anders Hanssen
* Don't nest includes here. There's no need and the subset included is lame.imp2004-05-281-5/+0
| | | | Submitted by: bde
* Include required machine/bus.himp2004-05-281-0/+1
|
* Fixing disorder is the hardest thing in the world: Learn to sort :-)imp2004-05-271-1/+2
| | | | Submitted by: bde
* These are now not needed, after repo copy and conversion.imp2004-05-272-186/+0
|
* Sort includes, remove unnecssary ones.imp2004-05-271-10/+3
| | | | Submitted by: bde
* Move to generating pccarddevs.h on the fly, both for the kernel andimp2004-05-262-1181/+1
| | | | | | | the modules. Also generate usbdevs.h automatically now, but a non-kernel file is stopping that at the moment.
* Sync to pccarddevs 1.84imp2004-05-131-1/+4
|
* Add Intel EtherExpress PRO/100 LAN Modem. This will eventually beimp2004-05-131-0/+1
| | | | added to xe once the pccard issues are resolved...
* Resyncemax2004-05-101-1/+4
|
* Mode few Bluetooth defines into system include filesemax2004-05-101-0/+1
| | | | Reviewed by: imp
* This file has never been used, nor will it ever be used in FreeBSD, soimp2004-05-091-71/+0
| | | | remove it.
* Improve reading of CIS cards:imp2004-04-121-3/+10
| | | | | | | | | | | | | | (1) Align to 64k for the CIS. Some cards don't like it when we aren't aligned to a 64k boundary. I can't find anything in the standard that requires this, but I have 1/2 dozen cards that won't work at all unless I enable this. (2) Sleep 1s before scanning the CIS. This may be a nop, but has little harm. (3) The CIS can be up to 4k in some weird, odd-ball edge cases. Since we have limiters for when that's not the case, it does no harm to increase it to 4k. #1 was submitted, in a different form, by Carlos Velasco.
* Sync to pccarddevs 1.83rsm2004-04-091-11/+29
| | | | Reviewed by: imp (mentor)
* Add Xircom XEM5600 and known versions of CE2, CEM33 and CEM56.rsm2004-04-091-5/+11
| | | | | | | | Xircom had an unfortunate habit of re-using PCMCIA IDs for quite different cards - the xe driver knows about this and uses the first byte of 'extra' PCMCIA ID info to identify cards with ambiguous IDs. Reviewed by: imp (mentor)
* Sync to pccarddevs 1.82imp2004-03-251-2/+5
|
* Add a new Intersil card that DLINK is selling as the DWL-650.imp2004-03-251-1/+2
| | | | Reported by: Brian O'Shea
* Convert callers to the new bus_alloc_resource_any(9) API.njl2004-03-171-2/+2
| | | | | Submitted by: Mark Santcroos <marks@ripe.net> Reviewed by: imp, dfr, bde
* Sync to pccarddevs 1.81.ume2004-01-211-1/+4
|
* There is PANASONIC KXLC005 which has another product id.ume2004-01-211-0/+1
|
OpenPOWER on IntegriCloud