I have L4T Linux R32.5.1 with bit tweaked kernel and device tree (I don’t see how they might cause my problem though) running on my Jetson Nano emmc. I’d like to change the group of the pwm-fan to for example group nvidia so that my user application could control the fan. With udevadm info -a /sys/devices/pwm-fan, I can find that the pwm-fan has:
looking at device ‘/devices/pwm-fan’:
KERNEL==“pwm-fan”
SUBSYSTEM==“platform”
DRIVER==“pwm_fan_driver”
so I created a udev rule to /etc/udev/rules.d/10-my.rules having
However, I can see no reaction anywhere. The group has not changed. Setting logging level to debug in udev.conf tells me that rule file has been found but I cannot determine if there are entries related to that device or rule.
Don’t know if I can help, but is this for controlling a file in “/dev”, or is it instead for something “/sys”? For whatever file it is, what is its full path and default permission if not modified?
@linuxdev, the file is in /sys. For example this file:
root@localhost:/home/nvidia# ls -l /sys/devices/pwm-fan/target_pwm
-rw-r–r-- 1 root root 4096 Jan 28 15:59 /sys/devices/pwm-fan/target_pwm
Apparently I need to change permissions as well for group to write, but I’d like to see at least something happening first.
@JerryChang, we have an application running with user privileges on Jetson Nano. I’d like this application to be able to control the fan and other hardware of the system. There is also a led controller in i2c bus that I need to change permissions as well. pwm-fan privileges I might be able to circumvent, but I thought that I make a question about it first as it comes with L4T by default and I think there is something fundamental with L4T udev rules that I do not get (I think I tried everything and nothing seems to happen…).
I’ve never thought about using udev for files outside of “/dev”. Whether or not that would work I do not know. However, there is a lot to break by changing permissions inside of “/sys”. My instinct is that “it is a bad idea”.
The method probably intended for such issues is to add the given user to that group. Is there a reason you can’t use usermod to do this instead of modifying the file itself? An example, if the user name is “nvidia”, to add to group “dialout” (you’d substitute for the desired group and user name) would be: sudo usermod -aG dialout nvidia
The “-a” part says to add a group and to not replace existing groups. Thus in the example “dialout” becomes a supplemental group of user “nvidia”.
Messing with “/sys” is probably going to lead to unexpected problems. If you can add your user to the group, then you are done and no other changes are needed.
@linuxdev, thanks for the suggestion but the desired devices have group root. Assigning the user to that group sounds like security violation and is almost the same as running my application as root user. If you think that sysfs is out of the question I wonder how can user control the devices such as pwm-fan or led controller in i2c bus? Can I make them somehow appear under the /dev?
By the way, I understood from these instructions (Writing udev rules) and some other sources online that the sysfs could be managed with udev.
Yes, I overlooked that. Still I think udev was meant for “/dev” files, and not “/sys”. However, I have not actually tried to alter something in “/sys” via udev.
I am not the right person to answer some of this, but it does seem that if you are using i2c, then probably there is a way to use that instead of directly using those files. If so, then this would dramatically simplify life.
Would someone be able to suggest how a non-root user could be used for i2c control of the fan, possibly with an interface in “/dev”?
To clarify, the pwm-fan is not in the i2c bus, only the leds. pwm-fan is what comes with the L4T.
But to me it looks that they share the same problem: how can the non-root user control the devices provided by kernel? I could add another application running as root to control the devices, but designing such application seems very complex approach compared to the changing the group of device.
The key point in that URL is that it uses “/etc/init.d” files to run the chmod each boot. There is probably a more modern way to do this with a service file, but it shouldn’t matter so long as the init.d files run. I’d just try to customize that URL’s script for your “/sys” and see if it works. Name your script file after the “/sys” file and make sure the script itself is executable.