kernel/linux.git/drivers/base/platform.c, branch v4.4.89

driver core: platform: fix race condition with driver_override

2017-07-15T09:57:44+00:00

commit 6265539776a0810b7ce6398c27866ddb9c6bd154 upstream. The driver_override implementation is susceptible to race condition when different threads are reading vs storing a different driver override. Add locking to avoid race condition. Fixes: 3d713e0e382e ("driver core: platform: add device binding path 'driver_override'") Cc: stable@vger.kernel.org Signed-off-by: Adrian Salido Signed-off-by: Greg Kroah-Hartman

platform: don't return 0 from platform_get_irq[_byname]() on error

2016-10-28T07:01:26+00:00

commit e330b9a6bb35dc7097a4f02cb1ae7b6f96df92af upstream. of_irq_get[_byname]() return 0 iff irq_create_of_mapping() call fails. Returning both error code and 0 on failure is a sign of a misdesigned API, it makes the failure check unnecessarily complex and error prone. We should rely on the platform IRQ resource in this case, not return 0, especially as 0 can be a valid IRQ resource too... Fixes: aff008ad813c ("platform_get_irq: Revert to platform_get_resource if of_irq_get fails") Signed-off-by: Sergei Shtylyov Signed-off-by: Greg Kroah-Hartman

base/platform: Fix platform drivers with no probe callback

2016-02-17T20:30:55+00:00

commit 25cad69f21f5532d99e2ee73c8ab6512bcab614c upstream. Since b8b2c7d845d5, platform_drv_probe() is called for all platform devices. If drv->probe is NULL, and dev_pm_domain_attach() fails, platform_drv_probe() will return the error code from dev_pm_domain_attach(). This causes real_probe() to enter the "probe_failed" path and set dev->driver to NULL. Before b8b2c7d845d5, real_probe() would assume success if both dev->bus->probe and drv->probe were missing. As a result, a device and driver could be "bound" together just by matching their names; this doesn't work any more after b8b2c7d845d5. This may cause problems later for certain usage of platform_driver_register() and platform_device_register_simple(). I observed a panic while loading the tpm_tis driver with parameter "force=1" (i.e. registering tpm_tis as a platform driver), because tpm_tis_init's assumption that the device returned by platform_device_register_simple() was bound didn't hold any more (tpmm_chip_alloc() dereferences chip->pdev->driver, causing panic). This patch restores the previous (4.3.0 and earlier) behavior of platform_drv_probe() in the case when the associated platform driver has no "probe" function. Fixes: b8b2c7d845d5 ("base/platform: assert that dev_pm_domain callbacks are called unconditionally") Signed-off-by: Martin Wilck Cc: Martin Fuzzey Acked-by: Jarkko Sakkinen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

driver-core: platform: Provide helpers for multi-driver modules

2015-10-05T04:02:40+00:00

Some modules register several sub-drivers. Provide a helper that makes it easy to register and unregister a list of sub-drivers, as well as unwind properly on error. Signed-off-by: Thierry Reding Signed-off-by: Greg Kroah-Hartman

base/platform: assert that dev_pm_domain callbacks are called unconditionally

2015-10-04T18:42:22+00:00

When a platform driver doesn't provide a .remove callback the function platform_drv_remove isn't called and so the call to dev_pm_domain_attach called at probe time isn't paired by dev_pm_domain_detach at remove time. To fix this (and similar issues if different callbacks are missing) hook up the driver callbacks unconditionally and make them aware that the platform callbacks might be missing. Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman

drivercore: Fix unregistration path of platform devices

2015-08-25T16:29:57+00:00

The unregister path of platform_device is broken. On registration, it will register all resources with either a parent already set, or type==IORESOURCE_{IO,MEM}. However, on unregister it will release everything with type==IORESOURCE_{IO,MEM}, but ignore the others. There are also cases where resources don't get registered in the first place, like with devices created by of_platform_populate()*. Fix the unregister path to be symmetrical with the register path by checking the parent pointer instead of the type field to decide which resources to unregister. This is safe because the upshot of the registration path algorithm is that registered resources have a parent pointer, and non-registered resources do not. * It can be argued that of_platform_populate() should be registering it's resources, and they argument has some merit. However, there are quite a few platforms that end up broken if we try to do that due to overlapping resources in the device tree. Until that is fixed, we need to solve the immediate problem. Cc: Pantelis Antoniou Cc: Wolfram Sang Cc: Rob Herring Cc: Greg Kroah-Hartman Cc: Ricardo Ribalda Delgado Signed-off-by: Grant Likely Tested-by: Ricardo Ribalda Delgado Tested-by: Wolfram Sang Cc: stable@vger.kernel.org Signed-off-by: Rob Herring

Revert "base/platform: Only insert MEM and IO resources"

2015-06-10T15:38:29+00:00

This reverts commit 36d4b29260753ad78b1ce4363145332c02519adc as it breaks working machines. Cc: Rob Herring Cc: Ricardo Ribalda Delgado Signed-off-by: Greg Kroah-Hartman

Revert "base/platform: Continue on insert_resource() error"

2015-06-10T15:38:02+00:00

This reverts commit e50e69d1ac4232af0b6890f16929bf5ceee81538 as it breaks working machines. Cc: Rob Herring Cc: Ricardo Ribalda Delgado Signed-off-by: Greg Kroah-Hartman

Revert "base/platform: Remove code duplication"

2015-06-10T15:36:50+00:00

This reverts commit 6d9d4b1469b0d9748145e168fc9ec585e1f3f4b0 as it breaks working machines. Cc: Rob Herring Cc: Ricardo Ribalda Delgado Signed-off-by: Greg Kroah-Hartman

base/platform: Remove code duplication

2015-06-01T01:15:17+00:00

Failure path of platform_device_add was almost the same as platform_device_del. Refactor same code in a function. Acked-by: Rob Herring Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Greg Kroah-Hartman