> > <snipped> > > > > + ret = usbnet_read_cmd(dev, USB_CDC_GET_NET_ADDRESS, > > > > + USB_DIR_IN | USB_TYPE_CLASS > > > > + | USB_RECIP_INTERFACE, 0, > > > > + USB_REQ_SET_ADDRESS, buf, ETH_ALEN); > > > > > > Where did that USB_REQ_SET_ADDRESS come from? Did you just look up > > > an arbutrary macro that happened to match your device config? How > > > do you expect this to work with a generic NCM device? Or even your > > > own device, when the next firmware revision moves the function to a > different interface? > > <snipped> > > > > https://wiki.osdev.org/Universal_Serial_Bus#SET_ADDRESS > > > > https://www.usb.org/document-library/network-control-model-devices-spe > > cification-v10-and-errata-and-adopters-agreement > > Download and view the NCM specification v1.0 (Errata 1), dated November > 24, 2010. See table 6.2 on page 30. Also see sections 6.2.2 and 6.2.3 on page > 32. > > > > USB_REQ_SET_ADDRESS came from include/uapi/linux/usb/ch9.h. This > matches the SET_ADDRESS definition from the osdev wiki page, so I used it > because the name and numeric values both matched. It further matches what > the Windows driver issues. > > The names and values may match, but the meanings do not. > USB_REQ_SET_ADDRESS refers to a USB bus address, not a MAC address. > > Alan Stern What better suggestion do folks have, instead of using USB_REQ_SET_ADDRESS? Thank you, Charles
