linux-toradex.git/drivers/base, branch v4.9.88

drivers: base: cacheinfo: fix boot error message when acpi is enabled

2018-01-31T11:55:51+00:00

commit 55877ef45fbd7f975d078426866b7d1a2435dcc3 upstream.

ARM64 enables both CONFIG_OF and CONFIG_ACPI and the firmware can pass
both ACPI tables and the device tree. Based on the kernel parameter, one
of the two will be chosen. If acpi is enabled, then device tree is not
unflattened.

Currently ARM64 platforms report:
"
	Failed to find cpu0 device node
	Unable to detect cache hierarchy from DT for CPU 0
"
which is incorrect when booting with ACPI. Also latest ACPI v6.1 has no
support for cache properties/hierarchy.

This patch adds check for unflattened device tree and also returns as
"not supported" if ACPI is runtime enabled.

It also removes the reference to DT from the error message as the cache
hierarchy can be detected from the firmware(OF/DT/ACPI)

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
Signed-off-by: Mian Yousaf Kaukab 
Signed-off-by: Greg Kroah-Hartman

drivers: base: cacheinfo: fix x86 with CONFIG_OF enabled

2018-01-31T11:55:51+00:00

commit fac51482577d5e05bbb0efa8d602a3c2111098bf upstream.

With CONFIG_OF enabled on x86, we get the following error on boot:
"
	Failed to find cpu0 device node
 	Unable to detect cache hierarchy from DT for CPU 0
"
and the cacheinfo fails to get populated in the corresponding sysfs
entries. This is because cache_setup_of_node looks for of_node for
setting up the shared cpu_map without checking that it's already
populated in the architecture specific callback.

In order to indicate that the shared cpu_map is already populated, this
patch introduces a boolean `cpu_map_populated` in struct cpu_cacheinfo
that can be used by the generic code to skip cache_shared_cpu_map_setup.

This patch also sets that boolean for x86.

Cc: Greg Kroah-Hartman 
Signed-off-by: Sudeep Holla 
Signed-off-by: Mian Yousaf Kaukab 
Signed-off-by: Greg Kroah-Hartman

sysfs/cpu: Add vulnerability folder

2018-01-17T08:38:57+00:00

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

PM / OPP: Move error message to debug level

2017-12-25T13:23:44+00:00

[ 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

isa: Prevent NULL dereference in isa_bus driver callbacks

2017-12-14T08:28:11+00:00

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

PM / OPP: Add missing of_node_put(np)

2017-11-30T08:39:09+00:00

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

PM / OPP: Error out on failing to add static OPPs for v1 bindings

2017-11-15T14:53:12+00:00

[ Upstream commit 04a86a84c42ca18f37ab446127dc619b41dd3b23 ]

The code adding static OPPs for V2 bindings already does so. Make the V1
bindings specific code behave the same.

Signed-off-by: Viresh Kumar 
Reviewed-by: Stephen Boyd 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PM / wakeirq: report a wakeup_event on dedicated wekup irq

2017-11-08T09:08:33+00:00

[ Upstream commit 09bb6e93956ae5175b96905b723ec879c3ca0765 ]

There are two reasons for reporting wakeup event when dedicated wakeup
IRQ is triggered:

- wakeup events accounting, so proper statistical data will be
  displayed in sysfs and debugfs;

- there are small window when System is entering suspend during which
  dedicated wakeup IRQ can be lost:

dpm_suspend_noirq()
  |- device_wakeup_arm_wake_irqs()
      |- dev_pm_arm_wake_irq(X)
         |- IRQ is enabled and marked as wakeup source
[1]...
  |- suspend_device_irqs()
     |- suspend_device_irq(X)
	|- irqd_set(X, IRQD_WAKEUP_ARMED);
	   |- wakup IRQ armed

The wakeup IRQ can be lost if it's triggered at point [1]
and not armed yet.

Hence, fix above cases by adding simple pm_wakeup_event() call in
handle_threaded_wake_irq().

Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Signed-off-by: Grygorii Strashko 
Tested-by: Keerthy 
[ tony@atomide.com: added missing return to avoid warnings ]
Tested-by: Tony Lindgren 
Signed-off-by: Tony Lindgren 
Signed-off-by: Rafael J. Wysocki 

Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

device property: Track owner device of device property

2017-10-18T07:35:39+00:00

commit 5ab894aee0f171a682bcd90dd5d1930cb53c55dc upstream.

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)
Signed-off-by: Jarkko Nikula 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

driver core: platform: Don't read past the end of "driver_override" buffer

2017-10-12T09:51:24+00:00

commit bf563b01c2895a4bfd1a29cc5abc67fe706ecffd upstream.

When printing the driver_override parameter when it is 4095 and 4094 bytes
long, the printing code would access invalid memory because we need count+1
bytes for printing.

Reject driver_override values of these lengths in driver_override_store().

This is in close analogy to commit 4efe874aace5 ("PCI: Don't read past the
end of sysfs "driver_override" buffer") from Sasha Levin.

Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'")
Signed-off-by: Nicolai Stange 
Signed-off-by: Greg Kroah-Hartman