netdev - Re: [RFC 0/8] Stop monitoring disabled devices

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: <aeec2ce8-8fb9-9353-f3dd-36a476ceeb3b@collabora.com>
Date:   Thu, 9 Apr 2020 13:10:01 +0200
From:   Andrzej Pietrasiewicz <andrzej.p@...labora.com>
To:     Daniel Lezcano <daniel.lezcano@...aro.org>,
        linux-pm@...r.kernel.org
Cc:     Zhang Rui <rui.zhang@...el.com>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>, Jiri Pirko <jiri@...lanox.com>,
        Ido Schimmel <idosch@...lanox.com>,
        "David S . Miller" <davem@...emloft.net>,
        Peter Kaestle <peter@...e.net>,
        Darren Hart <dvhart@...radead.org>,
        Andy Shevchenko <andy@...radead.org>,
        Support Opensource <support.opensource@...semi.com>,
        Amit Kucheria <amit.kucheria@...durent.com>,
        Shawn Guo <shawnguo@...nel.org>,
        Sascha Hauer <s.hauer@...gutronix.de>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        Fabio Estevam <festevam@...il.com>,
        NXP Linux Team <linux-imx@....com>,
        Allison Randal <allison@...utok.net>,
        Enrico Weigelt <info@...ux.net>,
        Gayatri Kammela <gayatri.kammela@...el.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-acpi@...r.kernel.org, netdev@...r.kernel.org,
        platform-driver-x86@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: [RFC 0/8] Stop monitoring disabled devices

Hi Daniel,

W dniu 09.04.2020 o 12:29, Daniel Lezcano pisze:
> On 07/04/2020 19:49, Andrzej Pietrasiewicz wrote:
>> The current kernel behavior is to keep polling the thermal zone devices
>> regardless of their current mode. This is not desired, as all such "disabled"
>> devices are meant to be handled by userspace,> so polling them makes no sense.
> 
> Thanks for proposing these changes.
> 
> I've been (quickly) through the series and the description below. I have
> the feeling the series makes more complex while the current code which
> would deserve a cleanup.
> 
> Why not first:
> 
>   - Add a 'mode' field in the thermal zone device
>   - Kill all set/get_mode callbacks in the drivers which are duplicated code.
>   - Add a function:
> 
>   enum thermal_device_mode thermal_zone_get_mode( *tz)
>   {
> 	...
> 	if (tz->ops->get_mode)
> 		return tz->ops->get_mode();
> 
> 	return tz->mode;
>   }
> 
> 
>   int thermal_zone_set_mode(..*tz, enum thermal_device_mode mode)
>   {
> 	...
> 	if (tz->ops->set_mode)
> 		return tz->ops->set_mode(tz, mode);
> 
> 	tz->mode = mode;
> 
> 	return 0;
>   }
> 
>   static inline thermal_zone_enable(... *tz)
>   {
> 	thermal_zone_set_mode(tz, THERMAL_DEVICE_ENABLED);
>   }
> 
>   static inline thermal_zone_disable(... *tz) {
> 	thermal_zone_set_mode(tz, THERMAL_DEVICE_DISABLED);
>   }
> 
> And then when the code is consolidated, use the mode to enable/disable
> the polling and continue killing the duplicated code in of-thermal.c and
> anywhere else.
> 
> 

Thanks for feedback.

Anyone else?

Andrzej