summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* regulator: da9121: Remove surplus DA9141 parametersAdam Ward2022-02-221-4/+0
| | | | | | | | Remove ramp_delay/enable_time values - subject to OTP, incorrect Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/a175201b4a7ea323c6a70d77f7f6d2124bfc0bed.1645489455.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9121: Fix DA914x voltage valueAdam Ward2022-02-221-1/+1
| | | | | | | | Update DA9141/2 max voltage to match spec change Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/9d1ec5b6db70d27f56d05b8a0139fc0840f03e20.1645489455.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: da9121: Fix DA914x current valuesAdam Ward2022-02-221-5/+5
| | | | | | | | Update DA9141/2 ranges to correct errors Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/cd5732c5061ce49dcfbcebb306d12ba1664b4ea6.1645489455.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: core: fix false positive in regulator_late_cleanup()Oliver Barta2022-02-081-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The check done by regulator_late_cleanup() to detect whether a regulator is on was inconsistent with the check done by _regulator_is_enabled(). While _regulator_is_enabled() takes the enable GPIO into account, regulator_late_cleanup() was not doing that. This resulted in a false positive, e.g. when a GPIO-controlled fixed regulator was used, which was not enabled at boot time, e.g. reg_disp_1v2: reg_disp_1v2 { compatible = "regulator-fixed"; regulator-name = "display_1v2"; regulator-min-microvolt = <1200000>; regulator-max-microvolt = <1200000>; gpio = <&tlmm 148 0>; enable-active-high; }; Such regulator doesn't have an is_enabled() operation. Nevertheless it's state can be determined based on the enable GPIO. The check in regulator_late_cleanup() wrongly assumed that the regulator is on and tried to disable it. Signed-off-by: Oliver Barta <oliver.barta@aptiv.com> Link: https://lore.kernel.org/r/20220208084645.8686-1-oliver.barta@aptiv.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: MAX20086: add gpio/consumer.hRandy Dunlap2022-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | max20086-regulator.c needs <linux/gpio/consumer.h> for an enum, some macros, and a function prototype. (seen on ARCH=m68k) Adding this header file fixes multiple build errors: ../drivers/regulator/max20086-regulator.c: In function 'max20086_i2c_probe': ../drivers/regulator/max20086-regulator.c:217:26: error: storage size of 'flags' isn't known 217 | enum gpiod_flags flags; ../drivers/regulator/max20086-regulator.c:261:27: error: 'GPIOD_OUT_HIGH' undeclared (first use in this function); did you mean 'GPIOF_INIT_HIGH'? 261 | flags = boot_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW; | ^~~~~~~~~~~~~~ ../drivers/regulator/max20086-regulator.c:261:44: error: 'GPIOD_OUT_LOW' undeclared (first use in this function); did you mean 'GPIOF_INIT_LOW'? 261 | flags = boot_on ? GPIOD_OUT_HIGH : GPIOD_OUT_LOW; ../drivers/regulator/max20086-regulator.c:262:27: error: implicit declaration of function 'devm_gpiod_get'; did you mean 'devm_gpio_free'? [-Werror=implicit-function-declaration] 262 | chip->ena_gpiod = devm_gpiod_get(chip->dev, "enable", flags); ../drivers/regulator/max20086-regulator.c:217:26: warning: unused variable 'flags' [-Wunused-variable] 217 | enum gpiod_flags flags; Fixes: bfff546aae50 ("regulator: Add MAX20086-MAX20089 driver") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reported-by: kernel test robot <lkp@intel.com> Cc: Watson Chow <watson.chow@avnet.com> Cc: Mark Brown <broonie@kernel.org> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20220115033603.24473-1-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: max20086: fix error code in max20086_parse_regulators_dt()Dan Carpenter2022-01-111-1/+1
| | | | | | | | | | | This code accidentally returns PTR_ERR(NULL) which is success. It should return a negative error code. Fixes: bfff546aae50 ("regulator: Add MAX20086-MAX20089 driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20220111072657.GK11243@kili Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Add MAX20086-MAX20089 driverWatson Chow2022-01-074-1/+349
| | | | | | | | | | | The MAX20086-MAX20089 are dual/quad power protectors for cameras. Add a driver that supports controlling the outputs individually. Additional features, such as overcurrent detection, may be added later if needed. Signed-off-by: Watson Chow <watson.chow@avnet.com> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20220106224350.16957-3-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Mark Brown <broonie@kernel.org>
* dt-bindings: regulators: Add bindings for Maxim MAX20086-MAX20089Laurent Pinchart2022-01-071-0/+106
| | | | | | | | | The MAX20086-MAX20089 are dual/quad power protectors for cameras. Add corresponding DT bindings. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20220106224350.16957-2-laurent.pinchart+renesas@ideasonboard.com Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: qcom_smd: Align probe function with rpmh-regulatorKonrad Dybcio2022-01-061-30/+70
| | | | | | | | | | | | | | | | | | | | | | | The RPMh regulator driver is much newer and gets more attention, which in consequence makes it do a few things better. Update qcom_smd-regulator's probe function to mimic what rpmh-regulator does to address a couple of issues: - Probe defer now works correctly, before it used to, well, kinda just die.. This fixes reliable probing on (at least) PM8994, because Linux apparently cannot deal with supply map dependencies yet.. - Regulator data is now matched more sanely: regulator data is matched against each individual regulator node name and throwing an -EINVAL if data is missing, instead of just assuming everything is fine and iterating over all subsequent array members. - status = "disabled" will now work for disabling individual regulators in DT. Previously it didn't seem to do much if anything at all. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Link: https://lore.kernel.org/r/20211230023442.1123424-1-konrad.dybcio@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: remove redundant ret variableMinghao Chi2022-01-041-4/+2
| | | | | | | | | | | Return value from regmap_update_bits() directly instead of taking this in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Signed-off-by: CGEL ZTE <cgel.zte@gmail.com> Link: https://lore.kernel.org/r/20220104104139.601031-1-chi.minghao@zte.com.cn Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: qcom-labibb: OCP interrupts are not a failure while disabledMarijn Suijten2021-12-241-1/+1
| | | | | | | | | | | | | Receiving the Over-Current Protection interrupt while the regulator is disabled does not count as unhandled/failure (IRQ_NONE, or 0 as it were) but a "fake event", usually due to inrush as the is regulator about to be enabled. Fixes: 390af53e0411 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Link: https://lore.kernel.org/r/20211224113450.107958-1-marijn.suijten@somainline.org Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: dt-bindings: samsung,s5m8767: Move fixed string BUCK9 to 'properties'Rob Herring2021-12-211-1/+2
| | | | | | | | | There's no need for a fixed string like 'BUCK9' to be under 'patternProperties', so move it under 'properties' instead. Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211221120744.1118518-1-robh@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
* regulator: Introduce tps68470-regulator driverHans de Goede2021-12-153-0/+211
| | | | | | | | | | | | | | | | | | | | | The TPS68470 PMIC provides Clocks, GPIOs and Regulators. At present in the kernel the Regulators and Clocks are controlled by an OpRegion driver designed to work with power control methods defined in ACPI, but some platforms lack those methods, meaning drivers need to be able to consume the resources of these chips through the usual frameworks. This commit adds a driver for the regulators provided by the tps68470, and is designed to bind to the platform_device registered by the intel_skl_int3472 module. This is based on this out of tree driver written by Intel: https://github.com/intel/linux-intel-lts/blob/4.14/base/drivers/regulator/tps68470-regulator.c with various cleanups added. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-6-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org>
* Merge tag 'platform-drivers-x86-int3472-1' of ↵Mark Brown2021-12-1514-161/+473
|\ | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 into regulator-5.17 Signed tag for the immutable platform-drivers-x86-int3472 branch This branch contains 5.16-rc1 + the pending ACPI/i2c, tps68570 platform_data and INT3472 driver patches required so that the tps68570 regulator driver can be applied.
| * platform/x86: int3472: Deal with probe ordering issuesHans de Goede2021-12-132-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around this info missing from the ACPI tables on devices where the int3472 driver is used, the int3472 MFD-cell drivers attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. All the sensor ACPI fw-nodes have a _DEP dependency on the INT3472 ACPI fw-node, so to work around these probe ordering issues the ACPI core / i2c-code does not instantiate the I2C-clients for any ACPI devices which have a _DEP dependency on an INT3472 ACPI device until all _DEP-s are met. This relies on acpi_dev_clear_dependencies() getting called by the driver for the _DEP-s when they are ready, add a acpi_dev_clear_dependencies() call to the discrete.c probe code. In the tps68470 case calling acpi_dev_clear_dependencies() is already done by the acpi_gpiochip_add() call done by the driver for the GPIO MFD cell (The GPIO cell is deliberately the last cell created to make sure the clk + regulator cells are already instantiated when this happens). However for proper probe ordering, the clk/regulator cells must not just be instantiated the must be fully ready (the clks + regulators must be registered with their subsystems). Add MODULE_SOFTDEP dependencies for the clk and regulator drivers for the instantiated MFD-cells so that these are loaded before us and so that they bind immediately when the platform-devs are instantiated. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-12-hdegoede@redhat.com
| * platform/x86: int3472: Pass tps68470_regulator_platform_data to the ↵Hans de Goede2021-12-134-1/+199
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tps68470-regulator MFD-cell Pass tps68470_regulator_platform_data to the tps68470-regulator MFD-cell, specifying the voltages of the various regulators and tying the regulators to the sensor supplies so that sensors which use the TPS68470 can find their regulators. Since the voltages and supply connections are board-specific, this introduces a DMI matches int3472_tps68470_board_data struct which contains the necessary per-board info. This per-board info also includes GPIO lookup information for the sensor IO lines which may be connected to the tps68470 GPIOs. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-11-hdegoede@redhat.com
| * platform/x86: int3472: Pass tps68470_clk_platform_data to the ↵Hans de Goede2021-12-131-7/+28
| | | | | | | | | | | | | | | | | | | | | | tps68470-regulator MFD-cell Pass tps68470_clk_platform_data to the tps68470-clk MFD-cell, so that sensors which use the TPS68470 can find their clock. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-10-hdegoede@redhat.com
| * platform/x86: int3472: Add get_sensor_adev_and_name() helperHans de Goede2021-12-133-18/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | The discrete.c code is not the only code which needs to lookup the acpi_device and device-name for the sensor for which the INT3472 ACPI-device is a GPIO/clk/regulator provider. The tps68470.c code also needs this functionality, so factor this out into a new get_sensor_adev_and_name() helper. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-9-hdegoede@redhat.com
| * platform/x86: int3472: Split into 2 driversHans de Goede2021-12-137-120/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The intel_skl_int3472.ko module contains 2 separate drivers, the int3472_discrete platform driver and the int3472_tps68470 I2C-driver. These 2 drivers contain very little shared code, only skl_int3472_get_acpi_buffer() and skl_int3472_fill_cldb() are shared. Split the module into 2 drivers, linking the little shared code directly into both. This will allow us to add soft-module dependencies for the tps68470 clk, gpio and regulator drivers to the new intel_skl_int3472_tps68470.ko to help with probe ordering issues without causing these modules to get loaded on boards which only use the int3472_discrete platform driver. While at it also rename the .c and .h files to remove the cumbersome intel_skl_int3472_ prefix. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-8-hdegoede@redhat.com
| * platform_data: Add linux/platform_data/tps68470.h fileHans de Goede2021-12-131-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the provider-device during probe/registration of the provider device. The TI TPS68470 PMIC is used x86/ACPI devices with the consumer-info missing from the ACPI tables. Thus the tps68470-clk and tps68470-regulator drivers must provide the consumer-info at probe time. Define tps68470_clk_platform_data and tps68470_regulator_platform_data structs to allow the x86 platform code to pass the necessary consumer info to these drivers. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-5-hdegoede@redhat.com
| * i2c: acpi: Add i2c_acpi_new_device_by_fwnode() functionHans de Goede2021-12-132-10/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change i2c_acpi_new_device() into i2c_acpi_new_device_by_fwnode() and add a static inline wrapper providing the old i2c_acpi_new_device() behavior. This is necessary because in some cases we may only have access to the fwnode / acpi_device and not to the matching physical-node struct device *. Suggested-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-4-hdegoede@redhat.com
| * i2c: acpi: Use acpi_dev_ready_for_enumeration() helperHans de Goede2021-12-131-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. To ensure the correct probe-ordering the ACPI core has code to defer the enumeration of consumers affected by this until the providers are ready. Call the new acpi_dev_ready_for_enumeration() helper to avoid enumerating / instantiating i2c-clients too early. Acked-by: Wolfram Sang <wsa@kernel.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-3-hdegoede@redhat.com
| * ACPI: delay enumeration of devices with a _DEP pointing to an INT3472 deviceHans de Goede2021-12-132-5/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The clk and regulator frameworks expect clk/regulator consumer-devices to have info about the consumed clks/regulators described in the device's fw_node. To work around cases where this info is not present in the firmware tables, which is often the case on x86/ACPI devices, both frameworks allow the provider-driver to attach info about consumers to the clks/regulators when registering these. This causes problems with the probe ordering wrt drivers for consumers of these clks/regulators. Since the lookups are only registered when the provider-driver binds, trying to get these clks/regulators before then results in a -ENOENT error for clks and a dummy regulator for regulators. One case where we hit this issue is camera sensors such as e.g. the OV8865 sensor found on the Microsoft Surface Go. The sensor uses clks, regulators and GPIOs provided by a TPS68470 PMIC which is described in an INT3472 ACPI device. There is special platform code handling this and setting platform_data with the necessary consumer info on the MFD cells instantiated for the PMIC under: drivers/platform/x86/intel/int3472. For this to work properly the ov8865 driver must not bind to the I2C-client for the OV8865 sensor until after the TPS68470 PMIC gpio, regulator and clk MFD cells have all been fully setup. The OV8865 on the Microsoft Surface Go is just one example, all X86 devices using the Intel IPU3 camera block found on recent Intel SoCs have similar issues where there is an INT3472 HID ACPI-device, which describes the clks and regulators, and the driver for this INT3472 device must be fully initialized before the sensor driver (any sensor driver) binds for things to work properly. On these devices the ACPI nodes describing the sensors all have a _DEP dependency on the matching INT3472 ACPI device (there is one per sensor). This allows solving the probe-ordering problem by delaying the enumeration (instantiation of the I2C-client in the ov8865 example) of ACPI-devices which have a _DEP dependency on an INT3472 device. The new acpi_dev_ready_for_enumeration() helper used for this is also exported because for devices, which have the enumeration_by_parent flag set, the parent-driver will do its own scan of child ACPI devices and it will try to enumerate those during its probe(). Code doing this such as e.g. the i2c-core-acpi.c code must call this new helper to ensure that it too delays the enumeration until all the _DEP dependencies are met on devices which have the new honor_deps flag set. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20211203102857.44539-2-hdegoede@redhat.com
* | drivers/regulator: remove redundant ret variableMinghao Chi2021-12-131-8/+2
| | | | | | | | | | | | | | | | | | | | Return value from twlreg_write() directly instead of taking this in another redundant variable. Reported-by: Zeal Robot <zealci@zte.com.cn> Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/r/20211213021655.435423-1-chi.minghao@zte.com.cn Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: fix bullet lists of regulator_ops commentYanteng Si2021-12-071-9/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 89a6a5e56c82("regulator: add property parsing and callbacks to set protection limits") which introduced a warning: Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:96: WARNING: Unexpected indentation. Documentation/driver-api/regulator:166: ./include/linux/regulator/driver.h:98: WARNING: Block quote ends without a blank line; unexpected unindent. Let's fix them. Signed-off-by: Yanteng Si <siyanteng@loongson.cn> Link: https://lore.kernel.org/r/20211207123230.2262047-1-siyanteng@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: Fix type of regulator-coupled-max-spread propertyThierry Reding2021-12-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | According to the description and the various uses of this property it is meant to be an array of unsigned 32-bit values, so fixup the type to match that. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211206153726.227464-1-thierry.reding@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: maxim,max8973: Document interrupts propertyThierry Reding2021-12-071-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | One of the examples in the bindings has an interrupts property and the Linux kernel driver has support for requesting an interrupt as well. It looks like the absence from the bindings was just an oversight. Add the property to make sure the examples can be validated. Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Rob Herring <robh@kernel.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211206153432.226963-1-thierry.reding@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: qcom-rpmh: Add support for PM8450 regulatorsVinod Koul2021-12-011-0/+18
| | | | | | | | | | | | | | | | | | Add the rpmh regulators found in PM8450 PMIC Signed-off-by: Vinod Koul <vkoul@kernel.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211201072515.3968843-3-vkoul@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: qcom,rpmh: Add compatible for PM8450Vinod Koul2021-12-011-0/+2
| | | | | | | | | | | | | | | | Add compatible string for PM8450 used in SM8450 boards. Signed-off-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20211201072515.3968843-2-vkoul@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: da9121: Add DA914x binding infoAdam Ward2021-11-301-31/+44
| | | | | | | | | | | | | | | | | | | | Add the configuration for the DA9141 and DA9142 regulators. Also tidy the table, cleaning away superfluous information. Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/9293e3ae4ff8776704257085df65516b81209b87.1638223185.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: da9121: Remove erroneous compatible from bindingAdam Ward2021-11-301-13/+12
| | | | | | | | | | | | | | | | | | Clean away information from a test that was included accidentally Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Acked-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/530a626cee6bc12ff5b4ab16319ac7a1fac6e306.1638223185.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: da9121: Add DA914x supportAdam Ward2021-11-302-5/+124
| | | | | | | | | | | | | | | | | | Add the DA9141 and DA9142 regulators device recognition data and operational parameters. Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/5f5b9b02f07578cd36c6bc266349a56efc9b08d1.1638223185.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: da9121: Prevent current limit change when enabledAdam Ward2021-11-301-0/+5
| | | | | | | | | | | | | | | | | | Prevent changing current limit when enabled as a precaution against possibile instability due to tight integration with switching cycle Signed-off-by: Adam Ward <Adam.Ward.opensource@diasemi.com> Link: https://lore.kernel.org/r/52ee682476004a1736c1e0293358987319c1c415.1638223185.git.Adam.Ward.opensource@diasemi.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: qcom-rpmh: Add PMG1110 regulatorsSatya Priya2021-11-291-0/+9
| | | | | | | | | | | | | | | | Add support for PMG1110 regulators. Signed-off-by: Satya Priya <quic_c_skakit@quicinc.com> Link: https://lore.kernel.org/r/1637668167-31325-3-git-send-email-quic_c_skakit@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | dt-bindings: regulator: Add compatible for pmg1110Satya Priya2021-11-291-0/+1
| | | | | | | | | | | | | | | | Add compatible string for pmg1110 pmic. Signed-off-by: Satya Priya <quic_c_skakit@quicinc.com> Link: https://lore.kernel.org/r/1637668167-31325-2-git-send-email-quic_c_skakit@quicinc.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: qcom_spmi: Add pm8226 regulatorsDominik Kobinski2021-11-261-0/+39
| | | | | | | | | | | | | | | | | | | | | | The PM8226 PMIC is very often seen on MSM8x26 boards. Suggested-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com> Signed-off-by: Dominik Kobinski <dominikkobinski314@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211123181119.2897-1-dominikkobinski314@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | dt-bindings: regulator: qcom: spmi-regulator: Document pm8226 compatibleDominik Kobinski2021-11-261-0/+1
| | | | | | | | | | | | | | Suggested-by: Ivaylo Ivanov <ivo.ivanov.ivanov1@gmail.com> Signed-off-by: Dominik Kobinski <dominikkobinski314@gmail.com> Link: https://lore.kernel.org/r/20211123180816.2835-1-dominikkobinski314@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: rohm-generic: remove unused dummiesMatti Vaittinen2021-11-241-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Function rohm_regulator_set_voltage_sel_restricted() and rohm_regulator_set_dvs_levels() had inlined dummy implementations for cases when the real implementation was not configured in. All of the drivers who issue the call to these functions do SELECT the real implementation from the Kconfig. There should be no cases where the real implementation was not selected by the drivers using these functions - such a situation is likely to be an error which deserves to be noticed at compile-time. These dummies could in theory be used for compile-testing the drivers only (without the generic rohm regulator pieces). However, for such compile testing we should manually drop the selection from KConfig - and I guess that if it does not work out-of-the-box, then it is not going to happen. Especially when there should be no reason to omit compile-testing the generic rohm_regulator part. Crash test dummies. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/YZ3UXXrk/Efe7Scj@fedora Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: irq_helper: Provide helper for trivial IRQ notificationsMatti Vaittinen2021-11-242-1/+42
| | | | | | | | | | | | | | | | | | | | | | Provide a generic map_event helper for regulators which have a notification IRQ with single, well defined purpose. Eg, IRQ always indicates exactly one event for exactly one regulator device. For such IRQs the mapping is trivial. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/603b7ed1938013a00371c1e7ccc63dfb16982b87.1637736436.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: Add regulator_err2notif() helperMatti Vaittinen2021-11-241-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | Help drivers avoid storing both supported notification and supported error flags by supporting conversion from regulator error to notification. This may help saving some bytes. Add helper for finding the regulator notification corresponding to a regulator error. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/eb1755ac0569ff07ffa466cf8912c6fd50e7c7c6.1637736436.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: Drop unnecessary struct memberMatti Vaittinen2021-11-241-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The irq_flags from the regulator IRQ helper description struct was never used. The IRQ flags are passed as parameters to helper registration instead. Remove the unnecessary struct field. Fixes: 7111c6d1b31b ("regulator: IRQ based event/error notification helpers") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/5f6371e178453fa2b165da50452f7db4e986debb.1637736436.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: rohm-generic: iniline stub functionMatti Vaittinen2021-11-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function rohm_regulator_set_voltage_sel_restricted() has a stub implementation. Linux-next testing spot following: include/linux/mfd/rohm-generic.h:93:12: error: 'rohm_regulator_set_voltage_sel_restricted' defined but not used Fix this by inlining the stub. Fixes: 8b6e88555971 ("regulator: rohm-regulator: add helper for restricted voltage setting") Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/YZzEP3S7U15bTDAI@fedora Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: Add units to limit documentationMatti Vaittinen2021-11-181-3/+5
| | | | | | | | | | | | | | | | | | | | | | The documentation for limits used at protection level setting did not mention the units. Fix the units in documentation to match values passed in from device-tree (uV, uA, Kelvin) to avoid confusion. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/111114aca991e41e49a32f89b74e95285f07c1e3.1637233864.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: bd718x7: Use rohm generic restricted voltage settingMatti Vaittinen2021-11-181-25/+4
| | | | | | | | | | | | | | | | Use common restricted voltage setting instead of implementing own. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/5a0ee14852802690241568a29ed19ff9550b0b08.1637233864.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: rohm-regulator: add helper for restricted voltage settingMatti Vaittinen2021-11-182-0/+23
| | | | | | | | | | | | | | | | | | Few ROHM PMICs have regulators where voltage setting can be done only when regulator is disabled. Add helper for those PMICs. Signed-off-by: Matti Vaittinen <matti.vaittinen@fi.rohmeurope.com> Link: https://lore.kernel.org/r/6f51871e9fea611d133b5dd2560f4a7ee1ede9cd.1637233864.git.matti.vaittinen@fi.rohmeurope.com Signed-off-by: Mark Brown <broonie@kernel.org>
* | regulator: da9121: Emit only one error message in .remove()Uwe Kleine-König2021-11-161-2/+2
|/ | | | | | | | | | | | | | When an i2c remove callback fails, the i2c core emits a generic error message and still removes the device. Apart from the message there the return value isn't further used. So don't return an error code after having already emitted a driver specific warning about the problem to prevent two messages about the same issue. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20211116110951.1213566-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
* Linux 5.16-rc1v5.16-rc1Linus Torvalds2021-11-141-2/+2
|
* kconfig: Add support for -Wimplicit-fallthroughGustavo A. R. Silva2021-11-142-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add Kconfig support for -Wimplicit-fallthrough for both GCC and Clang. The compiler option is under configuration CC_IMPLICIT_FALLTHROUGH, which is enabled by default. Special thanks to Nathan Chancellor who fixed the Clang bug[1][2]. This bugfix only appears in Clang 14.0.0, so older versions still contain the bug and -Wimplicit-fallthrough won't be enabled for them, for now. This concludes a long journey and now we are finally getting rid of the unintentional fallthrough bug-class in the kernel, entirely. :) Link: https://github.com/llvm/llvm-project/commit/9ed4a94d6451046a51ef393cd62f00710820a7e8 [1] Link: https://bugs.llvm.org/show_bug.cgi?id=51094 [2] Link: https://github.com/KSPP/linux/issues/115 Link: https://github.com/ClangBuiltLinux/linux/issues/236 Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Co-developed-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* Merge tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds2021-11-144-7/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull xfs cleanups from Darrick Wong: "The most 'exciting' aspect of this branch is that the xfsprogs maintainer and I have worked through the last of the code discrepancies between kernel and userspace libxfs such that there are no code differences between the two except for #includes. IOWs, diff suffices to demonstrate that the userspace tools behave the same as the kernel, and kernel-only bits are clearly marked in the /kernel/ source code instead of just the userspace source. Summary: - Clean up open-coded swap() calls. - A little bit of #ifdef golf to complete the reunification of the kernel and userspace libxfs source code" * tag 'xfs-5.16-merge-5' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux: xfs: sync xfs_btree_split macros with userspace libxfs xfs: #ifdef out perag code for userspace xfs: use swap() to make dabtree code cleaner
| * xfs: sync xfs_btree_split macros with userspace libxfsDarrick J. Wong2021-11-111-0/+4
| | | | | | | | | | | | | | | | Sync this one last bit of discrepancy between kernel and userspace libxfs. Signed-off-by: Darrick J. Wong <djwong@kernel.org> Reviewed-by: Eric Sandeen <sandeen@redhat.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-07 16:03:20 +0100