To clarify my response somewhat. It does seem to me that you're using
configfs to create your HID device. I get that, so you're not modifying the
kernel module, or anything like that. What I'm saying is that perhaps
things have changed in how configfs is used, in order to setup a composite
HID device. Or the kernel module code has reverted to an earlier state that
was previously non functional. When moving to 4.9.x. This( the later )
seems to happen a lot in these "cutting edge" kernels. Which is why I
personally sty away from them for a few weeks at least.


I'm also not sure who would need to be contacted for this type of
situation. But it's likely the maintainer for this part of the kernel.

On Tue, Dec 20, 2016 at 1:27 PM, William Hermans <yyrk...@gmail.com> wrote:

>
>
> On Tue, Dec 20, 2016 at 10:02 AM, roboknight <robokni...@gmail.com> 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.
>
> 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.
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORo8r8PzwZBAPtxsyMabE3fAhYzGttGXvM01pdAw2vBLWA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to