summaryrefslogtreecommitdiffstats
path: root/sys/dev/pccard
Commit message (Collapse)AuthorAgeFilesLines
* Remove unnecessary Dlink de650 entryimp2005-09-241-1/+0
|
* Remove compat layer for OLDCARD compatibility. All instances of itimp2005-09-222-39/+0
| | | | are now gone from the tree.
* Better descriptions for the Jack of Diamonds cards.imp2005-09-211-5/+5
|
* Don't confuse the tuple code and the tuple length. Ooops. Since mostimp2005-09-211-1/+1
| | | | CIS are tiny, this likely hasn't bit anybody yet...
* Use the correct minor number for the pccardX.cis device.imp2005-09-201-3/+7
| | | | | | | Don't destroy a NULL device. This should fix the panics on boot people are seeing on systems with more than one pccard slot.
* remove some dead codeimp2005-09-201-9/+1
|
* Fix build.glebius2005-09-202-0/+14
|
* Implement /dev/pccardN.cis. This mirrors the CIS for the card to userland.imp2005-09-204-164/+368
| | | | | | pccardc dumpcis /dev/pccardN.cis will work now, but I may rewrite pccardc. Also, move more of the private data to a new file called pccardvarp.h.
* Call the passed function on cis scanning for all nodes in the CISimp2005-09-201-0/+17
| | | | chains, not just the 'real' ones.
* Add a few new functions interfaces to allow reading/writing attributeimp2005-09-134-11/+172
| | | | memory, the CCR and a tweak to cis_scan.
* Define and use PCCARD_MEM_PAGE_SIZE.imp2005-09-132-1/+3
|
* MFp4: Remove stale functions.imp2005-09-131-21/+0
|
* MFp4:imp2005-09-101-2/+2
| | | | | | | | | | | | | Reduce the size of ed a little by removing some CIS based entries (others likely can be removed too): o The D-Link DFE-670TXD doesn't need its own entry based on strings. o The Xircom CompactCard appears to be a TDK design, so list it there by ID and remove the strings. Increase the size of ed a little: o Add support for the Addtron AE-660CT and Addtron AE-660. This is a very generic NE-2000 clone (so generic that its CIS tags say NE-2000 generic card!).
* Sorting the belly button lint of history:imp2005-09-071-7/+15
| | | | | | | | o Note that the first 255 locations are reserved for JEDEC Ids from publication 106 (current revision Q, each one verified with JEDEC and the PMCICA). o Move ADAPTEC2 to the right section. o Sort TOSHIBA2 numerically.
* Update for a few recently discovered Olicom token ring cards:imp2005-08-311-1/+3
| | | | | OC3231 Token Ring + 28.8 modem OC3232 Token Ring + 33.6 modem
* Global Village appears to be using 0x018c as its vendor ID, but thisimp2005-08-291-1/+6
| | | | doesn't appear in the official lists, so make a note of that.
* o Add Toshiba's id. Make AGERE an alias for LUCENT. Add Ungermann's ID.imp2005-07-181-0/+7
| | | | | | o Add Agere Hermes II and II.5 PC Cards (from zipit web page), TDK GlobalNetworker 3410 (from dmesg for my card) and another alternate PANASONIC KXLC0005_2 (from pcmcia-cs id lists).
* I believe that this tsleep was placed here in 1.28 to try to solve theimp2005-07-171-3/+1
| | | | | | | problems we were having properly mapping the CIS attr space on some cards. Those problems have been solved other ways, so this kludge is no longer necessary. Remove it and have pccards come up a whole second faster.
* Insert missing int i;imp2005-07-151-0/+1
|
* Also provide the function type in the nomatch routine.imp2005-07-141-4/+7
|
* Add device id for RATOC REX CFU1 sl811 based USB Host Controller.takawata2005-07-141-1/+2
|
* o Check to make sure the card has a function (panic if not) in read_ivar.imp2005-07-132-45/+65
| | | | | | | o Use pf more consistantly for pccard_function. o Make sure we quote the strings properly (maybe this function belongs in subr_bus.c) o Tweak a comment to be more accurate after code changed.
* The supposed OLD STYLE network MAC id tuple was really just a buggyimp2005-07-132-14/+1
| | | | | expression in the card in question. Since that driver uses a different mechanism, retire the workaround for this bug.
* Add a couple of other products, tweak a few descriptions.imp2005-07-131-1/+5
|
* Add a boatload of new device ids, gleaned from the pcmcia-cs-3.2.8imp2005-07-101-8/+49
| | | | | | | distribution. Add the appropriate devices to the man pages. Obtained from: pcmcia-cs Approved by: re (scottl)
* Add device entry for a Farallon EtherMac PC Card that I won on ebay. Thisimp2005-07-061-0/+1
| | | | | | one is supported by the sn driver. Approved by: re (scottl)
* Upon relection, we shouldn't allow the tuple structs to be modified byimp2005-07-012-10/+6
| | | | | | | the functor, so make it a const pointer, and chase down the resulting const-poisoning. Approved by: re (scottl)
* Add a much-requested feature: The ability for pccard attachments toimp2005-07-014-8/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | scan the CIS for interesting tuples. 95% of what can be obtained from the CIS is harvested by the pccard layer and presented to the user in standard function calls. However, there are special needs at times where the standard stuff doesn't suffice. This is for those special cases. CARD_SCAN_CIS(device_get_parent(dev), function, argp) scans the CIS of the card, passing each tuple to function with the tuple and argp as its arguments. Returning 0 continues the scan, while returning 1 terminates the scan. The value of the last invocation of function is returned from this function. int (*pccard_scan_t)(struct pccard_tuple *tuple, void *argp) function called for each tuple. Elements of the CIS tuple can be read with pccard_tuple_read_{1,2,3,4,n}(). You are reading the actual tuple memory each time, in case your card has registers in the CIS. # I suppose these things should be documented in pccard(4) or something like # that. # I plan on unifying cardbus CIS support in a similar way. Approved by: re (scottl)
* Eliminate unused argument in PCMCIA_CARD macro.imp2005-06-241-5/+29
| | | | | | | | Provide a backwards compatible way to have the extra macro by defining PCCARD_API_LEVEL 5 before including pccarddevs for driver writers that want/need to have the same driver on 5 and 6 with pccard attachments. Approved by: re (dwhite)
* Add wireless + flash CF card I haveimp2005-06-241-0/+1
| | | | Approved by: re (pccard API changes)
* Initial import of ipw, iwi, ral and ural drivers:damien2005-04-181-0/+4
| | | | | | | | | ipw - Intel PRO/Wireless 2100 iwi - Intel PRO/Wireless 2200BG/2225BG/2915ABG ral - Ralink Technology RT2500 ural - Ralink Technology RT2500USB Approved by: silby (mentor)
* Big cleanup of resource code for pccard. Once coventry noticedimp2005-04-122-104/+30
| | | | | | | | | | problems here, it became clear we were being too complex. o Don't keep track of resources in two places o Use resource_list_purge instead of rolling our own o Just reassign the ownership of the resource, rather than freeing it and reallocating it. o Fix compile problems when sizeof(u_long) != sizeof(int)
* Cleanup of resource allocation code after having my attention focused onimp2005-04-122-34/+61
| | | | | | | | this code: o rid is stored in the resource, so don't bother keeping track of it here. o Implement memory space o Don't try to activate 'memory card' CFEs. This is type memory, as opposed to the memory resource.
* Use return value of resource_list_add to avoid a secondimp2005-04-121-7/+11
| | | | | | | | | | | | resource_list_find. Check to make sure that rle is not NULL and panic if it is (but it appears that resource_list_add already panics, so I'm not entirely sure it is necessary now). Add a test to make sure we have a interrupt resource when we're disabling it. This is also a cannot happen, but the extra care shoudln't hurt. Found by: Coventry tool via sam@
* deal with malloc failuresam2005-03-261-1/+4
| | | | Noticed by: Coverity Prevent analysis tool
* deal with failed malloc callssam2005-03-261-0/+14
| | | | | Noticed by: Coverity Prevent analysis tool Glanced at by: mdodd
* Need to initialize the resource list that we keep for our children.imp2005-03-181-0/+1
| | | | | | | STAILQ's require this, while it is optional for SLIST (well, as long as the memory is bzeroed). Noticed by: phk's crash
* Use STAILQ in preference to SLIST for the resources. Insert new resourcesimp2005-03-181-1/+1
| | | | | | | | | last in the list rather than first. This makes the resouces print in the 4.x order rather than the 5.x order (eg fdc0 at 0x3f0-0x3f5,0x3f7 is 4.x, but 0x3f7,0x3f0-0x3f5 is 5.x). This also means that the pci code will once again print the resources in BAR ascending order.
* 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
|
OpenPOWER on IntegriCloud