aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/patch-kernel
diff options
context:
space:
mode:
Diffstat (limited to 'scripts/patch-kernel')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2026-02-02 13:42:03 +0000
18-12-11regulator: da9211: Hand over GPIO to regulator coreLinus Walleij1-0/+6 The GPIO descriptors used by the DA9211 driver are retrieved during probe() and it is really helpful to have those under devres management because of all the errorpaths in the intialization. Using the new dev_gpiod_unhinge() call we can remove the devres management of the descriptor right before handing it over to the regulators core. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11regulator: max8973: Let core handle GPIO descriptorLinus Walleij1-1/+7 The probe path of this driver is a bit complex: sometimes the GPIO descriptor is passed to the regulator core, sometimes it is not. To handle it in a simple way: stick with the devm_* resource management and unhinge the GPIO descriptor devres handling right before passing it to the regulator core, if we pass it to the regulator core. Fixes: e7d2be696faa ("regulator: max8973: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11gpio: Add devm_gpiod_unhinge()Linus Walleij3-0/+41 This adds a function named devm_gpiod_unhinge() that removes the resource management from a GPIO descriptor. I am not sure if this is the best anglosaxon name for the function, no other managed resources have an equivalent currently, but I chose "unhinge" as the closest intuitive thing I could imagine that fits Rusty Russell's API design criterions "the obvious use is the correct one" and "the name tells you how to use it". The idea came out of a remark from Mark Brown that it should be possible to handle over management of a resource from devres to the regulator core, and indeed we can do that. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11gpio: devres: Handle nonexclusive GPIOsLinus Walleij1-12/+38 When we get a nonexeclusive GPIO descriptor using managed resources, we should only add it to the list of managed resources once: on the first user. Augment the devm_gpiod_get_index() and devm_gpiod_get_from_of_node() calls to account for this by checking if the descriptor is already resource managed before we proceed to allocate a new resource management struct. Fixes: b0ce7b29bfcd ("regulator/gpio: Allow nonexclusive GPIO access") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11gpio: Enable nonexclusive gpiods from DT nodesLinus Walleij1-0/+2 This makes gpiod_get_from_of_node() respect the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which is especially nice when getting regulator GPIOs right out of device tree nodes. Suggested-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: b0ce7b29bfcd ("regulator/gpio: Allow nonexclusive GPIO access") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11regulator: max77686: Let core handle GPIO descriptorLinus Walleij1-5/+9 Use the gpiod_get_from_of_node() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fix up the errorpath so that we free this descriptor if an error occurs in the callback. Rely on the regulator core to deal with it after this point: a previous patch fixed up the regulator core to properly dispose any GPIO descriptors once you call regulator_register(). Fixes: 96392c3d8ca4 ("regulator: max77686: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11gpio: Export gpiod_get_from_of_node()Linus Walleij2-6/+13 This function already exist inside gpiolib, we were just reluctant to make it available to the kernel at large as the devm_* seemed to be enough for anyone. However we found out that regulators need to do their own lifecycle/refcounting on GPIO descriptors and explicitly call gpiod_put() when done with a descriptor, so export this function so we can hand the refcounting over to the regulator core for these descriptors after retrieveal. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11regulator: max8952: Let core handle GPIO descriptorLinus Walleij1-3/+7 Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: d7a261c2d1f2 ("regulator: max8952: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11regulator: lp8788-ldo: Let core handle GPIO descriptorLinus Walleij1-2/+6 Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: 2468f0d51548 ("regulator: lp8788-ldo: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11regulator: lm363x: Let core handle GPIO descriptorLinus Walleij1-2/+6 Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: b2d751b7f69b ("regulator: lm363x: Pass descriptor instead of GPIO number") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11regulator: fixed: Let core handle GPIO descriptorLinus Walleij1-1/+5 Use the gpiod_get() rather than the devm_* version so that the regulator core can handle the lifecycle of these descriptors. Fixes: efdfeb079cc3 ("regulator: fixed: Convert to use GPIO descriptor only") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-11regulator: core: Track dangling GPIO descriptorsLinus Walleij1-10/+45 If a GPIO descriptor is passed to the regulator_register() function inside the config->ena_gpiod callers must be sure that once they call this API the regulator core owns that descriptor and will make sure to issue gpiod_put() on it, no matter whether the call is successful or not. For device tree regulators, the regulator core will automatically set up regulator init data from the device tree when registering a regulator by calling regulator_of_get_init_data() which in turn calls down to the regulator driver's .of_parse_cb() callback. This callback (in drivers such as for max77686) may also choose to fill in the config->ena_gpiod field with a GPIO descriptor. Harden the errorpath of regulator_register() to properly gpiod_put() any passed in cfg->ena_gpiod or any gpiod coming from the device tree on any type of error. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-06regulator: Use of_node_name_eq for node name comparisonsRob Herring6-6/+6 Convert string compares of DT node names to use of_node_name_eq helper instead. This removes direct access to the node name pointer. For instances using of_node_cmp, this has the side effect of now using case sensitive comparisons. This should not matter for any FDT based system which all of these are. Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: Support Opensource <support.opensource@diasemi.com> Cc: Sangbeom Kim <sbkim73@samsung.com> Cc: Krzysztof Kozlowski <krzk@kernel.org> Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-04regulator: Allow regulator nodes to contain their own init dataCharles Keepax1-2/+6 Currently it is expected that regulator init data will be defined as a series of sub-nodes from the node that bound in the driver. Add support for a node to both bind in a driver and contain init data for that regulator. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-04regulator: Factor out location of init data OF nodeCharles Keepax1-27/+37 To support future additions factor out the location of the OF node containing the init data for the regulator from the code that parses the init data. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-12-03regulator: stpmic1: fix regulator_lock usagePascal PAILLET-LME1-1/+1 fix a compilation issue due to regulator_lock usage. Signed-off-by: Pascal Paillet <p.paillet@st.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-11-26regulator: core: Apply system load even if no consumer loadsDouglas Anderson1-0/+6 Prior to commit 5451781dadf8 ("regulator: core: Only count load for enabled consumers") we used to always add up the total load on every enable in _regulator_enable(). After that commit we only updated the total load when enabling / disabling a regulator where a consumer specified a load or when changing the consumer load on an enabled regulator. The problem with the new scheme is that if there is a system load specified for a regulator but no consumers specify a load then we never account for it. Let's account for the system load in set_machine_constraints(). NOTE: with the new scheme we end up with a bit of a quandry. What if someone specifies _both_ an initial mode and a system load? If we take the system load into account right at init time then it will effectively clobber the initial mode. We'll resolve this by saying that if both are specified then the initial mode will win. The system load will then only take effect if/when a consumer specifies a load. If no consumers ever specify a load then the initial mode will persist and the system load will have no effect. Fixes: 5451781dadf8 ("regulator: core: Only count load for enabled consumers") Reported-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Brian Masney <masneyb@onstation.org> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-11-22spi: spi-qcom-qspi: Fix remaining driver nitsRyan Case1-4/+4 Address remaining comments from original driver patch series * Move RD_FIFO_CFG to be ordered corretly * Expand spinlock comment Signed-off-by: Ryan Case <ryandcase@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-11-22regulator: core: Avoid propagating to supplies when possibleDouglas Anderson1-7/+7 When we called regulator_enable() on a regulator we'd end up propagating that call all the way up the chain every time. This is a bit of a waste of time. A child regulator already refcounts its own enables so it should avoid passing on to its parent unless the refcount transitioned between 0 and 1. Historically this hasn't been a huge problem since we skipped dealing with enable for always-on regulators. In a previous patch, however, we removed the always-on optimization. On one system, the debugfs regulator_summary was now showing a "use_count" of 33 for a top-level regulator. Let's implement this optimization. This turns out to be fairly trivial with the recent reorganization of the regulator core. NOTE: as part of this patch I'll make "always-on" regulators start with a use count of 1. This keeps the counts clean when recursively resolving regulators. ALSO NOTE: this commit also contains somewhat of a bug fix to regulator_force_disable(). It was incorrectly looping over "rdev->open_count" when it should have been looping over use_count. We have to touch that code anyway (since we should no longer loop at all), so we'll fix it together in one patch. Also: since this comes after commit f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking") we can now move to use _regulator_disable() for our supply and keep it in the lock. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-11-22regulator: core: Only count load for enabled consumersDouglas Anderson3-52/+144 In general when the consumer of a regulator requests that the regulator be disabled it no longer will be drawing much load from the regulator--it should just be the leakage current and that should be very close to 0. Up to this point the regulator framework has continued to count a consumer's load request for disabled regulators. This has led to code patterns that look like this: enable_my_thing(): regular_set_load(reg, load_uA) regulator_enable(reg) disable_my_thing(): regulator_disable(reg) regulator_set_load(reg, 0) Sometimes disable_my_thing() sets a nominal (<= 100 uA) load instead of setting a 0 uA load. I will make the assertion that nearly all (if not all) places where we set a nominal load of 100 uA or less we end up with a result that is the same as if we had set a load of 0 uA. Specifically: - The whole point of setting the load is to help set the operating mode of the regulator. Higher loads may need less efficient operating modes. - The only time this matters at all is if there is another consumer of the regulator that wants the regulator on. If there are no other consumers of the regulator then the regulator will turn off and we don't care about the operating mode. - If there's another consumer that actually wants the regulator on then presumably it is requesting a load that makes our nominal <= 100 uA load insignificant. A quick survey of the existing callers to regulator_set_load() to see how everyone uses it: Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-11-21regulator: wm8994: Don't use devres for enable GPIOsCharles Keepax1-5/+9 The regulator core takes over managing the lifetime of the enable GPIO once the regulator is registered. As such we shouldn't register the enable GPIO using devm, or it will be freed twice. Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Mark Brown <broonie@kernel.org> 2018-11-20regulator: core: Properly expose requested_microamps in sysfsDouglas Anderson1-4/+0 The "requested_microamps" sysfs attribute was only being exposed for "current" regulators. This didn't make sense. Allow it to be exposed always. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>