lkml.org 
[lkml]   [2020]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: weird cooling_device/cur_state sysfs behaviour
Indeed, many thanks for you help.

On Fri, Mar 20, 2020 at 09:17:47pm +0100, Daniel Lezcano wrote:
> Adding Rafael,
>
> On 20/03/2020 18:43, Daniel Lezcano wrote:
> > On 20/03/2020 16:10, Willy Wolff wrote:
> >> Hi all,
> >> Hope you're doing well with the situation.
> >>
> >> I fill that my board get a cold too...
> >>
> >> When I write to a sysfs node, I have a weird behaviour about the function that is called behind.
> >> This bug appears on an arm32 odroid-xu3, and only after v5.4, v5.3.18 behave correctly.
> >>
> >>
> >> Here my modification to see what's going on:
> >>
> >> diff --git a/drivers/thermal/thermal_sysfs.c b/drivers/thermal/thermal_sysfs.c
> >> index aa99edb4dff7..a437ae3f4b9f 100644
> >> --- a/drivers/thermal/thermal_sysfs.c
> >> +++ b/drivers/thermal/thermal_sysfs.c
> >> @@ -706,11 +706,22 @@ cur_state_store(struct device *dev, struct device_attribute *attr,
> >
> > [ ... ]
> >
> >> return result ? result : count;
> >> }
> >>
> >> +
> >
> > [ ... ]
> >
> >>
> >> As you can see, the function is recalled with one character less, until the "buffer is empty".
> >> I don't understand why. Can anybody help me for this thing?
> >> Many thanks in advance.
> >
> > [ ... ]
> >
> > Very likely the problem is coming from:
> >
> > result = cdev->ops->set_cur_state(cdev, state);
> >
> > which returns '1' as showed by the traces:
> >
> > drivers/thermal/thermal_sysfs.c:735:cur_state_store result = 1, count = 3
> >
> > And because of the return condition above:
> >
> > return result ? result : count;
> >
> > the function is returning result, so '1', which is interpreted by the
> > sysfs as "I wrote one character', so it recalls the function with the
> > two remaining characters, etc ...
> >
> > The problem is from the governor AFAICT, which governor is it?
>
> I went through the code and I believe the problem is coming from:
>
> cpufreq_set_cur_state
> -> freq_qos_update_request
> -> freq_qos_apply
> -> pm_qos_update_target =>
>
> " * This function returns 1 if the aggregated constraint value has changed,"
>
> freq_qos_apply() does:
>
> ret = pm_qos_update_target()
> ...
> return ret;
>
>
> At the first glance, it is related to commit 77751a466ebd1 (Nov 2019).
>
>
>
>
> --
> <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>

\
 
 \ /
  Last update: 2020-03-21 10:44    [W:0.024 / U:3.532 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site