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: <d6da5203-c113-5cec-c12e-9af91a9ff716@i2se.com>
Date:   Fri, 17 May 2019 14:25:24 +0200
From:   Stefan Wahren <stefan.wahren@...e.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Eduardo Valentin <edubezval@...il.com>,
        Guenter Roeck <linux@...ck-us.net>
Cc:     Rui Zhang <rui.zhang@...el.com>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1

On 16.05.19 18:11, Stefan Wahren wrote:
> Hi Linus,
>
> On 16.05.19 17:07, Linus Torvalds wrote:
>> On Wed, May 15, 2019 at 9:43 PM Eduardo Valentin <edubezval@...il.com> wrote:
>>> - thermal core has a new devm_* API for registering cooling devices, thanks to Guenter R.
>>>   I took the entire series, that is why you see changes on drivers/hwmon in this pull.
>> This clashed badly with commit 6b1ec4789fb1 ("hwmon: (pwm-fan) Add RPM
>> support via external interrupt"), which added a timer to the pwm-fan
>> handling.
>>
>> In particular, that timer now needed the same kind of cleanup changes,
>> and I'd like you guys (particularly Guenther, who was involved on both
>> sides) to double-check my merge.
>>
>> The way I solved it was to just make the pwm_fan_pwm_disable()
>> callback do both the pwm_diable() _and_ the del_timer_sync() on the
>> new timer. That seemed to be the simplest solution that meshed with
>> the new devm cleanup model, but while I build-tested the result, I
>> obviously did no actual use testing. And maybe there's some reason why
>> that approach is flawed.
> i will try to test on our custom i.MX6 board. Unfortunately this take
> some time since it isn't mainline yet (at least until tomorrow).

Okay, today's test based on your tree ( a6a4b66bd8f ) were successful.

Thanks
Stefan

>
> Stefan
>
>> Guenther?
>>
>>                     Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