Open iainaff opened 2 years ago
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 ttyDPIFAN0
so it's very clear on which fan we're dealing with.
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)...
Please check out /boot/config.txt file
Can not access /dev/ttyUSB0, please check it out.
serial port can not be accessed
Though the solution provided here seems more robust I solved the /dev/ttyUSB0 issue by just getting rid of brltty...
# systemctl stop brltty-udev.service
# systemctl mask brltty-udev.service
# systemctl stop brltty.service
# systemctl disable brltty.service
# apt purge brltty # uninstalled it in the end
The fan is working now.
With your description I was able to solve the fan problem when connecting another device to ttyUSB0. Unfortunately, however, shutdown -h now
does not work. I have also done changes in /drivers/c/safecutoffpower.c
and /drivers/python/safecutoffpower.py
Does that work for you?
My DeskPi hosts RPI 4 running 64-bit Raspberry Pi OS. I have tested install.sh and install-raspbios-64bit.sh
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)...
Please check out /boot/config.txt file Can not access /dev/ttyUSB0, please check it out. serial port can not be accessed
Though the solution provided here seems more robust I solved the /dev/ttyUSB0 issue by just getting rid of brltty...
# systemctl stop brltty-udev.service # systemctl mask brltty-udev.service # systemctl stop brltty.service # systemctl disable brltty.service # apt purge brltty # uninstalled it in the end
The fan is working now.
This method is good for the OS which can not generate /dev/ttyUSB0 device file, due to this file is generated by this overlay: dtoverlay=dwc2,dr_mode=host, and it will detect the MCU's serial port ,but brltty service will occupy this device file name, so that this is best solution for this issue.
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