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

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

PM: core: Fix device_pm_check_callbacks()

2017-10-05T07:44:01+00:00

commit 157c460e10cb6eca29ccbd0f023db159d0c55ec7 upstream.

The device_pm_check_callbacks() function doesn't check legacy
->suspend and ->resume callback pointers under the device's
bus type, class and driver, so in some cases it may set the
no_pm_callbacks flag for the device incorrectly and then the
callbacks may be skipped during system suspend/resume, which
shouldn't happen.

Fixes: aa8e54b55947 (PM / sleep: Go direct_complete if driver has no callbacks)
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

driver core: bus: Fix a potential double free

2017-09-09T15:39:38+00:00

commit 0f9b011d3321ca1079c7a46c18cb1956fbdb7bcb upstream.

The .release function of driver_ktype is 'driver_release()'.
This function frees the container_of this kobject.

So, this memory must not be freed explicitly in the error handling path of
'bus_add_driver()'. Otherwise a double free will occur.

Signed-off-by: Christophe JAILLET 
Signed-off-by: Greg Kroah-Hartman

device property: Make dev_fwnode() public

2017-08-11T15:49:29+00:00

commit e44bb0cbdc88686c21e2175a990b40bf6db5d005 upstream.

The function to obtain a fwnode related to a struct device is useful for
drivers that use the fwnode property API: it allows not being aware of the
underlying firmware implementation.

Signed-off-by: Sakari Ailus 
Reviewed-by: Mika Westerberg 
Signed-off-by: Rafael J. Wysocki 
Cc: Chris Metcalf 
Signed-off-by: Greg Kroah-Hartman