Currently regmap requires that a reg_read callback is supplied, otherwise a
warning is emitted each time regmap_read() is called. This means a device
or bus without readback support needs to supply dummy reg_read callback.
Apart from that regmap_read() will still work fine if a cache is used.

Remove the warning and let regmap_readable() return false if not reg_read
callback is supplied. This means a device no longer has to supply a dummy
callback if it does not support readback and it also doesn't have to have a
readable_reg callback that always returns false since this is now implicit.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch initalises all low memory struct pages and 2G of the highest
zone on each node during memory initialisation if
CONFIG_DEFERRED_STRUCT_PAGE_INIT is set.  That config option cannot be set
but will be available in a later patch.  Parallel initialisation of struct
page depends on some features from memory hotplug and it is necessary to
alter alter section annotations.
Signed-off-by: NMel Gorman <mgorman@suse.de>
Tested-by: NNate Zimmer <nzimmer@sgi.com>
Tested-by: NWaiman Long <waiman.long@hp.com>
Tested-by: NDaniel J Blueman <daniel@numascale.com>
Acked-by: NPekka Enberg <penberg@kernel.org>
Cc: Robin Holt <robinmholt@gmail.com>
Cc: Nate Zimmer <nzimmer@sgi.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Waiman Long <waiman.long@hp.com>
Cc: Scott Norton <scott.norton@hp.com>
Cc: "Luck, Tony" <tony.luck@intel.com>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This eliminates a little .text and avoids repeating the strchr call when
we meet a '!' (which will happen at least once).
Signed-off-by: NRasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 8a0662d9 introduced of_node and acpi_node symbols in global namespace
but there were already ~63 of_node local variables or function parameters
(no single acpi_node though, but anyway).

After debugging undefined but used of_node local varible (which turned out
to reference static function of_node() instead) it became clear that the names
for the functions are too short and too generic for global scope.
Signed-off-by: NAlexander Sverdlin <alexander.sverdlin@gmail.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The way the mask is generated in regmap_field_init() is wrong.
Indeed, a field initialized with msb = 31 and lsb = 0 provokes a shift
overflow while calculating the mask field.

On some 32 bits architectures, such as x86, the generated mask is 0,
instead of the expected 0xffffffff.

This patch uses GENMASK() to fix the problem, as this macro is already safe
regarding shift overflow.
Signed-off-by: NMaxime Coquelin <maxime.coquelin@st.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Currently the con_id of the acquired clock is printed for debugging
purposes.  But in several cases, the con_id is NULL, which doesn't
provide much debugging information when printed.  These cases are:
  - When explicitly passing a NULL con_id (which means the first clock
    tied to the device, if available),
  - When not using pm_clk_add(), but pm_clk_add_clk() (which takes a
    "struct clk *" directly).

Hence print the actual clock name in addition to (and not instead of;
thanks Grygorii Strashko!) the con_id.

Note that the clock name is not available with legacy clock frameworks,
and the hex pointer address will be printed instead.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NGrygorii Strashko <grygorii.strashko@linaro.org>
Reviewed-by: NUlf Hansson <ulf.hansson@linaro.org>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

The PM Domain code uses ktime_get() to perform various latency
measurements.  However, if ktime_get() is called while timekeeping is
suspended, the following warning is printed:

    WARNING: CPU: 0 PID: 1340 at kernel/time/timekeeping.c:576 ktime_get+0x3

This happens when resuming the PM Domain that contains the clock events
source, which calls pm_genpd_syscore_poweron(). Chain of operations is:

    timekeeping_resume()
    {
	clockevents_resume()
	    sh_cmt_clock_event_resume()
		pm_genpd_syscore_poweron()
		    pm_genpd_sync_poweron()
			genpd_syscore_switch()
			    genpd_power_on()
				ktime_get(), but timekeeping_suspended == 1
	...
	timekeeping_suspended = 0;
    }

Fix this by adding a "timed" parameter to genpd_power_{on,off}() and
pm_genpd_sync_power{off,on}(), to indicate whether latency measurements
are allowed.  This parameter is passed as false in
genpd_syscore_switch() (i.e. during syscore suspend/resume), and true in
all other cases.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

