Si on regarde la définition de hid_reset_resume un peu plus haut on voit qu'il retourne ce que hid_post_reset retourne. hid_post_reset quant à lui peut retourner 1 dans plusieurs cas, toujours après avoir appelé dbg_hid: http://lxr.linux.no/#linux+v3.6/drivers/hid/usbhid/hid-core.c#L1404
# UTSL
Posté par Krunch (courriel, site web personnel) . En réponse au message Petit bug dans le noyau?. Évalué à 4.
Sans la version ça va être compliqué mais bon. Admettons que ce soit du 3.6. Le message vient de http://lxr.linux.no/#linux+v3.6/drivers/usb/core/driver.c#L1198
Ce qui veut dire que la méthode reset_resume du driver a retourné 1. Le driver semble être usbhid: http://lxr.linux.no/#linux+v3.6/drivers/hid/usbhid/hid-core.c#L1601
Si on regarde la définition de hid_reset_resume un peu plus haut on voit qu'il retourne ce que hid_post_reset retourne. hid_post_reset quant à lui peut retourner 1 dans plusieurs cas, toujours après avoir appelé dbg_hid: http://lxr.linux.no/#linux+v3.6/drivers/hid/usbhid/hid-core.c#L1404
En examinant la définition de dbg_hid http://lxr.linux.no/#linux+v3.6/include/linux/hid.h#L918 on voit que cela afficher quelque chose uniquement si hid_debug ne vaut pas 0. Cette variable étant une paramètre du module hid-core: http://lxr.linux.no/#linux+v3.6/drivers/hid/hid-core.c#L48
L'étape suivante serait donc d'activer les messages de debug HID et de reproduire le problème.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.