Help writing a custom HID driver

Help writing a custom HID driver

[Jose Diez]

Hello linux-input,

I'm trying to write a custom HID driver. It works fine, and I can send 
reports just fine, but one of the requirements of this device is that I 
have to reply to reports with code 62 with another report with code 62, 
which resets a watchdog in the device.

This is my code so far: http://codepad.org/m4QiWhDt

The problem is in line 40. It seems like I'm not allowed to call 
hid_hw_output_report from the raw_event callback handler. I've tried 
surrounding the call with spin_locks, but I still get the "scheduling 
while atomic" error.

I'm not sure how to approach this - can someone help? It would be much 
appreciated. Thanks.

Re: Help writing a custom HID driver

[Benjamin Tissoires]

Hi Jose,

On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez <jose@mediacru.sh> wrote:
> Hello linux-input,
>
> I'm trying to write a custom HID driver. It works fine, and I can send
> reports just fine, but one of the requirements of this device is that I have
> to reply to reports with code 62 with another report with code 62, which
> resets a watchdog in the device.
>
> This is my code so far: http://codepad.org/m4QiWhDt
>
> The problem is in line 40. It seems like I'm not allowed to call
> hid_hw_output_report from the raw_event callback handler. I've tried
> surrounding the call with spin_locks, but I still get the "scheduling while
> atomic" error.

Yeah, when you are in the .event callback, you are basically called by
an IRQ, so you can not schedule a potentially blocking operation.

>
> I'm not sure how to approach this - can someone help? It would be much
> appreciated. Thanks.

I would use a worker to do what you are trying to do. You can have a
look at the reset_worker we have in drivers/hid/hid-rmi.c.
When the event is not one we expected, we schedule a worker thread
which then sends an output report to the device. This way, the
blocking operation is sent from a different thread than the IRQ one.
It is kind of what you are willing to do.
There are many other examples of workers in the hid subtree, or you
can refer to the doc to find out more.

Cheers,
Benjamin

Re: Help writing a custom HID driver

[Jose Diez]

Thanks Benjamin. That fixed the issue. Have a great day.

On 06/11/14 18:57, Benjamin Tissoires wrote:
> Hi Jose,
>
> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez <jose@mediacru.sh> wrote:
>> Hello linux-input,
>>
>> I'm trying to write a custom HID driver. It works fine, and I can send
>> reports just fine, but one of the requirements of this device is that I have
>> to reply to reports with code 62 with another report with code 62, which
>> resets a watchdog in the device.
>>
>> This is my code so far: http://codepad.org/m4QiWhDt
>>
>> The problem is in line 40. It seems like I'm not allowed to call
>> hid_hw_output_report from the raw_event callback handler. I've tried
>> surrounding the call with spin_locks, but I still get the "scheduling while
>> atomic" error.
> Yeah, when you are in the .event callback, you are basically called by
> an IRQ, so you can not schedule a potentially blocking operation.
>
>> I'm not sure how to approach this - can someone help? It would be much
>> appreciated. Thanks.
> I would use a worker to do what you are trying to do. You can have a
> look at the reset_worker we have in drivers/hid/hid-rmi.c.
> When the event is not one we expected, we schedule a worker thread
> which then sends an output report to the device. This way, the
> blocking operation is sent from a different thread than the IRQ one.
> It is kind of what you are willing to do.
> There are many other examples of workers in the hid subtree, or you
> can refer to the doc to find out more.
>
> Cheers,
> Benjamin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help writing a custom HID driver

[Jose Diez]

Okay, so I've solved the watchdog issue, and now I want the driver to be 
loaded automatically. I've copied the module to /lib/modules/<kernel>/ 
and run depmod -a, and I can see it in modules.alias, but it looks like 
hid_generic grabs it first upon boot - my module is loaded correctly, 
but it doesn't grab the HID device.

If I `modprobe -r hid_generic` and then load my module, everything works 
correctly.
On 06/11/14 19:28, Jose Diez wrote:
> Thanks Benjamin. That fixed the issue. Have a great day.
>
> On 06/11/14 18:57, Benjamin Tissoires wrote:
>> Hi Jose,
>>
>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez <jose@mediacru.sh> wrote:
>>> Hello linux-input,
>>>
>>> I'm trying to write a custom HID driver. It works fine, and I can send
>>> reports just fine, but one of the requirements of this device is 
>>> that I have
>>> to reply to reports with code 62 with another report with code 62, 
>>> which
>>> resets a watchdog in the device.
>>>
>>> This is my code so far: http://codepad.org/m4QiWhDt
>>>
>>> The problem is in line 40. It seems like I'm not allowed to call
>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>> surrounding the call with spin_locks, but I still get the 
>>> "scheduling while
>>> atomic" error.
>> Yeah, when you are in the .event callback, you are basically called by
>> an IRQ, so you can not schedule a potentially blocking operation.
>>
>>> I'm not sure how to approach this - can someone help? It would be much
>>> appreciated. Thanks.
>> I would use a worker to do what you are trying to do. You can have a
>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>> When the event is not one we expected, we schedule a worker thread
>> which then sends an output report to the device. This way, the
>> blocking operation is sent from a different thread than the IRQ one.
>> It is kind of what you are willing to do.
>> There are many other examples of workers in the hid subtree, or you
>> can refer to the doc to find out more.
>>
>> Cheers,
>> Benjamin
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-input" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Help writing a custom HID driver

