Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ https://git.shady.money/linux/atom?h=v3.14 2014-03-04T16:41:42Z 2014-03-04T16:41:42Z Linus Torvalds torvalds@linux-foundation.org 2014-03-04T16:41:42Z urn:sha1:16e3f5391c23a52a91a11ee4f2661a625b36dfe1 Pull regulator fixes from Mark Brown: "A couple of fixes here which ensure that regulators using the core support for GPIO enables work in all cases by ensuring that helpers are used consistently rather than open coding in places and hence not having GPIO support in some of them" * tag 'regulator-v3.14-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: core: Replace direct ops->disable usage regulator: core: Replace direct ops->enable usage 2014-02-25T01:31:45Z Markus Pargmann mpa@pengutronix.de 2014-02-20T16:36:04Z urn:sha1:66fda75f47dc583f1c187556e9a2c082dd64f8c6 There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org> 2014-02-25T01:31:25Z Markus Pargmann mpa@pengutronix.de 2014-02-20T16:36:03Z urn:sha1:30c219710358c5cca2f8bd2e9e547c6aadf7cf8b There are some direct ops->enable in the regulator core driver. This is a potential issue as the function _regulator_do_enable() handles gpio regulators and the normal ops->enable calls. These gpio regulators are simply ignored when ops->enable is called directly. One possible bug is that boot-on and always-on gpio regulators are not enabled on registration. This patch replaces all ops->enable calls by _regulator_do_enable. [Handle missing enable operations -- broonie] Cc: <stable@vger.kernel.org> # 3.10+ Signed-off-by: Markus Pargmann <mpa@pengutronix.de> Signed-off-by: Mark Brown <broonie@linaro.org> regulator: Handle invalid enable operation for always/boot on regulators Signed-off-by: Mark Brown <broonie@linaro.org> 2014-02-23T03:22:18Z Mark Brown broonie@linaro.org 2014-02-23T03:22:18Z urn:sha1:bcad2ca37296ab6c09de7975e850cb8f90c44c08 2014-02-23T03:22:18Z Mark Brown broonie@linaro.org 2014-02-23T03:22:18Z urn:sha1:f29d778fa47aacb4b0e7dede603756ac782c9391 2014-02-22T02:54:17Z Krzysztof Kozlowski k.kozlowski@samsung.com 2014-02-21T12:12:38Z urn:sha1:08221fc4e7aa585a59de90c0354da3e8d3e88d94 This fixes bug introduced in 667a6b7a (regulator: max14577: Add missing of_node_put). The DTS parsing function returned number of matched regulators as success status which then was compared against 0 in probe. Result was a probe fail after successful parsing the DTS: max14577-regulator: probe of max14577-regulator failed with error 2 Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviwed-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> 2014-02-20T23:35:31Z Shuah Khan shuah.kh@samsung.com 2014-02-20T19:58:15Z urn:sha1:acc3d5cec84f82ebea535fa0bd9500ac3df2aee9 Change "dummy supplies not allowed" error message to warning instead, as this is a just warning message with no change to the behavior. [Added a CC to stable since some other bug fixes cause this to come up more frequently on PCs which is how it was noticed -- broonie] Signed-off-by: Shuah Khan <shuah.kh@samsung.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org 2014-02-13T18:25:40Z Sachin Kamat sachin.kamat@linaro.org 2014-02-13T11:35:07Z urn:sha1:b7db01f3b3b86f6b02a98756a051d176610ca0f1 Add of_node_put to decrement the ref count. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> 2014-02-13T18:25:40Z Sachin Kamat sachin.kamat@linaro.org 2014-02-13T11:35:06Z urn:sha1:4e52c03dfcdef5ad1415e18af0e7230d98ff3a7c of_find_node_by_name walks the allnodes list, and can thus walk outside of the parent node. Use of_get_child_by_name instead. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Mark Brown <broonie@linaro.org> 2014-02-12T15:14:37Z Steve Twiss stwiss.opensource@diasemi.com 2014-02-12T09:57:52Z urn:sha1:ebf6dad0de89677aa58a4d8b009014ff88a23452 Bug fix to allow the setting of maximum voltage for certain LDOs. What the bug is: There is a problem caused by an invalid calculation of n_voltages in the driver. This n_voltages value has the potential to be different for each regulator. The value for linear_min_sel is set as DA9063_V##regl_name# which can be different depending upon the regulator. This is chosen according to the following definitions in the DA9063 registers.h file: DA9063_VLDO1_BIAS 0 DA9063_VLDO2_BIAS 0 DA9063_VLDO3_BIAS 0 DA9063_VLDO4_BIAS 0 DA9063_VLDO5_BIAS 2 DA9063_VLDO6_BIAS 2 DA9063_VLDO7_BIAS 2 DA9063_VLDO8_BIAS 2 DA9063_VLDO9_BIAS 3 DA9063_VLDO10_BIAS 2 DA9063_VLDO11_BIAS 2 The calculation for n_voltages is valid for LDOs whose BIAS value is zero but this is not correct for those LDOs which have a non-zero value. What the fix is: In order to take into account the non-zero linear_min_sel value which is set for the regulators LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 and LDO11, the calculation for n_voltages should take into account the missing term defined by DA9063_V##regl_name#. This will in turn allow the core constraints calculation to set the maximum voltage limits correctly and therefore allow users to apply the maximum expected voltage to all of the LDOs. Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@linaro.org> Cc: stable@vger.kernel.org