summaryrefslogtreecommitdiffstats
path: root/sys/pci/if_rl.c
Commit message (Collapse)AuthorAgeFilesLines
* Make all Ethernet drivers attach using ether_ifattach() and detach usingarchie2000-07-131-6/+3
| | | | | | | | | ether_ifdetach(). The former consolidates the operations of if_attach(), ng_ether_attach(), and bpfattach(). The latter consolidates the corresponding detach operations. Reviewed by: julian, freebsd-net
* Use the correct register name. s/PCI_COMMAND_STATUS_REG/PCIR_COMMAND/peter2000-05-281-3/+3
|
* Move code to handle BPF and bridging for incoming Ethernet packets outarchie2000-05-141-17/+0
| | | | | | | | | | | | | | | of the individual drivers and into the common routine ether_input(). Also, remove the (incomplete) hack for matching ethernet headers in the ip_fw code. The good news: net result of 1016 lines removed, and this should make bridging now work with *all* Ethernet drivers. The bad news: it's nearly impossible to test every driver, especially for bridging, and I was unable to get much testing help on the mailing lists. Reviewed by: freebsd-net
* Apply patch to rl_rxeof() to really enforce payload alignment inwpaul2000-05-051-10/+7
| | | | | | the case where we receive a packet that wraps from the end of the RX buffer back to the start. This fixes an unaligned access trap on the alpha with NFS.
* Depend on miibus.peter2000-04-291-0/+2
| | | | | | | | Note that if_aue doesn't strictly depend on usb because it uses the method interface for calls rather than using internal symbols, and because it's a child driver of usb and therefore will not try and do anything unless the parent usb code is loaded at some point. if_aue does strictly depend on miibus as it will fail to link if it is missing.
* Two fixes for the RealTek:wpaul2000-03-291-2/+8
| | | | | | | | | - Only call m_pullup() when necessary. - Check return value from rl_encap() in rl_start() to avoid panic when we run out of mbufs. (Fixes PR kern/17582) PR: kern/17582
* Fix a small typo in the comments.billf1999-12-281-1/+1
|
* Fix problem reported by Matt Dillon. Occasionally, very small receivedwpaul1999-12-231-1/+14
| | | | | | | | | | frames would be handled incorrectly due to bad usage of m_pullup() in the case where the frame wraps from the end of the receive buffer back the beginning. Also, when manually extending small packets to pad them to the minimum frame length during transmission, zero out the pad area to make some really paranoid people happy.
* Fix usage of m_pullup().wpaul1999-11-161-1/+1
|
* Make some tweaks to the RealTek driver:wpaul1999-10-211-11/+25
| | | | | | | | | | | | | | | | | | - Fix a bug in rl_rxeof() handler: in the case where the packet wraps from the end of the receive buffer back to the beginning, we need to insure that at least sizeof(ether_header) bytes make it into the first mbuf. If we don't, then doing eh = mtod(m, struct ether_header *) loses. To avoid this, we use m_pullup() to suck at least MHLEN - RL_ETHER_ALIGN bytes into the first mbuf, which should also help small packets fit into a single mbuf. Pointed out by: Philip A. Prindeville <philipp@zembu.com> - Make the transmit threshold autotuning: start off with a small value and jack it up when TX underruns are detected. - Also improve TX error recovery: kick the chip in the head with a reset/init sequence to make sure it recovers afer a transmit error.
* Change contigmalloc() lower memory bound from 1MB to 0 to improvewpaul1999-09-251-1/+1
| | | | | | | chances of allocations succeeding on systems with small amounts of RAM. Pointed out by: bde
* As suggested by phk, unconditionalize BPF support in these drivers. Sincewpaul1999-09-231-10/+2
| | | | | | | there are stubs compiled into the kernel if BPF support is not enabled, there aren't any problems with unresolved symbols. The modules in /modules are compiled with BPF support enabled anyway, so the most this will do is bloat GENERIC a little.
* Tweak these for what I hope is the last time: change the DRIVER_MODULE()wpaul1999-09-221-1/+1
| | | | | | | | | | declaration for the interface driver from "foo" to "if_foo" but leave the declaration for the miibus attached to the interface driver alone. This lets the internal module name be "if_foo" while still allowing the miibus instances to attach to "foo." This should allow ifconfig to autoload driver modules again without breaking the miibus attach.
* Un-do the changes to the DRIVER_MODULE() declarations in these drivers.wpaul1999-09-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This whole idea isn't going to work until somebody makes the bus/kld code smarter. The idea here is to change the module's internal name from "foo" to "if_foo" so that ifconfig can tell a network driver from a non-network one. However doing this doesn't work correctly no matter how you slice it. For everything to work, you have to change the name in both the driver_t struct and the DRIVER_MODULE() declaration. The problems are: - If you change the name in both places, then the kernel thinks that the device's name is now "if_foo", so you get things like: if_foo0: <FOO ethernet> irq foo at device foo on pcifoo if_foo0: Ethernet address: foo:foo:foo:foo:foo:foo This is bogus. Now the device name doesn't agree with the logical interface name. There's no reason for this, and it violates the principle of least astonishment. - If you leave the name in the driver_t struct as "foo" and only change the names in the DRIVER_MODULE() declaration to "if_foo" then attaching drivers to child devices doesn't work because the names don't agree. This breaks miibus: drivers that need to have miibuses and PHY drivers attached never get them. In other words: damned if you do, damned if you don't. This needs to be thought through some more. Since the drivers that use miibus are broken, I have to change these all back in order to make them work again. Yes this will stop ifconfig from being able to demand load driver modules. On the whole, I'd rather have that than having the drivers not work at all.
* Grrr. Okay, changing the devnames was a bad idea. Put them back the waywpaul1999-09-201-1/+1
| | | | they were.
* Fix the strings in the driver_t structs so that they match the new nameswpaul1999-09-201-1/+1
| | | | in the DRIVER_MODULES() declarations. *sigh*
* Goofed and didn't change the second DRIVER_MODULE() linking these withobrien1999-09-201-1/+1
| | | | | | the miibus. Noticed by: wpaul
* Change the name we register with DRIVER_MODULE() to include the leadingobrien1999-09-201-1/+1
| | | | | | "if_". Reviewed by: msmith, wpaul
* Add a pointer to "controller miibus0" for people who will not read thepeter1999-09-081-0/+1
| | | | | commit messages or GENERIC and insist on running -CURRENT. It probably won't work, but it's worth a try.
* Convert the RealTek 8139 driver to newbus and miibus in one swell foop.wpaul1999-08-311-557/+258
| | | | Also set it up to be compiled as a module.
* Don't restrict our requests for contiguous memory to addresses >= 1MB.bde1999-08-291-1/+1
| | | | | | | | This fixes, at least, panics in ncr_attach() on i386's with about 5MB of memory. The restriction was a hack to leave some low memory for ISA DMA, but on i386's we now allocate pages from the top down, so all the restriction did was cause our allocations to fail when there is no free memory above 1MB.
* $Id$ -> $FreeBSD$peter1999-08-281-2/+2
|
* Clean up after removing sys/eventhandler.h from sys/systm.h at the lastmsmith1999-08-211-2/+3
| | | | | minute. This should cover all of the missed cases (and should let LINT build again).
* Implement a new generic mechanism for attaching handler functions tomsmith1999-08-211-6/+7
| | | | | | | | | | | | | events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
* Remove the definitions for the SiS 900 chip. This is not a RealTekwpaul1999-07-221-6/+3
| | | | | clone after all. I have the datasheets for this part; hopefully I can write a proper driver soon.
* Rename bpfilter to bpf.des1999-07-061-7/+7
|
* Change the cast in pci_map_port() from u_short * to pci_port_t * so itpeter1999-07-021-3/+3
| | | | | | | compiles cleanly on the Alpha. (On the alpha, the port type is an int, not a short). Cast a couple of pointers to ints via 'uintptr_t' rather than 'unsigned int' since uintptr_t is long (64 bit) on Alpha, as are pointers.
* Fix up the RealTek 8139 driver to work on FreeBSD/alpha. This involves awpaul1999-06-191-8/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | few changes: - there was a bug in rl_list_tx_init(): it was calculating the registers to initialize incorrectly. Not a problem on the x86 where unaligned access are allowed, but a problem on the alpha. - set rl_btag accordingly depending on the machine type - rl_rxeof() needs to be sure to longword-align the packet data. This is a little tricky since we copy the data out of the receive buffer using m_devget(), however there's no way to tell m_devget() to fill in the mbufs starting at a particular offset. To get around this, we tell m_devget to copy bytes+2 bytes starting at offset offset-2. This results in the proper alignment, and we can trim off the two leading bytes afterwards with m_adj(). We also allocate some extra space before the start of the receive buffer so that we don't get into trouble in the case where offset == 0. - redefine vtophys() in if_rlreg.h for the alpha. Making this chipset work on the alpha is sort of the inverse of putting a jet engine on a rowboat (putting a propeller on a 747?) but when you can get these things for $5 a pop, it's hard to stop people from buying them.
* Add support for SiS 900 chipset (PCI ID 0x1039/0x0900), which appears towpaul1999-05-301-3/+6
| | | | be yet another rebadged RealTek 8139.
* Simplify the COMPAT_PCI_DRIVER/DATA_SET hack. We can add:peter1999-05-091-6/+2
| | | | | | | | #define COMPAT_PCI_DRIVER(name,data) DATA_SET(pcidevice_set,data) .. to 2.2.x and 3.x if people think it's worth it. Driver writers can do this if it's not defined. (The reason for this is that I'm trying to progressively eliminate use of linker_sets where it hurts modularity and runtime load capability, and these DATA_SET's keep getting in the way.)
* Use COMPAT_PCI_DRIVER() for registration if it exists. This shouldn'tpeter1999-04-241-2/+6
| | | | hurt the driver portability to 3.x too much for where drivers are shared.
* Merge in some updates for the RealTek driver, mainly:wpaul1999-04-121-141/+60
| | | | | | - Rewrite the transmit section to be a little less bogus. - Set ifq_maxlen correctly. RL_TX_LIST_CNT - 1 is wrong, because for the RealTek, RL_TX_LIST_CNT is 4. Set it to IFQ_MAXLEN instead.
* Add support for still more cheapo 10/100 cards: Delta Electronics andwpaul1999-02-231-3/+8
| | | | | | | | | | Addtron appear to have their own VIA Rhine II and RealTek 8139 boards with custom PCI vendor and device IDs. This commit updates the PCI vendor and device lists in the vr and rl drivers so that we can probe the additional devices. Found by: nosing around the PCI vendor and device code list at: http://www.halcyon.com/scripts/jboemler/pci/pcicode
* Remember to initialize ifp->if_snd.ifq_maxlen.wpaul1999-02-011-2/+3
|
* Multicast code isn't quite correct. The RealTek wants the upper six bitswpaul1999-01-221-5/+5
| | | | | | | of the CRC as the multicast hash table bit, not the lower six bits. Plus we have to flip on all bits in the table for multicast mode. Pointed out by: Kazushi SUGYO <k-sugyou@nwsl.mesh.ad.jp>
* Small cosmetic tweak: in rl_rxeof(), use the constant RX_CMD_EMPTY_RXBUFwpaul1999-01-161-3/+3
| | | | instead of the magic number 1.
* Grrrr... The RealTek 8139 is yet another chip that includes the ethernetwpaul1998-12-241-4/+13
| | | | CRC in received frames, which we need to trim manually.
* probe function changed from returning char * to const char *.dillon1998-12-141-4/+4
|
* Silence gcc -Wall -ansi -pedantic.wpaul1998-12-101-18/+12
| | | | Pointed out by: Eivind
* The "easy" fixes for compiling the kernel -Wunused: remove unreferenced staticarchie1998-12-071-3/+3
| | | | and local variables, goto labels, and functions declared but not defined.
* if_rl.c: make a small tweak to properly handle the Accton MPX 5030/5038wpaul1998-12-071-15/+15
| | | | | | | | as a RealTek 8139 if_rlreg.h: use bus_space_read_X() in CSR_READ_X() macros instead of directly calling inb()/outb() etc... rl.4 + RELNOTES.TXT: mention that SMC EtherEZ PCI 1211-TX is supported by the RealTek driver
* Add missing return statement to rl_phy_writereg(). This bug didn't actuallywpaul1998-11-201-2/+3
| | | | | | hurt anything, but it's still a bug. Pointed out by: Jason Wright <jason@thought.net>
* The Accton 1207D adapter uses a chip called the MXP 5030 (or 5038)wpaul1998-11-181-25/+24
| | | | | | | | | | | | | | which is either a RealTek 8139 in disguise or a RealTek workalike. This commit fixes the PCI vendor/device ID for this device and updates the description string to reflect the actual identity of the device. I also changed the transmit encapsulation routine to always to buffer copies on transmit. We end up doing this 99% of the time anyway. I also tweaked the code that pads packets out to the minimum length (60) bytes. I was fixing up the m_pkthdr.len value but not m_len. I don't think this makes that much difference in the grand scheme of things, but it makes me feel better.
* Add driver support for PCI fast ethernet adapters based on thewpaul1998-10-181-0/+1989
RealTek 8129/8139 chipset like I've been threatening. Update kernel configs, userconfig.c, relnotes and sysinstall. No man page yet; comming soon. I consider this driver stable enough that I want to give it some exposure in -current.
OpenPOWER on IntegriCloud