<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/base, branch linux-4.5.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>PM / sleep: Handle failures in device_suspend_late() consistently</title>
<updated>2016-06-08T01:18:53+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2016-05-20T21:09:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0c42f6c9199233f3947d531df81fc44574ace18e'/>
<id>0c42f6c9199233f3947d531df81fc44574ace18e</id>
<content type='text'>
commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream.

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Tested-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 3a17fb329da68cb00558721aff876a80bba2fdb9 upstream.

Grygorii Strashko reports:

 The PM runtime will be left disabled for the device if its
 .suspend_late() callback fails and async suspend is not allowed
 for this device. In this case device will not be added in
 dpm_late_early_list and dpm_resume_early() will ignore this
 device, as result PM runtime will be disabled for it forever
 (side effect: after 8 subsequent failures for the same device
 the PM runtime will be reenabled due to disable_depth overflow).

To fix this problem, add devices to dpm_late_early_list regardless
of whether or not device_suspend_late() returns errors for them.

That will ensure failures in there to be handled consistently for
all devices regardless of their async suspend/resume status.

Reported-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Tested-by: Grygorii Strashko &lt;grygorii.strashko@ti.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PM / Runtime: Fix error path in pm_runtime_force_resume()</title>
<updated>2016-06-08T01:18:49+00:00</updated>
<author>
<name>Ulf Hansson</name>
<email>ulf.hansson@linaro.org</email>
</author>
<published>2016-04-08T11:10:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=90af331d8f16f9749664760b836fb1b9317eb408'/>
<id>90af331d8f16f9749664760b836fb1b9317eb408</id>
<content type='text'>
commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f upstream.

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the -&gt;runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 0ae3aeefabbeef26294e7a349b51f1c761d46c9f upstream.

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the -&gt;runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>regmap: spmi: Fix regmap_spmi_ext_read in multi-byte case</title>
<updated>2016-05-19T01:35:11+00:00</updated>
<author>
<name>Jack Pham</name>
<email>jackp@codeaurora.org</email>
</author>
<published>2016-04-15T06:37:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d764263450e64f2dddb07afda47c54238fdc491d'/>
<id>d764263450e64f2dddb07afda47c54238fdc491d</id>
<content type='text'>
commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 upstream.

Specifically for the case of reads that use the Extended Register
Read Long command, a multi-byte read operation is broken up into
8-byte chunks.  However the call to spmi_ext_register_readl() is
incorrectly passing 'val_size', which if greater than 8 will
always fail.  The argument should instead be 'len'.

Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces")
Signed-off-by: Jack Pham &lt;jackp@codeaurora.org&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit dec8e8f6e6504aa3496c0f7cc10c756bb0e10f44 upstream.

Specifically for the case of reads that use the Extended Register
Read Long command, a multi-byte read operation is broken up into
8-byte chunks.  However the call to spmi_ext_register_readl() is
incorrectly passing 'val_size', which if greater than 8 will
always fail.  The argument should instead be 'len'.

Fixes: c9afbb05a9ff ("regmap: spmi: support base and extended register spaces")
Signed-off-by: Jack Pham &lt;jackp@codeaurora.org&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PM / Domains: Fix removal of a subdomain</title>
<updated>2016-05-04T21:49:11+00:00</updated>
<author>
<name>Jon Hunter</name>
<email>jonathanh@nvidia.com</email>
</author>
<published>2016-03-04T10:55:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=074b8d8788e1ffa41e1517e79f7fc192c2966f02'/>
<id>074b8d8788e1ffa41e1517e79f7fc192c2966f02</id>
<content type='text'>
commit beda5fc1ff9b527059290a97b672d2ee0eb7b92f upstream.

Commit 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use
before removing) added a test to ensure that a subdomain is not a
master to another subdomain or if any devices are using the subdomain
before removing. This change incorrectly used the "slave_links" list to
determine if the subdomain is a master to another subdomain, where it
should have been using the "master_links" list instead. The
"slave_links" list will never be empty for a subdomain and so a
subdomain can never be removed. Fix this by testing if the
"master_links" list is empty instead.

Fixes: 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use before removing)
Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Thierry Reding &lt;treding@nvidia.com&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Acked-by: Kevin Hilman &lt;khilman@baylibre.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit beda5fc1ff9b527059290a97b672d2ee0eb7b92f upstream.

