FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F10.2 2012-12-04T09:32:43Z 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 2011-11-22T21:28:20Z Marius Strobl marius@FreeBSD.org 2011-11-22T21:28:20Z urn:sha1:4b7ec27007570e0ce4fe9dbb447e7afc131b487a one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID. 2011-08-19T19:13:31Z Marius Strobl marius@FreeBSD.org 2011-08-19T19:13:31Z urn:sha1:5ca7dfffdf925aec3238b53ca7034f7be4d37388 latter from working as expected was fixed in r225014. MFC after: 3 days Approved by: re (kib) 2011-07-17T21:54:51Z Pyun YongHyeon yongari@FreeBSD.org 2011-07-17T21:54:51Z urn:sha1:23b179f5d3b14f6a6164e0a2a988bbe558a1eb2e unknown reason Apple UniNorth2 gem(4) device required manual interface down/up operation after r222135. Even though this is not correct thing and I don't like to revert it but it would be better than breaking gem(4) on PPC. This should be revisited. PR: kern/157405 2011-07-12T13:06:44Z Marius Strobl marius@FreeBSD.org 2011-07-12T13:06:44Z urn:sha1:5ed0b954175cd816fe4cb10024e472a38701d343 sets GEM_MAC_RX_CONFIG based on sc_mac_rxcfg which in turn is initialized to zero, before reading the supposedly default configuration we were effectively not basing sc_mac_rxcfg and thus GEM_MAC_RX_CONFIG on the default configuration. Solve this by calling gem_setladrf() after reading in the default configuration of GEM_MAC_RX_CONFIG. This also avoids the need to distinguish whether gem_setladrf() should enable the RX MAC again and should be slightly more correct as we're now doing all of the RX MAC configuration in the intended step. 2011-07-12T08:20:15Z Marius Strobl marius@FreeBSD.org 2011-07-12T08:20:15Z urn:sha1:9f9cc2edd8f36f11c8d2fe5657e890cbbc44a7df should be set for Sun ERI. Tested by: yongari 2011-06-28T16:44:02Z Marius Strobl marius@FreeBSD.org 2011-06-28T16:44:02Z urn:sha1:2b2f3c09a63925b12b5897dbb74c7292c38358cb 2011-06-28T16:16:43Z Marius Strobl marius@FreeBSD.org 2011-06-28T16:16:43Z urn:sha1:c0e3e9d4d2ee745d0bdde7d4e82b0bb4ee1ee32b get it out of a stuck condition that can be caused by GEM_MAC_RX_OVERFLOW. - In gem_reset_rxdma() call gem_setladrf() in order to reprogram the RX filter and restore the previous content of GEM_MAC_RX_CONFIG. While at it consistently use the newly introduced sc_mac_rxcfg throughout the driver instead of reading the its old content. - Increment if_iqdrops instead of if_ierrors in case of RX buffer allocation failure. - According to the GEM datasheet the RX MAC should also be disabled in gem_setladrf() before changing its configuration. - Add error messages to gem_disable_{r,t}x() and take advantage of these throughout the driver instead of duplicating their functionality all over the place. In joint forces with: yongari 2011-05-20T17:01:22Z Pyun YongHyeon yongari@FreeBSD.org 2011-05-20T17:01:22Z urn:sha1:83242185a3ae33394c241fcaa11301f2748c29da IFF_DRV_RUNNING flag. Previously running dhclient or adding alias addresses reinitialized controller and it resulted in unnecessary link flips. Reviewed by: marius