On Sat, 27 Jan 2007, Soeren Sonnenburg wrote: > I realized that any setting to /sys/module/usbhid/parameters/pb_fnmode > is just ignored until the machine does a suspend-resume cycle.
Hi Soeren, I would probably not call this a regression, as this has been always there, as far as I can see. > I've added a printk in drivers/usb/input/hid-core.c (which is the only > place where hid->pb_fnmode is set) and indeed only on module load ( in > my case usbhid is compiled into the kernel - so on kernel boot) any > change to hid>pb_fnmode is done. Adding a printk to hidinput_pb_event() > in drivers/hid/hid-input.c says the same: hid->pb_fnmode cannot be > changed on the fly anymore... HOWEVER: If I s2ram the machine > hid->pb_fnmode is initialized with the value I put into > /sys/module/usbhid/parameters/pb_fnmode . As I have no idea how/whether > sysfs works/is possible I now hope someone more knowledgable than me can > resolve this issue! Changing module parameter values through sysfs is not a very nice idea, because the change of the value is indeed silent - the driver is not notified in any way, that the value has changed. So the driver should take care of it by itself, which is not a nice thing. The fact that during suspend/resume cycle it works is caused by the fact that all the hid devices are reinitialized, and therefore the hid->pb_fnmode is reassigned a new value, which has eventually been changed through sysfs. I would rather be inclined to just make the /sys/module/usbhid/parameters/pb_fnmode read-only (which is what most of the drivers do anyway), to avoid this kind of confusion. Do you have really any strong use-case, when setting the parameter during runtime would be much more useful than just do it during modprobe or rmmod/modprobe cycle? Thanks, -- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
