K 10 svn:author V 3 ian K 8 svn:date V 27 2019-05-30T14:40:23.410384Z K 7 svn:log V 4067 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 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 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. END