[Benjamin Tissoires]

On Thu, Nov 6, 2014 at 3:18 PM, Jose Diez <jose@mediacru.sh> wrote:
> Okay, so I've solved the watchdog issue, and now I want the driver to be
> loaded automatically. I've copied the module to /lib/modules/<kernel>/ and
> run depmod -a, and I can see it in modules.alias, but it looks like
> hid_generic grabs it first upon boot - my module is loaded correctly, but it
> doesn't grab the HID device.
>
> If I `modprobe -r hid_generic` and then load my module, everything works
> correctly.

Yep. You need to add your device VendorID/ProductID in
hid_have_special_driver[] in hid-core.c.
This will tell hid-generic not to grab your device, and your custom
module will take over.

Cheers,
Benjamin

>
> On 06/11/14 19:28, Jose Diez wrote:
>>
>> Thanks Benjamin. That fixed the issue. Have a great day.
>>
>> On 06/11/14 18:57, Benjamin Tissoires wrote:
>>>
>>> Hi Jose,
>>>
>>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez <jose@mediacru.sh> wrote:
>>>>
>>>> Hello linux-input,
>>>>
>>>> I'm trying to write a custom HID driver. It works fine, and I can send
>>>> reports just fine, but one of the requirements of this device is that I
>>>> have
>>>> to reply to reports with code 62 with another report with code 62, which
>>>> resets a watchdog in the device.
>>>>
>>>> This is my code so far: http://codepad.org/m4QiWhDt
>>>>
>>>> The problem is in line 40. It seems like I'm not allowed to call
>>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>>> surrounding the call with spin_locks, but I still get the "scheduling
>>>> while
>>>> atomic" error.
>>>
>>> Yeah, when you are in the .event callback, you are basically called by
>>> an IRQ, so you can not schedule a potentially blocking operation.
>>>
>>>> I'm not sure how to approach this - can someone help? It would be much
>>>> appreciated. Thanks.
>>>
>>> I would use a worker to do what you are trying to do. You can have a
>>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>>> When the event is not one we expected, we schedule a worker thread
>>> which then sends an output report to the device. This way, the
>>> blocking operation is sent from a different thread than the IRQ one.
>>> It is kind of what you are willing to do.
>>> There are many other examples of workers in the hid subtree, or you
>>> can refer to the doc to find out more.
>>>
>>> Cheers,
>>> Benjamin
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: Help writing a custom HID driver

[Jose Diez]

Ah, I was hoping there would be a way to avoid having to patch the 
kernel itself.

Thanks again,
Jose
On 06/11/14 20:22, Benjamin Tissoires wrote:
> On Thu, Nov 6, 2014 at 3:18 PM, Jose Diez<jose@mediacru.sh>  wrote:
>> Okay, so I've solved the watchdog issue, and now I want the driver to be
>> loaded automatically. I've copied the module to /lib/modules/<kernel>/ and
>> run depmod -a, and I can see it in modules.alias, but it looks like
>> hid_generic grabs it first upon boot - my module is loaded correctly, but it
>> doesn't grab the HID device.
>>
>> If I `modprobe -r hid_generic` and then load my module, everything works
>> correctly.
> Yep. You need to add your device VendorID/ProductID in
> hid_have_special_driver[] in hid-core.c.
> This will tell hid-generic not to grab your device, and your custom
> module will take over.
>
> Cheers,
> Benjamin
>
>> On 06/11/14 19:28, Jose Diez wrote:
>>> Thanks Benjamin. That fixed the issue. Have a great day.
>>>
>>> On 06/11/14 18:57, Benjamin Tissoires wrote:
>>>> Hi Jose,
>>>>
>>>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez<jose@mediacru.sh>  wrote:
>>>>> Hello linux-input,
>>>>>
>>>>> I'm trying to write a custom HID driver. It works fine, and I can send
>>>>> reports just fine, but one of the requirements of this device is that I
>>>>> have
>>>>> to reply to reports with code 62 with another report with code 62, which
>>>>> resets a watchdog in the device.
>>>>>
>>>>> This is my code so far:http://codepad.org/m4QiWhDt
>>>>>
>>>>> The problem is in line 40. It seems like I'm not allowed to call
>>>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>>>> surrounding the call with spin_locks, but I still get the "scheduling
>>>>> while
>>>>> atomic" error.
>>>> Yeah, when you are in the .event callback, you are basically called by
>>>> an IRQ, so you can not schedule a potentially blocking operation.
>>>>
>>>>> I'm not sure how to approach this - can someone help? It would be much
>>>>> appreciated. Thanks.
>>>> I would use a worker to do what you are trying to do. You can have a
>>>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>>>> When the event is not one we expected, we schedule a worker thread
>>>> which then sends an output report to the device. This way, the
>>>> blocking operation is sent from a different thread than the IRQ one.
>>>> It is kind of what you are willing to do.
>>>> There are many other examples of workers in the hid subtree, or you
>>>> can refer to the doc to find out more.
>>>>
>>>> Cheers,
>>>> Benjamin
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>>>> the body of a message tomajordomo@vger.kernel.org
>>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-input" in
>>> the body of a message tomajordomo@vger.kernel.org
>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message tomajordomo@vger.kernel.org
> More majordomo info athttp://vger.kernel.org/majordomo-info.html

