- 24 Dec, 2021 1 commit
-
-
Marijn Suijten authored
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: 390af53e ("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.orgSigned-off-by:
Mark Brown <broonie@kernel.org>
-
- 21 Dec, 2021 1 commit
-
-
Rob Herring authored
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.orgSigned-off-by:
-
- 15 Dec, 2021 2 commits
-
-
Hans de Goede authored
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.comSigned-off-by:
-
Mark Brown authored
Merge tag 'platform-drivers-x86-int3472-1' of 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.
-
- 13 Dec, 2021 10 commits
-
-
Minghao Chi authored
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.cnSigned-off-by:
-
Hans de Goede authored
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:
-
Hans de Goede authored
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:
-
Hans de Goede authored
Pass tps68470_clk_platform_data to the tps68470-clk MFD-cell, so that sensors which use the TPS68470 can find their clock. Reviewed-by:
-
Hans de Goede authored
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:
-
Hans de Goede authored
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:
-
Hans de Goede authored
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:
-
Hans de Goede authored
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:
Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by:
Wolfram Sang <wsa@kernel.org> Signed-off-by:
-
Hans de Goede authored
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:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
Hans de Goede authored
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:
-
- 07 Dec, 2021 3 commits
-
-
Yanteng Si authored
Since 89a6a5e5("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.cnSigned-off-by:
-
Thierry Reding authored
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:
-
Thierry Reding authored
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:
Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211206153432.226963-1-thierry.reding@gmail.comSigned-off-by:
-
- 01 Dec, 2021 2 commits
-
-
Vinod Koul authored
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.orgSigned-off-by:
-
Vinod Koul authored
Add compatible string for PM8450 used in SM8450 boards. Signed-off-by:
-
- 30 Nov, 2021 4 commits
-
-
Adam Ward authored
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:
-
Adam Ward authored
Clean away information from a test that was included accidentally Signed-off-by:
-
Adam Ward authored
Add the DA9141 and DA9142 regulators device recognition data and operational parameters. Signed-off-by:
-
Adam Ward authored
Prevent changing current limit when enabled as a precaution against possibile instability due to tight integration with switching cycle Signed-off-by:
-
- 29 Nov, 2021 2 commits
-
-
Satya Priya authored
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.comSigned-off-by:
-
Satya Priya authored
Add compatible string for pmg1110 pmic. Signed-off-by:
-
- 26 Nov, 2021 2 commits
-
-
Dominik Kobinski authored
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.comSigned-off-by:
-
Dominik Kobinski authored
Suggested-by:
-
- 24 Nov, 2021 4 commits
-
-
Matti Vaittinen authored
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@fedoraSigned-off-by:
-
Matti Vaittinen authored
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 authored
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 authored
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: 7111c6d1 ("regulator: IRQ based event/error notification helpers") Signed-off-by:
-
- 23 Nov, 2021 1 commit
-
-
Matti Vaittinen authored
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: 8b6e8855 ("regulator: rohm-regulator: add helper for restricted voltage setting") Signed-off-by:
-
- 18 Nov, 2021 3 commits
-
-
Matti Vaittinen authored
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 authored
Use common restricted voltage setting instead of implementing own. Signed-off-by:
-
Matti Vaittinen authored
Few ROHM PMICs have regulators where voltage setting can be done only when regulator is disabled. Add helper for those PMICs. Signed-off-by:
-
- 16 Nov, 2021 1 commit
-
-
Uwe Kleine-König authored
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.deSigned-off-by:
-
- 14 Nov, 2021 4 commits
-
-
Linus Torvalds authored
-
Gustavo A. R. Silva authored
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/236Co-developed-by:
Kees Cook <keescook@chromium.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:
-
git://git.kernel.org/pub/scm/fs/xfs/xfs-linuxLinus Torvalds authored
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 -
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linuxLinus Torvalds authored
Pull more parisc fixes from Helge Deller: "Fix a build error in stracktrace.c, fix resolving of addresses to function names in backtraces, fix single-stepping in assembly code and flush userspace pte's when using set_pte_at()" * tag 'for-5.16/parisc-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux: parisc/entry: fix trace test in syscall exit path parisc: Flush kernel data mapping in set_pte_at() when installing pte for user page parisc: Fix implicit declaration of function '__kernel_text_address' parisc: Fix backtrace to always include init funtion names
-
