On Fri, 27 Jul 2012, Damjan wrote: > > No, that's not right at all, for a couple of reasons. > > > > First, &ep->desc is the address of a member of a structure. Even if ep > > itself were null, &ep->desc would not be NULL unless desc happened to > > be the first member of the ep structure (it is now, but there's no > > guarantee that it always will be). Probably you really meant to test > > ep instead of &ep->desc. > > Maybe I read the kernel OOPS wrong. Was &ep->desc NULL or not?
It's hard to tell from the information in the oops. You'd have to get an assembly listing of usb_submit_urb() and figure out what source code statement corresponds to offset 0x75 in the object code. Why did you originally think the problem was in the usb_endpoint_type function call? > Also there's a check for a NULL ep 9 lines above this code, so I guess > ep was not NULL. Right. But apparently _something_ was NULL. > > Second, ep will never be NULL if the system is working correctly. If > > it is NULL then the caller is buggy. We don't want to paper over bugs > > in drivers; we want to find them and fix them. > > Maybe BUG_ON or something? An oops is about as good as a BUG_ON. In fact it's better, because it won't crash the whole machine. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
