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
| ||
|
Date: Wed, 13 Jul 2016 06:01:22 -0400 From: Prarit Bhargava <prarit@...hat.com> To: Kalle Valo <kvalo@...eaurora.org> CC: "Grumbach, Emmanuel" <emmanuel.grumbach@...el.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, linuxwifi <linuxwifi@...el.com>, "Coelho, Luciano" <luciano.coelho@...el.com>, "Berg, Johannes" <johannes.berg@...el.com>, "Ivgi, Chaya Rachel" <chaya.rachel.ivgi@...el.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "Sharon, Sara" <sara.sharon@...el.com>, "linux-wireless@...r.kernel.org" <linux-wireless@...r.kernel.org> Subject: Re: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded On 07/13/2016 02:50 AM, Kalle Valo wrote: > Prarit Bhargava <prarit@...hat.com> writes: > >>> We implement thermal zone because we do support it, but the problem is >>> that we need the firmware to be loaded for that. So you can argue that >>> we should register *later* when the firmware is loaded. But this is >>> really not helping all that much because the firmware can also be >>> stopped at any time. So you'd want us to register / unregister the >>> thermal zone anytime the firmware is loaded / unloaded? >> >> You might have to do that. I think that if the firmware enables a feature then >> the act of loading the firmware should run the code that enables the feature. >> IMO of course. > > But I suspect that the iwlwifi firmware is loaded during interface up > (and unloaded during interface down) and in that case > register/unregister would be happening all the time. You make it sound like the interface is coming and going a 1000 times a second. Maybe this happens once during runtime & during suspend/resume cycles? What about the cases when the firmware isn't present (and that's what lead me to this bug)? That doesn't sound > like a good idea. I would rather try to fix the thermal interface to > handle the cases when the measurement is not available. > Userspace is broken because of this change. I've had to make another horrible change to cpufreq for a similar change so I don't see the argument here to just blame userspace and ignore the outcome of the patch. P.
Powered by blists - more mailing lists