I don’t think they will approve the pwm-mediatek.c patch, since it removes support for all the other mediatek PWM devices. I do have one for the 6.6 kernel, that they might approve though.
just bring the pwm driver to mainline-state (6.8) and add the enabling in board dts…i wait for my r4 fan i ordered on aliexpress
What do you mean with mainline-state (6.8)? Do you know how I can submit patches to OpenWrt?
Thank you for making me smile 
.
https://wiki.fw-web.de/doku.php?id=en:start
I found that very strange (in a nice way), that you found out, how to get the PWM fan run and how to make your own image. And than this question 
.
The reason why I found out how to do that myself is because I used to work with modifying drivers and hardware for a part of the Norwegian government, so I know how to debug, read and modify code - but not how to write for example new drivers, and how to submit patches, since everything I did was kept and used internally in the county.
Current linux version is 6.8 (or 6.9-rcX):
Took me 10 seconds: [OpenWrt Wiki] Submitting patches
I’m not familar with openwrt build/patch system,but you should orient on mainline…either adding all parches done on mainline (git log v6.1…v6.8 – drivers/pwm/pwm-mediatek.c) or just add the file itself.
Btw. My moderator state is unrelated to this
The best practice would be to first submit the needed changes to mainline Linux and then backport them to OpenWrt Linux 6.1 and Linux 6.6. Backporting should be done by exporting the relevant commits from mainline Linux using git format-patch ... and adding them as patches to OpenWrt in target/linux/mediatek/patches-*. Patches should be named having the first Linux release they are part of in their filename – that makes future maintenance much easier as we will know when to remove them.
Adding the file itself (ie. overwriting the existing file from Linux) or doing a single dirty patch just bringing the driver to the same level as in Linux git HEAD is not acceptable.
2 Likes
Hi,
many thanks, I just installed your version and I can confirm my pwm fan works: now I must to learn how to set trip points.
1 Like
@Alexago, a quick tldr:
https://www.kernel.org/doc/Documentation/thermal/sysfs-api.txt
cat /sys/class/thermal/thermal_zone0/temp # read current temp
42678
Thermal zone types:
cat /sys/class/thermal/thermal_zone0/trip_point_0_type
critical
cat /sys/class/thermal/thermal_zone0/trip_point_1_type
hot
cat /sys/class/thermal/thermal_zone0/trip_point_2_type
active
cat /sys/class/thermal/thermal_zone0/trip_point_3_type
active
cat /sys/class/thermal/thermal_zone0/trip_point_4_type
active
Stock settings (currently):
cat /sys/class/thermal/thermal_zone0/trip_point_0_temp
125000
cat /sys/class/thermal/thermal_zone0/trip_point_1_temp
120000
cat /sys/class/thermal/thermal_zone0/trip_point_2_temp
115000
cat /sys/class/thermal/thermal_zone0/trip_point_3_temp
85000
cat /sys/class/thermal/thermal_zone0/trip_point_4_temp
40000
Updating:
echo 40000 > /sys/class/thermal/thermal_zone0/trip_point_1_temp # override
echo 120000 > /sys/class/thermal/thermal_zone0/trip_point_1_temp # set to default
echo 35000 > /sys/class/thermal/thermal_zone0/trip_point_2_temp # override
echo 115000 > /sys/class/thermal/thermal_zone0/trip_point_2_temp # set to default
echo 32000 > /sys/class/thermal/thermal_zone0/trip_point_3_temp # override
echo 85000 > /sys/class/thermal/thermal_zone0/trip_point_3_temp # set to default
echo 30000 > /sys/class/thermal/thermal_zone0/trip_point_4_temp # override
echo 40000 > /sys/class/thermal/thermal_zone0/trip_point_4_temp # set to default
I’ve heard that overriding the values via echoing to the sysfs path will persist on reboot, but have not confirmed; it may need to be set via an rc.local or sysctl.conf manner
1 Like
No, that is not true (at least not on this board).
Sorry for just disappearing / not answering.
My grandmother has gotten bowel cancer and is going into surgery tomorrow, so I have helped her a lot and haven’t had time to write here.
I don’t have time to try to submit patches to either the kernel or OpenWrt for the next few weeks either - can someone else here please do it for me ? 
I’m sorry to hear that. Unfortunately I also don’t have much time right now to pick up your work. Anyone?
1 Like
Thank you for your Work!
Don’t care about the project so much, care about your grandmother 
.
1 Like
I believe this is not a 3-PIN PWM fan. The third pin from the fan is output to the host for reporting fan speed.
Do you have a way to measure PWM signal? If so, do you get pulses from the 3rd PIN of this fan in your experiment? I would like some assurance that this fan is indeed a 3-pin PWM fan…lol
Update
@Hypnotize confirms the fan is indeed PWM fan in this post
I want to have this question also in this chat:
I think it is really important that Frank and/or dangowrt gets your code into the actual Openwrt snapshot. I was really happy to hear about your progress. Some people will not find this chat, this is why it is so important to get it into the snapshot!
How I can update kernel on this one to 6.1.8 ? Because :
Version: 6.1.86-r1
Size: ~180.00 KiB installed
Dependencies:
kernel VERSION INCOMPATIBLE
kmod-hwmon-core INSTALLED
Description
Kernel module for NVM Express solid state drives directly connected to the PCI or PCI Express bus.
The installed version of package kernel is not compatible, require 6.1.86~0dc73eff…-r1 while 6.1.82~c31a377a…-r1 is installed.
I guess you use openwrt snapshot,right? Please make own topic as this is for bpi-r4 fan setup,not nvme.
I’m using compiled image from Hypnotize. So exactly with PWM fan patch. But if I want keep this build and add as example nvme, I cannot due to compatibility.
Independ from this it is unrelated to cpu fan setup…you can link to the image and maybe hypnotize build an image to include the nvme part or upgrade to actual openwrt where you maybe can install additional packages