Commit 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use
before removing) added a test to ensure that a subdomain is not a
master to another subdomain or if any devices are using the subdomain
before removing. This change incorrectly used the "slave_links" list to
determine if the subdomain is a master to another subdomain, where it
should have been using the "master_links" list instead. The
"slave_links" list will never be empty for a subdomain and so a
subdomain can never be removed. Fix this by testing if the
"master_links" list is empty instead.

Fixes: 30e7a65b3fdb (PM / Domains: Ensure subdomain is not in use before removing)
Signed-off-by: Jon Hunter &lt;jonathanh@nvidia.com&gt;
Reviewed-by: Thierry Reding &lt;treding@nvidia.com&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Acked-by: Kevin Hilman &lt;khilman@baylibre.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>PM / OPP: Initialize u_volt_min/max to a valid value</title>
<updated>2016-05-04T21:49:11+00:00</updated>
<author>
<name>Viresh Kumar</name>
<email>viresh.kumar@linaro.org</email>
</author>
<published>2016-02-15T04:51:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0ea539773e0169e14a4209d48fcb1a6a67519d6d'/>
<id>0ea539773e0169e14a4209d48fcb1a6a67519d6d</id>
<content type='text'>
commit c88c395f4a6485f23f81e385c79945d68bcd5c5d upstream.

We kept u_volt_min/max initialized to 0, when only the target voltage is
present in DT, instead of the target/min/max triplet.

This didn't go well with the regulator framework, as on few calls the
min voltage was set to target and max was set to 0 and so resulted in a
kernel crash like below:

kernel BUG at ../drivers/regulator/core.c:216!

[&lt;c0684af4&gt;] (regulator_check_voltage) from [&lt;c06857ac&gt;] (regulator_set_voltage_unlocked+0x58/0x230)
[&lt;c06857ac&gt;] (regulator_set_voltage_unlocked) from [&lt;c06859ac&gt;] (regulator_set_voltage+0x28/0x54)
[&lt;c06859ac&gt;] (regulator_set_voltage) from [&lt;c0775b28&gt;] (_set_opp_voltage+0x30/0x98)
[&lt;c0775b28&gt;] (_set_opp_voltage) from [&lt;c0776630&gt;] (dev_pm_opp_set_rate+0xf0/0x28c)
[&lt;c0776630&gt;] (dev_pm_opp_set_rate) from [&lt;c096f784&gt;] (__cpufreq_driver_target+0x184/0x2b4)
[&lt;c096f784&gt;] (__cpufreq_driver_target) from [&lt;c0973760&gt;] (dbs_check_cpu+0x1b0/0x1f4)
[&lt;c0973760&gt;] (dbs_check_cpu) from [&lt;c0973f30&gt;] (cpufreq_governor_dbs+0x324/0x5c4)
[&lt;c0973f30&gt;] (cpufreq_governor_dbs) from [&lt;c0970958&gt;] (__cpufreq_governor+0xe4/0x1ec)
[&lt;c0970958&gt;] (__cpufreq_governor) from [&lt;c09711e0&gt;] (cpufreq_init_policy+0x64/0x8c)
[&lt;c09711e0&gt;] (cpufreq_init_policy) from [&lt;c09718cc&gt;] (cpufreq_online+0x2fc/0x708)
[&lt;c09718cc&gt;] (cpufreq_online) from [&lt;c0765ff0&gt;] (subsys_interface_register+0x94/0xd8)
[&lt;c0765ff0&gt;] (subsys_interface_register) from [&lt;c0970530&gt;] (cpufreq_register_driver+0x14c/0x19c)
[&lt;c0970530&gt;] (cpufreq_register_driver) from [&lt;c09746dc&gt;] (dt_cpufreq_probe+0x70/0xec)
[&lt;c09746dc&gt;] (dt_cpufreq_probe) from [&lt;c076907c&gt;] (platform_drv_probe+0x4c/0xb0)
[&lt;c076907c&gt;] (platform_drv_probe) from [&lt;c07678e0&gt;] (driver_probe_device+0x214/0x2c0)
[&lt;c07678e0&gt;] (driver_probe_device) from [&lt;c0767a18&gt;] (__driver_attach+0x8c/0x90)
[&lt;c0767a18&gt;] (__driver_attach) from [&lt;c0765c2c&gt;] (bus_for_each_dev+0x68/0x9c)
[&lt;c0765c2c&gt;] (bus_for_each_dev) from [&lt;c0766d78&gt;] (bus_add_driver+0x1a0/0x218)
[&lt;c0766d78&gt;] (bus_add_driver) from [&lt;c076810c&gt;] (driver_register+0x78/0xf8)
[&lt;c076810c&gt;] (driver_register) from [&lt;c0301d74&gt;] (do_one_initcall+0x90/0x1d8)
[&lt;c0301d74&gt;] (do_one_initcall) from [&lt;c1100e14&gt;] (kernel_init_freeable+0x15c/0x1fc)
[&lt;c1100e14&gt;] (kernel_init_freeable) from [&lt;c0b27a0c&gt;] (kernel_init+0x8/0xf0)
[&lt;c0b27a0c&gt;] (kernel_init) from [&lt;c0307d78&gt;] (ret_from_fork+0x14/0x3c)
Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2)

