Stop usbhid from claiming usb device on hotplug

Stop usbhid from claiming usb device on hotplug

[Armin Moradi]

Hi all,

I'm writing a kernel module, but probe() is never called since usbhid
claims the usb device as soon as the device is plugged in.

Tried/potential solutions:

#1: I have tried to write the usb hid id to
/sys/bus/usb/drivers/usbhid/unbind (e.g. echo "1-1.1:1.4" >
/sys/bus/usb/drivers/usbhid/unbind) and that properly unbinds the
device from usbhid, but I want my module to claim the device when it's
plugged in. Adding the above command to udev didn't do much as I
couldn't find a way to tell my module to claim it as it was plugged
in. It seems to me that usbhid claims the device, then udev rule
unbinds it, but since usbhid already claimed it at plugin, my module's
probe() wasn't called regardless.

#2: I also tried unloading usbhid and loading my module and *then*
usbhid. When the device was plugged in, usbhid still took over and my
module's probe() still wasn't called. Even if that worked, it wouldn't
feel like a proper solution.

#3: I could potentially blacklist the device in drivers sources, but
that doesn't seem a good option because I may want to have usbhid
manage the device at some point

At this point, I have no idea what else I could try! Any help or
direction would be appreciated.

Thanks.

Stop usbhid from claiming usb device on hotplug

[Greg KH]

On Fri, May 29, 2015 at 04:58:17PM -0400, Armin Moradi wrote:
> Hi all,
> 
> I'm writing a kernel module, but probe() is never called since usbhid
> claims the usb device as soon as the device is plugged in.

What type of module for what type of device?  And why do you want to
override the hid driver from binding to it?

thanks,

greg k-h

Stop usbhid from claiming usb device on hotplug

[Armin Moradi]

>> I'm writing a kernel module, but probe() is never called since usbhid
>> claims the usb device as soon as the device is plugged in.
>
> What type of module for what type of device?  And why do you want to
> override the hid driver from binding to it?
>
> thanks,
>
> greg k-h

I'm just learning about device drivers, so I'm writing a dummy usb
device driver. I've pasted the code here (I hope the formatting is
correct):

#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/usb.h>

static int mmod_probe(struct usb_interface *intf,
                      const struct usb_device_id *id)
{
        pr_debug("mmod: probe is called");

        /* return -ENODEV if we don't want to claim the device */
        return 0;
}

static void mmod_disc(struct usb_interface *intf)
{
        pr_debug("mmod: disconnected");
}

static const struct usb_device_id mmod_id[] = {
        {.match_flags = USB_DEVICE_ID_MATCH_INT_PROTOCOL,
         .bInterfaceClass = 0x01
        },
        {}
};

/* export the id to userspace */
MODULE_DEVICE_TABLE(usb, mmod_id);

static struct usb_driver mmod_driver = {
        .name = "mmod_driver",
        .id_table = mmod_id,
        .probe = mmod_probe,
        .disconnect = mmod_disc
};

static int __init init_task05(void)
{
        pr_debug("mmod loaded");
        usb_register(&mmod_driver);

        return 0;
}

static void __exit exit_mymod(void)
{
        pr_debug("mmod unloaded");
        usb_deregister(&mmod_driver);
}

module_init(init_mmod);
module_exit(exit_mmod);

MODULE_LICENSE("GPL");


I can load and unload the module and I can see the messages being
printed. I can also see usbcore registering the new driver in dmesg,
but when I plug any usb keyboard (which I have registered in id
table), the probe never gets called. Instead, I see usbhid taking over
and initializing the device in dmesg. And as far as intention goes,
this is just for fun.

I have thought about editing hid-core.c and adding usb quirks there
and recompile the kernel, but that seems a bit drastic. I thought
maybe there's a better way to do it.

Thanks a lot,
-- 
Armin Moradi

Stop usbhid from claiming usb device on hotplug

[Greg KH]

On Sat, May 30, 2015 at 01:43:20AM -0400, Armin Moradi wrote:
> >> I'm writing a kernel module, but probe() is never called since usbhid
> >> claims the usb device as soon as the device is plugged in.
> >
> > What type of module for what type of device?  And why do you want to
> > override the hid driver from binding to it?
> >
> > thanks,
> >
> > greg k-h
> 
> I'm just learning about device drivers, so I'm writing a dummy usb
> device driver. I've pasted the code here (I hope the formatting is
> correct):

