MFC r350685:

Add cdceem(4) driver, for virtual ethernet devices compliant
with Communication Device Class Ethernet Emulation Model (CDC EEM).
The driver supports both the device, and host side opera

MFC r350685:

Add cdceem(4) driver, for virtual ethernet devices compliant
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
Relnotes: yes
Sponsored by: Hewlett Packard Enterprise

show more ...

MFC r348979:

Stop using .OODATE for extracting firmware.

MFC r347974, r348001, r348006, r348013, r348016, r348018, r348020

FDT support for if_muge and if_smsc drivers...

r347974:
Add common support functions for USB devices configured via FDT data.

FDT

MFC r347974, r348001, r348006, r348013, r348016, r348018, r348020

FDT support for if_muge and if_smsc drivers...

r347974:
Add common support functions for USB devices configured via FDT data.

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

r348001 by emaste:
muge: configure LEDs per dtb (for Raspberry Pi 3B+)

Also apply some style(9) and remove the message about EEPROM configuration
(if there's an EEPROM the hardware handles LED configuration itself).

PR: 237325
Reviewed by: ian
Submitted by: Ralf <[email protected]>

r348006 by emaste:
muge: update FDT LED configuration

Also use LED mode settings from the FDT to set the PHY.
From v3 of the patch submitted in the PR.

I moved the sc_led_modes and sc_led_modes_mask default setting outside
of the #ifdef FDT case.

PR: 237325
Submitted by: Ralf <[email protected]>
Reviewed by: ian
MFC with: r348001
Event: Waterloo Hackathon 2019
Differential Revision: https://reviews.freebsd.org/D20325

r348013:
Use the new usb fdt support functions to locate the proper fdt node for
the device instance, and to get the MAC address for the device instance.
The ad-hoc code this replaces could find the wrong instance if multiple
devices were present.

r348016:
Don't detour through sc->sc_ue when we have a direct pointer to ue in hand
already. Also, shorten a variable name for nicer line-wrapping.

No functional changes.

r348018:
A MAC adddress from FDT data should override anything stored in eeprom or
OTP registers (because the user is in control of the fdt data). Remove the
early returns from the code that tries to find a good mac address, so that
the execution always flows through the routine to get an address from FDT
data last, when on FDT-enabled systems.

r348020:
Reverse the bit logic of sc_led_modes_mask. Instead of initializing it to
all-ones then carving out blocks of zeroes where specified values go, init
it to all-zeroes, put in ones where values need to be masked, then use it
as value &= ~sc_led_modes_mask. In addition to being more idiomatic, this
means everything related to FDT data is initialized to zero along with the
rest of the softc, and that allows removing some #ifdef FDT sections and
wrapping the whole muge_set_leds() function in a single ifdef block.

This also deletes the early-out from muge_set_leds() when an eeprom exists.
Even if there is an eeprom with led config in it, the fdt data (if present)
should override that, because the user is in control of the fdt data.

show more ...