Fix that by initializing u_volt_min/max to the target voltage in such cases.

Reported-and-tested-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings)
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit c88c395f4a6485f23f81e385c79945d68bcd5c5d upstream.

We kept u_volt_min/max initialized to 0, when only the target voltage is
present in DT, instead of the target/min/max triplet.

This didn't go well with the regulator framework, as on few calls the
min voltage was set to target and max was set to 0 and so resulted in a
kernel crash like below:

kernel BUG at ../drivers/regulator/core.c:216!

[&lt;c0684af4&gt;] (regulator_check_voltage) from [&lt;c06857ac&gt;] (regulator_set_voltage_unlocked+0x58/0x230)
[&lt;c06857ac&gt;] (regulator_set_voltage_unlocked) from [&lt;c06859ac&gt;] (regulator_set_voltage+0x28/0x54)
[&lt;c06859ac&gt;] (regulator_set_voltage) from [&lt;c0775b28&gt;] (_set_opp_voltage+0x30/0x98)
[&lt;c0775b28&gt;] (_set_opp_voltage) from [&lt;c0776630&gt;] (dev_pm_opp_set_rate+0xf0/0x28c)
[&lt;c0776630&gt;] (dev_pm_opp_set_rate) from [&lt;c096f784&gt;] (__cpufreq_driver_target+0x184/0x2b4)
[&lt;c096f784&gt;] (__cpufreq_driver_target) from [&lt;c0973760&gt;] (dbs_check_cpu+0x1b0/0x1f4)
[&lt;c0973760&gt;] (dbs_check_cpu) from [&lt;c0973f30&gt;] (cpufreq_governor_dbs+0x324/0x5c4)
[&lt;c0973f30&gt;] (cpufreq_governor_dbs) from [&lt;c0970958&gt;] (__cpufreq_governor+0xe4/0x1ec)
[&lt;c0970958&gt;] (__cpufreq_governor) from [&lt;c09711e0&gt;] (cpufreq_init_policy+0x64/0x8c)
[&lt;c09711e0&gt;] (cpufreq_init_policy) from [&lt;c09718cc&gt;] (cpufreq_online+0x2fc/0x708)
[&lt;c09718cc&gt;] (cpufreq_online) from [&lt;c0765ff0&gt;] (subsys_interface_register+0x94/0xd8)
[&lt;c0765ff0&gt;] (subsys_interface_register) from [&lt;c0970530&gt;] (cpufreq_register_driver+0x14c/0x19c)
[&lt;c0970530&gt;] (cpufreq_register_driver) from [&lt;c09746dc&gt;] (dt_cpufreq_probe+0x70/0xec)
[&lt;c09746dc&gt;] (dt_cpufreq_probe) from [&lt;c076907c&gt;] (platform_drv_probe+0x4c/0xb0)
[&lt;c076907c&gt;] (platform_drv_probe) from [&lt;c07678e0&gt;] (driver_probe_device+0x214/0x2c0)
[&lt;c07678e0&gt;] (driver_probe_device) from [&lt;c0767a18&gt;] (__driver_attach+0x8c/0x90)
[&lt;c0767a18&gt;] (__driver_attach) from [&lt;c0765c2c&gt;] (bus_for_each_dev+0x68/0x9c)
[&lt;c0765c2c&gt;] (bus_for_each_dev) from [&lt;c0766d78&gt;] (bus_add_driver+0x1a0/0x218)
[&lt;c0766d78&gt;] (bus_add_driver) from [&lt;c076810c&gt;] (driver_register+0x78/0xf8)
[&lt;c076810c&gt;] (driver_register) from [&lt;c0301d74&gt;] (do_one_initcall+0x90/0x1d8)
[&lt;c0301d74&gt;] (do_one_initcall) from [&lt;c1100e14&gt;] (kernel_init_freeable+0x15c/0x1fc)
[&lt;c1100e14&gt;] (kernel_init_freeable) from [&lt;c0b27a0c&gt;] (kernel_init+0x8/0xf0)
[&lt;c0b27a0c&gt;] (kernel_init) from [&lt;c0307d78&gt;] (ret_from_fork+0x14/0x3c)
Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2)

