On Tuesday, December 20, 2016 at 3:27:44 PM UTC-5, William Hermans wrote: > > > > On Tue, Dec 20, 2016 at 10:02 AM, roboknight <[email protected] > <javascript:>> wrote: > > At the underlined point, I believe ep->desc is NULL because using the > kernel and an arm objdump variant, >> >> I located the assembly that is causing the NULL dereference. Inside of >> usb_endpoing_dir_out, it tries to >> dereference ep->desc, but ep->desc must be NULL otherwise things would >> likely go swimmingly. The problem >> is, I don't know what would cause ep->desc == NULL? Whatever causes this >> (and it might be related to >> a function called "usb_gadget_ep_match_desc") I'd like to know because >> knowing might tell me how to fix >> whatever it is I'm doing wrong or maybe patch the code so that things >> might work. >> >> I'm hoping someone knowledgeable about am335x USB can help here, or maybe >> let me know what I'm missing >> in my HID configuration. The above configuration steps may not work, >> however, some python code I had previously >> also fails to function. It might even be possible that I just need to >> use the regular HID driver and not one based on >> libcomposite. >> >> Thanks for reading this. Hopefully there are some answers. >> > > So, I'm not a USB composite framework expert. I only started reading about > it last night for another reason. A lot of what you're stating in your last > couple paragraphs here do not make sense to me. What I'm reading from your > post is that the end point descriptor must be NULL. but you're not sure why > it's NULL . . .yadda yadda yadda . . .That should not be true. >
The yadda yadda yadda was kind of the point. I actually have looked into it further and the only way that reference would actually be null is if the autoepconfig function couldn't choose any available endpoint because none of them matched the correct criteria. I'm not sure where I'm supposed to SET UP the appropriate criteria, hence the question, and the details. > > My first impression after looking through that code is user error. Simply > because a function that's being used requires a valid end point descriptor > reference as an argument, and that argument is NULL. Which tells me that > whole "object" was never instantiated in the first place. > those objects aren't "instantiated". They are actually endpoints that are "built-in" (you can see one for full-speed, high-speed, and now super-speed). One of the endpoints is supposed to get selected based on an appropriate description. Mine probably doesn't match or I haven't set one, hence it doesn't work. But I don't see anywhere where I can actually SPECIFY the necessary things in configfs... Maybe you just can't build a HID device with configfs right now? Or maybe something changed. Either way, I'm researching the answer to that question so I can figure out what I really need to do. Maybe there is another way I can configure a HID driver, not using configfs. The things I was able to do in the 3.13.xx kernel don't seem to work with this kernel either, or I don't have them set up correctly, hence I figured the "new" or current method was to use configfs. But maybe this isn't the case. I have tried to get the "latest" from the TI repo, and the results are the same. So I'm guessing that my kernel configuration was probably okay, but somehow I'm not doing something right with configfs, or configfs doesn't work for HID devices yet (I don't know if I believe that, but its possible). At any rate, I've not managed to get it working yet. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1f8e3b22-f8b9-4b9e-88a4-5fdc077e6cc6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
