Skip to contentSkip to conversation

Give hiddev a device link in sysfs

HACK Adam Kropelin 2 participants 3 messages Dec 16, 2003 – Dec 23, 2003 USB

lore
Share & tools
lore
#0 lore raw

I have a bunch of USB interface UPSes which are managed via the hiddev interface. Recently I've been working on setting up a dedicated server to manage them all. I'd like to use udev to manage the device nodes so that I can have consistent naming no matter what USB port a particular UPS happens to be plugged into. They have unique serial numbers, so a udev.rules LABEL entry seemed the appropriate thing to do.

It didn't work. Eventually I tracked it to a bad device link in sysfs (/sys/class/usb/hiddevN/device). Further investigation showed that the broken link is due to hiddev's being not-quite-a-usb-device and having a zero kobj with no parent, etc.

I cooked up the hack-job patch below and it seems to be working. Clearly this isn't the right solution, but it's a starting point and it solves my immediate need.

Bearing in mind that I'm a kobj newbie, can anyone suggest what the right approach is to solve this problem? Do we actually want to grow a legitimate kobj for the hiddev and register it? Comments in the code imply that hiddev could eventually be severed from usb altogether. Is there a shorter term solution that is workable?

Thanks for you input...
--Adam

drivers/usb/input/hiddev.c +9 -0
@@ -234,6 +234,7 @@
 static void hiddev_cleanup(struct hiddev *hiddev)
 {
 	usb_deregister_dev(&hiddev->intf, &hiddev_class);
+	kobject_put(hiddev->intf.dev.kobj.parent);
 	hiddev_table[hiddev->minor] = NULL;
 	kfree(hiddev);
 }
@@ -724,6 +725,14 @@
 		return -1;
 	memset(hiddev, 0, sizeof(struct hiddev));
 
+	strcpy(hiddev->intf.dev.kobj.name, hid->dev->dev.kobj.name);
+	kobject_get(hid->dev->dev.kobj.parent);
+	hiddev->intf.dev.kobj.parent = hid->dev->dev.kobj.parent;
+	hiddev->intf.dev.kobj.kset = NULL;
+	hiddev->intf.dev.kobj.ktype = NULL;
+	hiddev->intf.dev.kobj.dentry = NULL;
+	kobject_init(&hiddev->intf.dev.kobj);
+
  	retval = usb_register_dev(&hiddev->intf, &hiddev_class);
 	if (retval) {
 		err("Not able to get a minor for this device.");

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#1 lore raw
Quoted 7 lines · Adam Kropelin

I have a bunch of USB interface UPSes which are managed via the hiddev interface. Recently I've been working on setting up a dedicated server to manage them all. I'd like to use udev to manage the device nodes so that I can have consistent naming no matter what USB port a particular UPS happens to be plugged into. They have unique serial numbers, so a udev.rules LABEL entry seemed the appropriate thing to do.

Quoted 8 lines

It didn't work. Eventually I tracked it to a bad device link in sysfs (/sys/class/usb/hiddevN/device). Further investigation showed that the broken link is due to hiddev's being not-quite-a-usb-device and having a zero kobj with no parent, etc.

I cooked up the hack-job patch below and it seems to be working. Clearly this isn't the right solution, but it's a starting point and it solves my immediate need.

Yeah, hiddev is wierd. It needs to dynamically allocate that interface structure, and then a patch like this will start to make sense. Right now bad things can happen if you unload the hiddev module when you have a file in sysfs open for that device.

But this patch is a start. Care to finish it up?

thanks,

greg k-h

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

#2 lore raw
In reply to Adam Kropelin
Quoted 9 lines · Greg KH
Quoted 7 lines · Adam Kropelin

(/sys/class/usb/hiddevN/device). Further investigation showed that the broken link is due to hiddev's being not-quite-a-usb-device and having a zero kobj with no parent, etc.

I cooked up the hack-job patch below and it seems to be working. Clearly this isn't the right solution, but it's a starting point and it solves my immediate need.

Quoted 6 lines

Yeah, hiddev is wierd. It needs to dynamically allocate that interface structure, and then a patch like this will start to make sense. Right now bad things can happen if you unload the hiddev module when you have a file in sysfs open for that device.

But this patch is a start. Care to finish it up?

Sure...I'll have a chance to look at it after the holidays.

--Adam

-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel