Beginner query regarding usbhid

Beginner query regarding usbhid

[Rohit Sarkar]

Re: Beginner query regarding usbhid

[Oliver Neukum]

Am Mittwoch, den 25.03.2020, 19:12 +0530 schrieb Rohit Sarkar:
> 

Hi,

I am afraid something went wrong with your mail.

	Regards
		Oliver

Re: Beginner query regarding usbhid

[Rohit Sarkar]

On Wed, Mar 25, 2020 at 03:45:43PM +0100, Oliver Neukum wrote:
> Am Mittwoch, den 25.03.2020, 19:12 +0530 schrieb Rohit Sarkar:
> > 
> 
> Hi,
> 
> I am afraid something went wrong with your mail.
> 
> 	Regards
> 		Oliver
> 
Ah, Thanks for telling me. 

This was the original mail:

Hi,

I was trying to mess around with the driver that drives my mouse. I
found out that it is usbhid. I then added a printk statement to the init
and exit function of usbhid.
I then compiled and installed the usbhid drivers. Post that I ran
`sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
any logs in dmesg.

I am certain I am missing something fundamental. Could someone help me
with this.

Thanks,
Rohit

Re: Beginner query regarding usbhid

[Hubert CHAUMETTE]

Le 25/03/2020 15:47, Rohit Sarkar a écrit :
> I was trying to mess around with the driver that drives my mouse. I
> found out that it is usbhid. I then added a printk statement to the 
> init
> and exit function of usbhid.
> I then compiled and installed the usbhid drivers. Post that I ran
> `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt 
> observe
> any logs in dmesg.
> 
> I am certain I am missing something fundamental. Could someone help me
> with this.

Hi,

Did you check whether your module was effectively loaded with lsmod?
What log level did you use in your printk statement? Depending on your
system default loglevel your logs might not be printed. A quick fix
would be to use one of the lowest levels (pr_emerg, but pr_err might
suffice).
Regards,

Hubert Chaumette

Re: Beginner query regarding usbhid

[Rohit Sarkar]

On Wed, Mar 25, 2020 at 04:41:38PM +0100, Hubert CHAUMETTE wrote:
> Le 25/03/2020 15:47, Rohit Sarkar a écrit :
> > I was trying to mess around with the driver that drives my mouse. I
> > found out that it is usbhid. I then added a printk statement to the init
> > and exit function of usbhid.
> > I then compiled and installed the usbhid drivers. Post that I ran
> > `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
> > any logs in dmesg.
> > 
> > I am certain I am missing something fundamental. Could someone help me
> > with this.
> 
> Hi,
> 
> Did you check whether your module was effectively loaded with lsmod?
> What log level did you use in your printk statement? Depending on your
> system default loglevel your logs might not be printed. A quick fix
> would be to use one of the lowest levels (pr_emerg, but pr_err might
> suffice).
> Regards,

Hey,
I did check that module was loaded. And one of the signs was that my
mouse started working after insmod :).

I used printk(KERN_ALERT "some message") for logging. I also tried with
KERN_ERR but no luck. 

The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
both were executed from the usbhid directory.
from the usbhid directory.
> Hubert Chaumette

Thanks,
Rohit

Re: Beginner query regarding usbhid

[Randy Dunlap]

On 3/25/20 10:13 AM, Rohit Sarkar wrote:
> On Wed, Mar 25, 2020 at 04:41:38PM +0100, Hubert CHAUMETTE wrote:
>> Le 25/03/2020 15:47, Rohit Sarkar a écrit :
>>> I was trying to mess around with the driver that drives my mouse. I
>>> found out that it is usbhid. I then added a printk statement to the init
>>> and exit function of usbhid.
>>> I then compiled and installed the usbhid drivers. Post that I ran
>>> `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
>>> any logs in dmesg.
>>>
>>> I am certain I am missing something fundamental. Could someone help me
>>> with this.
>>
>> Hi,
>>
>> Did you check whether your module was effectively loaded with lsmod?
>> What log level did you use in your printk statement? Depending on your
>> system default loglevel your logs might not be printed. A quick fix
>> would be to use one of the lowest levels (pr_emerg, but pr_err might
>> suffice).
>> Regards,
> 
> Hey,
> I did check that module was loaded. And one of the signs was that my
> mouse started working after insmod :).

Hi,
I'm not convinced that your modified usbhid module was loaded.

