- 07 Dec, 2023 40 commits
-
-
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:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by:
Lee Jones <lee@kernel.org>
-
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:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231124045019.21003-1-s-k6@ti.comSigned-off-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:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231120-pm8916-dtsi-bms-lbc-v4-1-4f91056c8252@trvn.ruSigned-off-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:
-
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. Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Andre Werner authored
Previously there was no output for the regmap's registers in debugfs due to missing "max_register" property in regmap configuration. Signed-off-by:
Andre Werner <andre.werner@systec-electronic.com> Link: https://lore.kernel.org/r/20231121063259.13991-1-andre.werner@systec-electronic.comSigned-off-by:
-
Neil Armstrong authored
Since commit 210f418f ("mfd: rk8xx: Add rk806 support"), devices are registered with "0" as id, causing devices to not have an automatic device id and prevents having multiple RK8xx PMICs on the same system. Properly pass PLATFORM_DEVID_AUTO to devm_mfd_add_devices() and since it will ignore the cells .id with this special value, also cleanup by removing all now ignored cells .id values. Now we have the same behaviour as before rk806 introduction and rk806 retains the intended behavior. This fixes a regression while booting the Odroid Go Ultra on v6.6.1: sysfs: cannot create duplicate filename '/bus/platform/devices/rk808-clkout' CPU: 3 PID: 97 Comm: kworker/u12:2 Not tainted 6.6.1 #1 Hardware name: Hardkernel ODROID-GO-Ultra (DT) Workqueue: events_unbound deferred_probe_work_func Call trace: dump_backtrace+0x9c/0x11c show_stack+0x18/0x24 dump_stack_lvl+0x78/0xc4 dump_stack+0x18/0x24 sysfs_warn_dup+0x64/0x80 sysfs_do_create_link_sd+0xf0/0xf8 sysfs_create_link+0x20/0x40 bus_add_device+0x114/0x160 device_add+0x3f0/0x7cc platform_device_add+0x180/0x270 mfd_add_device+0x390/0x4a8 devm_mfd_add_devices+0xb0/0x150 rk8xx_probe+0x26c/0x410 rk8xx_i2c_probe+0x64/0x98 i2c_device_probe+0x104/0x2e8 really_probe+0x184/0x3c8 __driver_probe_device+0x7c/0x16c driver_probe_device+0x3c/0x10c __device_attach_driver+0xbc/0x158 bus_for_each_drv+0x80/0xdc __device_attach+0x9c/0x1ac device_initial_probe+0x14/0x20 bus_probe_device+0xac/0xb0 deferred_probe_work_func+0xa0/0xf4 process_one_work+0x1bc/0x378 worker_thread+0x1dc/0x3d4 kthread+0x104/0x118 ret_from_fork+0x10/0x20 rk8xx-i2c 0-001c: error -EEXIST: failed to add MFD devices rk8xx-i2c: probe of 0-001c failed with error -17 Fixes: 210f418f ("mfd: rk8xx: Add rk806 support") Reported-by:
Adam Green <greena88@gmail.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Link: https://lore.kernel.org/r/20231116-topic-amlogic-upstream-fix-rk8xx-devid-auto-v2-1-3f1bad68ab9d@linaro.orgSigned-off-by:
-
Chen Ni authored
platform_get_irq() returns a negative error code to indicate an error. As does pci_alloc_irq_vectors() and pci_irq_vector(). So in intel_lpss_probe() the erroneous IRQ would be better returned as is. The pci_alloc_irq_vectors() call and platform_get_irq() guarantee that IRQs will not be 0, so we'll drop that check as well. Signed-off-by:
Chen Ni <nichen@iscas.ac.cn> [andy: updated commit message] Signed-off-by:
-
Andy Shevchenko authored
We have a few PCI APIs that may be used instead of direct dereferencing, Using them will also provide better error codes. Signed-off-by:
-
Christophe JAILLET authored
ida_alloc() and ida_free() should be preferred to the deprecated ida_simple_get() and ida_simple_remove(). This is less verbose. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/a63f3da5745187f5a9b1e2ec0492f2fe2e0b0b8d.1698854117.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Mukesh Ojha authored
Document the compatible for both sm8250 and sm8350 SoCs. Signed-off-by:
Mukesh Ojha <quic_mojha@quicinc.com> Reviewed-by:
-
Geert Uytterhoeven authored
Convert the Austria MicroSystems AS3711 Quad Buck High Current PMIC with Charger Device Tree binding documentation to json-schema. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/56a5ebee588696f9022fa29fa8e266c8bdee6fd7.1698228043.git.geert+renesas@glider.beSigned-off-by:
-
Amit Kumar Mahapatra authored
In preparation for adding multiple CS support for a device, set/get functions were introduces accessing spi->chip_select in 'commit 303feb3c ("spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod")'. Replace spi->chip_select with spi_get_chipselect() API. Signed-off-by:
Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com> Link: https://lore.kernel.org/r/20231125092137.2948-2-amit.kumar-mahapatra@amd.comSigned-off-by:
-
