FreeBSD source tree https://cgit-dev.freebsd.org/src-test/atom?h=main 2020-09-12T00:33:11Z 2020-09-12T00:33:11Z John-Mark Gurney jmg@FreeBSD.org 2020-09-12T00:33:11Z urn:sha1:7d5522e16a2970ade4e79e647842841cd32a19e1 This update adds support for: HW VLAN tagging HW checksum offload for IPv4 and IPv6 tx and rx aggreegation (for full gige speeds) multiple transactions In my testing, I am able to get 900-950Mbps depending upon TCP or UDP, which is a significant improvement over the previous 91Mbps (~8kint/sec*1500bytes/packet*1packet/int). Reviewed by: hselasky MFC after: 2 months Differential Revision: https://reviews.freebsd.org/D25809 2020-08-20T17:35:47Z Warner Losh imp@FreeBSD.org 2020-08-20T17:35:47Z urn:sha1:209d3fb41fe5a22a23eda209a3e65fed946c8b74 It was a driver for a USB FM tuner that was available in the market in 2002. I wrote the driver in 2003. I've not used it since 2005 or so, so it's time to retire this driver. No userland code ever interfaced to the special device it created. There's no user base: the last bug I received on this driver was in 2004. Relnotes: Yes 2020-08-16T12:59:43Z Eugene Grosbein eugen@FreeBSD.org 2020-08-16T12:59:43Z urn:sha1:1aca6504534c2339789cc8cce84378ab4947524d 2020-08-06T13:41:42Z Andriy Gapon avg@FreeBSD.org 2020-08-06T13:41:42Z urn:sha1:c178a7e73ccb042a30b8a3634e5d92e2ae83c41e Documentation: - CP2112 Datasheet https://www.silabs.com/documents/public/data-sheets/cp2112-datasheet.pdf - AN495: CP2112 Interface Specification https://www.silabs.com/documents/public/application-notes/an495-cp2112-interface-specification.pdf - CP2112 Errata https://www.silabs.com/documents/public/errata/cp2112-errata.pdf The logic is implemented as three sub-drivers. The parent driver claims the USB device and creates two child devices. One acts as a GPIO controller and the other is an I2C controller. Tested with CP2112 revision F02. Both features seem to work. HTU21 sensor was used as an I2C slave. Reviewed by: adrian, hselasky MFC after: 2 weeks Relnotes: maybe Differential Revision: https://reviews.freebsd.org/D25359 2020-01-23T10:40:34Z Hans Petter Selasky hselasky@FreeBSD.org 2020-01-23T10:40:34Z urn:sha1:8427dd0899fb0a5f652eccf69efcc673a327c7bf MFC after: 1 week Sponsored by: Mellanox Technologies 2019-08-07T18:14:45Z Edward Tomasz Napierala trasz@FreeBSD.org 2019-08-07T18:14:45Z urn:sha1:63722e52121eb7b86537db4a3f53af8ad323b43c with Communication Device Class Ethernet Emulation Model (CDC EEM). The driver supports both the device, and host side operation; there is a new USB template (#11) for the former. This enables communication with virtual USB NIC provided by iLO 5, as found in new HPE Proliant servers. Reviewed by: hselasky MFC after: 2 weeks Relnotes: yes Sponsored by: Hewlett Packard Enterprise 2019-07-08T20:53:25Z Hans Petter Selasky hselasky@FreeBSD.org 2019-07-08T20:53:25Z urn:sha1:7fe671dc9b849e295cf04db354fc12c42a2e1c78 The code needs more testing before being enabled by default. Sponsored by: Mellanox Technologies 2019-06-17T23:03:30Z Takanori Watanabe takawata@FreeBSD.org 2019-06-17T23:03:30Z urn:sha1:e68fcc8875dfc29758af159d66751b238559b1e4 This adds ACPI device path on devinfo(8) output and show value of _UPC(usb port capabilities), _PLD (physical location of device) when hw.usb.debug >= 1 . Reviewed by: hselasky Differential Revision: https://reviews.freebsd.org/D20630 2019-06-12T00:03:00Z Bryan Drewery bdrewery@FreeBSD.org 2019-06-12T00:03:00Z urn:sha1:f68801df100565820b35631a8709229141537baa This fixes META_MODE rebuilding since it assumes that it this is a non-consistent build command. These are always unencoded consistently though and do not need to use the .OODATE/$? mechanism. MFC after: 2 weeks Reported by: npn Sponsored by: DellEMC 2019-05-19T16:56:59Z Ian Lepore ian@FreeBSD.org 2019-05-19T16:56:59Z urn:sha1:bac5ec96f46e2446c2a77f7431216f1aea4b76d2 FDT data is sometimes used to configure usb devices which are hardwired into an embedded system. Because the devices are instantiated by the usb enumeration process rather than by ofwbus iterating through the fdt data, it is somewhat difficult for a usb driver to locate fdt data that belongs to it. In the past, various ad-hoc methods have been used, which can lead to errors such applying configuration that should apply only to a hardwired device onto a similar device attached by the user at runtime. For example, if the user adds an ethernet device that uses the same driver as the builtin ethernet, both devices might end up with the same MAC address. These changes add a new usb_fdt_get_node() helper function that a driver can use to locate FDT data that belongs to a single unique instance of the device. This function locates the proper FDT data using the mechanism detailed in the standard "usb-device.txt" binding document [1]. There is also a new usb_fdt_get_mac_addr() function, used to retrieve the mac address for a given device instance from the fdt data. It uses usb_fdt_get_node() to locate the right node in the FDT data, and attempts to obtain the mac-address or local-mac-address property (in that order, the same as linux does it). The existing if_smsc driver is modified to use the new functions, both as an example and for testing the new functions. Rpi and rpi2 boards use this driver and provide the mac address via the fdt data. [1] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.txt Differential Revision: https://reviews.freebsd.org/D20262