In big endian mode regmap_bulk_read gives incorrect data
for byte reads.

This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.
Signed-off-by: NArun Chandran <achandran@mvista.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

Currently, device drivers, which support both OF and ACPI,
need to call two separate APIs, of_dma_is_coherent() and
acpi_dma_is_coherent()) to determine device coherency attribute.

This patch simplifies this process by introducing a new device
property API, device_dma_is_coherent(), which calls the appropriate
interface based on the booting architecture.
Signed-off-by: NSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

This reverts commit 36d4b292 as it
breaks working machines.

Cc: Rob Herring <robh@kernel.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit e50e69d1 as it
breaks working machines.

Cc: Rob Herring <robh@kernel.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This reverts commit 6d9d4b14 as it
breaks working machines.

Cc: Rob Herring <robh@kernel.org>
Cc: Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Move the trace_device_pm_callback locations for dpm_prepare and dpm_complete
to encompass the attempt to capture the device mutex prior to callback. This
is needed by analyze_suspend to identify gaps in the trace output caused by
the delay in locking the mutex for a device.
Signed-off-by: NTodd Brandt <todd.e.brandt@linux.intel.com>
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>

set_irq_flags is ARM specific with custom flags which have genirq
equivalents. Convert drivers to use the genirq interfaces directly, so we
can kill off set_irq_flags. The translation of flags is as follows:

IRQF_VALID -> !IRQ_NOREQUEST
IRQF_PROBE -> !IRQ_NOPROBE
IRQF_NOAUTOEN -> IRQ_NOAUTOEN

For IRQs managed by an irqdomain, the irqdomain core code handles clearing
and setting IRQ_NOREQUEST already, so there is no need to do this in
.map() functions and we can simply remove the set_irq_flags calls. Some
users also set IRQ_NOPROBE and this has been maintained although it is not
clear that is really needed. There appears to be a great deal of blind
copy and paste of this code.
Signed-off-by: NRob Herring <robh@kernel.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Fixed a typo error in the file
Signed-off-by: NSriram Dash <dash.sriram@gmail.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

On some simulators like GEM5, caches may not be simulated. In those
cases, the cache levels and leaves will be zero and will result in
following exception:

Unable to handle kernel NULL pointer dereference at virtual address 0040
pgd = ffffffc0008fa000
[00000040] *pgd=00000009f6807003, *pud=00000009f6807003,
	   *pmd=00000009f6808003, *pte=006000002c010707
Internal error: Oops: 96000005 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.1.0-rc5 #198
task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000
PC is at detect_cache_attributes+0x98/0x2c8
LR is at detect_cache_attributes+0x88/0x2c8

kcalloc(0) returns a special value ZERO_SIZE_PTR which is non-NULL value
but results in fault only on any attempt to dereferencing it. So
checking for the non-NULL pointer will not suffice.

This patch checks for non-zero cache leaf nodes and returns error if
there are no cache leaves in detect_cache_attributes.

Cc: <stable@vger.kernel.org> # 3.19.x
Cc: Will Deacon <will.deacon@arm.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reported-by: NWilliam Wang <william.wang@arm.com>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The recent fix to use kstrdup_const() failed to add a
kfree upon failure of name allocation...

Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Signed-off-by: NShailendra Verma <shailendra.capricorn@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Failure path of platform_device_add was almost the same as
platform_device_del. Refactor same code in a function.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

insert_resource() can fail when the resource added  overlaps
(partially or fully) with another.