Could an older (original) usbhid module be reloaded so that the mouse
started working again?  That would also explain the lack of (new) messages.

What kernel version are you using?  Is it a distro kernel?
Are you trying to replace the usbhid module in a distro kernel or are
you building the entire kernel?

> I used printk(KERN_ALERT "some message") for logging. I also tried with
> KERN_ERR but no luck. 
> 
> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
> both were executed from the usbhid directory.

why those commands?  seems unusual.

-- 
~Randy

Re: Beginner query regarding usbhid

[Rohit Sarkar]

On Wed, Mar 25, 2020 at 02:40:27PM -0700, Randy Dunlap wrote:
> On 3/25/20 10:13 AM, Rohit Sarkar wrote:
> > On Wed, Mar 25, 2020 at 04:41:38PM +0100, Hubert CHAUMETTE wrote:
> >> Le 25/03/2020 15:47, Rohit Sarkar a écrit :
> >>> I was trying to mess around with the driver that drives my mouse. I
> >>> found out that it is usbhid. I then added a printk statement to the init
> >>> and exit function of usbhid.
> >>> I then compiled and installed the usbhid drivers. Post that I ran
> >>> `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
> >>> any logs in dmesg.
> >>>
> >>> I am certain I am missing something fundamental. Could someone help me
> >>> with this.
> >>
> >> Hi,
> >>
> >> Did you check whether your module was effectively loaded with lsmod?
> >> What log level did you use in your printk statement? Depending on your
> >> system default loglevel your logs might not be printed. A quick fix
> >> would be to use one of the lowest levels (pr_emerg, but pr_err might
> >> suffice).
> >> Regards,
> > 
> > Hey,
> > I did check that module was loaded. And one of the signs was that my
> > mouse started working after insmod :).
Hi,
> Hi,
> I'm not convinced that your modified usbhid module was loaded.
Hmm, here's my dmesg logs if that helps:
"
[  382.132319] usbcore: deregistering interface driver usbhid
[  391.077410] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input26
[  391.136724] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input27
[  391.137285] hid-generic 0003:3938:1031.0002: input,hiddev0,hidraw0: USB HID v1.10 Mouse [MOSART Semi. 2.4G Wireless Mouse] on usb-0000:00:14.0-2/input0
[  391.137480] usbcore: registered new interface driver usbhid
[  391.137483] usbhid: USB HID core driver
"
> Could an older (original) usbhid module be reloaded so that the mouse
> started working again?  That would also explain the lack of (new) messages.
I think so too. But how do I verify if this is the case?

> What kernel version are you using?  Is it a distro kernel?
I am currently running a bleeding edge kernel that I built. ie 5.6-rc7. 
> Are you trying to replace the usbhid module in a distro kernel or are
> you building the entire kernel?
I am building the entire kernel
> > I used printk(KERN_ALERT "some message") for logging. I also tried with
> > KERN_ERR but no luck. 
> > 
> > The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
> > and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
> > both were executed from the usbhid directory.
> 
> why those commands?  seems unusual.
My Linux kernel source is in the directory mentioned in the commands. So
it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
source root.
> -- 
> ~Randy
> 

Thanks,
Rohit

Re: Beginner query regarding usbhid

[Randy Dunlap]

On 3/25/20 10:31 PM, Rohit Sarkar wrote:
> On Wed, Mar 25, 2020 at 02:40:27PM -0700, Randy Dunlap wrote:
>> On 3/25/20 10:13 AM, Rohit Sarkar wrote:
>>> On Wed, Mar 25, 2020 at 04:41:38PM +0100, Hubert CHAUMETTE wrote:
>>>> Le 25/03/2020 15:47, Rohit Sarkar a écrit :
>>>>> I was trying to mess around with the driver that drives my mouse. I
>>>>> found out that it is usbhid. I then added a printk statement to the init
>>>>> and exit function of usbhid.
>>>>> I then compiled and installed the usbhid drivers. Post that I ran
>>>>> `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
>>>>> any logs in dmesg.
>>>>>
>>>>> I am certain I am missing something fundamental. Could someone help me
>>>>> with this.
>>>>
>>>> Hi,
>>>>
>>>> Did you check whether your module was effectively loaded with lsmod?
>>>> What log level did you use in your printk statement? Depending on your
>>>> system default loglevel your logs might not be printed. A quick fix
>>>> would be to use one of the lowest levels (pr_emerg, but pr_err might
>>>> suffice).
>>>> Regards,
>>>
>>> Hey,
>>> I did check that module was loaded. And one of the signs was that my
>>> mouse started working after insmod :).
> Hi,
>> Hi,
>> I'm not convinced that your modified usbhid module was loaded.
> Hmm, here's my dmesg logs if that helps:
> "
> [  382.132319] usbcore: deregistering interface driver usbhid
> [  391.077410] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input26
> [  391.136724] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input27
> [  391.137285] hid-generic 0003:3938:1031.0002: input,hiddev0,hidraw0: USB HID v1.10 Mouse [MOSART Semi. 2.4G Wireless Mouse] on usb-0000:00:14.0-2/input0
> [  391.137480] usbcore: registered new interface driver usbhid
> [  391.137483] usbhid: USB HID core driver
> "

