-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of hard-coded /dev/ttyUSB0 in fan drivers can cause conflict #118
Comments
A "healthy" project would merge this immediately. I came from ArgonOne and they neglect their upstream the same way. The diff looks great. One small knit. I suggest the udev rule and c code use device |
Yeah, good call - naming things is always hard! |
My DeskPi hosts RPI 4 running 64-bit Ubuntu 22.04.1. I found the /var/log/syslog inundated with following errors (20 GB of it filling the root filesystem after just one day of uptime)...
Though the solution provided here seems more robust I solved the /dev/ttyUSB0 issue by just getting rid of brltty...
The fan is working now. |
With your description I was able to solve the fan problem when connecting another device to ttyUSB0. Unfortunately, however, My DeskPi hosts RPI 4 running 64-bit Raspberry Pi OS. I have tested install.sh and install-raspbios-64bit.sh |
This method is good for the OS which can not generate /dev/ttyUSB0 device file, due to this file is generated by this overlay: |
Problem
The code for the fan drivers, etc, uses a hard-coded device - /dev/ttyUSB0
This is very bad practice, and will cause failures if other USB serial devices are present at boot & device enumeration.
Because the fan serial device is on the USB-C bus - bus 3, device 3 - it will fall to be enumerated AFTER any other USB serial devices present, so will not be numbered as /dev/ttyUSB0, as the devices(s) on the lower buses will get that, so the drivers using the hard-coded /dev/ttyUSB0 device name will open the wrong device , thus breaking both the fan control and the other serial device.
Fix
The simplest fix for this is to use udev rules to cause creation of a symlink to the dynamically assigned /dev/ttyUSB?, and then use that instead of the hard-coded /dev/ttyUSB0.
To get udev to do this, a file /etc/udev/rules.d/20-serial.rules is created, containing:
SUBSYSTEM=="tty",ATTRS{idVendor}=="1a86",ATTRS{idProduct}=="7523",SYMLINK+="ttyFAN0"
(Note than this is a the simplest possible rule; if any other devices of the same vendor:product ID are also present, it will have to be more specific, eg identifying the bus & device, etc, to uniquely identify it, and prevent the same conflict problem happening).
This rule creates a device symlink /dev/ttyFAN0 (pointing to the dynamically assigned /dev/ttyUSB?) which the fan drivers can then safely open and use.
Other necessary changes to the C and Python code from the drivers directory are below, as a git diff:
Patch
The text was updated successfully, but these errors were encountered: