29 Oct, 2018
7 commits
-
If no valid state idx specified by governor, we use the default state_idx
0 to enter in case the domain has multi low power states.Reviewed-by: Frank Li
Reviewed-by: Ranjani Vaidyanathan
Signed-off-by: Dong Aisheng -
For a domain belongs to no devices anymore, let's choose the deepest state
to enter to save power.Reviewed-by: Frank Li
Reviewed-by: Ranjani Vaidyanathan
Signed-off-by: Dong Aisheng -
Currently the generic power domain suspend code pm_genpd_suspend_noirq
will try to power off a domain used by devices in genpd_sync_poweroff
if its status is not GPD_STATE_ACTIVE.However, for power domains supporting multiple low power states, it may
already enter an intermediate low power state by runtime PM before system
suspend and the status is already GPD_STATE_POWER_OFF which results in
then the power domain stay at an intermediate low power state during
system suspend.Let's give the power domain a chance to switch to the deepest state in
case it's already off but in an intermediate low power state.
Due to power domain is alway off, so no need to check device wakeup
case anymore.Reviewed-by: Frank Li
Reviewed-by: Ranjani Vaidyanathan
Signed-off-by: Dong Aisheng -
clear error message during wifi bootup
Signed-off-by: Gao Pan
(cherry-picked from ad4eee9376ed26c92d05f9f2a5ab74a6a7b42055) -
In some platforms, accessing registers needs to make sure
power domain is enabled, such as for clock operations, power
domain needs to be enabled first before accessing clock
registers, so some clocks need to know its power domain's
status, it will need to get power domain structure by phandle,
expose the API to support this case.Signed-off-by: Anson Huang
-
Without FW_LOADER_USER_HELPER enable, iwl wifi cards can't
load their firmware in imx_4.1.y, enable it.Signed-off-by: Richard Zhu
-
According to clock framework, the clk_id could be NULL when getting clock.
But current code relies on a non null clk_id to get clock.
Changing the code to allow a null clk_id to get clock to make it more
reasonable to use.
And the regmap_mmio_gen_context will try to get clock by default but ignore
error if not finding the clock in case some regmap access not reply on
a specific clock.Signed-off-by: Dong Aisheng
(cherry picked from commit a60a38a5285ab27814f261ed39653c55a0a6e24b)
13 Oct, 2018
1 commit
-
commit 69e445ab8b66a9f30519842ef18be555d3ee9b51 upstream.
If __device_suspend() runs asynchronously (in which case the device
passed to it is in dpm_suspended_list at that point) and it returns
early on an error or pending wakeup, and the power.direct_complete
flag has been set for the device already, the subsequent
device_resume() will be confused by that and it will call
pm_runtime_enable() incorrectly, as runtime PM has not been
disabled for the device by __device_suspend().To avoid that, clear power.direct_complete if __device_suspend()
is not going to disable runtime PM for the device before returning.Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily)
Reported-by: Al Cooper
Tested-by: Al Cooper
Reviewed-by: Ulf Hansson
Cc: 3.16+ # 3.16+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
26 Sep, 2018
1 commit
-
[ Upstream commit 3297c8fc65af5d40501ea7cddff1b195cae57e4e ]
There is a race window in device_shutdown(), which may cause
-1. parent device shut down before child or
-2. no shutdown on a new probing device.For 1st, taking the following scenario:
device_shutdown new plugin device
list_del_init(parent_dev);
spin_unlock(list_lock);
device_add(child)
probe child
shutdown parent_dev
--> now child is on the tail of devices_ksetFor 2nd, taking the following scenario:
device_shutdown new plugin device
device_add(dev)
device_lock(dev);
...
device_unlock(dev);
probe dev
--> now, the new occurred dev has no opportunity to shutdownTo fix this race issue, just prevent the new probing request. With this
logic, device_shutdown() is more similar to dpm_prepare().Signed-off-by: Pingfan Liu
Reviewed-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
05 Sep, 2018
1 commit
-
commit 5e2e2f9f76e157063a656351728703cb02b068f1 upstream.
"count" needs to be signed for the error handling to work. I made "i"
signed as well so they match.Fixes: 02113ba93ea4 (PM / clk: Add support for obtaining clocks from device-tree)
Cc: 4.6+ # 4.6+
Signed-off-by: Dan Carpenter
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
16 Aug, 2018
1 commit
-
commit 17dbca119312b4e8173d4e25ff64262119fcef38 upstream
L1TF core kernel workarounds are cheap and normally always enabled, However
they still should be reported in sysfs if the system is vulnerable or
mitigated. Add the necessary CPU feature/bug bits.- Extend the existing checks for Meltdowns to determine if the system is
vulnerable. All CPUs which are not vulnerable to Meltdown are also not
vulnerable to L1TF- Check for 32bit non PAE and emit a warning as there is no practical way
for mitigation due to the limited physical address bits- If the system has more than MAX_PA/2 physical memory the invert page
workarounds don't protect the system against the L1TF attack anymore,
because an inverted physical address will also point to valid
memory. Print a warning in this case and report that the system is
vulnerable.Add a function which returns the PFN limit for the L1TF mitigation, which
will be used in follow up patches for sanity and range checks.[ tglx: Renamed the CPU feature bit to L1TF_PTEINV ]
Signed-off-by: Andi Kleen
Signed-off-by: Thomas Gleixner
Reviewed-by: Josh Poimboeuf
Acked-by: Dave Hansen
Signed-off-by: Greg Kroah-Hartman
28 Jul, 2018
1 commit
-
commit 722e5f2b1eec7de61117b7c0a7914761e3da2eda upstream.
Commit 52cdbdd49853 (driver core: correct device's shutdown order)
introduced a regression by breaking device shutdown on some systems.Namely, the devices_kset_move_last() call in really_probe() added by
that commit is a mistake as it may cause parents to follow children
in the devices_kset list which then causes shutdown to fail. For
example, if a device has children before really_probe() is called
for it (which is not uncommon), that call will cause it to be
reordered after the children in the devices_kset list and the
ordering of that list will not reflect the correct device shutdown
order any more.Also it causes the devices_kset list to be constantly reordered
until all drivers have been probed which is totally pointless
overhead in the majority of cases and it only covered an issue
with system shutdown, while system-wide suspend/resume potentially
had the same issue on the affected platforms (which was not covered).Moreover, the shutdown issue originally addressed by the change in
really_probe() made by commit 52cdbdd49853 is not present in 4.18-rc
any more, since dra7 started to use the sdhci-omap driver which
doesn't disable any regulators during shutdown, so the really_probe()
part of commit 52cdbdd49853 can be safely reverted. [The original
issue was related to the omap_hsmmc driver used by dra7 previously.]For the above reasons, revert the really_probe() modifications made
by commit 52cdbdd49853.The other code changes made by commit 52cdbdd49853 are useful and
they need not be reverted.Fixes: 52cdbdd49853 (driver core: correct device's shutdown order)
Link: https://lore.kernel.org/lkml/CAFgQCTt7VfqM=UyCnvNFxrSw8Z6cUtAi3HUwR4_xPAc03SgHjQ@mail.gmail.com/
Reported-by: Pingfan Liu
Tested-by: Pingfan Liu
Reviewed-by: Kishon Vijay Abraham I
Signed-off-by: Rafael J. Wysocki
Cc: stable
Signed-off-by: Greg Kroah-Hartman
03 Jul, 2018
3 commits
-
commit c5c2a97b3ac7d1ec19e7cff9e38caca6afefc3de upstream.
This commit fixes a rare but possible case when the clk rate is updated
without update of the regulator voltage.At boot up, CPUfreq checks if the system is running at the right freq. This
is a sanity check in case a bootloader set clk rate that is outside of freq
table present with cpufreq core. In such cases system can be unstable so
better to change it to a freq that is preset in freq-table.The CPUfreq takes next freq that is >= policy->cur and this is our
target_freq that needs to be set now.dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
old_freq (a current rate). If these are equal it returns early. If not,
it searches for OPP (old_opp) that fits best to old_freq (not listed in
the table) and updates old_freq (!).Here, we can end up with old_freq = old_opp.rate = target_freq, which
is not handled in _generic_set_opp_regulator(). It's supposed to update
voltage only when freq > old_freq || freq > old_freq.if (freq > old_freq) {
ret = _set_opp_voltage(dev, reg, new_supply);
[...]
if (freq < old_freq) {
ret = _set_opp_voltage(dev, reg, new_supply);
if (ret)It results in, no voltage update while clk rate is updated.
Example:
freq-table = {
1000MHz 1.15V
666MHZ 1.10V
333MHz 1.05V
}
boot-up-freq = 800MHz # not listed in freq-table
freq = target_freq = 1GHz
old_freq = 800Mhz
old_opp = _find_freq_ceil(opp_table, &old_freq); #(old_freq is modified!)
old_freq = 1GHzFixes: 6a0712f6f199 ("PM / OPP: Add dev_pm_opp_set_rate()")
Cc: 4.6+ # v4.6+
Signed-off-by: Waldemar Rymarkiewicz
Signed-off-by: Viresh Kumar
Signed-off-by: Greg Kroah-Hartman -
commit 47e5abfb546a3ace23a77453dc2e9db92704c5ac upstream.
If a device link is added via device_link_add() by the driver of the
link's consumer device, the supplier's runtime PM usage counter is
going to be dropped by the pm_runtime_put_suppliers() call in
driver_probe_device(). However, in that case it is not incremented
unless the supplier driver is already present and the link is not
stateless. That leads to a runtime PM usage counter imbalance for
the supplier device in a few cases.To prevent that from happening, bump up the supplier runtime
PM usage counter in device_link_add() for all links with the
DL_FLAG_PM_RUNTIME flag set that are added at the consumer probe
time. Use pm_runtime_get_noresume() for that as the callers of
device_link_add() who want the supplier to be resumed by it are
expected to pass DL_FLAG_RPM_ACTIVE in flags to it anyway, but
additionally resume the supplier if the link is added during
consumer driver probe to retain the existing behavior for the
callers depending on it.Fixes: 21d5c57b3726 (PM / runtime: Use device links)
Reported-by: Ulf Hansson
Reviewed-by: Ulf Hansson
Tested-by: Marek Szyprowski
Cc: 4.10+ # 4.10+
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 72038df3c580c4c326b83c86149d7ac34007532a upstream.
In case the PM domain fails to be powered on in genpd_dev_pm_attach(), it
returns -EPROBE_DEFER, but keeping the device attached to its PM domain.
This leads to problems when the next attempt to attach is re-tried. More
precisely, in that situation an -EEXIST error code is returned, because the
device already has its PM domain pointer assigned, from the first attempt.Now, because of the sloppy error handling by the existing callers of
dev_pm_domain_attach(), probing is allowed to continue when -EEXIST is
returned. However, in such case there are no guarantees that the PM domain
is powered on by genpd, which may lead to hangs when buses/drivers tried to
access their devices.Let's fix this behaviour, simply by detaching the device when powering on
fails in genpd_dev_pm_attach().Cc: v4.11+ # v4.11+
Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
26 Jun, 2018
1 commit
-
commit 84d0c27d6233a9ba0578b20f5a09701eb66cee42 upstream.
syzbot is hitting WARN() at kernfs_add_one() [1].
This is because kernfs_create_link() is confused by previous device_add()
call which continued without setting dev->kobj.parent field when
get_device_parent() failed by memory allocation fault injection.
Fix this by propagating the error from class_dir_create_and_add() to
the calllers of get_device_parent().[1] https://syzkaller.appspot.com/bug?id=fae0fb607989ea744526d1c082a5b8de6529116f
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Greg Kroah-Hartman
Cc: stable
Signed-off-by: Greg Kroah-Hartman
30 May, 2018
1 commit
-
[ Upstream commit 71df179363a5a733a8932e9afb869760d7559383 ]
The cache pointer points to the actual memory used by the cache, as the
comparison here is looking for the type of the cache it should check
against cache_type.Fixes: 1ea975cf1ef5 ("regmap: Add a function to check if a regmap register is cached")
Signed-off-by: Charles Keepax
Signed-off-by: Mark Brown
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
23 May, 2018
1 commit
-
commit c456442cd3a59eeb1d60293c26cbe2ff2c4e42cf upstream
Add the sysfs file for the new vulerability. It does not do much except
show the words 'Vulnerable' for recent x86 cores.Intel cores prior to family 6 are known not to be vulnerable, and so are
some Atoms and some Xeon Phi.It assumes that older Cyrix, Centaur, etc. cores are immune.
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Thomas Gleixner
Reviewed-by: Borislav Petkov
Reviewed-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman
26 Apr, 2018
2 commits
-
[ Upstream commit 69728051f5bf15efaf6edfbcfe1b5a49a2437918 ]
If a device is runtime PM suspended when we enter suspend and has
a dedicated wake IRQ, we can get the following warning:WARNING: CPU: 0 PID: 108 at kernel/irq/manage.c:526 enable_irq+0x40/0x94
[ 102.087860] Unbalanced enable for IRQ 147
...
(enable_irq) from [] (dev_pm_arm_wake_irq+0x4c/0x60)
(dev_pm_arm_wake_irq) from []
(device_wakeup_arm_wake_irqs+0x58/0x9c)
(device_wakeup_arm_wake_irqs) from []
(dpm_suspend_noirq+0x10/0x48)
(dpm_suspend_noirq) from []
(suspend_devices_and_enter+0x30c/0xf14)
(suspend_devices_and_enter) from []
(enter_state+0xad4/0xbd8)
(enter_state) from [] (pm_suspend+0x38/0x98)
(pm_suspend) from [] (state_store+0x68/0xc8)This is because the dedicated wake IRQ for the device may have been
already enabled earlier by dev_pm_enable_wake_irq_check(). Fix the
issue by checking for runtime PM suspended status.This issue can be easily reproduced by setting serial console log level
to zero, letting the serial console idle, and suspend the system from
an ssh terminal. On resume, dmesg will have the warning above.The reason why I have not run into this issue earlier has been that I
typically run my PM test cases from on a serial console instead over ssh.Fixes: c84345597558 (PM / wakeirq: Enable dedicated wakeirq for suspend)
Signed-off-by: Tony Lindgren
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit a3381e3a65cbaf612c8f584906c4dba27e84267c ]
Commit b539cc82d493 (PM / Domains: Ignore domain-idle-states that are
not compatible), made it possible to ignore non-compatible
domain-idle-states OF nodes. However, in case that happens while doing
the OF parsing, the number of elements in the allocated array would
exceed the numbers actually needed, thus wasting memory.Fix this by pre-iterating the genpd OF node and counting the number of
compatible domain-idle-states nodes, before doing the allocation. While
doing this, it makes sense to rework the code a bit to avoid open coding,
of parts responsible for the OF node iteration.Let's also take the opportunity to clarify the function header for
of_genpd_parse_idle_states(), about what is being returned in case of
errors.Fixes: b539cc82d493 (PM / Domains: Ignore domain-idle-states that are not compatible)
Signed-off-by: Ulf Hansson
Reviewed-by: Lina Iyer
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
24 Apr, 2018
1 commit
-
commit f00e71091ab92eba52122332586c6ecaa9cd1a56 upstream.
We're supposed to be checking that "val_len" is not too large but
instead we check if it is smaller than the max.The only function affected would be regmap_i2c_smbus_i2c_write() in
drivers/base/regmap/regmap-i2c.c. Strangely that function has its own
limit check which returns an error if (count >= I2C_SMBUS_BLOCK_MAX) so
it doesn't look like it has ever been able to do anything except return
an error.Fixes: c335931ed9d2 ("regmap: Add raw_write/read checks for max_raw_write/read sizes")
Signed-off-by: Dan Carpenter
Signed-off-by: Mark Brown
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman
08 Apr, 2018
1 commit
-
commit 9de9a449482677a75f1edd2049268a7efc40fc96 upstream.
This reverts commit 452562abb5b7 ("base: arch_topology: fix section
mismatch build warnings"). It causes the notifier call hangs in some
use-cases.In some cases with using maxcpus, some of cpus are booted first and
then the remaining cpus are booted. As an example, some users who want
to realize fast boot up often use the following procedure.1) Define all CPUs on device tree (CA57x4 + CA53x4)
2) Add "maxcpus=4" in bootargs
3) Kernel boot up with CA57x4
4) After kernel boot up, CA53x4 is booted from userWhen kernel init was finished, CPUFREQ_POLICY_NOTIFIER was not still
unregisterd. This means that "__init init_cpu_capacity_callback()"
will be called after kernel init sequence. To avoid this problem,
it needs to remove __init{,data} annotations by reverting this commit.Also, this commit was needed to fix kernel compile issue below.
However, this issue was also fixed by another patch: commit 82d8ba717ccb
("arch_topology: Fix section miss match warning due to
free_raw_capacity()") in v4.15 as well.
Whereas commit 452562abb5b7 added all the missing __init annotations,
commit 82d8ba717ccb removed it from free_raw_capacity().WARNING: vmlinux.o(.text+0x548f24): Section mismatch in reference
from the function init_cpu_capacity_callback() to the variable
.init.text:$x
The function init_cpu_capacity_callback() references
the variable __init $x.
This is often because init_cpu_capacity_callback lacks a __init
annotation or the annotation of $x is wrong.Fixes: 82d8ba717ccb ("arch_topology: Fix section miss match warning due to free_raw_capacity()")
Cc: stable
Signed-off-by: Gaku Inami
Reviewed-by: Dietmar Eggemann
Tested-by: Dietmar Eggemann
Acked-by: Sudeep Holla
Signed-off-by: Greg Kroah-Hartman
19 Mar, 2018
1 commit
-
[ Upstream commit 03e4e0a9e02cf703da331ff6cfd57d0be9bf5692 ]
Ages ago Rob Clark noted,
"Currently with fence-array, we have a potential deadlock situation. If
we fence_add_callback() on an array-fence, the array-fence's lock is
acquired first, and in it's ->enable_signaling() callback, it will install
cbs on it's array-member fences, so the array-member's lock is acquired
second.But in the signal path, the array-member's lock is acquired first, and
the array-fence's lock acquired second."Rob proposed either extensive changes to dma-fence to unnest the
fence-array signaling, or to defer the signaling onto a workqueue. This
is a more refined version of the later, that should keep the latency
of the fence signaling to a minimum by using an irq-work, which is
executed asap.Reported-by: Rob Clark
Suggested-by: Rob Clark
References: 1476635975-21981-1-git-send-email-robdclark@gmail.com
Signed-off-by: Chris Wilson
Cc: Rob Clark
Cc: Gustavo Padovan
Cc: Sumit Semwal
Cc: Christian König
Reviewed-by: Christian König
Signed-off-by: Sumit Semwal
Link: https://patchwork.freedesktop.org/patch/msgid/20171114162719.30958-1-chris@chris-wilson.co.uk
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
25 Feb, 2018
1 commit
-
[ Upstream commit 31eb7431805493e10f4731f366cf4d4e3e952035 ]
Prevent rpm_get_suppliers() from returning an error code if runtime
PM is disabled for one or more of the supplier devices it wants to
runtime-resume, so as to make runtime PM work for devices with links
to suppliers that don't use runtime PM (such links may be created
during device enumeration even before it is known whether or not
runtime PM will be enabled for the devices in question, for example).Fixes: 21d5c57b3726 (PM / runtime: Use device links)
Reported-by: Adrian Hunter
Signed-off-by: Rafael J. Wysocki
Reviewed-by: Lukas Wunner
Tested-by: Adrian Hunter
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
22 Feb, 2018
1 commit
-
commit 433986c2c265d106d6a8e88006e0131fefc92b7b upstream.
Commit baa8809f6097 (PM / runtime: Optimize the use of device links)
added an invocation of pm_runtime_drop_link() to __device_link_del().
However there are two variants of that function, one for CONFIG_SRCU and
another for !CONFIG_SRCU, and the commit only modified the former.Fixes: baa8809f6097 (PM / runtime: Optimize the use of device links)
Cc: v4.10+ # v4.10+
Signed-off-by: Lukas Wunner
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
17 Jan, 2018
1 commit
-
commit 87590ce6e373d1a5401f6539f0c59ef92dd924a9 upstream.
As the meltdown/spectre problem affects several CPU architectures, it makes
sense to have common way to express whether a system is affected by a
particular vulnerability or not. If affected the way to express the
mitigation should be common as well.Create /sys/devices/system/cpu/vulnerabilities folder and files for
meltdown, spectre_v1 and spectre_v2.Allow architectures to override the show function.
Signed-off-by: Thomas Gleixner
Reviewed-by: Greg Kroah-Hartman
Reviewed-by: Konrad Rzeszutek Wilk
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Dave Hansen
Cc: Linus Torvalds
Cc: Borislav Petkov
Cc: David Woodhouse
Link: https://lkml.kernel.org/r/20180107214913.096657732@linutronix.de
Signed-off-by: Greg Kroah-Hartman
03 Jan, 2018
1 commit
-
commit f57ab9a01a36ef3454333251cc57e3a9948b17bf upstream.
Commit dfea747d2aba ("drivers: base: cacheinfo: support DT overrides for
cache properties") doesn't initialise the cache type if it's present
only in DT and the architecture is not aware of it. They are unified
system level cache which are generally transparent.This patch check if the cache type is set to NOCACHE but the DT node
indicates that it's unified cache and sets the cache type accordingly.Fixes: dfea747d2aba ("drivers: base: cacheinfo: support DT overrides for cache properties")
Reported-and-tested-by: Tan Xiaojun
Cc: Greg Kroah-Hartman
Signed-off-by: Sudeep Holla
Signed-off-by: Greg Kroah-Hartman
25 Dec, 2017
1 commit
-
[ Upstream commit 035ed07208dc501d023873447113f3f178592156 ]
On some i.MX6 platforms which do not have speed grading
check, opp table will not be created in platform code,
so cpufreq driver prints the following error message:cpu cpu0: dev_pm_opp_get_opp_count: OPP table not found (-19)
However, this is not really an error in this case because the
imx6q-cpufreq driver first calls dev_pm_opp_get_opp_count()
and if it fails, it means that platform code does not provide
OPP and then dev_pm_opp_of_add_table() will be called.In order to avoid such confusing error message, move it to
debug level.It is up to the caller of dev_pm_opp_get_opp_count() to check its
return value and decide if it will print an error or not.Signed-off-by: Fabio Estevam
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
14 Dec, 2017
2 commits
-
commit 5a244727f428a06634f22bb890e78024ab0c89f3 upstream.
The isa_driver structure for an isa_bus device is stored in the device
platform_data member of the respective device structure. This
platform_data member may be reset to NULL if isa_driver match callback
for the device fails, indicating a device unsupported by the ISA driver.This patch fixes a possible NULL pointer dereference if one of the
isa_driver callbacks to attempted for an unsupported device. This error
should not occur in practice since ISA devices are typically manually
configured and loaded by the users, but we may as well prevent this
error from popping up for the 0day testers.Fixes: a5117ba7da37 ("[PATCH] Driver model: add ISA bus")
Signed-off-by: William Breathitt Gray
Acked-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 0946b2fb38fdb6585a5ac3ca84ac73924f645952 upstream.
The help for FIRMWARE_IN_KERNEL still references the firmware_install
command that was recently removed by commit 5620a0d1aacd ("firmware:
delete in-kernel firmware").Clean up the message to direct the user to their distribution's
linux-firmware package, and remove any reference to firmware being
included in the kernel source tree.Fixes: 5620a0d1aacd ("firmware: delete in-kernel firmware").
Cc: Masahiro Yamada
Cc: David Woodhouse
Signed-off-by: Robin H. Johnson
Signed-off-by: Greg Kroah-Hartman
10 Dec, 2017
1 commit
-
[ Upstream commit 5241ab40f6e742f8a1631f8826faf6dc6412b3b5 ]
During system-wide PM, genpd relies on its PM callbacks to be invoked for
all its attached devices, as to deal with powering off/on the PM domain. In
other words, genpd is not compatible with the direct_complete path, if
executed by the PM core for any of its attached devices.However, when genpd's ->prepare() callback invokes pm_generic_prepare(), it
does not take into account that it may return 1. Instead it treats that as
an error internally and expects the PM core to abort the prepare phase and
roll back. This leads to genpd not properly powering on/off the PM domain,
because its internal counters gets wrongly balanced.To fix the behaviour, allow drivers to return 1 from their ->prepare()
callbacks, but let's return 0 from genpd's ->prepare() callback in such
case, as that prevents the PM core from running the direct_complete path
for the device.Signed-off-by: Ulf Hansson
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman
30 Nov, 2017
1 commit
-
commit 7978db344719dab1e56d05e6fc04aaaddcde0a5e upstream.
The for_each_available_child_of_node() loop in _of_add_opp_table_v2()
doesn't drop the reference to "np" on errors. Fix that.Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings)
Signed-off-by: Tobias Jordan
[ VK: Improved commit log. ]
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
02 Nov, 2017
1 commit
-
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.By default all files without license information are under the default
license of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if
Reviewed-by: Philippe Ombredanne
Reviewed-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
14 Oct, 2017
1 commit
-
When I execute numactl -H (which reads /sys/devices/system/node/nodeX/cpumap
and displays cpumask_of_node for each node), I get different result
on X86 and arm64. For each numa node, the former only displayed online
CPUs, and the latter displayed all possible CPUs. Unfortunately, both
Linux documentation and numactl manual have not described it clear.I sent a mail to ask for help, and Michal Hocko replied that he
preferred to print online cpus because it doesn't really make much sense
to bind anything on offline nodes.Will said:
"I suspect the vast majority (if not all) code that reads this file was
developed for x86, so having the same behaviour for arm64 sounds like
something we should do ASAP before people try to special case with
things like #ifdef __aarch64__. I'd rather have this in 4.14 if
possible."Link: http://lkml.kernel.org/r/1506678805-15392-2-git-send-email-thunder.leizhen@huawei.com
Signed-off-by: Zhen Lei
Acked-by: Michal Hocko
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Greg Kroah-Hartman
Cc: Tianhong Ding
Cc: Hanjun Guo
Cc: Libin
Cc: Kefeng Wang
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
12 Oct, 2017
1 commit
-
acpi_fwnode_get_reference_args(), the function implementing ACPI
support for fwnode_property_get_reference_args(), returns directly
error codes from __acpi_node_get_property_reference(). The latter
uses different error codes than the OF implementation. In particular,
the OF implementation uses -ENOENT to indicate that the property is
not found, a reference entry is empty and there are no more
references.Document and align the error codes for property for
fwnode_property_get_reference_args() so that they match with
of_parse_phandle_with_args().Fixes: 3e3119d3088f (device property: Introduce fwnode_property_get_reference_args)
Signed-off-by: Sakari Ailus
Signed-off-by: Rafael J. Wysocki
10 Oct, 2017
1 commit
-
Deletion of subdevice will remove device properties associated to parent
when they share the same firmware node after commit 478573c93abd (driver
core: Don't leak secondary fwnode on device removal). This was observed
with a driver adding subdevice that driver wasn't able to read device
properties after rmmod/modprobe cycle.Consider the lifecycle of it:
parent device registration
ACPI_COMPANION_SET()
device_add_properties()
pset_copy_set()
set_secondary_fwnode(dev, &p->fwnode)
device_add()parent probe
read device properties
ACPI_COMPANION_SET(subdevice, ACPI_COMPANION(parent))
device_add(subdevice)parent remove
device_del(subdevice)
device_remove_properties()
set_secondary_fwnode(dev, NULL);
pset_free()Parent device will have its primary firmware node pointing to an ACPI
node and secondary firmware node point to device properties.ACPI_COMPANION_SET() call in parent probe will set the subdevice's
firmware node to point to the same 'struct fwnode_handle' and the
associated secondary firmware node, i.e. the device properties as the
parent.When subdevice is deleted in parent remove that will remove those
device properties and attempt to read device properties in next
parent probe call will fail.Fix this by tracking the owner device of device properties and delete
them only when owner device is being deleted.Fixes: 478573c93abd (driver core: Don't leak secondary fwnode on device removal)
Cc: 4.9+ # 4.9+
Signed-off-by: Jarkko Nikula
Signed-off-by: Rafael J. Wysocki
03 Oct, 2017
1 commit
-
Pull driver core fixes from Greg KH:
"Here are a few small fixes for 4.14-rc4.The removal of DRIVER_ATTR() was almost completed by 4.14-rc1, but one
straggler made it in through some other tree (odds are, one of
mine...) So there's a simple removal of the last user, and then
finally the macro is removed from the tree.There's a fix for old crazy udev instances that insist on reloading a
module when it is removed from the kernel due to the new uevents for
bind/unbind. This fixes the reported regression, hopefully some year
in the future we can drop the workaround, once users update to the
latest version, but I'm not holding my breath.And then there's a build fix for a linker warning, and a buffer
overflow fix to match the PCI fixes you took through the PCI tree in
the same area.All of these have been in linux-next for a few weeks while I've been
traveling, sorry for the delay"* tag 'driver-core-4.14-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
driver core: remove DRIVER_ATTR
fpga: altera-cvp: remove DRIVER_ATTR() usage
driver core: platform: Don't read past the end of "driver_override" buffer
base: arch_topology: fix section mismatch build warnings
driver core: suppress sending MODALIAS in UNBIND uevents
26 Sep, 2017
1 commit
-
The notifier callbacks may want to call some OPP helper routines which
may try to take the same opp_table->lock again and cause a deadlock. One
such usecase was reported by Chanwoo Choi, where calling
dev_pm_opp_disable() leads us to the devfreq's OPP notifier handler,
which further calls dev_pm_opp_find_freq_floor() and it deadlocks.We don't really need the opp_table->lock to be held across the notifier
call though, all we want to make sure is that the 'opp' doesn't get
freed while being used from within the notifier chain. We can do it with
help of dev_pm_opp_get/put() as well. Let's do it.Cc: 4.11+ # 4.11+
Fixes: 5b650b388844 "PM / OPP: Take kref from _find_opp_table()"
Reported-by: Chanwoo Choi
Tested-by: Chanwoo Choi
Reviewed-by: Stephen Boyd
Reviewed-by: Chanwoo Choi
Signed-off-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
23 Sep, 2017
2 commits
-
Pull power management fixes from Rafael Wysocki:
"These fix a cpufreq regression introduced by recent changes related to
the generic DT driver, an initialization time memory leak in cpuidle
on ARM, a PM core bug that may cause system suspend/resume to fail on
some systems, a request type validation issue in the PM QoS framework
and two documentation-related issues.Specifics:
- Fix a regression in cpufreq on systems using DT as the source of
CPU configuration information where two different code paths
attempt to create the cpufreq-dt device object (there can be only
one) and fix up the "compatible" matching for some TI platforms on
top of that (Viresh Kumar, Dave Gerlach).- Fix an initialization time memory leak in cpuidle on ARM which
occurs if the cpuidle driver initialization fails (Stefan Wahren).- Fix a PM core function that checks whether or not there are any
system suspend/resume callbacks for a device, but forgets to check
legacy callbacks which then may be skipped incorrectly and the
system may crash and/or the device may become unusable after a
suspend-resume cycle (Rafael Wysocki).- Fix request type validation for latency tolerance PM QoS requests
which may lead to unexpected behavior (Jan Schönherr).- Fix a broken link to PM documentation from a header file and a typo
in a PM document (Geert Uytterhoeven, Rafael Wysocki)"* tag 'pm-4.14-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq: ti-cpufreq: Support additional am43xx platforms
ARM: cpuidle: Avoid memleak if init fail
cpufreq: dt-platdev: Add some missing platforms to the blacklist
PM: core: Fix device_pm_check_callbacks()
PM: docs: Drop an excess character from devices.rst
PM / QoS: Use the correct variable to check the QoS request type
driver core: Fix link to device power management documentation -
* pm-core:
PM: core: Fix device_pm_check_callbacks()* pm-qos:
PM / QoS: Use the correct variable to check the QoS request type* pm-docs:
PM: docs: Drop an excess character from devices.rst
driver core: Fix link to device power management documentation