Hi, Patrick Doyle <wpdster@xxxxxxxxx> writes: > On Mon, Aug 15, 2016 at 5:02 PM, Greg KH <greg@xxxxxxxxx> wrote: >> ls -l /sys/class/net/usb0/device/driver >> >> sysfs is fun :) > Yes it is... I also managed to find > /sys/devices/pci0000:00/0000:00:11.0/dwc3-device.1/gadget/net/usb0 > with which machine is this? Is this Edison? > $ find /sys -name usb0 -prune > > Apparently, usb0 gets created because my system loads the g_multi which system is it? > gadget. But when I plug a hub into the USB port, (to which a cdc_eem which usb port? On the system you mention above? Is it a standard-A port or a micro-ab receptacle? > device is attached), the driver configures itself as a host, > enumerates my device, and sets up usb1. Poking around the kernel right, this is all fine. > configuration, I see that "DWC3 Mode selection" is set to "Gadget only > mode". I am guessing that "Gadget only mode" means something I'll just assume this is an Intel platform. They work differently. DWC3 is, indeed, gadget only. There's other logic in the SoC which muxes the port between a gadget-only DWC3 and host-only XHCI. DWC3 *can* be configured (the RTL itself) as a dual-role IP, but Intel's HW engineers decided to use DWC3 as peripheral-only and have proprietary logic to switch roles. > different than I would have expected, which is a good thing, because > I'm not sure I ever would have tracked that down based on the path I > was following previously. what were you tracking previously? usb0 is, indeed, g_multi. But keep in mind that usb0 is unusable until you connect the cable to a host PC. Much like your cdc_eem device sitting in the hub won't do anything until you plug it to a host PC, even if you provide it with external 5V supply ;-) -- balbi
Attachment:
signature.asc
Description: PGP signature