Device tree and AMBA devices may contain resources that overlap, so they
could not call platform_device_add (see 02bbde78 ('Revert "of:
use platform_device_add"'))"

On the other hand, device trees are released using
platform_device_unregister(). This function calls platform_device_del(),
which calls release_resource(), that crashes when the resource has not
been added with with insert_resource. This was not an issue when the
device tree could not be modified online, but this is not the case
anymore.

This patch let the flow continue when there is an insert error, after
notifying the user with a dev_err(). r->parent is set to NULL, so
platform_device_del() knows that the resource was not added, and
therefore it should not be released.
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

platform_device_del only checks the type of the resource in order to
call release_resource.

On the other hand, platform_device_add calls insert_resource for any
resource that has a parent.

Make both code branches balanced.
Signed-off-by: NRicardo Ribalda Delgado <ricardo.ribalda@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Delete jump to a label on the next line, when that label is not
used elsewhere.

A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
@r@
identifier l;
@@

-if (...) goto l;
-l:
// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NMark Brown <broonie@kernel.org>

Rename topology_thread_cpumask() to topology_sibling_cpumask()
for more consistency with scheduler code.
Signed-off-by: NBartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NCatalin Marinas <catalin.marinas@arm.com>
Cc: Benoit Cousson <bcousson@baylibre.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <jdelvare@suse.de>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Drokin <oleg.drokin@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Link: http://lkml.kernel.org/r/1432645896-12588-2-git-send-email-bgolaszewski@baylibre.comSigned-off-by: NIngo Molnar <mingo@kernel.org>

Commit 5590f319 ("drivers/core/of: Add symlink to device-tree from
devices with an OF node") adds the symlink `of_node` for each device
pointing to it's device tree node while creating/initialising it.

However the devicetree sysfs is created and setup in of_init which is
executed at core_initcall level. For all the devices created before
of_init, the following error is thrown:
	"Error -2(-ENOENT) creating of_node link"

Like many other components in driver model, initialize the sysfs support
for OF/devicetree from driver_init so that it's ready before any devices
are created.

Fixes: 5590f319 ("drivers/core/of: Add symlink to device-tree from
	devices with an OF node")
Suggested-by: NRob Herring <robh+dt@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Tested-by: NRobert Schwebel <r.schwebel@pengutronix.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

We currently use flexible arrays with a char at the
end for the remaining internal firmware name uses.
There are two limitations with the way we use this.
Since we're using a flexible array for a string on the
struct if we wanted to use two strings it means we'd
have a disjoint means of handling the strings, one
using the flexible array, and another a char * pointer.
We're also currently not using 'const' for the string.

We wish to later extend some firmware data structures
with other string/char pointers, but we also want to be
very pedantic about const usage. Since we're going to
change things to use 'const' we might as well also address
unified way to use multiple strings on the structs.

Replace the flexible array practice for strings with
kstrdup_const() and kfree_const(), this will avoid
allocations when the vmlinux .rodata is used, and just
allocate a new proper string for us when needed. This
also means we can simplify the struct allocations by
removing the string length from the allocation size
computation, which would otherwise get even more
complicated when supporting multiple strings.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Asynchronous firmware loading copies the pointer to the
name passed as an argument only to be scheduled later and
used. This behaviour works well for synchronous calling
but in asynchronous mode there's a chance the caller could
immediately free the passed string after making the
asynchronous call. This could trigger a use after free
having the kernel look on disk for arbitrary file names.

In order to force-test the issue you can use a test-driver
designed to illustrate this issue on github [0], use the
next-20150505-fix-use-after-free branch.

With this patch applied you get:

[  283.512445] firmware name: test_module_stuff.bin
[  287.514020] firmware name: test_module_stuff.bin
[  287.532489] firmware found

Without this patch applied you can end up with something such as:

[  135.624216] firmware name: \xffffff80BJ
[  135.624249] platform fake-dev.0: Direct firmware load for \xffffff80Bi failed with error -2
[  135.624252] No firmware found
[  135.624252] firmware found

Unfortunatley in the worst and most common case however you
can typically crash your system with a page fault by trying to
free something which you cannot, and/or a NULL pointer
dereference [1].

The fix and issue using schedule_work() for asynchronous
runs is generalized in the following SmPL grammar patch,
when applied to next-20150505 only the firmware_class
code is affected. This grammar patch can and should further
be generalized to vet for for other kernel asynchronous
mechanisms.

@ calls_schedule_work @
type T;
T *priv_work;
identifier func, work_func;
identifier work;
identifier priv_name, name;
expression gfp;
@@

 func(..., const char *name, ...)
 {
 	...
 	priv_work = kzalloc(sizeof(T), gfp);
 	...
-	priv_work->priv_name = name;
+	priv_work->priv_name = kstrdup_const(name, gfp);
	...
(... when any
 	if (...)
 	{
 		...
+ 		kfree_const(priv_work->priv_name);
 		kfree(priv_work);
		...
 	}
) ... when any
 	INIT_WORK(&priv_work->work, work_func);
 	...
 	schedule_work(&priv_work->work);
 	...
 }

@ the_work_func depends on calls_schedule_work @
type calls_schedule_work.T;
T *priv_work;
identifier calls_schedule_work.work_func;
identifier calls_schedule_work.priv_name;
identifier calls_schedule_work.work;
identifier some_work;
@@

 work_func(...)
 {
 	...
 	priv_work = container_of(some_work, T, work);
 	...
+	kfree_const(priv_work->priv_name);
 	kfree(priv_work);
 	...
 }

[0] https://github.com/mcgrof/fake-firmware-test.git
[1] The following kernel ring buffer splat:

firmware name: test_module_stuff.bin
firmware name:
firmware found
general protection fault: 0000 [#1] SMP
Modules linked in: test(O) <...etc-it-does-not-matter>
 drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G           O    4.0.0-00010-g22b5bb0-dirty #176
Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
Workqueue: events request_firmware_work_func
task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
RIP: 0010:[<ffffffff814a586c>]  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
RSP: 0000:ffff8800c7f97d78  EFLAGS: 00010286
RAX: ffffffff81ae3700 RBX: ffffffff816d1181 RCX: 0000000000000006
RDX: 0001ee850ff68500 RSI: 0000000000000246 RDI: c35d5f415e415d41
RBP: ffff8800c7f97d88 R08: 000000000000000a R09: 0000000000000000
R10: 0000000000000358 R11: ffff8800c7f97a7e R12: ffff8800c7ec1e80
R13: ffff88021e2d4cc0 R14: ffff88021e2dff00 R15: 00000000000000c0
FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000034b8cd8 CR3: 000000021073c000 CR4: 00000000001407e0
Stack:
 ffffffff816d1181 ffff8800c7ec1e80 ffff8800c7f97da8 ffffffff814a58f8
 000000000000000a ffffffff816d1181 ffff8800c7f97dc8 ffffffffa047002c
 ffff88021e2dff00 ffff8802116ac1c0 ffff8800c7f97df8 ffffffff814a65fe
Call Trace:
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a58f8>] release_firmware+0x58/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
 [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
 [<ffffffff8108d911>] worker_thread+0x121/0x460
 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
 [<ffffffff810928f9>] kthread+0xc9/0xe0
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
Code: c7 c6 dd ad a3 81 48 c7 c7 20 97 ce 81 31 c0 e8 0b b2 ed ff e9 78 ff ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 54 53 <4c> 8b 67 38 48 89 fb 4c 89 e7 e8 85 f7 22 00 f0 83 2b 01 74 0f
RIP  [<ffffffff814a586c>] fw_free_buf+0xc/0x40
 RSP <ffff8800c7f97d78>
---[ end trace 4e62c56a58d0eac1 ]---
BUG: unable to handle kernel paging request at ffffffffffffffd8
IP: [<ffffffff81093ee0>] kthread_data+0x10/0x20
PGD 1c13067 PUD 1c15067 PMD 0
Oops: 0000 [#2] SMP
Modules linked in: test(O) <...etc-it-does-not-matter>
 drm sr_mod cdrom xhci_pci xhci_hcd rtsx_pci mfd_core video button sg
CPU: 3 PID: 87 Comm: kworker/3:2 Tainted: G      D    O    4.0.0-00010-g22b5bb0-dirty #176
Hardware name: LENOVO 20AW000LUS/20AW000LUS, BIOS GLET43WW (1.18 ) 12/04/2013
task: ffff8800c7f8e290 ti: ffff8800c7f94000 task.ti: ffff8800c7f94000
RIP: 0010:[<ffffffff81092ee0>]  [<ffffffff81092ee0>] kthread_data+0x10/0x20
RSP: 0018:ffff8800c7f97b18  EFLAGS: 00010096
RAX: 0000000000000000 RBX: 0000000000000003 RCX: 000000000000000d
RDX: 0000000000000003 RSI: 0000000000000003 RDI: ffff8800c7f8e290
RBP: ffff8800c7f97b18 R08: 000000000000bc00 R09: 0000000000007e76
R10: 0000000000000001 R11: 000000000000002f R12: ffff8800c7f8e290
R13: 00000000000154c0 R14: 0000000000000003 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff88021e2c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000028 CR3: 0000000210675000 CR4: 00000000001407e0
Stack:
 ffff8800c7f97b38 ffffffff8108dcd5 ffff8800c7f97b38 ffff88021e2d54c0
 ffff8800c7f97b88 ffffffff816d1500 ffff880213d42368 ffff8800c7f8e290
 ffff8800c7f97b88 ffff8800c7f97fd8 ffff8800c7f8e710 0000000000000246
Call Trace:
 [<ffffffff8108dcd5>] wq_worker_sleeping+0x15/0xa0
 [<ffffffff816d1500>] __schedule+0x6e0/0x940
 [<ffffffff816d1797>] schedule+0x37/0x90
 [<ffffffff810779bc>] do_exit+0x6bc/0xb40
 [<ffffffff8101898f>] oops_end+0x9f/0xe0
 [<ffffffff81018efb>] die+0x4b/0x70
 [<ffffffff81015622>] do_general_protection+0xe2/0x170
 [<ffffffff816d74e8>] general_protection+0x28/0x30
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a586c>] ? fw_free_buf+0xc/0x40
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff814a58f8>] release_firmware+0x58/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffffa047002c>] test_mod_cb+0x2c/0x43 [test]
 [<ffffffff814a65fe>] request_firmware_work_func+0x5e/0x80
 [<ffffffff816d1181>] ? __schedule+0x361/0x940
 [<ffffffff8108d23a>] process_one_work+0x14a/0x3f0
 [<ffffffff8108d911>] worker_thread+0x121/0x460
 [<ffffffff8108d7f0>] ? rescuer_thread+0x310/0x310
 [<ffffffff810928f9>] kthread+0xc9/0xe0
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
 [<ffffffff816d52d8>] ret_from_fork+0x58/0x90
 [<ffffffff81092830>] ? kthread_create_on_node+0x180/0x180
Code: 00 48 89 e5 5d 48 8b 40 c8 48 c1 e8 02 83 e0 01 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 8b 87 30 05 00 00 55 48 89 e5 <48> 8b 40 d8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
RIP  [<ffffffff81092ee0>] kthread_data+0x10/0x20
 RSP <ffff8800c7f97b18>
CR2: ffffffffffffffd8
---[ end trace 4e62c56a58d0eac2 ]---
Fixing recursive fault but reboot is needed!

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Kyle McMartin <kyle@kernel.org>
Generated-by: Coccinelle SmPL
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

When direct firmware loading is used we iterate over a list
of possible firmware paths and concatenate the desired firmware
name with each path and look for the file there. Should the
passed firmware name be too long we end up truncating the
file we want to look for, the search however is still done.
Add a check for truncation instead of looking for a
truncated firmware filename.

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

The request_firmware*() APIs uses __getname() to iterate
over the list of paths possible for firmware to be found,
the code however never checked for failure on __getname().
Although *very unlikely*, this can still happen. Add the
missing check.

There is still no checks on the concatenation of the path
and filename passed, that requires a bit more work and
subsequent patches address this. The commit that introduced
this is abb139e7 ("firmware: teach the kernel to load
firmware files directly from the filesystem").

mcgrof@ergon ~/linux (git::firmware-fixes) $ git describe --contains abb139e7
v3.7-rc1~120

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: David Howells <dhowells@redhat.com>
Cc: Kyle McMartin <kyle@kernel.org>
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit 5590f319 ("drivers/core/of: Add symlink to device-tree from
devices with an OF node") adds the symlink `of_node` for each device
pointing to it's device tree node while creating/initialising it.

However the devicetree sysfs is created and setup in of_init which is
executed at core_initcall level. For all the devices created before
of_init, the following error is thrown:
	"Error -2(-ENOENT) creating of_node link"

Like many other components in driver model, initialize the sysfs support
for OF/devicetree from driver_init so that it's ready before any devices
are created.

Fixes: 5590f319 ("drivers/core/of: Add symlink to device-tree from
	devices with an OF node")
Suggested-by: NRob Herring <robh+dt@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
Tested-by: NRobert Schwebel <r.schwebel@pengutronix.de>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

s/hierarcy/hierarchy/

Maybe the typo will annoy people enough so that they add the missing
nodes to their device-tree files, but I still think this is better off
fixed.
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Acked-by: NSudeep Holla <sudeep.holla@arm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit f2411da7 ("driver-core: add driver module asynchronous probe
support") broke build in case modules are disabled, because in this case
"struct module" is not defined and we can't dereference it. Let's define
module_requested_async_probing() helper and stub it out if modules are
disabled.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

It is only used within dd.c and thus need not be global.
Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

This patch introduces regmap_get_reg_stride() function which would
be used by the infrastructures like nvmem framework built on top of
regmap. Mostly this function would be used for sanity checks on inputs
within such infrastructure.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

This patch introduces regmap_get_max_register() function which would be
used by the infrastructures like nvmem framework built on top of
regmap.
Signed-off-by: NSrinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: NMark Brown <broonie@kernel.org>

Because platform_driver_probe() checks, after trying to register driver,
if there are any devices that driver successfully bound to, driver's
probe routine must be run synchronously.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

There are drivers that can not be probed asynchronously. One such group
is platform drivers registered with platform_driver_probe(), which
expects driver's probe routine be discarded after the driver has been
registered and initial binding attempt executed. Also
platform_driver_probe() an error when no devices were bound to the
driver, allowing failing to load such driver module altogether.

Other drivers do not work well with asynchronous probing because of
driver bug or not optimal driver organization.

To allow using such drivers even when user requests asynchronous probing
as default boot strategy, let's allow them to opt out.
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some init systems may wish to express the desire to have device drivers
run their probe() code asynchronously. This implements support for this
and allows userspace to request async probe as a preference through a
generic shared device driver module parameter, async_probe.

Implementation for async probe is supported through a module parameter
given that since synchronous probe has been prevalent for years some
userspace might exist which relies on the fact that the device driver
will probe synchronously and the assumption that devices it provides
will be immediately available after this.
Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Some devices take a long time when initializing, and not all drivers are
suited to initialize their devices when they are open. For example,
input drivers need to interrogate their devices in order to publish
device's capabilities before userspace will open them. When such drivers
are compiled into kernel they may stall entire kernel initialization.

This change allows drivers request for their probe functions to be
called asynchronously during driver and device registration (manual
binding is still synchronous). Because async_schedule is used to perform
asynchronous calls module loading will still wait for the probing to
complete.

Note that the end goal is to make the probing asynchronous by default,
so annotating drivers with PROBE_PREFER_ASYNCHRONOUS is a temporary
measure that allows us to speed up boot process while we validating and
fixing the rest of the drivers and preparing userspace.

This change is based on earlier patch by "Luis R. Rodriguez"
<mcgrof@suse.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

Currently there is no way to query which CPUs are in nohz_full
mode from userspace.

Export the CPU list running in nohz_full mode in sysfs,
specifically in the file /sys/devices/system/cpu/nohz_full

This can be used by system management tools like libvirt,
openstack, and others to ensure proper task placement.
Signed-off-by: NRik van Riel <riel@redhat.com>
Acked-by: NMike Galbraith <umgwanakikbuti@gmail.com>
Acked-by: NChris Metcalf <cmetcalf@ezchip.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

After system bootup, there is no totally reliable way to see
which CPUs are isolated, because the kernel may modify the
CPUs specified on the isolcpus= kernel command line option.

Export the CPU list that actually got isolated in sysfs,
specifically in the file /sys/devices/system/cpu/isolated

This can be used by system management tools like libvirt,
openstack, and others to ensure proper placement of tasks.
Suggested-by: NLi Zefan <lizefan@huawei.com>
Signed-off-by: NRik van Riel <riel@redhat.com>
Acked-by: NMike Galbraith <umgwanakikbuti@gmail.com>
Acked-by: NChris Metcalf <cmetcalf@ezchip.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>