I can't tell that helps any.

>> Could an older (original) usbhid module be reloaded so that the mouse
>> started working again?  That would also explain the lack of (new) messages.
> I think so too. But how do I verify if this is the case?
> 
>> What kernel version are you using?  Is it a distro kernel?
> I am currently running a bleeding edge kernel that I built. ie 5.6-rc7. 
>> Are you trying to replace the usbhid module in a distro kernel or are
>> you building the entire kernel?
> I am building the entire kernel
>>> I used printk(KERN_ALERT "some message") for logging. I also tried with
>>> KERN_ERR but no luck. 
>>>
>>> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
>>> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
>>> both were executed from the usbhid directory.
>>
>> why those commands?  seems unusual.
> My Linux kernel source is in the directory mentioned in the commands. So
> it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
> source root.

So /home/rohit/kernels/staging is the top-level kernel source directory?

"M=dir" is for external modules to be built.  AFAICT you are not building any
external modules.

Just run
$ cd <top of kernel source tree>
$ make all
$ sudo make install



-- 
~Randy

Re: Beginner query regarding usbhid

[Rohit Sarkar]

On Wed, Mar 25, 2020 at 11:07:55PM -0700, Randy Dunlap wrote:
> On 3/25/20 10:31 PM, Rohit Sarkar wrote:
> > On Wed, Mar 25, 2020 at 02:40:27PM -0700, Randy Dunlap wrote:
> >> On 3/25/20 10:13 AM, Rohit Sarkar wrote:
> >>> On Wed, Mar 25, 2020 at 04:41:38PM +0100, Hubert CHAUMETTE wrote:
> >>>> Le 25/03/2020 15:47, Rohit Sarkar a écrit :
> >>>>> I was trying to mess around with the driver that drives my mouse. I
> >>>>> found out that it is usbhid. I then added a printk statement to the init
> >>>>> and exit function of usbhid.
> >>>>> I then compiled and installed the usbhid drivers. Post that I ran
> >>>>> `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
> >>>>> any logs in dmesg.
> >>>>>
> >>>>> I am certain I am missing something fundamental. Could someone help me
> >>>>> with this.
> >>>>
> >>>> Hi,
> >>>>
> >>>> Did you check whether your module was effectively loaded with lsmod?
> >>>> What log level did you use in your printk statement? Depending on your
> >>>> system default loglevel your logs might not be printed. A quick fix
> >>>> would be to use one of the lowest levels (pr_emerg, but pr_err might
> >>>> suffice).
> >>>> Regards,
> >>>
> >>> Hey,
> >>> I did check that module was loaded. And one of the signs was that my
> >>> mouse started working after insmod :).
> > Hi,
> >> Hi,
> >> I'm not convinced that your modified usbhid module was loaded.
> > Hmm, here's my dmesg logs if that helps:
> > "
> > [  382.132319] usbcore: deregistering interface driver usbhid
> > [  391.077410] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input26
> > [  391.136724] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input27
> > [  391.137285] hid-generic 0003:3938:1031.0002: input,hiddev0,hidraw0: USB HID v1.10 Mouse [MOSART Semi. 2.4G Wireless Mouse] on usb-0000:00:14.0-2/input0
> > [  391.137480] usbcore: registered new interface driver usbhid
> > [  391.137483] usbhid: USB HID core driver
> > "
> 
> I can't tell that helps any.
> 
> >> Could an older (original) usbhid module be reloaded so that the mouse
> >> started working again?  That would also explain the lack of (new) messages.
> > I think so too. But how do I verify if this is the case?
> > 
> >> What kernel version are you using?  Is it a distro kernel?
> > I am currently running a bleeding edge kernel that I built. ie 5.6-rc7. 
> >> Are you trying to replace the usbhid module in a distro kernel or are
> >> you building the entire kernel?
> > I am building the entire kernel
> >>> I used printk(KERN_ALERT "some message") for logging. I also tried with
> >>> KERN_ERR but no luck. 
> >>>
> >>> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
> >>> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
> >>> both were executed from the usbhid directory.
> >>
> >> why those commands?  seems unusual.
> > My Linux kernel source is in the directory mentioned in the commands. So
> > it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
> > source root.
> 
> So /home/rohit/kernels/staging is the top-level kernel source directory?
> 
> "M=dir" is for external modules to be built.  AFAICT you are not building any
> external modules.
Oh, I think M=dir options just makes the Makefile build the folder
specified. I see such an output when I run the make command which makes
me feel that the make command I am using is actually building the
modules:
"
drivers/hid/usbhid❯ make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)                                            staging/git/master !
make: Entering directory '/home/rohit/LINUX/kernels/staging'
  AR      /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/built-in.a
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/hid-core.o
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/hiddev.o
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/hid-pidff.o
  LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbhid.o
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbkbd.o
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbmouse.o
  MODPOST 3 modules
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbhid.mod.o
  LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbhid.ko
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbkbd.mod.o
  LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbkbd.ko
  CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbmouse.mod.o
  LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbmouse.ko
make: Leaving directory '/home/rohit/LINUX/kernels/staging'
"

> Just run
> $ cd <top of kernel source tree>
> $ make all
> $ sudo make install
> 
> 
> -- 
> ~Randy
> 
Thanks,
Rohit

Re: Beginner query regarding usbhid

[Rohit Sarkar]

On Wed, Mar 25, 2020 at 11:07:55PM -0700, Randy Dunlap wrote:
> On 3/25/20 10:31 PM, Rohit Sarkar wrote:
> > On Wed, Mar 25, 2020 at 02:40:27PM -0700, Randy Dunlap wrote:
> >> On 3/25/20 10:13 AM, Rohit Sarkar wrote:
> >>> On Wed, Mar 25, 2020 at 04:41:38PM +0100, Hubert CHAUMETTE wrote:
> >>>> Le 25/03/2020 15:47, Rohit Sarkar a écrit :
> >>>>> I was trying to mess around with the driver that drives my mouse. I
> >>>>> found out that it is usbhid. I then added a printk statement to the init
> >>>>> and exit function of usbhid.
> >>>>> I then compiled and installed the usbhid drivers. Post that I ran
> >>>>> `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
> >>>>> any logs in dmesg.
> >>>>>
> >>>>> I am certain I am missing something fundamental. Could someone help me
> >>>>> with this.
> >>>>
> >>>> Hi,
> >>>>
> >>>> Did you check whether your module was effectively loaded with lsmod?
> >>>> What log level did you use in your printk statement? Depending on your
> >>>> system default loglevel your logs might not be printed. A quick fix
> >>>> would be to use one of the lowest levels (pr_emerg, but pr_err might
> >>>> suffice).
> >>>> Regards,
> >>>
> >>> Hey,
> >>> I did check that module was loaded. And one of the signs was that my
> >>> mouse started working after insmod :).
> > Hi,
> >> Hi,
> >> I'm not convinced that your modified usbhid module was loaded.
> > Hmm, here's my dmesg logs if that helps:
> > "
> > [  382.132319] usbcore: deregistering interface driver usbhid
> > [  391.077410] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input26
> > [  391.136724] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input27
> > [  391.137285] hid-generic 0003:3938:1031.0002: input,hiddev0,hidraw0: USB HID v1.10 Mouse [MOSART Semi. 2.4G Wireless Mouse] on usb-0000:00:14.0-2/input0
> > [  391.137480] usbcore: registered new interface driver usbhid
> > [  391.137483] usbhid: USB HID core driver
> > "
> 
> I can't tell that helps any.
> 
> >> Could an older (original) usbhid module be reloaded so that the mouse
> >> started working again?  That would also explain the lack of (new) messages.
> > I think so too. But how do I verify if this is the case?
> > 
> >> What kernel version are you using?  Is it a distro kernel?
> > I am currently running a bleeding edge kernel that I built. ie 5.6-rc7. 
> >> Are you trying to replace the usbhid module in a distro kernel or are
> >> you building the entire kernel?
> > I am building the entire kernel
> >>> I used printk(KERN_ALERT "some message") for logging. I also tried with
> >>> KERN_ERR but no luck. 
> >>>
> >>> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
> >>> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
> >>> both were executed from the usbhid directory.
> >>
> >> why those commands?  seems unusual.
> > My Linux kernel source is in the directory mentioned in the commands. So
> > it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
> > source root.
> 
> So /home/rohit/kernels/staging is the top-level kernel source directory?
> 
> "M=dir" is for external modules to be built.  AFAICT you are not building any
> external modules.
> 
> Just run
> $ cd <top of kernel source tree>
> $ make all
> $ sudo make install
Further, on my system it takes a significant amount of time to run "make
all" for some reason. (30 minutes) even though I have previously
built the kernel and not pulled any update.
AFAIK, make is only supposed to build the files that have
changed. Idk why it is also compiling other files. Most of the time is
taken by make running modpost.

