Page MenuHomeFreeBSD

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

Authored by ian on May 14 2019, 8:20 PM.
Tags
None
Referenced Files
Unknown Object (File)
Jan 30 2024, 9:41 AM
Unknown Object (File)
Jan 23 2024, 12:43 AM
Unknown Object (File)
Dec 20 2023, 12:35 AM
Unknown Object (File)
Dec 2 2023, 9:41 AM
Unknown Object (File)
Nov 13 2023, 3:10 AM
Unknown Object (File)
Oct 10 2023, 12:12 AM
Unknown Object (File)
Aug 24 2023, 9:22 PM
Unknown Object (File)
Aug 18 2023, 5:33 PM
Subscribers

Details

Summary

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 (https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/usb/usb-device.txt).

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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

sys/dev/usb/usb_fdt_support.c
63 ↗(On Diff #57396)

You are sure about %x and not %04x ?

119 ↗(On Diff #57396)

Can you refactor "uhub_is_too_deep()" into another function which returns the maximum depth based on the USB root HUB's speed? And then use the USB stacks maximum in this function?

Or use MAX(USB_HUB_MAX_DEPTH,USB_SS_HUB_DEPTH_MAX) [maybe you need to add 1 for the rootHUB]. Please check the code.

sys/dev/usb/usb_fdt_support.c
63 ↗(On Diff #57396)

Absolutely. From the bindings doc...

Required properties for device nodes:
- compatible: "usbVID,PID", where VID is the vendor id and PID the product id.
  The textual representation of VID and PID shall be in lower case hexadecimal with leading zeroes suppressed.
119 ↗(On Diff #57396)

I had read somewhere that the max nesting depth for a usb bus was 7 (probably on wikipedia). USB_HUB_MAX_DEPTH and USB_SS_HUB_DEPTH_MAX both seem to be 5. If you add 1 each for the root hub and the actual device, that'd be 7 (but this code doesn't put the root hub into the stack it builds). I think in the real world this code will never hit anything nested deeper than 3, but I'll just use MAX(USB_HUB_MAX_DEPTH,USB_SS_HUB_DEPTH_MAX) + 1 for the device itself.

Update to allocate udev_stack using (MAX(USB_HUB_MAX_DEPTH, USB_SS_HUB_DEPTH_MAX) + 1) instead of a hardcoded 7.

This revision is now accepted and ready to land.May 15 2019, 7:32 AM
This revision was automatically updated to reflect the committed changes.