- 10 Jan, 2024 2 commits
-
-
Chunyan Zhang authored
Add bindings for Unisoc UMS9620 system global registers which provide register maps for clocks. Signed-off-by:
Chunyan Zhang <chunyan.zhang@unisoc.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231215085630.984892-2-chunyan.zhang@unisoc.comSigned-off-by:
Lee Jones <lee@kernel.org>
-
Linus Walleij authored
The sysctrl driver was looking for an instance of the PM2301 charger but this has been deleted from the kernel and is not used with the U8500 systems any more. Drop the string. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231214-ab8500-sysctrl-oneliner-v1-1-fd78a15c0b2f@linaro.orgSigned-off-by:
-
- 13 Dec, 2023 3 commits
-
-
Andy Shevchenko authored
The conversion to CLK_FRAC_DIVIDER_POWER_OF_TWO_PS uses wrong flags in the parameters and hence miscalculates the values in the clock divider. Fix this by applying the flag to the proper parameter. Fixes: 82f53f9e ("clk: fractional-divider: Introduce POWER_OF_TWO_PS flag") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reported-by:
Alex Vinarskis <alex.vinarskis@gmail.com> Link: https://lore.kernel.org/r/20231211111441.3910083-1-andriy.shevchenko@linux.intel.comSigned-off-by:
-
Kunwu Chan authored
devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Fixes: 325bec71 ("mfd: tps6594: Add driver for TI TPS6594 PMIC") Suggested-by:
Kunwu Chan <chentao@kylinos.cn> Link: https://lore.kernel.org/r/20231208033320.49345-1-chentao@kylinos.cnSigned-off-by:
-
Johan Hovold authored
Devicetree node names should be generic; fix up the pm8008 binding example accordingly. Signed-off-by:
Johan Hovold <johan+linaro@kernel.org> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231206111754.7410-5-johan+linaro@kernel.orgSigned-off-by:
-
- 07 Dec, 2023 35 commits
-
-
Johan Hovold authored
The SPMI PMIC sits on an SPMI bus which and has two address cells with no size. Clean up the example by adding a parent SPMI bus node with proper '#address-cells' and '#size-cells' properties, using a define for the second register value, dropping the unnecessary label and increasing the indentation to four spaces. Signed-off-by:
-
Johan Hovold authored
The regulator child nodes do not have unit addresses so drop the incorrect '#address-cells' and '#size-cells' properties from the parent 'regulators' node. Fixes: 352335a6 ("staging: hikey9xx: hisilicon, hi6421-spmi-pmic.yaml: simplify props") Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231206111754.7410-3-johan+linaro@kernel.orgSigned-off-by:
-
Johan Hovold authored
Fix up the SPMI PMIC binding document free text reference which erroneously referred to itself rather than the parent SPMI controller binding as intended. Fixes: 9e591728 ("dt: document HiSilicon SPMI controller and mfd/regulator properties") Signed-off-by:
-
Biju Das authored
Simplify probe() by replacing of_device_get_match_data() and ID lookup for retrieving match data by i2c_get_match_data(). Some minor cleanups: * Remove the trailing comma in the terminator entry for the ID table making code robust against (theoretical) misrebases or other similar things where the new entry goes _after_ the termination without the compiler noticing. * Move OF table near to the user. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20231204124507.124758-1-biju.das.jz@bp.renesas.comSigned-off-by:
-
Kunwu Chan authored
kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Fixes: e15d7f2b ("mfd: syscon: Use a unique name with regmap_config") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20231204092443.2462115-1-chentao@kylinos.cnSigned-off-by:
-
Andy Shevchenko authored
The pci_alloc_irq_vectors() returns a positive number on success. Hence we have to filter the negative numbers for error condition. Update the check accordingly. Fixes: e6951fb78787 ("mfd: intel-lpss: Use PCI APIs instead of dereferencing") Reported-by:Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by:
-
Peter Ujfalusi authored
The core twl chip is probed via i2c and the dev->driver->of_match_table is NULL, causing the driver to fail to probe. This partially reverts: commit 1e0c866887f4 ("mfd: Use device_get_match_data() in a bunch of drivers") Fixes: 1e0c866887f4 ("mfd: Use device_get_match_data() in a bunch of drivers") Signed-off-by:Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20231029114843.15553-1-peter.ujfalusi@gmail.comSigned-off-by:
-
Charles Keepax authored
Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20231130115712.669180-2-ckeepax@opensource.cirrus.comSigned-off-by:
-
Charles Keepax authored
Two ports are missing from the port list, and the wrong port is set to 4 channels. Also the attempt to list them by function is rather misguided, there is nothing in the hardware that fixes a particular port to one function. Factor out the port properties to an actual struct, fixing the missing ports and correcting the port set to 4 channels. Fixes: ace6d144 ("mfd: cs42l43: Add support for cs42l43 core driver") Signed-off-by:
-
Kaihua Zhong authored
Fix four comment typos in MFD PMIC header files. Reported-by:
k2ci <kernel-bot@kylinos.cn> Signed-off-by:
Kaihua Zhong <zhongkaihua@kylinos.cn> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/r/20231129015526.3302865-1-zhongkaihua@kylinos.cnSigned-off-by:
-
Andy Shevchenko authored
With the help of EXPORT_NS_GPL_DEV_PM_OPS() and other *_PM_OPS() macros we may convert PM ops functions to become static. This also takes into account the PM configuration options such as CONFIG_PM and CONFIG_PM_SLEEP. This all removes a lot of ugly macros and ifdeffery in the driver. Signed-off-by:
-
Andy Shevchenko authored
Avoid unnecessary pollution of the global symbol namespace by moving library functions in to a specific namespace and import that into the drivers that make use of the functions. For more info: https://lwn.net/Articles/760045/Signed-off-by:
-
Andy Shevchenko authored
Adjust header inclusions to avoid "proxy" headers and explicitly include what we are using. Signed-off-by:
-
Andy Shevchenko authored
Use preferred device_get_match_data() instead of acpi_match_device() to get the driver match data. With this, adjust the includes to explicitly include the correct headers. Introduce a temporary variable in PCI glue driver to be consistent with ACPI one on the same matter. Signed-off-by:
-
Andy Shevchenko authored
This reverts commit d918e0d5. The commit in question does not fix anything and only introduces a duplication in the code. The main intel_lpss_probe() performs all necessary checks. While at it and in order of avoiding similar patches to come, add a comment. Signed-off-by:
-
Santhosh Kumar K authored
ADC module can function without DMA, so there may not be dma channel always associated with device. Hence, remove "dmas", "dma-names" from list of required properties. Signed-off-by:
Santhosh Kumar K <s-k6@ti.com> Reviewed-by:
Miquel Raynal <miquel.raynal@bootlin.com> Acked-by:
-
Nikita Travkin authored
PM8916 (and probably some other similar pmics) have hardware blocks for battery monitoring and charging. Add patterns for respecive nodes so the devicetree for those blocks can be validated properly. Signed-off-by:
Nikita Travkin <nikita@trvn.ru> Reviewed-by:
-
Dang Huynh authored
Add bindings for PM8937 PMIC (qcom,pm8937). This PMIC is found in boards with MSM8917, MSM8937, MSM8940 and APQ variants. Reviewed-by:
Dang Huynh <danct12@riseup.net> Link: https://lore.kernel.org/r/20231121-pm8937-v2-2-b0171ab62075@riseup.netSigned-off-by:
-
Dang Huynh authored
Add the subtype and compatible strings for PM8937. The PM8937 is found in various SoCs, including MSM8917, MSM8937, MSM8940 and APQ variants. Reviewed-by:
Caleb Connolly <caleb.connolly@linaro.org> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20231123165627.492259-19-u.kleine-koenig@pengutronix.deSigned-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Reviewed-by:
Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
Uwe Kleine-König authored
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by:
-