This was for a challenge that doesn't want you to ask in public, sorry,
I'm not going to answer it.

best of luck,

greg k-h

Stop usbhid from claiming usb device on hotplug

[Abhishek bist]

I think it is a part of eudyptula challenge and if it is so, just make sure
that is it asking for probing or just for dynamic loading.



On 30 May 2015 at 13:09, Greg KH <greg@kroah.com> wrote:

> On Sat, May 30, 2015 at 01:43:20AM -0400, Armin Moradi wrote:
> > >> I'm writing a kernel module, but probe() is never called since usbhid
> > >> claims the usb device as soon as the device is plugged in.
> > >
> > > What type of module for what type of device?  And why do you want to
> > > override the hid driver from binding to it?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > I'm just learning about device drivers, so I'm writing a dummy usb
> > device driver. I've pasted the code here (I hope the formatting is
> > correct):
>
> This was for a challenge that doesn't want you to ask in public, sorry,
> I'm not going to answer it.
>
> best of luck,
>
> greg k-h
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150530/1786c247/attachment.html 

Stop usbhid from claiming usb device on hotplug

[Armin Moradi]

> On 30 May 2015 at 13:09, Greg KH <greg@kroah.com> wrote:
>>
>> On Sat, May 30, 2015 at 01:43:20AM -0400, Armin Moradi wrote:
>> > >> I'm writing a kernel module, but probe() is never called since usbhid
>> > >> claims the usb device as soon as the device is plugged in.
>> > >
>> > > What type of module for what type of device?  And why do you want to
>> > > override the hid driver from binding to it?
>> > >
>> > > thanks,
>> > >
>> > > greg k-h
>> >
>> > I'm just learning about device drivers, so I'm writing a dummy usb
>> > device driver. I've pasted the code here (I hope the formatting is
>> > correct):
>>
>> This was for a challenge that doesn't want you to ask in public, sorry,
>> I'm not going to answer it.
>>
>> best of luck,
>>
>> greg k-h

Right. I'm already kicked from the challenge (my bad :( ), but I still
wanted to know how this may be possible. Though, it's probably not a
good idea to talk about this as others may be doing the challenge.

Anyway, thanks for your help.

> I think it is a part of eudyptula challenge and if it is so, just make sure
> that is it asking for probing or just for dynamic loading.

The challenge asked for userspace dynamic *loading* on hotplug which I
had done, but while I was reading LDD 3rd ed., I also wanted to get
probing to work which is done after the driver is already loaded.
That's when I found out only one driver can claim a device and wanted
to see if it were possible to change which driver binds which device
at runtime without reloading usbhid or changing the order which
modules are loaded.

Thanks,
-- 
Armin Moradi

Stop usbhid from claiming usb device on hotplug

[Valdis.Kletnieks at vt.edu]

On Sat, 30 May 2015 04:07:08 -0400, Armin Moradi said:

> had done, but while I was reading LDD 3rd ed., I also wanted to get
> probing to work which is done after the driver is already loaded.

If it's a dummy driver, what device is it going to probe?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150530/695c6215/attachment.bin 

Stop usbhid from claiming usb device on hotplug

[Armin Moradi]

On Sat, May 30, 2015 at 9:28 PM,  <Valdis.Kletnieks@vt.edu> wrote:
> On Sat, 30 May 2015 04:07:08 -0400, Armin Moradi said:
>
>> had done, but while I was reading LDD 3rd ed., I also wanted to get
>> probing to work which is done after the driver is already loaded.
>
> If it's a dummy driver, what device is it going to probe?

I have tried specifying a vendorID and productID in the id_table for
one of the keyboards I have lying around. My expectation would be that
the probe would get called when that device is connected, but I see
usbhid initializing the keyboard and probe() not getting called at
all.

Stop usbhid from claiming usb device on hotplug

[Valdis.Kletnieks at vt.edu]

On Sun, 31 May 2015 20:39:06 -0400, Nicholas Krause said:

> If you send your complete code to the list I can try and see if there are other issues but that's the most likely.

Actually, he shouldn't send it to the list.  It smells too much of
eucalyptus....
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150531/b0385e7a/attachment.bin 

