On Wed, May 13, 2020 at 8:14 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > On Wed, May 13, 2020 at 07:07:20PM +0200, Andrey Konovalov wrote: > > Hi Alan, > > > > I've been looking at this a little more. Do I understand correctly > > that even though Dummy UDC names endpoints as "ep1in", etc. it > > actually allows to assign endpoints addresses different from what is > > specified in the endpoint names (it uses find_endpoint() to find the > > right endpoint based on ep->desc)? E.g. you can technically assign > > endpoint with address 2 (| USB_DIR_IN) to "ep1in". > > Yes, that's right. In fact, you can do this with any UDC. (But with > other UDCs it won't work, whereas with dummy-hcd it will.) > > > If this is correct, this kind of limits Dummy UDC usage with Raw > > Gadget the way it is currently implemented, as Raw Gadget assumes that > > the endpoint address must be fixed when the endpoint is named as > > ep1in. > > Okay. That makes sense, since it is true for most UDCs. > > > Would it be acceptable to add another mode to Dummy UDC that names the > > endpoints as "ep-a"? Perhaps enabled with a module parameter. I'm not > > sure if this kind of naming would be technically correct, as "ep-a" > > name assumes that we can assign arbitrary transfer type to the > > endpoint as well, which isn't possible with Dummy UDC, as it doesn't > > support ISO transfers. > > > > Or do you think there can be another way to expose the fact that Dummy > > UDC allows arbitrary addresses? I could hardcode this into Raw Gadget, > > but it doesn't feel like the right approach. > > Why do you want to do this? Does anything go wrong if you just continue > to assume the endpoint numbers are fixed? Yes. Some USB drivers require endpoints with certain logical functions to have certain addresses (e.g. for ath9k: [1]). This limits the ability to use Raw Gadget + Dummy UDC for fuzzing, as sometimes we can't emulate such devices unless Dummy UDC endpoint with a particular address has required capabilities to implement those logical functions (e.g. for ath9k: we can't emulate USB_REG_IN_PIPE endpoint, as Dummy UDC only has an OUT endpoint with address 3). It's acceptable to be unable to emulate such devices with real UDCs with fixed address endpoints, but it would be highly desirable to be able to do that with Dummy UDC, as it technically supports configurable endpoint addresses. [1] https://elixir.bootlin.com/linux/v5.6.12/source/drivers/net/wireless/ath/ath9k/hif_usb.h#L68 > I suppose, if you thought this was really necessary, we could change > find_endpoint() so that it looks for a match against the endpoint's name > instead of against the address stored in the descriptor. That would make the behaviour of Dummy UDC match what is expected from it based on the endpoint names, but won't help with the problem described above. > Or we could > change the last thirteen "generic" endpoints in ep_info[] to be > configurable: "ep-a", ..., "ep-m", or "ep-aout", ..., "ep-min". (The > fact that the endpoints don't support isochronous is exposed through the > usb_ep_caps structures.) I think this should work. If we put this under a module parameter, then we can make all endpoints have configurable names.