Re: Help writing a custom HID driver

[Jose Diez]

Hi, it's me again.

So I'm trying to use the Linux input system to report key events from 
the device.
This is my code so far: http://sprunge.us/KfhF

As you can see, I'm trying to send event 1 whenever the watchdog work is 
executed.
I can see from dmesg that the task is actually being executed, but when 
I run evtest
to check if I actually receive the messages, I see nothing.

Any help would be much appreciated.

Thanks,
Jose
On 06/11/14 20:56, Jose Diez wrote:
> Ah, I was hoping there would be a way to avoid having to patch the 
> kernel itself.
>
> Thanks again,
> Jose
> On 06/11/14 20:22, Benjamin Tissoires wrote:
>> On Thu, Nov 6, 2014 at 3:18 PM, Jose Diez<jose@mediacru.sh>  wrote:
>>> Okay, so I've solved the watchdog issue, and now I want the driver 
>>> to be
>>> loaded automatically. I've copied the module to 
>>> /lib/modules/<kernel>/ and
>>> run depmod -a, and I can see it in modules.alias, but it looks like
>>> hid_generic grabs it first upon boot - my module is loaded 
>>> correctly, but it
>>> doesn't grab the HID device.
>>>
>>> If I `modprobe -r hid_generic` and then load my module, everything 
>>> works
>>> correctly.
>> Yep. You need to add your device VendorID/ProductID in
>> hid_have_special_driver[] in hid-core.c.
>> This will tell hid-generic not to grab your device, and your custom
>> module will take over.
>>
>> Cheers,
>> Benjamin
>>
>>> On 06/11/14 19:28, Jose Diez wrote:
>>>> Thanks Benjamin. That fixed the issue. Have a great day.
>>>>
>>>> On 06/11/14 18:57, Benjamin Tissoires wrote:
>>>>> Hi Jose,
>>>>>
>>>>> On Thu, Nov 6, 2014 at 1:33 PM, Jose Diez<jose@mediacru.sh>  wrote:
>>>>>> Hello linux-input,
>>>>>>
>>>>>> I'm trying to write a custom HID driver. It works fine, and I can 
>>>>>> send
>>>>>> reports just fine, but one of the requirements of this device is 
>>>>>> that I
>>>>>> have
>>>>>> to reply to reports with code 62 with another report with code 
>>>>>> 62, which
>>>>>> resets a watchdog in the device.
>>>>>>
>>>>>> This is my code so far:http://codepad.org/m4QiWhDt
>>>>>>
>>>>>> The problem is in line 40. It seems like I'm not allowed to call
>>>>>> hid_hw_output_report from the raw_event callback handler. I've tried
>>>>>> surrounding the call with spin_locks, but I still get the 
>>>>>> "scheduling
>>>>>> while
>>>>>> atomic" error.
>>>>> Yeah, when you are in the .event callback, you are basically 
>>>>> called by
>>>>> an IRQ, so you can not schedule a potentially blocking operation.
>>>>>
>>>>>> I'm not sure how to approach this - can someone help? It would be 
>>>>>> much
>>>>>> appreciated. Thanks.
>>>>> I would use a worker to do what you are trying to do. You can have a
>>>>> look at the reset_worker we have in drivers/hid/hid-rmi.c.
>>>>> When the event is not one we expected, we schedule a worker thread
>>>>> which then sends an output report to the device. This way, the
>>>>> blocking operation is sent from a different thread than the IRQ one.
>>>>> It is kind of what you are willing to do.
>>>>> There are many other examples of workers in the hid subtree, or you
>>>>> can refer to the doc to find out more.
>>>>>
>>>>> Cheers,
>>>>> Benjamin
>>>>> -- 
>>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>>> linux-input" in
>>>>> the body of a message tomajordomo@vger.kernel.org
>>>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>>> -- 
>>>> To unsubscribe from this list: send the line "unsubscribe 
>>>> linux-input" in
>>>> the body of a message tomajordomo@vger.kernel.org
>>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>> -- 
>> To unsubscribe from this list: send the line "unsubscribe 
>> linux-input" in
>> the body of a message tomajordomo@vger.kernel.org
>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html