That is the reason I tried to build and install only the hid folder
> 
> 
> -- 
> ~Randy
> 

Re: Beginner query regarding usbhid

[Rohit Sarkar]

Hi,
On Wed, Mar 25, 2020 at 11:07:55PM -0700, Randy Dunlap wrote:
> 
> So /home/rohit/kernels/staging is the top-level kernel source directory?
> 
> "M=dir" is for external modules to be built.  AFAICT you are not building any
> external modules.
> 
> Just run
> $ cd <top of kernel source tree>
> $ make all
> $ sudo make install

Wow it worked now.
I ran make and make modules_install install. After that I restarted the
system.

Does this mean everytime I do some changes to an intree module I need to
reboot my system?
> 
> 
> -- 
> ~Randy
> 
Thanks,
Rohit

Re: Beginner query regarding usbhid

[Randy Dunlap]

On 3/25/20 11:53 PM, Rohit Sarkar wrote:
> On Wed, Mar 25, 2020 at 11:07:55PM -0700, Randy Dunlap wrote:
>> On 3/25/20 10:31 PM, Rohit Sarkar wrote:
>>> On Wed, Mar 25, 2020 at 02:40:27PM -0700, Randy Dunlap wrote:
>>>> On 3/25/20 10:13 AM, Rohit Sarkar wrote:
>>>>> On Wed, Mar 25, 2020 at 04:41:38PM +0100, Hubert CHAUMETTE wrote:
>>>>>> Le 25/03/2020 15:47, Rohit Sarkar a écrit :
>>>>>>> I was trying to mess around with the driver that drives my mouse. I
>>>>>>> found out that it is usbhid. I then added a printk statement to the init
>>>>>>> and exit function of usbhid.
>>>>>>> I then compiled and installed the usbhid drivers. Post that I ran
>>>>>>> `sudo modprobe -r usbhid` and `sudo modprobe usbhid` but couldnt observe
>>>>>>> any logs in dmesg.
>>>>>>>
>>>>>>> I am certain I am missing something fundamental. Could someone help me
>>>>>>> with this.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Did you check whether your module was effectively loaded with lsmod?
>>>>>> What log level did you use in your printk statement? Depending on your
>>>>>> system default loglevel your logs might not be printed. A quick fix
>>>>>> would be to use one of the lowest levels (pr_emerg, but pr_err might
>>>>>> suffice).
>>>>>> Regards,
>>>>>
>>>>> Hey,
>>>>> I did check that module was loaded. And one of the signs was that my
>>>>> mouse started working after insmod :).
>>> Hi,
>>>> Hi,
>>>> I'm not convinced that your modified usbhid module was loaded.
>>> Hmm, here's my dmesg logs if that helps:
>>> "
>>> [  382.132319] usbcore: deregistering interface driver usbhid
>>> [  391.077410] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input26
>>> [  391.136724] input: MOSART Semi. 2.4G Wireless Mouse as /devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/0003:3938:1031.0002/input/input27
>>> [  391.137285] hid-generic 0003:3938:1031.0002: input,hiddev0,hidraw0: USB HID v1.10 Mouse [MOSART Semi. 2.4G Wireless Mouse] on usb-0000:00:14.0-2/input0
>>> [  391.137480] usbcore: registered new interface driver usbhid
>>> [  391.137483] usbhid: USB HID core driver
>>> "
>>
>> I can't tell that helps any.
>>
>>>> Could an older (original) usbhid module be reloaded so that the mouse
>>>> started working again?  That would also explain the lack of (new) messages.
>>> I think so too. But how do I verify if this is the case?
>>>
>>>> What kernel version are you using?  Is it a distro kernel?
>>> I am currently running a bleeding edge kernel that I built. ie 5.6-rc7. 
>>>> Are you trying to replace the usbhid module in a distro kernel or are
>>>> you building the entire kernel?
>>> I am building the entire kernel
>>>>> I used printk(KERN_ALERT "some message") for logging. I also tried with
>>>>> KERN_ERR but no luck. 
>>>>>
>>>>> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
>>>>> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
>>>>> both were executed from the usbhid directory.
>>>>
>>>> why those commands?  seems unusual.
>>> My Linux kernel source is in the directory mentioned in the commands. So
>>> it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
>>> source root.
>>
>> So /home/rohit/kernels/staging is the top-level kernel source directory?
>>
>> "M=dir" is for external modules to be built.  AFAICT you are not building any
>> external modules.

