Sometimes, more than one (generally two) device can point to the same
fwnode.  However, only one device is set as the fwnode's device
(fwnode->dev) and can be looked up from the fwnode.

Typically, only one of these devices actually have a driver and actually
probe. If we create device links for all these devices, then the
suppliers' of these devices (with the same fwnode) will never get a
sync_state() call because one of their consumer devices will never probe
(because they don't have a driver).

So, create device links only for the device that is considered as the
fwnode's device.

One such example of this is the PCI bridge platform_device and the
corresponding pci_bus device. Both these devices will have the same
fwnode. It's the platform_device that is registered first and is set as
the fwnode's device. Also the platform_device is the one that actually
probes. Without this patch none of the suppliers of a PCI bridge
platform_device would get a sync_state() callback.

Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-pci@vger.kernel.org
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200321045448.15192-1-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In some cases the platform's main firmware (e.g. the UEFI fw) may contain
an embedded copy of device firmware which needs to be (re)loaded into the
peripheral. Normally such firmware would be part of linux-firmware, but in
some cases this is not feasible, for 2 reasons:

1) The firmware is customized for a specific use-case of the chipset / use
with a specific hardware model, so we cannot have a single firmware file
for the chipset. E.g. touchscreen controller firmwares are compiled
specifically for the hardware model they are used with, as they are
calibrated for a specific model digitizer.

2) Despite repeated attempts we have failed to get permission to
redistribute the firmware. This is especially a problem with customized
firmwares, these get created by the chip vendor for a specific ODM and the
copyright may partially belong with the ODM, so the chip vendor cannot
give a blanket permission to distribute these.

This commit adds a new platform fallback mechanism to the firmware loader
which will try to lookup a device fw copy embedded in the platform's main
firmware if direct filesystem lookup fails.

Drivers which need such embedded fw copies can enable this fallback
mechanism by using the new firmware_request_platform() function.

Note that for now this is only supported on EFI platforms and even on
these platforms firmware_fallback_platform() only works if
CONFIG_EFI_EMBEDDED_FIRMWARE is enabled (this gets selected by drivers
which need this), in all other cases firmware_fallback_platform() simply
always returns -ENOENT.
Reported-by: NDave Olsthoorn <dave@bewaar.me>
Suggested-by: NPeter Jones <pjones@redhat.com>
Acked-by: NLuis Chamberlain <mcgrof@kernel.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115163554.101315-5-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 8ba88804 as a better
version is already in Rafael's tree, sorry about that.
Reported-by: N"Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Pass cond argument to list_for_each_entry_rcu() to fix the
following false positive lockdep warning and other uses of
list_for_each_entry_rcu() in wakeup.c.

[  331.934648] =============================
[  331.934650] WARNING: suspicious RCU usage
[  331.934653] 5.6.0-rc1+ #5 Not tainted
[  331.934655] -----------------------------
[  331.934657] drivers/base/power/wakeup.c:408 RCU-list traversed in non-reader section!!

[  333.025156] =============================
[  333.025161] WARNING: suspicious RCU usage
[  333.025168] 5.6.0-rc1+ #5 Not tainted
[  333.025173] -----------------------------
[  333.025180] drivers/base/power/wakeup.c:424 RCU-list traversed in non-reader section!!

Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Signed-off-by: NMadhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
Link: https://lore.kernel.org/r/20200228174745.9308-1-madhuparnabhowmik10@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The component framework reuses the devres managed functions. There is no
need to specify an unbind() callback if the driver only wants to release
the devres managed resources. The bind/unbind is like the probe/remove
pair. The bind/probe is necessary and the unbind/remove is optional.
Signed-off-by: NMarco Felsch <m.felsch@pengutronix.de>
Reviewed-by: NPhilipp Zabel <p.zabel@pengutronix.de>
Link: https://lore.kernel.org/r/20200227104547.30085-1-m.felsch@pengutronix.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

fw_sysfs_wait_timeout may return err with -ENOENT
at fw_load_sysfs_fallback and firmware is already
in abort status, no need to abort again, so skip it.

This issue is caused by concurrent situation like below:
when thread 1# wait firmware loading, thread 2# may write
-1 to abort loading and wakeup thread 1# before it timeout.
so wait_for_completion_killable_timeout of thread 1# would
return remaining time which is != 0 with fw_st->status
FW_STATUS_ABORTED.And the results would be converted into
err -ENOENT in __fw_state_wait_common and transfered to
fw_load_sysfs_fallback in thread 1#.
The -ENOENT means firmware status is already at ABORTED,
so fw_load_sysfs_fallback no need to get mutex to abort again.
-----------------------------
thread 1#,wait for loading
fw_load_sysfs_fallback
 ->fw_sysfs_wait_timeout
    ->__fw_state_wait_common
       ->wait_for_completion_killable_timeout

