FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F10.2 2013-08-19T10:20:20Z 2013-08-19T10:20:20Z Andre Oppermann andre@FreeBSD.org 2013-08-19T10:20:20Z urn:sha1:9d1c4ca773b4003fda9cf7cb5a94147c163982bd from bce(4), bxe(4), mge(4) and ti(4) drivers. 2012-12-04T09:32:43Z Gleb Smirnoff glebius@FreeBSD.org 2012-12-04T09:32:43Z urn:sha1:c6499eccad497913a5025fbde8ae76da70e08043 malloc(9) flags in sys/dev. 2012-11-05T19:16:27Z Dimitry Andric dim@FreeBSD.org 2012-11-05T19:16:27Z urn:sha1:29658c96ce9914fdf4ff4e3519fbec696ef32118 them, please let me know if not). Most of these are of the form: static const struct bzzt_type { [...list of members...] } const bzzt_devs[] = { [...list of initializers...] }; The second const is unnecessary, as arrays cannot be modified anyway, and if the elements are const, the whole thing is const automatically (e.g. it is placed in .rodata). I have verified this does not change the binary output of a full kernel build (except for build timestamps embedded in the object files). Reviewed by: yongari, marius MFC after: 1 week 2012-11-01T05:39:21Z Pyun YongHyeon yongari@FreeBSD.org 2012-11-01T05:39:21Z urn:sha1:a8eeb50c81e311b74aba3bcd0cdcc0bf9a3bd511 datagrams. Traditionally upper stack fragmented packets without computing TCP/UDP checksum and these datagrams were passed to driver. But there are chances that other packets slip into the interface queue in SMP world. If this happens firmware running on MIPS 4000 processor in the controller would see mixed packets and it shall send out corrupted packets. While I'm here simplify checksum offloading setup. MFC After: 1 week 2011-12-15T05:07:16Z Alan Cox alc@FreeBSD.org 2011-12-15T05:07:16Z urn:sha1:3b03ca3bbe853d1ef0dd01e34915bf4b962d3e7c 2011-11-14T20:38:14Z Pyun YongHyeon yongari@FreeBSD.org 2011-11-14T20:38:14Z urn:sha1:b7c2632d6af08a5dc053adc201f997667815e0ee - Don't use a single big DMA block for all rings. Create separate DMA area for each ring instead. Currently the following DMA areas are created: Event ring, standard RX ring, jumbo RX ring, RX return ring, hardware MAC statistics and producer/consumer status area. For Tigon II, mini RX ring and TX ring are additionally created. - Added missing bus_dmamap_sync(9) in various TX/RX paths. - TX ring is no longer created for Tigon 1 such that it saves more resources on Tigon 1. - Data sheet is not clear about alignment requirement of each ring so use 32 bytes alignment for normal DMA area but use 64 bytes alignment for jumbo RX ring where the extended RX descriptor size is 64 bytes. - For each TX/RX buffers use separate DMA tag(e.g. the size of a DMA segment, total size of DMA segments etc). - Tigon allows separate DMA area for event producer, RX return producer and TX consumer which is really cool feature. This means TX and RX path could be independently run in parallel. However ti(4) uses a single driver lock so it's meaningless to have separate DMA area for these producer/consumer such that this change creates a single status DMA area. - It seems Tigon has no limits on DMA address space and I also don't see any problem with that but old comments in driver indicates there could be issues on descriptors being located in 64bit region. Introduce a tunable, dev.ti.%d.dac, to disable using 64bit DMA in driver. The default is 0 which means it would use full 64bit DMA. If there are DMA issues, users can disable it by setting the tunable to 0. - Do not increase watchdog timer in ti_txeof(). Previously driver increased the watchdog timer whenever there are queued TX frames. - When stat ticks is set to 0, skip processing ti_stats_update(), avoiding bus_dmamap_sync(9) and updating if_collisions counter. - MTU does not include FCS bytes, replace it with ETHER_VLAN_ENCAP_LEN. With these changes, ti(4) should work on PAE environments. Many thanks to Jay Borkenhagen for remote hardware access. 2011-11-14T19:10:20Z Pyun YongHyeon yongari@FreeBSD.org 2011-11-14T19:10:20Z urn:sha1:e79b243289528c13c991482cb946cf4a4cb77a9e have administrators control them. ti(4) provides a character device to control various other features of driver via ioctls but users had to write their own code to manipulate these parameters. It seems some default values for these parameters are not optimal on today's system but leave it as it was and let administrators change them. The following parameters could be changed: dev.ti.%d.rx_coal_ticks dev.ti.%d.rx_max_coal_bds dev.ti.%d.tx_coal_ticks dev.ti.%d.tx_max_coal_bds dev.ti.%d.tx_buf_ratio dev.ti.%d.stat_ticks The interface has to be brought down and up again before a change takes effect. ti(4) controller supports hardware MAC counters with additional DMA statistics. So it's doable to export these counters via sysctl interface. Unfortunately, these counters are cumulative such that driver have to either send an explicit clear command to controller after extracting them or have to maintain internal counters to get actual changes. Neither look good to me so counters were not exported via sysctl. 2011-11-14T18:40:04Z Pyun YongHyeon yongari@FreeBSD.org 2011-11-14T18:40:04Z urn:sha1:9b81d5e37fea7130db66995a85f170f2d612271b Pre-allocate the memory in device attach time. While I'm here remove unnecessary reassignment of error variable as it was already initialized. Also added a missing driver lock in TIIOCSETTRACE handler. 2011-11-10T23:14:04Z Pyun YongHyeon yongari@FreeBSD.org 2011-11-10T23:14:04Z urn:sha1:ecf3f60fed1c4a221b125b032eb458eb883c1e18 for the device. 2011-11-10T22:15:11Z Pyun YongHyeon yongari@FreeBSD.org 2011-11-10T22:15:11Z urn:sha1:8a9710aa8c0a8b82ef9a7fbdab47628efc06eabf No functional changes.