> Oh, I think M=dir options just makes the Makefile build the folder
> specified. I see such an output when I run the make command which makes
> me feel that the make command I am using is actually building the
> modules:

You should be able to build the usbhid sub-directory ("folder") like this:

$ cd /home/rohit/LINUX/kernels/staging
$ make drivers/hid/usbhid/

but maybe what you are doing is equivalent to this.

> "
> drivers/hid/usbhid❯ make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)                                            staging/git/master !
> make: Entering directory '/home/rohit/LINUX/kernels/staging'
>   AR      /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/built-in.a
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/hid-core.o
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/hiddev.o
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/hid-pidff.o
>   LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbhid.o
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbkbd.o
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbmouse.o
>   MODPOST 3 modules
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbhid.mod.o
>   LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbhid.ko
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbkbd.mod.o
>   LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbkbd.ko
>   CC [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbmouse.mod.o
>   LD [M]  /home/rohit/LINUX/kernels/staging/drivers/hid/usbhid/usbmouse.ko
> make: Leaving directory '/home/rohit/LINUX/kernels/staging'
> "


-- 
~Randy

Re: Beginner query regarding usbhid

[Randy Dunlap]

On 3/26/20 12:34 AM, Rohit Sarkar wrote:

>>>>>
>>>>> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
>>>>> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
>>>>> both were executed from the usbhid directory.
>>>>
>>>> why those commands?  seems unusual.
>>> My Linux kernel source is in the directory mentioned in the commands. So
>>> it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
>>> source root.
>>
>> So /home/rohit/kernels/staging is the top-level kernel source directory?
>>
>> "M=dir" is for external modules to be built.  AFAICT you are not building any
>> external modules.
>>
>> Just run
>> $ cd <top of kernel source tree>
>> $ make all
>> $ sudo make install
> Further, on my system it takes a significant amount of time to run "make
> all" for some reason. (30 minutes) even though I have previously
> built the kernel and not pulled any update.
> AFAIK, make is only supposed to build the files that have
> changed. Idk why it is also compiling other files. Most of the time is
> taken by make running modpost.
> 
> That is the reason I tried to build and install only the hid folder

OK, I get that.

For a driver that is built as a loadable module, you should be able to
edit the driver, build it, unload previous version (rmmod),
load new version (modprobe or insmod), and test it, without having to
reboot the kernel. [until an oops or BUG or WARN happens]

If you don't "install" the new module file, I think that modprobe will
look in /lib/modules/kernel_version/* for the module file and find the
old one.  In this case I usually use "insmod path_to_new_driver_file"
to load & test it.

-- 
~Randy

Re: Beginner query regarding usbhid

[Randy Dunlap]

On 3/26/20 4:48 AM, Rohit Sarkar wrote:
> Hi,
> On Wed, Mar 25, 2020 at 11:07:55PM -0700, Randy Dunlap wrote:
>>
>> So /home/rohit/kernels/staging is the top-level kernel source directory?
>>
>> "M=dir" is for external modules to be built.  AFAICT you are not building any
>> external modules.
>>
>> Just run
>> $ cd <top of kernel source tree>
>> $ make all
>> $ sudo make install
> 
> Wow it worked now.
> I ran make and make modules_install install. After that I restarted the
> system.
> 
> Does this mean everytime I do some changes to an intree module I need to
> reboot my system?

No, that should not be necessary.

-- 
~Randy

Re: Beginner query regarding usbhid

[Rohit Sarkar]

On Thu, Mar 26, 2020 at 09:02:55AM -0700, Randy Dunlap wrote:
> On 3/26/20 12:34 AM, Rohit Sarkar wrote:
> 
> >>>>>
> >>>>> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
> >>>>> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
> >>>>> both were executed from the usbhid directory.
> >>>>
> >>>> why those commands?  seems unusual.
> >>> My Linux kernel source is in the directory mentioned in the commands. So
> >>> it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
> >>> source root.
> >>
> >> So /home/rohit/kernels/staging is the top-level kernel source directory?
> >>
> >> "M=dir" is for external modules to be built.  AFAICT you are not building any
> >> external modules.
> >>
> >> Just run
> >> $ cd <top of kernel source tree>
> >> $ make all
> >> $ sudo make install
> > Further, on my system it takes a significant amount of time to run "make
> > all" for some reason. (30 minutes) even though I have previously
> > built the kernel and not pulled any update.
> > AFAIK, make is only supposed to build the files that have
> > changed. Idk why it is also compiling other files. Most of the time is
> > taken by make running modpost.
> > 
> > That is the reason I tried to build and install only the hid folder
> 
> OK, I get that.
> 
> For a driver that is built as a loadable module, you should be able to
> edit the driver, build it, unload previous version (rmmod),
> load new version (modprobe or insmod), and test it, without having to
> reboot the kernel. [until an oops or BUG or WARN happens]
> 
> If you don't "install" the new module file, I think that modprobe will
> look in /lib/modules/kernel_version/* for the module file and find the
> old one.  In this case I usually use "insmod path_to_new_driver_file"
> to load & test it.
Hmm, the weird part is that I did run "sudo make modules_install".
Shouldnt that get the latest modules into /lib/modules/{kernel
version}/*. Although it didnt work before rebooting.
I guess insmod path_to_new_driver_file is the best option here.

Thanks,
Rohit
> -- 
> ~Randy
> 

Re: Beginner query regarding usbhid

[Randy Dunlap]

On 3/26/20 9:14 AM, Rohit Sarkar wrote:
> On Thu, Mar 26, 2020 at 09:02:55AM -0700, Randy Dunlap wrote:
>> On 3/26/20 12:34 AM, Rohit Sarkar wrote:
>>
>>>>>>>
>>>>>>> The command I used for building was "make -C /home/rohit/LINUX/kernels/staging  M=$(pwd)"
>>>>>>> and for installing the modules: "sudo make -C /home/rohit/LINUX/kernels/staging  M=$(pwd) modules_install"
>>>>>>> both were executed from the usbhid directory.
>>>>>>
>>>>>> why those commands?  seems unusual.
>>>>> My Linux kernel source is in the directory mentioned in the commands. So
>>>>> it is same as running "make M=drivers/hid/usbhid/" from the linux kernel
>>>>> source root.
>>>>
>>>> So /home/rohit/kernels/staging is the top-level kernel source directory?
>>>>
>>>> "M=dir" is for external modules to be built.  AFAICT you are not building any
>>>> external modules.
>>>>
>>>> Just run
>>>> $ cd <top of kernel source tree>
>>>> $ make all
>>>> $ sudo make install
>>> Further, on my system it takes a significant amount of time to run "make
>>> all" for some reason. (30 minutes) even though I have previously
>>> built the kernel and not pulled any update.
>>> AFAIK, make is only supposed to build the files that have
>>> changed. Idk why it is also compiling other files. Most of the time is
>>> taken by make running modpost.
>>>
>>> That is the reason I tried to build and install only the hid folder
>>
>> OK, I get that.
>>
>> For a driver that is built as a loadable module, you should be able to
>> edit the driver, build it, unload previous version (rmmod),
>> load new version (modprobe or insmod), and test it, without having to
>> reboot the kernel. [until an oops or BUG or WARN happens]
>>
>> If you don't "install" the new module file, I think that modprobe will
>> look in /lib/modules/kernel_version/* for the module file and find the
>> old one.  In this case I usually use "insmod path_to_new_driver_file"
>> to load & test it.
> Hmm, the weird part is that I did run "sudo make modules_install".
> Shouldnt that get the latest modules into /lib/modules/{kernel
> version}/*. Although it didnt work before rebooting.

Yes.

> I guess insmod path_to_new_driver_file is the best option here.


-- 
~Randy