lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <NY750R.JRUHTBKNLH1F1@ljones.dev>
Date:   Wed, 29 Sep 2021 00:59:11 +1300
From:   Luke Jones <luke@...nes.dev>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Bastien Nocera <hadess@...ess.net>, linux-kernel@...r.kernel.org,
        pobrn@...tonmail.com, linux@...ck-us.net,
        platform-driver-x86@...r.kernel.org
Subject: Re: [PATCH v11] asus-wmi: Add support for custom fan curves



On Tue, Sep 28 2021 at 13:56:05 +0200, Hans de Goede 
<hdegoede@...hat.com> wrote:
> Hi,
> 
> On 9/28/21 1:43 PM, Luke Jones wrote:
>>  Sure, the path is similar to 
>> /sys/devices/platform/asus-nb-wmi/hwmon/hwmon4/pwm1_enable where 
>> hwmon4 will likely be different depending on init, and pwm2_enable 
>> is the second fan if it exists. The values are 1,2,3 - where 1 = fan 
>> curve enabled/manual, 2 = auto. 3 here is custom extra that writes 
>> default curve back then defaults to 2.
>> 
>>  As I understand it, this should be adhering to the accepted kernel 
>> standard, so if you use this for ASUS laptops, then it should carry 
>> over to other brands that implement it also.
> 
> Ah, so this is a bit different then how I thought this would work
> (this is probably better though).
> 
> <snip>
> 
>>>>   The fans have settings [1,2,3] under pwm<N>_enable:
>>>>   1. Enable and write settings out
>>>>   2. Disable and use factory fan mode
>>>>   3. Same as 2, additionally restoring default factory curve.
> 
> Quoting Documentation/hwmon/sysfs-interface.rst
> 
> `pwm[1-*]_enable`
>                 Fan speed control method:
> 
>                 - 0: no fan speed control (i.e. fan at full speed)
>                 - 1: manual fan speed control enabled (using 
> `pwm[1-*]`)
>                 - 2+: automatic fan speed control enabled
> 
> 1 normally means the fans runs at a fixed speed, but you are using it
> for the custom/manual profile, which is still a temp<->pwm table,
> right?
> 
> I guess this make sense since full manual control is not supported
> and this keeps "2" aka auto as being the normal factory auto
> setting which is good.
> 
> Bastien is this interface usable for p-p-d ?
> 
> I guess that it is a bit annoying that you need to figure out
> the # in the hwmon# part of the path, but there will be only
> one hwmon child.
> 
> You could also go through /sys/class/hwmon but then you really
> have no idea which one to use. Ideally we would have some way
> to indicate that there is a hmwon class-dev associated with
> /sys/firmware/acpi/platform_profile but as we mentioned before
> we should defer coming up with a generic solution for this
> until we have more then 1 user, so that we hopefully get the
> generic solution right in one go.

If it's at all helpful, I named the interface as 
"asus_custom_fan_curve". I use this to verify I have the correct hwmon 
for asusctl. Open to suggestions on that.

> 
> Regards,
> 
> Hans
> 
> 
> 
> 
> 
>>>> 
>>>>   Use of 2 means that the curve the user has set is still stored 
>>>> and
>>>>   won't be erased, but the laptop will be using its default 
>>>> auto-fan
>>>>   mode. Re-enabling the manual mode then activates the curves 
>>>> again.
>>>> 
>>>>   Notes:
>>>>   - pwm<N>_enable = 0 is an invalid setting.
>>>>   - pwm is actually a percentage and is scaled on writing to 
>>>> device.
>>> 
>>>  I was trying to update:
>>>  
>>> https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/merge_requests/80
>>>  but I don't understand what files I need to check for what values 
>>> to
>>>  detect whether custom fan curves were used.
>>> 
>>>  Can you help me out here?
>>> 
>>>  Also, was this patch accepted in the pdx86 tree?
>>> 
>>>  Cheers
>>> 
>> 
>> 
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