Properly map fan speed against gpios

[thatguyatgithub]

It appears that fan speed is mapped on a reverse order. This also affects pwm'ing, since the logic is inverted and a pwm of 0 is full speed and 255 fan off.

As a consequence, fancontrol does not work either.

I've tested this on a LS-WVL and works as expected:

  hwmon1/fan1_input ... speed was 5000 now 0
    It appears that fan hwmon1/fan1_input
    is controlled by pwm hwmon1/pwm1
Would you like to generate a detailed correlation (y)? 
    PWM 255 FAN 5000
    PWM 240 FAN 5000
    PWM 225 FAN 5000
    PWM 210 FAN 5000
    PWM 195 FAN 5000
    PWM 180 FAN 5000
    PWM 165 FAN 3250
    PWM 150 FAN 3250
    PWM 135 FAN 3250
    PWM 120 FAN 3250
    PWM 105 FAN 3250
    PWM 90 FAN 3250
    PWM 75 FAN 1500
    PWM 60 FAN 1500
    PWM 45 FAN 1500
    PWM 30 FAN 1500
    PWM 28 FAN 1500
    PWM 26 FAN 1500
    PWM 24 FAN 1500
    PWM 22 FAN 1500
    PWM 20 FAN 1500
    PWM 18 FAN 1500
    PWM 16 FAN 1500
    PWM 14 FAN 1500
    PWM 12 FAN 1500
    PWM 10 FAN 1500
    PWM 8 FAN 1500
    PWM 6 FAN 1500
    PWM 4 FAN 1500
    PWM 2 FAN 1500
    PWM 0 FAN 0
    Fan Stopped at PWM = 0

Testing is complete.```

[val-kulkov]

Fan GPIO controls used to work properly until late 2018 or early 2019. I am not sure what triggered the regression because apparently no changes were made to LinkStation DTS files during that period of time.

I first ran into the reverse order issue after upgrading my LS-WVL to the latest trunk version in March 2019. That upgrade broke the fan-control script. Since then I wrote a new script for monitoring disk temperature and controlling fan speed. I am willing to share my new script, but not as a new PR, because applying this PR would probably be a more straightforward way to solve the issue. IMO there is no need to create another PR.

[1000001101000]

I ran into the same thing for the armada-370 linkstations at about the same time. I think something might have changed in the driver/binding. I ended up dealing with it by just reversing them in my DTS files. I never got around to digging into what actually changed as it was one of a handful of bugs I was dealing with at the time.

If this affecting the kirkwood devices we should probably submit a PR to the kernel fixing the device trees, probably after figuring out what changed and why there weren't changes to all the other devices too (unless there have been since I last looked)

[val-kulkov]

@1000001101000 : good, so I am not alone then. I tried looking into the kernel code to see if I can identify the change the triggered the reverse order, and came to the conclusion that it would take me more time than I can possibly afford. So, unfortunately, I have given up for now.

[1000001101000]

you could always reverse them for your own dtb. on a long enough timeline I will probably fix this though when or how I don't really know. lately I've been working on adding support for devices that weren't covered by this project, eventually I may get around to making some updates to these as well.

[1000001101000]

I researched this a little further and discovered that up till a certain version the kernel driver assumed all fan GPIOs were ACTIVE-HIGH regardless of what the device tree set. Unfortunately it seems most of the Buffalo Devices had them set as ACTIVE-LOW in the device trees even though they should be ACTIVE-HIGH.

I went ahead and generated corrected trees for most affected buffalo devices, they can be found here: https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Buster