linux-kernel - RE: intel_soc_dts_thermal binding issues

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]

Date:	Thu, 5 Mar 2015 01:55:45 +0000
From:	"Zhang, Rui" <rui.zhang@...el.com>
To:	Josh Boyer <jwboyer@...oraproject.org>,
	Eduardo Valentin <edubezval@...il.com>
CC:	Linux PM list <linux-pm@...r.kernel.org>,
	"Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>
Subject: RE: intel_soc_dts_thermal binding issues

What kernel are you using?
I think it should be fixed by commit 014d9d5d0cc1da79bbe48fbc5e1068c5616238d2, which is merged in 3.19-rc5.

Thanks,
rui

-----Original Message-----
From: jwboyer@...il.com [mailto:jwboyer@...il.com] On Behalf Of Josh Boyer
Sent: Wednesday, March 4, 2015 10:05 PM
To: Zhang, Rui; Eduardo Valentin
Cc: Linux PM list; Linux-Kernel@...r. Kernel. Org
Subject: intel_soc_dts_thermal binding issues
Importance: High

Hi All,

We've seen a number of reports where people see:

[   20.499427] intel_soc_dts_thermal: request_threaded_irq ret -22
[   20.519160] intel_soc_dts_thermal: request_threaded_irq ret -22
[   20.532660] intel_soc_dts_thermal: request_threaded_irq ret -22

in their boot logs.  They view this as a kernel bug and report is as such.  The above log came from an ASUS x200ma machine, which has a quad core Baytrail-M Pentium CPU (N3530).

I can't tell if the issue is because the driver is trying to bind to all 4 cores and only CPU0 works, or what other issue would cause this.
I personally have a Celeron based NUC with a N2820 that gets the error above for both cores and the driver doesn't load at all.

Is there something else the driver should be doing to bind to the various CPUs?  If there's nothing else it can key off of, can we drop the pr_err so it stops showing up in dmesg?

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/