Stop usbhid from claiming usb device on hotplug

[Valdis.Kletnieks at vt.edu]

On Sun, 31 May 2015 21:31:20 -0400, Nicholas Krause said:

>  Your right, questions about eucalyptus based tasks should be asked off list
> to avoid people getting easy answers through.

No, the rules are to do it *on your own*, without asking anybody, on or off
list.

> However I think a lot of this could be avoided if we taught people how to do
> kernel programming research better.

Well, why don't you make suggestions from your own experience how we can improve
that?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20150601/7d6c5598/attachment.bin 

Stop usbhid from claiming usb device on hotplug

[Armin Moradi]

> Basically what your doing wrong is not understanding the hierarchy of USB devices on your system's bus.
> What is happening is your trying to register a USB device where the Id marco is not the correct one in the
> hierarchy and therefore is over ruled by the one from usbhid.
> If you send your complete code to the list I can try and see if there are other issues but that's the most likely.
> Nick

Thanks a lot! I have posted the complete code previously on this
thread, but it doesn't have much. I'll see what I can find out about
the usb subsystem hierarchy. Any recommended resources I could use to
learn more about the usb (and other) subsystems (e.g. pci, etc.) other
than LDD?

>>>  Your right, questions about eucalyptus based tasks should be asked
>>off list
>>> to avoid people getting easy answers through.
>>
>>No, the rules are to do it *on your own*, without asking anybody, on or
>>off
>>list.
>>
>>> However I think a lot of this could be avoided if we taught people
>>how to do
>>> kernel programming research better.
>>
>>Well, why don't you make suggestions from your own experience how we
>>can improve
>>that?
> Thats fine for me it was just not listening and pulling in effort, also lack of confidence .  However I am noticing a lot of people having difficulty
> understanding drivers and the driver core.  The issue is that most people don't know
> where to look.  I would recommend putting a list on kernel newbies of resources on a page for websites, books, tools that are useful.  Also it would be good to explain on their how to use crags/cscope for kernel code searching.
> Nick

I think I should clarify the eudyptula situation. I started doing the
challenge, and then I got to task05, which is the first task that
tells you to read LDD. I started reading the chapter that was
instructed (I'm really trying to avoid spoilers), but then also read
other chapters which looked interesting. Before I knew it, I was doing
something not related to my task at all (as far as I understood the
task, again, no spoilers). That's when I asked the question about
usbhid here and promptly got kicked. So, my question has nothing to do
with the eudyptula challenge and I'm not aware of any of the tasks
being related to this question.

Sidenote: unfortunately, I feel like the eudyptula challenge has
patented basic kernel questions as I can't even ask anything because
someone, somewhere, is doing something vaguely similar. I appreciate
the challenge, but maybe the Matasano's new challenge format
<http://cryptopals.com> would do more to help interested people learn
rather than create an exclusive tunnel.

> The issue is that most people don't know where to look.

That is the issue I'm having as the header files, while pretty good in
describing what's going on, don't explain the higher level stuff
that's needed before diving into header docs. Although I may have
jumped in unprepared.

--
Armin Moradi

Stop usbhid from claiming usb device on hotplug

[Armin Moradi]

>>> Basically what your doing wrong is not understanding the hierarchy of USB devices on your system's bus.
>>> What is happening is your trying to register a USB device where the Id marco is not the correct one in the
>>> hierarchy and therefore is over ruled by the one from usbhid.
>>> If you send your complete code to the list I can try and see if there are other issues but that's the most likely.
>>> Nick
>>
>> Thanks a lot! I have posted the complete code previously on this
>> thread, but it doesn't have much. I'll see what I can find out about
>> the usb subsystem hierarchy. Any recommended resources I could use to
>> learn more about the usb (and other) subsystems (e.g. pci, etc.) other
>> than LDD?
>>
> I used Essential Linux Device Drivers as my resource. Also look in the driver source code for usb keyboard driver
> and read through it. If you can't find it I will point it out to you but that should get you started. One piece
> of advice is when writing drivers, try to find one in the drivers folder with similar hardware/requirements
> to base your driver off of that your writing. Also don't ask about challenges like this on the list as there
> meant to be self taught.
> Hope that Helps,
> Nick

Thanks, I'll see what I can find. Again, my question has nothing to do
with the challenge.

--
Armin Moradi