Fix that by initializing u_volt_min/max to the target voltage in such cases.

Reported-and-tested-by: Krzysztof Kozlowski &lt;k.kozlowski@samsung.com&gt;
Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings)
Signed-off-by: Viresh Kumar &lt;viresh.kumar@linaro.org&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>device property: fwnode-&gt;secondary may contain ERR_PTR(-ENODEV)</title>
<updated>2016-03-09T00:07:43+00:00</updated>
<author>
<name>Heikki Krogerus</name>
<email>heikki.krogerus@linux.intel.com</email>
</author>
<published>2016-03-08T13:44:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7781203416ffc4e731619f8a8b93a37599a8f502'/>
<id>7781203416ffc4e731619f8a8b93a37599a8f502</id>
<content type='text'>
This fixes BUG triggered when fwnode-&gt;secondary is not NULL,
but has ERR_PTR(-ENODEV) instead.

BUG: unable to handle kernel paging request at ffffffffffffffed
IP: [&lt;ffffffff81677b86&gt;] __fwnode_property_read_string+0x26/0x160
PGD 200e067 PUD 2010067 PMD 0
Oops: 0000 [#1] SMP KASAN
Modules linked in: dwc3_pci(+) dwc3
CPU: 0 PID: 1138 Comm: modprobe Not tainted 4.5.0-rc5+ #61
task: ffff88015aaf5b00 ti: ffff88007b958000 task.ti: ffff88007b958000
RIP: 0010:[&lt;ffffffff81677b86&gt;]  [&lt;ffffffff81677b86&gt;] __fwnode_property_read_string+0x26/0x160
RSP: 0018:ffff88007b95eff8  EFLAGS: 00010246
RAX: fffffbfffffffffd RBX: ffffffffffffffed RCX: ffff88015999cd37
RDX: dffffc0000000000 RSI: ffffffff81e11bc0 RDI: ffffffffffffffed
RBP: ffff88007b95f020 R08: 0000000000000000 R09: 0000000000000000
R10: ffff88007b90f7cf R11: 0000000000000000 R12: ffff88007b95f0a0
R13: 00000000fffffffa R14: ffffffff81e11bc0 R15: ffff880159ea37a0
FS:  00007ff35f46c700(0000) GS:ffff88015b800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffffffffffed CR3: 000000007b8be000 CR4: 00000000001006f0
Stack:
 ffff88015999cd20 ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b383dd8
 ffff880159ea37a0 ffff88007b95f048 ffffffff81677d03 ffff88007b952460
 ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b95f070 ffffffff81677d40
Call Trace:
 [&lt;ffffffff81677d03&gt;] fwnode_property_read_string+0x43/0x50
 [&lt;ffffffff81677d40&gt;] device_property_read_string+0x30/0x40
...

Fixes: 362c0b30249e (device property: Fallback to secondary fwnode if primary misses the property)
Signed-off-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This fixes BUG triggered when fwnode-&gt;secondary is not NULL,
but has ERR_PTR(-ENODEV) instead.

BUG: unable to handle kernel paging request at ffffffffffffffed
IP: [&lt;ffffffff81677b86&gt;] __fwnode_property_read_string+0x26/0x160
PGD 200e067 PUD 2010067 PMD 0
Oops: 0000 [#1] SMP KASAN
Modules linked in: dwc3_pci(+) dwc3
CPU: 0 PID: 1138 Comm: modprobe Not tainted 4.5.0-rc5+ #61
task: ffff88015aaf5b00 ti: ffff88007b958000 task.ti: ffff88007b958000
RIP: 0010:[&lt;ffffffff81677b86&gt;]  [&lt;ffffffff81677b86&gt;] __fwnode_property_read_string+0x26/0x160
RSP: 0018:ffff88007b95eff8  EFLAGS: 00010246
RAX: fffffbfffffffffd RBX: ffffffffffffffed RCX: ffff88015999cd37
RDX: dffffc0000000000 RSI: ffffffff81e11bc0 RDI: ffffffffffffffed
RBP: ffff88007b95f020 R08: 0000000000000000 R09: 0000000000000000
R10: ffff88007b90f7cf R11: 0000000000000000 R12: ffff88007b95f0a0
R13: 00000000fffffffa R14: ffffffff81e11bc0 R15: ffff880159ea37a0
FS:  00007ff35f46c700(0000) GS:ffff88015b800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffffffffffed CR3: 000000007b8be000 CR4: 00000000001006f0
Stack:
 ffff88015999cd20 ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b383dd8
 ffff880159ea37a0 ffff88007b95f048 ffffffff81677d03 ffff88007b952460
 ffffffff81e11bc0 ffff88007b95f0a0 ffff88007b95f070 ffffffff81677d40
Call Trace:
 [&lt;ffffffff81677d03&gt;] fwnode_property_read_string+0x43/0x50
 [&lt;ffffffff81677d40&gt;] device_property_read_string+0x30/0x40
...

Fixes: 362c0b30249e (device property: Fallback to secondary fwnode if primary misses the property)
Signed-off-by: Heikki Krogerus &lt;heikki.krogerus@linux.intel.com&gt;
Signed-off-by: Rafael J. Wysocki &lt;rafael.j.wysocki@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'component' of git://ftp.arm.linux.org.uk/~rmk/linux-arm</title>
<updated>2016-02-14T18:40:21+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-02-14T18:40:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8b9f9ebe07f4ff1340f44e40aa7ce517d55e1882'/>
<id>8b9f9ebe07f4ff1340f44e40aa7ce517d55e1882</id>
<content type='text'>
Pull component helper fixes from Russell King:
 "A few fixes for problems people have encountered with the recent
  update to the component helpers"

* 'component' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  component: remove device from master match list on failed add
  component: Detach components when deleting master struct
  component: fix crash on x86_64 with hda audio drivers
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull component helper fixes from Russell King:
 "A few fixes for problems people have encountered with the recent
  update to the component helpers"

* 'component' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  component: remove device from master match list on failed add
  component: Detach components when deleting master struct
  component: fix crash on x86_64 with hda audio drivers
</pre>
</div>
</content>
</entry>
<entry>
<title>component: remove device from master match list on failed add</title>
<updated>2016-02-11T09:42:09+00:00</updated>
<author>
<name>Daniel Stone</name>
<email>daniels@collabora.com</email>
</author>
<published>2016-02-08T21:12:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8e7199c2c50fff1969302643171eaa33f1ca148f'/>
<id>8e7199c2c50fff1969302643171eaa33f1ca148f</id>
<content type='text'>
Calling component_add() may result in the completion of a set of
devices, which will try to bring up a master. In bringing the master
up, we populate its match array with the current set of children.

If binding any of the devices fails, component_add() itself will fail,
free the struct component entry, and return to the caller. The
now-freed entry is never removed from the master's match array, and
will later be used in a futile attempt to bind to freed memory.

Bring component_add's behaviour on failure to bring up a master into
line with component_del by removing the (to-be-freed) component from
the master's match array.

The specific case which broke was:
  - rockchip_drm_drv adds a component master
  - dwhdmi_rockchip adds a child component in probe (master incomplete)
  - rockchip_drm_vop adds two children in probe, which completes the
    set
  - inside component_add, we try to bring up the master, having
    populated the master's match array, and fail with EPROBE_DEFER from
    dwhdmi_rockchip; we delete the putative component
  - rockchip_drm_vop's probe fails and returns EPROBE_DEFER
  - we later re-probe rockchip_drm_vop and add the component; the
    master is complete, so we attempt to bring it up again
  - walking the match array, we find the previous child, whose master
    pointer doesn't match (as it has been freed in the meantime)
  - rockchip_drm_vop probe fails, and will never be attempted again

Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
Signed-off-by: Daniel Stone &lt;daniels@collabora.com&gt;
Cc: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Cc: Thierry Reding &lt;treding@nvidia.com&gt;
Cc: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Calling component_add() may result in the completion of a set of
devices, which will try to bring up a master. In bringing the master
up, we populate its match array with the current set of children.

If binding any of the devices fails, component_add() itself will fail,
free the struct component entry, and return to the caller. The
now-freed entry is never removed from the master's match array, and
will later be used in a futile attempt to bind to freed memory.

Bring component_add's behaviour on failure to bring up a master into
line with component_del by removing the (to-be-freed) component from
the master's match array.

The specific case which broke was:
  - rockchip_drm_drv adds a component master
  - dwhdmi_rockchip adds a child component in probe (master incomplete)
  - rockchip_drm_vop adds two children in probe, which completes the
    set
  - inside component_add, we try to bring up the master, having
    populated the master's match array, and fail with EPROBE_DEFER from
    dwhdmi_rockchip; we delete the putative component
  - rockchip_drm_vop's probe fails and returns EPROBE_DEFER
  - we later re-probe rockchip_drm_vop and add the component; the
    master is complete, so we attempt to bring it up again
  - walking the match array, we find the previous child, whose master
    pointer doesn't match (as it has been freed in the meantime)
  - rockchip_drm_vop probe fails, and will never be attempted again

Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8
Signed-off-by: Daniel Stone &lt;daniels@collabora.com&gt;
Cc: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Cc: Thierry Reding &lt;treding@nvidia.com&gt;
Cc: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'regmap-fix-v4.5-big-endian' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap</title>
<updated>2016-02-08T18:20:06+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2016-02-08T18:20:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=92e6edd685a83f8fa922f3274c362a583deea784'/>
<id>92e6edd685a83f8fa922f3274c362a583deea784</id>
<content type='text'>
Pull regmap fix from Mark Brown:
 "A single revert back to v4.4 endianness handling.

  Commit 29bb45f25ff3 ("regmap-mmio: Use native endianness for
  read/write") attempted to fix some long standing bugs in the MMIO
  implementation for big endian systems caused by duplicate byte
  swapping in both regmap and readl()/writel().  Sadly the fix makes
  things worse rather than better, so revert it for now"

* tag 'regmap-fix-v4.5-big-endian' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: mmio: Revert to v4.4 endianness handling
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull regmap fix from Mark Brown:
 "A single revert back to v4.4 endianness handling.

  Commit 29bb45f25ff3 ("regmap-mmio: Use native endianness for
  read/write") attempted to fix some long standing bugs in the MMIO
  implementation for big endian systems caused by duplicate byte
  swapping in both regmap and readl()/writel().  Sadly the fix makes
  things worse rather than better, so revert it for now"

* tag 'regmap-fix-v4.5-big-endian' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: mmio: Revert to v4.4 endianness handling
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branches 'pm-core' and 'pm-domains'</title>
<updated>2016-02-05T23:34:01+00:00</updated>
<author>
<name>Rafael J. Wysocki</name>
<email>rafael.j.wysocki@intel.com</email>
</author>
<published>2016-02-05T23:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=79e2f8dd522873614eb31001745af487451a10de'/>
<id>79e2f8dd522873614eb31001745af487451a10de</id>
<content type='text'>
* pm-core:
  PM: Avoid false-positive warnings in dev_pm_domain_set()
  ACPI / LPSS: set PM domain via helper setter

* pm-domains:
  PM / Domains: Silence compiler warning for an unused function
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* pm-core:
  PM: Avoid false-positive warnings in dev_pm_domain_set()
  ACPI / LPSS: set PM domain via helper setter

* pm-domains:
  PM / Domains: Silence compiler warning for an unused function
</pre>
</div>
</content>
</entry>
</feed>
