summaryrefslogtreecommitdiff
path: root/drivers/base
AgeCommit message (Collapse)AuthorFilesLines
2016-02-19regmap: merge regmap_update_bits() into macroKuninori Morimoto1-23/+0
Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch merges regmap_update_bits() into macro by using regmap_update_bits_base(). Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: add regmap_update_bits_base()Kuninori Morimoto1-0/+40
Current regmap has many similar update functions like below, but the difference is very few. regmap_update_bits() regmap_update_bits_async() regmap_update_bits_check() regmap_update_bits_check_async() Furthermore, we can add *force* write option too in the future. This patch adds new regmap_update_bits_base() which is feature merged function. Above functions can be merged into it by macro. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regcache: flat: Introduce register strider orderXiubo Li1-5/+15
Here we introduce regcache_flat_get_index(), which using register stride order and bit rotation, will save some memory spaces for flat cache. Though this will also lost some access performance, since the bit rotation is used to get the index of the cache array, and this could be ingored for memory I/O accessing. Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regcache: Introduce the index parsing API by stride orderXiubo Li1-0/+6
Here introduces regcache_get_index_by_order() for regmap cache, which uses the register stride order and bit rotation, to improve the performance. Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19regmap: core: Introduce register stride orderXiubo Li2-6/+23
Since the register stride should always equal to 2^N, and bit rotation is much faster than multiplication and division. So introducing the stride order and using bit rotation to get the offset of the register from the index to improve the performance. Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-19firmware: clean up filesystem load exit pathKees Cook1-7/+5
This makes the error and success paths more readable while trying to load firmware from the filesystem. Signed-off-by: Kees Cook <keescook@chromium.org> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: David Howells <dhowells@redhat.com> Acked-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2016-02-19firmware: move completing fw into a helperLuis R. Rodriguez1-4/+10
This will be re-used later through a new extensible interface. Reviewed-by: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by: Kees Cook <keescook@chromium.org>
2016-02-19firmware: simplify dev_*() print messages for generic helpersLuis R. Rodriguez1-4/+4
Simplify a few of the *generic* shared dev_warn() and dev_dbg() print messages for three reasons: 0) Historically firmware_class code was added to help get device driver firmware binaries but these days request_firmware*() helpers are being repurposed for general *system data* needed by the kernel. 1) This will also help generalize shared code as much as possible later in the future in consideration for a new extensible firmware API which will enable to separate usermode helper code out as much as possible. 2) Kees Cook pointed out the the prints already have the device associated as dev_*() helpers are used, that should help identify the user and case in which the helpers are used. That should provide enough context and simplifies the messages further. v4: generalize debug/warn messages even further as suggested by Kees Cook. Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: David Howells <dhowells@redhat.com> Cc: Kees Cook <keescook@chromium.org> Cc: Casey Schaufler <casey@schaufler-ca.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Vojtěch Pavlík <vojtech@suse.cz> Cc: Kyle McMartin <kyle@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-16ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()Tomeu Vizoso1-2/+22
Allow implementations of the match() callback in struct bus_type to return errors and if it's -EPROBE_DEFER then queue the device for deferred probing. This is useful to buses such as AMBA in which devices are registered before their matching information can be retrieved from the HW (typically because a clock driver hasn't probed yet). [changed if-else code structure, adjusted documentation to match the code, extended comments] Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-02-16PM / OPP: Initialize regulator pointer to an error valueViresh Kumar1-6/+9
We are currently required to do two checks for regulator pointer: IS_ERR() and IS_NULL(). And multiple instances are reported, about both of these not being used consistently and so resulting in crashes. Fix that by initializing regulator pointer with an error value and checking it only against an error. This makes code more consistent and more efficient. Fixes: 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator) Reported-and-tested-by: Jon Hunter <jonathanh@nvidia.com> Reported-and-tested-by: Tony Lindgren <tony@atomide.com> Reported-and-tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Initialize to -ENXIO ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-16PM / Domains: remove old power on/off latenciesAxel Haslam1-7/+1
Now that all known users have been converted to use state latencies, we can remove the latency field in the generic_pm_domain structure. Signed-off-by: Axel Haslam <ahaslam+renesas@baylibre.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-16PM / Domains: Support for multiple statesAxel Haslam2-29/+74
Some hardware (eg. OMAP), has the ability to enter different low power modes for a given power domain. This allows for more fine grained control over the power state of the platform. As a typical example, some registers of the hardware may be implemented with retention flip-flops and be able to retain their state at lower voltages allowing for faster on/off latencies and an increased window of opportunity to enter an intermediate low power state other than "off" When trying to set a power domain to off, the genpd governor will choose the deepest state that will respect the qos constraints of all the devices and sub-domains on the power domain. The state chosen by the governor is saved in the "state_idx" field of the generic_pm_domain structure and shall be used by the power_off and power_on callbacks to perform the necessary actions to set the power domain into (and out of) the state indicated by state_idx. States must be declared in ascending order from shallowest to deepest, deepest meaning the state which takes longer to enter and exit. For platforms that don't declare any states, a single a single "off" state is used. Once all platforms are converted to use the state array, the legacy on/off latencies will be removed. [ Lina: Modified genpd state initialization and remove use of save_state_latency_ns in genpd timing data ] Suggested-by: Kevin Hilman <khilman@linaro.org> Signed-off-by: Lina Iyer <lina.iyer@linaro.org> Signed-off-by: Axel Haslam <ahaslam+renesas@baylibre.com> Acked-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-16PM / OPP: Initialize u_volt_min/max to a valid valueViresh Kumar1-2/+8
We kept u_volt_min/max initialized to 0, when only the target voltage is present in DT, instead of the target/min/max triplet. This didn't go well with the regulator framework, as on few calls the min voltage was set to target and max was set to 0 and so resulted in a kernel crash like below: kernel BUG at ../drivers/regulator/core.c:216! [<c0684af4>] (regulator_check_voltage) from [<c06857ac>] (regulator_set_voltage_unlocked+0x58/0x230) [<c06857ac>] (regulator_set_voltage_unlocked) from [<c06859ac>] (regulator_set_voltage+0x28/0x54) [<c06859ac>] (regulator_set_voltage) from [<c0775b28>] (_set_opp_voltage+0x30/0x98) [<c0775b28>] (_set_opp_voltage) from [<c0776630>] (dev_pm_opp_set_rate+0xf0/0x28c) [<c0776630>] (dev_pm_opp_set_rate) from [<c096f784>] (__cpufreq_driver_target+0x184/0x2b4) [<c096f784>] (__cpufreq_driver_target) from [<c0973760>] (dbs_check_cpu+0x1b0/0x1f4) [<c0973760>] (dbs_check_cpu) from [<c0973f30>] (cpufreq_governor_dbs+0x324/0x5c4) [<c0973f30>] (cpufreq_governor_dbs) from [<c0970958>] (__cpufreq_governor+0xe4/0x1ec) [<c0970958>] (__cpufreq_governor) from [<c09711e0>] (cpufreq_init_policy+0x64/0x8c) [<c09711e0>] (cpufreq_init_policy) from [<c09718cc>] (cpufreq_online+0x2fc/0x708) [<c09718cc>] (cpufreq_online) from [<c0765ff0>] (subsys_interface_register+0x94/0xd8) [<c0765ff0>] (subsys_interface_register) from [<c0970530>] (cpufreq_register_driver+0x14c/0x19c) [<c0970530>] (cpufreq_register_driver) from [<c09746dc>] (dt_cpufreq_probe+0x70/0xec) [<c09746dc>] (dt_cpufreq_probe) from [<c076907c>] (platform_drv_probe+0x4c/0xb0) [<c076907c>] (platform_drv_probe) from [<c07678e0>] (driver_probe_device+0x214/0x2c0) [<c07678e0>] (driver_probe_device) from [<c0767a18>] (__driver_attach+0x8c/0x90) [<c0767a18>] (__driver_attach) from [<c0765c2c>] (bus_for_each_dev+0x68/0x9c) [<c0765c2c>] (bus_for_each_dev) from [<c0766d78>] (bus_add_driver+0x1a0/0x218) [<c0766d78>] (bus_add_driver) from [<c076810c>] (driver_register+0x78/0xf8) [<c076810c>] (driver_register) from [<c0301d74>] (do_one_initcall+0x90/0x1d8) [<c0301d74>] (do_one_initcall) from [<c1100e14>] (kernel_init_freeable+0x15c/0x1fc) [<c1100e14>] (kernel_init_freeable) from [<c0b27a0c>] (kernel_init+0x8/0xf0) [<c0b27a0c>] (kernel_init) from [<c0307d78>] (ret_from_fork+0x14/0x3c) Code: e1550004 baffffeb e3a00000 e8bd8070 (e7f001f2) Fix that by initializing u_volt_min/max to the target voltage in such cases. Reported-and-tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Fixes: 274659029c9d (PM / OPP: Add support to parse "operating-points-v2" bindings) Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-15Revert "driver-core: platform: probe of-devices only using list of compatibles"Greg Kroah-Hartman1-2/+2
This reverts commit 67d02a1bbb334558e9380409a3cd426b36d4578b This should reallow binding of of-devices by name. It turned out that there are valid reasons (e.g. step by step conversion to device tree probing using auxdata) to bind of-instantiated devices to drivers by name. So revert to the original logic. Reported-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org
2016-02-15regmap: irq: add devm apis for regmap_{add,del}_irq_chipLaxman Dewangan1-0/+82
Add device managed APIs for regmap_add_irq_chip() and regmap_del_irq_chip() so that it can be managed by device framework for freeing it. This helps on following: 1. Maintaining the sequence of resource allocation and deallocation regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq) On free path: regmap_del_irq_chip(d); and then removing the irq registration. On this case, regmap irq is deleted before the irq is free. This force to use normal irq registration. By using devm apis, the sequence can be maintain properly: devm_regmap_add_irq_chip(&d); devm_requested_threaded_irq(virq); and resource deallocation will be done in reverse order by device framework. 2. No need to delete the regmap_irq_chip in error path or remove callback and hence there is less code on this path. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-15Merge 4.5-rc4 into driver-core-nextGreg Kroah-Hartman2-29/+36
We want the fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-15Merge 4.5-rc4 into char-misc-nextGreg Kroah-Hartman6-66/+70
We want those fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-14Merge branch 'component' of git://ftp.arm.linux.org.uk/~rmk/linux-armLinus Torvalds1-21/+28
Pull component helper fixes from Russell King: "A few fixes for problems people have encountered with the recent update to the component helpers" * 'component' of git://ftp.arm.linux.org.uk/~rmk/linux-arm: component: remove device from master match list on failed add component: Detach components when deleting master struct component: fix crash on x86_64 with hda audio drivers
2016-02-12PM / OPP: Fix NULL pointer dereference crash when disabling OPPsJon Hunter1-1/+1
Commit 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator) causes a crash to happen on Tegra124 Jetson TK1 when using the DFLL clock source for the CPU. The DFLL manages the voltage itself and so there is no regulator specified for the OPPs and so we get a crash when we try to dereference the regulator pointer. Fix this by checking to see if the regulator IS_ERR_OR_NULL before dereferencing it. Fixes: 7d34d56ef334 (PM / OPP: Disable OPPs that aren't supported by the regulator) Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-11PM / sleep: declare __tracedata symbols as char[] rather than charEric Biggers1-2/+2
Accessing more than one byte from a symbol declared simply 'char' is undefined behavior, as reported by UBSAN: UBSAN: Undefined behaviour in drivers/base/power/trace.c:178:18 load of address ffffffff8203fc78 with insufficient space for an object of type 'char' Avoid this by declaring the symbols as arrays. Signed-off-by: Eric Biggers <ebiggers3@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-11component: remove device from master match list on failed addDaniel Stone1-0/+2
Calling component_add() may result in the completion of a set of devices, which will try to bring up a master. In bringing the master up, we populate its match array with the current set of children. If binding any of the devices fails, component_add() itself will fail, free the struct component entry, and return to the caller. The now-freed entry is never removed from the master's match array, and will later be used in a futile attempt to bind to freed memory. Bring component_add's behaviour on failure to bring up a master into line with component_del by removing the (to-be-freed) component from the master's match array. The specific case which broke was: - rockchip_drm_drv adds a component master - dwhdmi_rockchip adds a child component in probe (master incomplete) - rockchip_drm_vop adds two children in probe, which completes the set - inside component_add, we try to bring up the master, having populated the master's match array, and fail with EPROBE_DEFER from dwhdmi_rockchip; we delete the putative component - rockchip_drm_vop's probe fails and returns EPROBE_DEFER - we later re-probe rockchip_drm_vop and add the component; the master is complete, so we attempt to bring it up again - walking the match array, we find the previous child, whose master pointer doesn't match (as it has been freed in the meantime) - rockchip_drm_vop probe fails, and will never be attempted again Fixes: ffc30b74fd6d01588bd3fdebc3b1acc0857e6fc8 Signed-off-by: Daniel Stone <daniels@collabora.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Thierry Reding <treding@nvidia.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-02-10driver-core: platform: probe of-devices only using list of compatiblesUwe Kleine-König1-2/+2
There are several indications that make a platform device match a platform driver. For devices that are instantiated by a device tree matching by name, id table or acpi mechanisms doesn't make sense and might result in surprising effects. So limit matching to use the driver's of_match_table for these. Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-10component: remove impossible conditionSudip Mukherjee1-1/+1
We will be evaluating this condition only if match->num == match->alloc and that means we have already dereferenced match which implies match can not be NULL at this point. Moreover we have done a NULL check on match just before this. Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-10drivers: dma-coherent: simplify dma_init_coherent_memory return valueMichal Nazarewicz1-17/+11
Since only dma_declare_coherent_memory cares about dma_init_coherent_memory returning part of flags as it return value, move the condition to the former and simplify the latter. This in turn makes rmem_dma_device_init less confusing. Reported-by: Fugang Duan <B38611@freescale.com> Signed-off-by: Michal Nazarewicz <mina86@mina86.com> Acked-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-10driver core: bus: use to_subsys_private and to_device_private_busGeliang Tang1-3/+2
Use to_subsys_private() and to_device_private_bus() instead of open-coding. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-10driver core: bus: use list_for_each_entry*Geliang Tang1-7/+3
Use list_for_each_entry*() instead of list_for_each*() to simplify the code. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-10PM / OPP: Add dev_pm_opp_set_rate()Viresh Kumar1-0/+176
This adds a routine, dev_pm_opp_set_rate(), responsible for configuring power-supply and clock source for an OPP. The OPP is found by matching against the target_freq passed to the routine. This shall replace similar code present in most of the OPP users and help simplify them a lot. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-10PM / OPP: Manage device clkViresh Kumar2-0/+18
OPP core has got almost everything now to manage device's OPP transitions, the only thing left is device's clk. Get that as well. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-10PM / OPP: Parse clock-latency and voltage-tolerance for v1 bindingsViresh Kumar2-0/+26
V2 bindings have better support for clock-latency and voltage-tolerance and doesn't need special care. To use callbacks, like dev_pm_opp_get_max_{transition|volt}_latency(), irrespective of the bindings, the core needs to know clock-latency/voltage-tolerance for the earlier bindings. This patch reads clock-latency/voltage-tolerance from the device node, irrespective of the bindings (to keep it simple) and use them only for V1 bindings. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-10PM / OPP: Introduce dev_pm_opp_get_max_transition_latency()Viresh Kumar1-0/+17
In few use cases (like: cpufreq), it is desired to get the maximum latency for changing OPPs. Add support for that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-10PM / OPP: Introduce dev_pm_opp_get_max_volt_latency()Viresh Kumar1-0/+59
In few use cases (like: cpufreq), it is desired to get the maximum voltage latency for changing OPPs. Add support for that. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-10PM / OPP: Disable OPPs that aren't supported by the regulatorViresh Kumar1-0/+22
Disable any OPPs where the connected regulator isn't able to provide the specified voltage. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-10PM / OPP: get/put regulators from OPP coreViresh Kumar2-0/+115
This allows the OPP core to request/free the regulator resource, attached to a device OPP. The regulator device is fetched using the name provided by the driver, while calling: dev_pm_opp_set_regulator(). This will work for both OPP-v1 and v2 bindings. This is a preliminary step for moving the OPP switching logic into the OPP core. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-09regmap: irq: dispose all virtual irq before removing domainLaxman Dewangan1-0/+21
It is require to dispose all virtual irq of hwirq on chip created on given irq domain before removing this irq domain. Hence dispose all mapped irqs before deleting the irq domains in regmap_del_irq_chip(); Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-09firmware: Change the page arrary alloc to vmallocChen Feng1-5/+4
No need to use use continuous memory, it may be fail when memory deeply fragmented. Signed-off-by: Chen Feng <puck.chen@hisilicon.com> Signed-off-by: Xia Qing <saberlily.xia@hisilicon.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-09firmware: simplify dev_*() print messages for generic helpersLuis R. Rodriguez1-4/+4
Simplify a few of the *generic* shared dev_warn() and dev_dbg() print messages for three reasons: 0) Historically firmware_class code was added to help get device driver firmware binaries but these days request_firmware*() helpers are being repurposed for general *system data* needed by the kernel. 1) This will also help generalize shared code as much as possible later in the future in consideration for a new extensible firmware API which will enable to separate usermode helper code out as much as possible. 2) Kees Cook pointed out the the prints already have the device associated as dev_*() helpers are used, that should help identify the user and case in which the helpers are used. That should provide enough context and simplifies the messages further. v4: generalize debug/warn messages even further as suggested by Kees Cook. Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Howells <dhowells@redhat.com> Cc: Casey Schaufler <casey@schaufler-ca.com> Cc: Ming Lei <ming.lei@canonical.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Vojtěch Pavlík <vojtech@suse.cz> Cc: Kyle McMartin <kyle@kernel.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: Luis R. Rodriguez <mcgrof@kernel.org> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-02-08Merge tag 'regmap-fix-v4.5-big-endian' of ↵Linus Torvalds1-8/+8
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap Pull regmap fix from Mark Brown: "A single revert back to v4.4 endianness handling. Commit 29bb45f25ff3 ("regmap-mmio: Use native endianness for read/write") attempted to fix some long standing bugs in the MMIO implementation for big endian systems caused by duplicate byte swapping in both regmap and readl()/writel(). Sadly the fix makes things worse rather than better, so revert it for now" * tag 'regmap-fix-v4.5-big-endian' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap: regmap: mmio: Revert to v4.4 endianness handling
2016-02-06Merge branches 'pm-core' and 'pm-domains'Rafael J. Wysocki2-21/+8
* pm-core: PM: Avoid false-positive warnings in dev_pm_domain_set() ACPI / LPSS: set PM domain via helper setter * pm-domains: PM / Domains: Silence compiler warning for an unused function
2016-02-05regmap: mmio: Revert to v4.4 endianness handlingMark Brown1-8/+8
Commit 29bb45f25ff3 (regmap-mmio: Use native endianness for read/write) attempted to fix some long standing bugs in the MMIO implementation for big endian systems caused by duplicate byte swapping in both regmap and readl()/writel() which affected MIPS systems as when they are in big endian mode they flip the endianness of all registers in the system, not just the CPU. MIPS systems had worked around this by declaring regmap using IPs as little endian which is inaccurate, unfortunately the issue had not been reported. Sadly the fix makes things worse rather than better. By changing the behaviour to match the documentation it caused behaviour changes for other IPs which broke them and by using the __raw I/O accessors to avoid the endianness swapping in readl()/writel() it removed some memory ordering guarantees and could potentially generate unvirtualisable instructions on some architectures. Unfortunately sorting out all this mess in any half way sensible fashion was far too invasive to go in during an -rc cycle so instead let's go back to the old broken behaviour for v4.5, the better fixes are already queued for v4.6. This does mean that we keep the broken MIPS DTs for another release but that seems the least bad way of handling the situation. Reported-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-03PM: Avoid false-positive warnings in dev_pm_domain_set()Rafael J. Wysocki1-1/+1
There is a WARN_ON() in dev_pm_domain_set() that triggers on attempts to set the pm_domain pointer for devices with a driver bound. However, that WARN_ON() triggers on attempts to clear the pointer too and the test it uses is based on checking the device's p->knode_driver pointer which still is set when the device bus type's/driver's ->remove callback has been executed. This leads to false-positive warnings when bus type code calls dev_pm_domain_set() to clear the pm_domain pointer after invoking the driver's ->remove() callback. To avoid those false-positives, make dev_pm_domain_set() check if the pointer passed to it is NULL and skip the warning in that case. Fixes: 989561de9b51 (PM / Domains: add setter for dev.pm_domain) Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Sinan Kaya <okaya@codeaurora.org> Tested-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-02-03PM / Domains: Silence compiler warning for an unused functionUlf Hansson1-20/+7
The only remaining caller of genpd_poweron() is conditionally compiled based on CONFIG_PM_GENERIC_DOMAINS_OF, so we get a warning when that is unset. By moving the locking/unlocking of the genpd outside genpd_poweron(), thus to the caller, genpd_poweron() becomes redundant. Within this context let's then rename the wrapper function, __genpd_poweron(), to genpd_poweron() as it will then be consistent with its friend genpd_poweroff(). This change silence the warning about the unused function. Reported-by: Arnd Bergmann <arnd@arndb.de> Fixes: ea823c7cbffa "PM / Domains: Remove pm_genpd_poweron() API" Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Arnd Bergmann <arnd@arndb.de> Cc: 4.4+ <stable@vger.kernel.org> # 4.4+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-02-02regmap: cache: Fall back to register by register read for cache defaultsMark Brown1-11/+30
If we are unable to read the cache defaults for a regmap then fall back on attempting to read them word by word. This is going to be painfully slow for large regmaps but might be adequate for smaller ones. Signed-off-by: Mark Brown <broonie@kernel.org> [maciej: Use cache_bypass around read and skipping of unreadable regs] Signed-off-by: Maciej S. Szmigiero <mail@maciej.szmigiero.name> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Tested-by: Fabio Estevam <fabio.estevam@nxp.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-02regmap: Return an error if a caller attempts to do an unsupported raw readMark Brown1-0/+3
regmaps without raw I/O access can't implement raw I/O operations, return an error if someone tries to do that rather than crashing. Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-01Merge tag 'driver-core-4.5-rc2' of ↵Linus Torvalds1-4/+9
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core fix from Greg KH: "Here's a single driver core fix that resolves an issue a lot of users have been hitting for a while now. It's been tested a lot and has been in linux-next successfully for a while" * tag 'driver-core-4.5-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: base/platform: Fix platform drivers with no probe callback
2016-02-01Merge branch 'irq-urgent-for-linus' of ↵Linus Torvalds1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull IRQ fixes from Ingo Molnar: "Mostly irqchip driver fixes, but also an irq core crash fix and a build fix" * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: irqchip/mxs: Add missing set_handle_irq() irqchip/atmel-aic: Fix wrong bit operation for IRQ priority irqchip/gic-v3-its: Recompute the number of pages on page size change base: Export platform_msi_domain_[alloc,free]_irqs of: MSI: Simplify irqdomain lookup irqdomain: Allow domain lookup with DOMAIN_BUS_WIRED token irqchip: Fix dependencies for archs w/o HAS_IOMEM irqchip/s3c24xx: Mark init_eint as __maybe_unused genirq: Validate action before dereferencing it in handle_irq_event_percpu()
2016-01-29Merge branches 'pm-cpuidle', 'pm-cpufreq', 'pm-domains' and 'pm-sleep'Rafael J. Wysocki1-17/+20
* pm-cpuidle: cpuidle: coupled: remove unused define cpuidle_coupled_lock cpuidle: fix fallback mechanism for suspend to idle in absence of enter_freeze * pm-cpufreq: cpufreq: cpufreq-dt: avoid uninitialized variable warnings: cpufreq: pxa2xx: fix pxa_cpufreq_change_voltage prototype cpufreq: Use list_is_last() to check last entry of the policy list cpufreq: Fix NULL reference crash while accessing policy->governor_data * pm-domains: PM / Domains: Fix typo in comment PM / Domains: Fix potential deadlock while adding/removing subdomains PM / domains: fix lockdep issue for all subdomains * pm-sleep: PM: APM_EMULATION does not depend on PM
2016-01-28PM / Domains: Fix typo in commentMoritz Fischer1-1/+1
Acked-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-28PM / Domains: Fix potential deadlock while adding/removing subdomainsUlf Hansson1-8/+6
We must preserve the same order of how we acquire and release the lock for genpd, as otherwise we may encounter deadlocks. The power on phase of a genpd starts by acquiring its lock. Then it walks the hierarchy of its parent domains to be able to power on these first, as per design of genpd. From a locking perspective this means the locks of the parents becomes acquired after the lock of the subdomain. Let's fix pm_genpd_add|remove_subdomain() to maintain the same order of acquiring/releasing the genpd lock as being applied in the power on/off sequence. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2016-01-27regmap: mmio: Convert to regmap_bus and fix accessor usageMark Brown1-120/+139
Currently regmap-mmio uses the __raw accessors to read and write from memory. This is not safe as these interact poorly with spinlocks and are not guaranteed to generate emulated instructions on at least ARM where regmap is commonly used. The APIs that are provided all provide some byte swapping so this is difficult to do with the current regmap-mmio implementation which attempts to use the regmap core byte swapping. We can fix this by modernising the MMIO implementation to use reg_read() and reg_write() operations which were added after the API was implemented and pass simple unsigned integers through to the bus, making use of the formatting provided by the I/O accessors using a similar pattern to that used by the core. This will be less efficient for block I/O operations since we now enable and disable any required clocks per register but it is not clear that any users of regmap-mmio actually use block I/O and there is room to optimise later. This removes support for big endian I/O on 64 bit registers since no I/O accessors are provided, no current users were found and support can be added easily once they are available. In addition make the default endianness little endian. This was the behaviour prior to 29bb45f25ff305 (regmap-mmio: Use native endianness for read/write) and is the behaviour desired by most existing users, the users have been audited and those that need native endianness converted to request it explicitly. Previously native was documented as the default but due to the byte swapping in the accessors this was not correctly implemented. Fixes: 29bb45f25ff305 (regmap-mmio: Use native endianness for read/write) Reported-by: Johannes Berg <johannes@sipsolutions.net> Tested-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-01-27component: Detach components when deleting master structJon Medhurst (Tixy)1-19/+22
component_master_add_with_match calls find_components which, if any components already exist, it attaches to the master struct. However, if we later encounter an error the master struct is deleted, leaving components with a dangling pointer to it. If the error was a temporary one, e.g. for probe deferral, then when the master device is re-probed, it will fail to find the required components as they appear to already be attached to a master. Fix this by nulling components pointers to the master struct when it is deleted. This code is factored out into a separate function so it can be shared with component_master_del. Signed-off-by: Jon Medhurst <tixy@linaro.org> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>