The patch regulator: qcom_spmi: Fix math of spmi_regulator_set_voltage_time_sel has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.3 All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 61d7fdc49f03f4ec990974d1d2a8b05e64afeae4 Mon Sep 17 00:00:00 2001 From: Jeffrey Hugo <jeffrey.l.hugo@xxxxxxxxx> Date: Wed, 19 Jun 2019 11:56:36 -0700 Subject: [PATCH] regulator: qcom_spmi: Fix math of spmi_regulator_set_voltage_time_sel spmi_regulator_set_voltage_time_sel() calculates the amount of delay needed as the result of setting a new voltage. Essentially this is the absolute difference of the old and new voltages, divided by the slew rate. The implementation of spmi_regulator_set_voltage_time_sel() is wrong. It attempts to calculate the difference in voltages by using the difference in selectors and multiplying by the voltage step between selectors. This ignores the possibility that the old and new selectors might be from different ranges, which have different step values. Also, the difference between the selectors may encapsulate N ranges inbetween, so a summation of each selector change from old to new would be needed. Lets avoid all of that complexity, and just get the actual voltage represented by both the old and new selector, and use those to directly compute the voltage delta. This is more straight forward, and has the side benifit of avoiding issues with regulator implementations that don't have hardware register support to get the current configured range. Fixes: e92a4047419c ("regulator: Add QCOM SPMI regulator driver") Reported-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> Reported-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@xxxxxxxxxx> Reported-by: Mark Brown <broonie@xxxxxxxxxx> Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@xxxxxxxxx> Reviewed-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx> Tested-by: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@xxxxxxxxxx> Signed-off-by: Mark Brown <broonie@xxxxxxxxxx> --- drivers/regulator/qcom_spmi-regulator.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/regulator/qcom_spmi-regulator.c b/drivers/regulator/qcom_spmi-regulator.c index 13f83be50076..877df33e0246 100644 --- a/drivers/regulator/qcom_spmi-regulator.c +++ b/drivers/regulator/qcom_spmi-regulator.c @@ -813,14 +813,10 @@ static int spmi_regulator_set_voltage_time_sel(struct regulator_dev *rdev, unsigned int old_selector, unsigned int new_selector) { struct spmi_regulator *vreg = rdev_get_drvdata(rdev); - const struct spmi_voltage_range *range; int diff_uV; - range = spmi_regulator_find_range(vreg); - if (!range) - return -EINVAL; - - diff_uV = abs(new_selector - old_selector) * range->step_uV; + diff_uV = abs(spmi_regulator_common_list_voltage(rdev, new_selector) - + spmi_regulator_common_list_voltage(rdev, old_selector)); return DIV_ROUND_UP(diff_uV, vreg->slew_rate); } -- 2.20.1