in __fw_state_wait_common,
...
93    ret = wait_for_completion_killable_timeout(&fw_st->completion, timeout);
94    if (ret != 0 && fw_st->status == FW_STATUS_ABORTED)
95       return -ENOENT;
96    if (!ret)
97	 return -ETIMEDOUT;
98
99    return ret < 0 ? ret : 0;
-----------------------------
thread 2#, write -1 to abort loading
firmware_loading_store
 ->fw_load_abort
   ->__fw_load_abort
     ->fw_state_aborted
       ->__fw_state_set
         ->complete_all

in __fw_state_set,
...
111    if (status == FW_STATUS_DONE || status == FW_STATUS_ABORTED)
112       complete_all(&fw_st->completion);
-------------------------------------------
BTW,the double abort issue would not cause kernel panic or create an issue,
but slow down it sometimes.The change is just a minor optimization.
Signed-off-by: NJunyong Sun <sunjunyong@xiaomi.com>
Acked-by: NLuis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/1583202968-28792-1-git-send-email-sunjunyong@xiaomi.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Add a sanity check before putting the cpu clk.

Fixes: b8fe128d (“arch_topology: Adjust initial CPU capacities with current freq")
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Link: https://lore.kernel.org/r/20200317063308.23209-1-jeffy.chen@rock-chips.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently there are only 10 bytes to store the cpu-topology 'name'
information. Only 10 bytes copied into cluster/thread/core names.

If the cluster ID exceeds 2-digit number, it will result in the data
corruption, and ending up in a dead loop in the parsing routines. The
same applies to the thread names with more that 3-digit number.

This issue was found using the boundary tests under virtualised
environment like QEMU.

Let us increase the buffer to fix such potential issues.
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NZeng Tao <prime.zeng@hisilicon.com>

Link: https://lore.kernel.org/r/1583294092-5929-1-git-send-email-prime.zeng@hisilicon.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The CPU freqs are not supposed to change before cpufreq policies
properly registered, meaning that they should be used to calculate the
initial CPU capacities.

Doing this helps choosing the best CPU during early boot, especially
for the initramfs decompressing.

There's no functional changes for non-clk CPU DVFS mechanism.
Signed-off-by: NJeffy Chen <jeffy.chen@rock-chips.com>
Link: https://lore.kernel.org/r/20200113034815.25924-1-jeffy.chen@rock-chips.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Use the simpler sprintf() instead of snprintf() or scnprintf() in a
single-shot sysfs output callbacks where you are very sure that it
won't go over PAGE_SIZE buffer limit.
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200311080207.12046-3-tiwai@suse.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since snprintf() returns the would-be-output size instead of the
actual output size, the succeeding calls may go beyond the given
buffer limit.  Fix it by replacing with scnprintf().
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20200311080207.12046-2-tiwai@suse.deSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Fixes: 8375e74f ("driver core: Add fw_devlink kernel commandline option")
Signed-off-by: Nkbuild test robot <lkp@intel.com>
Acked-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200305020916.GA14234@3143ef58ba07Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 3df85a1a.

The reverted commit says "It's possible to release the node ID
immediately when fwnode_remove_software_node() is called, no need to
wait for software_node_release() with that." However, releasing the node
ID before waiting for software_node_release() to be called causes the
node ID to be released before the kobject and the underlying sysfs
entry; this means there is a period of time where a sysfs entry exists
that is associated with an unallocated node ID.

Once consequence of this is that there is a race condition where it is
possible to call fwnode_create_software_node() with no parent node
specified (NULL) and have it fail with -EEXIST because the node ID that
was assigned is still associated with a stale sysfs entry that hasn't
been cleaned up yet.

Although it is difficult to reproduce this race condition under normal
conditions, it can be deterministically reproduced with the following
minconfig on UML:

CONFIG_KUNIT_DRIVER_PE_TEST=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_OBJECTS_TIMERS=y
CONFIG_DEBUG_KOBJECT_RELEASE=y
CONFIG_KUNIT=y

Running the tests with this configuration causes the following failure:

<snip>
kobject: 'node0' ((____ptrval____)): kobject_release, parent (____ptrval____) (delayed 400)
	ok 1 - pe_test_uints
sysfs: cannot create duplicate filename '/kernel/software_nodes/node0'
CPU: 0 PID: 28 Comm: kunit_try_catch Not tainted 5.6.0-rc3-next-20200227 #14
<snip>
kobject_add_internal failed for node0 with -EEXIST, don't try to register things with the same name in the same directory.
kobject: 'node0' ((____ptrval____)): kobject_release, parent (____ptrval____) (delayed 100)
	# pe_test_uint_arrays: ASSERTION FAILED at drivers/base/test/property-entry-test.c:123
	Expected node is not error, but is: -17
	not ok 2 - pe_test_uint_arrays
<snip>
Reported-by: NHeidi Fahim <heidifahim@google.com>
Signed-off-by: NBrendan Higgins <brendanhiggins@google.com>
Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: 5.3+ <stable@vger.kernel.org> # 5.3+
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

Sparse reports a warning at device_links_write_lock()

warning: context imbalance in evice_links_write_lock()
	 - wrong count at exit

The root cause is the missing annotation at device_links_write_lock()
Add the missing __acquires(&device_links_srcu) annotation
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20200214204741.94112-19-jbi.octave@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Sparse reports a warning at device_links_read_unlock()

warning:  warning: context imbalance in device_links_read_unlock()
	 - unexpected unlock

The root cause is the missing annotation at device_links_read_unlock()
Add the missing __releases(&device_links_srcu) annotation
Signed-off-by: NJules Irenge <jbi.octave@gmail.com>
Link: https://lore.kernel.org/r/20200214204741.94112-20-jbi.octave@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Since other subsystems (like regulator) have similar arbitrary
timeouts for how long they try to resolve driver dependencies,
rename deferred_probe_timeout to driver_deferred_probe_timeout
and set it as global, so it can be shared.

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-6-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Now that driver_deferred_probe_check_state() works better, and
we've converted the only user of
driver_deferred_probe_check_state_continue() we can simply
remove it and simplify some of the logic.

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-5-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When using modules, its common for the modules not to be loaded
until quite late by userland. With the current code,
driver_deferred_probe_check_state() will stop returning
EPROBE_DEFER after late_initcall, which can cause module
dependency resolution to fail after that.

So allow a longer window of 30 seconds (picked somewhat
arbitrarily, but influenced by the similar regulator core
timeout value) in the case where modules are enabled.

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Reviewed-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-3-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

driver_deferred_probe_check_state() has some uninituitive behavior.

* From boot to late_initcall, it returns -EPROBE_DEFER

* From late_initcall to the deferred_probe_timeout (if set)
  it returns -ENODEV

* If the deferred_probe_timeout it set, after it fires, it
  returns -ETIMEDOUT

This is a bit confusing, as its useful to have the function
return -EPROBE_DEFER while the timeout is still running. This
behavior has resulted in the somwhat duplicative
driver_deferred_probe_check_state_continue() function being
added.

Thus this patch tries to improve the logic, so that it behaves
as such:

* If late_initcall has passed, and modules are not enabled
  it returns -ENODEV

* If modules are enabled and deferred_probe_timeout is set,
  it returns -EPROBE_DEFER until the timeout, afterwhich it
  returns -ETIMEDOUT.

* In all other cases, it returns -EPROBE_DEFER

This will make the deferred_probe_timeout value much more
functional, and will allow us to consolidate the
driver_deferred_probe_check_state() and
driver_deferred_probe_check_state_continue() logic in a later
patch.

Cc: linux-pm@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Saravana Kannan <saravanak@google.com>
Cc: Todd Kjos <tkjos@google.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: NJohn Stultz <john.stultz@linaro.org>
Link: https://lore.kernel.org/r/20200225050828.56458-2-john.stultz@linaro.orgSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

fwnode_operations.add_links allows creating device links from
information provided by firmware.

fwnode_operations.add_links is currently implemented only by
OF/devicetree code and a specific case of efi. However, there's nothing
preventing ACPI or other firmware types from implementing it.

The OF implementation is currently controlled by a kernel commandline
parameter called of_devlink.

Since this feature is generic isn't limited to OF, add a generic
fw_devlink kernel commandline parameter to control this feature across
firmware types.
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200222014038.180923-3-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A previous patch 03324507 ("driver core: Allow
fwnode_operations.add_links to differentiate errors") forgot to update
all call sites to fwnode_operations.add_links. This patch fixes that.

Legend:
-> Denotes RHS is an optional/potential supplier for LHS
=> Denotes RHS is a mandatory supplier for LHS

Example:

Device A => Device X
Device A -> Device Y

Before this patch:
1. Device A is added.
2. Device A is marked as waiting for mandatory suppliers
3. Device X is added
4. Device A is left marked as waiting for mandatory suppliers

Step 4 is wrong since all mandatory suppliers of Device A have been
added.

After this patch:
1. Device A is added.
2. Device A is marked as waiting for mandatory suppliers
3. Device X is added
4. Device A is no longer considered as waiting for mandatory suppliers

This is the correct behavior.

Fixes: 03324507 ("driver core: Allow fwnode_operations.add_links to differentiate errors")
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200222014038.180923-2-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

A bunch of busy work is done for devices that don't have sync_state()
support. Stop doing the busy work.
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20200221080510.197337-4-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The initial patch that added sync_state() support didn't handle the case
where a supplier has no consumers. This was because when a device is
successfully bound with a driver, only its suppliers were checked to see
if they are eligible to get a sync_state(). This is not sufficient for
devices that have no consumers but still need to do device state clean
up. So fix this.

Fixes: fc5a251d (driver core: Add sync_state driver/bus callback)
Signed-off-by: NSaravana Kannan <saravanak@google.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200221080510.197337-2-saravanak@google.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

I have an experimental setup where almost every possible system
service (even early startup ones) runs in separate namespace, using a
dedicated, minimal file system. In process of minimizing the contents
of the file systems with regards to modules and firmware files, I
noticed that in my system, the firmware files are loaded from three
different mount namespaces, those of systemd-udevd, init and
systemd-networkd. The logic of the source namespace is not very clear,
it seems to depend on the driver, but the namespace of the current
process is used.

So, this patch tries to make things a bit clearer and changes the
loading of firmware files only from the mount namespace of init. This
may also improve security, though I think that using firmware files as
attack vector could be too impractical anyway.

Later, it might make sense to make the mount namespace configurable,
for example with a new file in /proc/sys/kernel/firmware_config/. That
would allow a dedicated file system only for firmware files and those
need not be present anywhere else. This configurability would make
more sense if made also for kernel modules and /sbin/modprobe. Modules
are already loaded from init namespace (usermodehelper uses kthreadd
namespace) except when directly loaded by systemd-udevd.

Instead of using the mount namespace of the current process to load
firmware files, use the mount namespace of init process.

Link: https://lore.kernel.org/lkml/bb46ebae-4746-90d9-ec5b-fce4c9328c86@gmail.com/
Link: https://lore.kernel.org/lkml/0e3f7653-c59d-9341-9db2-c88f5b988c68@gmail.com/Signed-off-by: NTopi Miettinen <toiwoton@gmail.com>
Link: https://lore.kernel.org/r/20200123125839.37168-1-toiwoton@gmail.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The former contains nothing but a pointer to an array of the latter...
Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>

The callers are only interested in the actual zone, they don't care about
boundaries.  Return the zone instead to simplify.

Link: http://lkml.kernel.org/r/20200110183308.11849-1-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Patch series "mm/memory_hotplug: pass in nid to online_pages()".

Simplify onlining code and get rid of find_memory_block().  Pass in the
nid from the memory block we are trying to online directly, instead of
manually looking it up.

This patch (of 2):

No need to lookup the memory block, we can directly pass in the nid.

Link: http://lkml.kernel.org/r/20200113113354.6341-2-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
Reviewed-by: NAndrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Luckily, we have no users left, so we can get rid of it.  Cleanup
set_migratetype_isolate() a little bit.

Link: http://lkml.kernel.org/r/20191114131911.11783-2-david@redhat.comSigned-off-by: NDavid Hildenbrand <david@redhat.com>
Reviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: NMichal Hocko <mhocko@suse.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Qian Cai <cai@lca.pw>
Cc: Anshuman Khandual <anshuman.khandual@arm.com>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If a device is deleted by one of its system-wide resume callbacks
(for example, because it does not appear to be present or accessible
any more) along with its children, the resume of the children may
continue leading to use-after-free errors and other issues
(potentially).

Namely, if the device's children are resumed asynchronously, their
resume may have been scheduled already before the device's callback
runs and so the device may be deleted while dpm_wait_for_superior()
is being executed for them.  The memory taken up by the parent device
object may be freed then while dpm_wait() is waiting for the parent's
resume callback to complete, which leads to a use-after-free.
Moreover, the resume of the children is really not expected to
continue after they have been unregistered, so it must be terminated
right away in that case.

To address this problem, modify dpm_wait_for_superior() to check
if the target device is still there in the system-wide PM list of
devices and if so, to increment its parent's reference counter, both
under dpm_list_mtx which prevents device_del() running for the child
from dropping the parent's reference counter prematurely.

If the device is not present in the system-wide PM list of devices
any more, the resume of it cannot continue, so check that again after
dpm_wait() returns, which means that the parent's callback has been
completed, and pass the result of that check to the caller of
dpm_wait_for_superior() to allow it to abort the device's resume
if it is not there any more.

Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.comReported-by: NChanho Min <chanho.min@lge.com>
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This is a preparation patch for adding a new platform fallback mechanism,
which will have its own enable/disable FW_OPT_xxx option.

Note this also fixes a typo in one of the re-wordwrapped comments:
enfoce -> enforce.
Acked-by: NLuis Chamberlain <mcgrof@kernel.org>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20200115163554.101315-4-hdegoede@redhat.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There's some common boilerplate in devtmpfs_{create,delete}_node, put
that in a little helper.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20200115184154.3492-6-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

devtmpfs_mount() is only called from prepare_namespace() in
init/do_mounts.c, which is an __init function, so devtmpfs_mount() can
also be moved to .init.text.

Then the mount_dev static variable is only referenced from __init
functions (devtmpfs_mount and its initializer function mount_param).
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20200115184154.3492-5-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Avoid a bit of ifdeffery by using the IS_ENABLED() helper.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20200115184154.3492-4-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Factor out the setup part of devtmpfsd() to make it a bit easier to
see that we always call setup_done() exactly once (provided of course
the kthread is succesfully created).
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20200115184154.3492-3-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After complete(&setup_done), devtmpfs_init proceeds and may actually
return, invalidating the *err pointer, before devtmpfsd() proceeds to
reading back *err.

This is of course completely theoretical since the error conditions
never trigger in practice, and even if they did, nobody cares about
the exit value from a kernel thread, so it doesn't matter if we happen
to read back some garbage from some other stack frame. Still, this
isn't a pattern that should be copy-pasted, so fix it.
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Link: https://lore.kernel.org/r/20200115184154.3492-2-linux@rasmusvillemoes.dkSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the check that a u32 variable i is >= 0 is always true because
the unsigned variable will never be negative, causing the loop to run
forever.  Fix this by changing the pre-decrement check to a zero check on
i followed by a decrement of i.

Addresses-Coverity: ("Unsigned compared against 0")
Fixes: 39cc539f ("driver core: platform: Prevent resouce overflow from causing infinite loops")
Signed-off-by: NColin Ian King <colin.king@canonical.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20200116175758.88396-1-colin.king@canonical.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When checking if a register block is writable we must ensure that the
block does not start with or contain a non incrementing register.

Fixes: 8b9f9d4d ("regmap: verify if register is writeable before writing operations")
Signed-off-by: NBen Whitten <ben.whitten@gmail.com>
Link: https://lore.kernel.org/r/20200118205625.14532-1-ben.whitten@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

When the kernel is configured with CONFIG_NR_CPUS smaller than the
number of CPU nodes in the device tree(DT), all the CPU nodes parsing
done to fetch topology information will fail. This is not reasonable
as it is legal to have all the physical CPUs in the system in the DT.

Let us just skip such CPU DT nodes that are not used in the kernel
rather than returning an error.
Reviewed-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NZeng Tao <prime.zeng@hisilicon.com>
Link: https://lore.kernel.org/r/1579225973-32423-1-git-send-email-prime.zeng@hisilicon.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently the property entry kunit tests are built if CONFIG_KUNIT=y.
This will cause warnings when merged with the kunit tree that now
supports tristate CONFIG_KUNIT.  While the tests appear to compile
as a module, we get a warning about missing module license.

It's better to have a per-test suite CONFIG variable so that
we can do selective building of kunit-based suites, and can
also avoid merge issues like this.

Fixes: c032ace7 ("software node: add basic tests for property entries")
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Reported-by: NRandy Dunlap <rdunlap@infradead.org>
Signed-off-by: NAlan Maguire <alan.maguire@oracle.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The transport registration may fail.  Make sure the errors are propagated
to the callers.

Link: https://lore.kernel.org/r/20200106185817.640331-3-krisman@collabora.comReviewed-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NGabriel Krisman Bertazi <krisman@collabora.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>