Please use Reply-To-All so that your messages get sent to the mailing list as well as to me. On Thu, 26 May 2011, Jon Pry wrote: > There certainly is something that could be done to my function driver > to make this work. But there are lots of other null pointer checks in > this function that are presumably not needed if everything else in the > world works a certain way. Afaict everything else is checked for null > except descriptors. Those other NULL checks return an error is something is wrong. You could change the descriptor checking so that it returns an error if a pointer is mistakenly set to NULL instead of ignoring the problem. > My function driver is setting usb speed to UNKNOWN > initially which seems to make sense since no effort has been made to > detect bus speed yet. No, that's wrong. The speed field should be set to the maximum speed supported by your driver. The UDC driver takes care of detecting the actual connection speed and setting gadget->speed accordingly. > So which descriptor should be populated in that > case? Apparently setting the wrong one to null will just blow up the > gadget core. Is this really the desired behavior? The function driver must set up appropriate descriptors for whatever speeds it claims to support. As far as desired behavior is concerned... The desired behavior is that all drivers work correctly. Even if composite.c were changed so that it didn't crash when a descriptor was missing, your function driver still wouldn't work correctly -- not if it doesn't have the right descriptors. Therefore changing composite.c is not an adequate fix. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
