summaryrefslogtreecommitdiff
path: root/drivers/mfd
AgeCommit message (Collapse)Author
2021-10-16Merge tag 'v4.4.288' into toradex_vf_4.4Max Krummenacher
This is the 4.4.288 stable release Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2021-07-20mfd: da9052/stmpe: Add and modify MODULE_DEVICE_TABLEZou Wei
[ Upstream commit 4700ef326556ed74aba188f12396740a8c1c21dd ] This patch adds/modifies MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-07Merge tag 'v4.4.274' into toradex_vf_4.4-nextMarcel Ziswiler
Linux 4.4.274
2021-03-03mfd: wm831x-auxadc: Prevent use after free in wm831x_auxadc_read_irq()Dan Carpenter
[ Upstream commit 26783d74cc6a440ee3ef9836a008a697981013d0 ] The "req" struct is always added to the "wm831x->auxadc_pending" list, but it's only removed from the list on the success path. If a failure occurs then the "req" struct is freed but it's still on the list, leading to a use after free. Fixes: 78bb3688ea18 ("mfd: Support multiple active WM831x AUXADC conversions") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29misc: rtsx: Fix memory leak in rtsx_pci_probeKeita Suzuki
[ Upstream commit bc28369c6189009b66d9619dd9f09bd8c684bb98 ] When mfd_add_devices() fail, pcr->slots should also be freed. However, the current implementation does not free the member, leading to a memory leak. Fix this by adding a new goto label that frees pcr->slots. Signed-off-by: Keita Suzuki <keitasuzuki.park@sslab.ics.keio.ac.jp> Link: https://lore.kernel.org/r/20200909071853.4053-1-keitasuzuki.park@sslab.ics.keio.ac.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-29mfd: sm501: Fix leaks in probe()Dan Carpenter
[ Upstream commit 8ce24f8967df2836b4557a23e74dc4bb098249f1 ] This code should clean up if sm501_init_dev() fails. Fixes: b6d6454fdb66 ("[PATCH] mfd: SM501 core driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-10-10Merge tag 'v4.4.238' into toradex_vf_4.4-nextMax Krummenacher
This is the 4.4.238 stable release Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-10-01mfd: mfd-core: Protect against NULL call-back function pointerLee Jones
[ Upstream commit b195e101580db390f50b0d587b7f66f241d2bc88 ] If a child device calls mfd_cell_{en,dis}able() without an appropriate call-back being set, we are likely to encounter a panic. Avoid this by adding suitable checking. Signed-off-by: Lee Jones <lee.jones@linaro.org> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-09-27Merge tag 'v4.4.237' into toradex_vf_4.4Max Krummenacher
This is the 4.4.237 stable release Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
2020-08-21mfd: dln2: Run event handler loop under spinlockAndy Shevchenko
[ Upstream commit 3d858942250820b9adc35f963a257481d6d4c81d ] The event handler loop must be run with interrupts disabled. Otherwise we will have a warning: [ 1970.785649] irq 31 handler lineevent_irq_handler+0x0/0x20 enabled interrupts [ 1970.792739] WARNING: CPU: 0 PID: 0 at kernel/irq/handle.c:159 __handle_irq_event_percpu+0x162/0x170 [ 1970.860732] RIP: 0010:__handle_irq_event_percpu+0x162/0x170 ... [ 1970.946994] Call Trace: [ 1970.949446] <IRQ> [ 1970.951471] handle_irq_event_percpu+0x2c/0x80 [ 1970.955921] handle_irq_event+0x23/0x43 [ 1970.959766] handle_simple_irq+0x57/0x70 [ 1970.963695] generic_handle_irq+0x42/0x50 [ 1970.967717] dln2_rx+0xc1/0x210 [dln2] [ 1970.971479] ? usb_hcd_unmap_urb_for_dma+0xa6/0x1c0 [ 1970.976362] __usb_hcd_giveback_urb+0x77/0xe0 [ 1970.980727] usb_giveback_urb_bh+0x8e/0xe0 [ 1970.984837] tasklet_action_common.isra.0+0x4a/0xe0 ... Recently xHCI driver switched to tasklets in the commit 36dc01657b49 ("usb: host: xhci: Support running urb giveback in tasklet context"). The handle_irq_event_* functions are expected to be called with interrupts disabled and they rightfully complain here because we run in tasklet context with interrupts enabled. Use a event spinlock to protect event handler from being interrupted. Note, that there are only two users of this GPIO and ADC drivers and both of them are using generic_handle_irq() which makes above happen. Fixes: 338a12814297 ("mfd: Add support for Diolan DLN-2 devices") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-29mfd: wm8994: Fix driver operation if loaded as modulesMarek Szyprowski
[ Upstream commit d4f9b5428b53dd67f49ee8deed8d4366ed6b1933 ] WM8994 chip has built-in regulators, which might be used for chip operation. They are controlled by a separate wm8994-regulator driver, which should be loaded before this driver calls regulator_get(), because that driver also provides consumer-supply mapping for the them. If that driver is not yet loaded, regulator core substitute them with dummy regulator, what breaks chip operation, because the built-in regulators are never enabled. Fix this by annotating this driver with MODULE_SOFTDEP() "pre" dependency to "wm8994_regulator" module. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-05-21Merge tag 'v4.4.220' into toradex_vf_4.4-nextMarcel Ziswiler
This is the 4.4.220 stable release
2020-05-10mfd: lp8788-irq: Uninitialized variable in irq handlerDan Carpenter
commit 22aab38e7b59fd79ce1045006be69a9abab58e5a upstream. Instead to being true/false, the "handled" is true/uninitialized. Presumably this doesn't cause that many problems in real life because normally we handle the IRQ. Fixes: eea6b7cc53aa ('mfd: Add lp8788 mfd driver') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-24mfd: dln2: Fix sanity checking for endpointsAndy Shevchenko
[ Upstream commit fb945c95a482200876993977008b67ea658bd938 ] While the commit 2b8bd606b1e6 ("mfd: dln2: More sanity checking for endpoints") tries to harden the sanity checks it made at the same time a regression, i.e. mixed in and out endpoints. Obviously it should have been not tested on real hardware at that time, but unluckily it didn't happen. So, fix above mentioned typo and make device being enumerated again. While here, introduce an enumerator for magic values to prevent similar issue to happen in the future. Fixes: 2b8bd606b1e6 ("mfd: dln2: More sanity checking for endpoints") Cc: Oliver Neukum <oneukum@suse.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-04-24misc: rtsx: set correct pcr_ops for rts522AYueHaibing
[ Upstream commit 10cea23b6aae15e8324f4101d785687f2c514fe5 ] rts522a should use rts522a_pcr_ops, which is diffrent with rts5227 in phy/hw init setting. Fixes: ce6a5acc9387 ("mfd: rtsx: Add support for rts522A") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200326032618.20472-1-yuehaibing@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-02-24Merge tag 'v4.4.214' into toradex_vf_4.4-nextMax Krummenacher
This is the 4.4.214 stable release
2020-02-14mfd: rn5t618: Mark ADC control register volatileAndreas Kemnade
commit 2f3dc25c0118de03a00ddc88b61f7216854f534d upstream. There is a bit which gets cleared after conversion. Fixes: 9bb9e29c78f8 ("mfd: Add Ricoh RN5T618 PMIC core driver") Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-14mfd: da9062: Fix watchdog compatible stringMarco Felsch
commit 1112ba02ff1190ca9c15a912f9269e54b46d2d82 upstream. The watchdog driver compatible is "dlg,da9062-watchdog" and not "dlg,da9062-wdt". Therefore the mfd-core can't populate the of_node and fwnode. As result the watchdog driver can't parse the devicetree. Fixes: 9b40b030c4ad ("mfd: da9062: Supply core driver") Signed-off-by: Marco Felsch <m.felsch@pengutronix.de> Acked-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Adam Thomson <Adam.Thomson.Opensource@diasemi.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-14mfd: dln2: More sanity checking for endpointsOliver Neukum
commit 2b8bd606b1e60ca28c765f69c1eedd7d2a2e9dca upstream. It is not enough to check for the number of endpoints. The types must also be correct. Reported-and-tested-by: syzbot+48a2851be24583b864dc@syzkaller.appspotmail.com Signed-off-by: Oliver Neukum <oneukum@suse.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-29mfd: intel-lpss: Release IDA resourcesAndy Shevchenko
[ Upstream commit 02f36911c1b41fcd8779fa0c135aab0554333fa5 ] ida instances allocate some internal memory for ->free_bitmap in addition to the base 'struct ida'. Use ida_destroy() to release that memory at module_exit(). Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-28mfd: max8997: Enale irq-wakeup unconditionallyMarek Szyprowski
[ Upstream commit efddff27c886e729a7f84a7205bd84d7d4af7336 ] IRQ wake up support for MAX8997 driver was initially configured by respective property in pdata. However, after the driver conversion to device-tree, setting it was left as 'todo'. Nowadays most of other PMIC MFD drivers initialized from device-tree assume that they can be an irq wakeup source, so enable it also for MAX8997. This fixes support for wakeup from MAX8997 RTC alarm. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-28mfd: mc13xxx-core: Fix PMIC shutdown when reading ADC valuesFabio Estevam
[ Upstream commit 55143439b7b501882bea9d95a54adfe00ffc79a3 ] When trying to read any MC13892 ADC channel on a imx51-babbage board: The MC13892 PMIC shutdowns completely. After debugging this issue and comparing the MC13892 and MC13783 initializations done in the vendor kernel, it was noticed that the CHRGRAWDIV bit of the ADC0 register was not being set. This bit is set by default after power on, but the driver was clearing it. After setting this bit it is possible to read the ADC values correctly. Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com> Tested-by: Chris Healy <cphealy@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-10-07mfd: intel-lpss: Remove D3cold delayKai-Heng Feng
[ Upstream commit 76380a607ba0b28627c9b4b55cd47a079a59624b ] Goodix touchpad may drop its first couple input events when i2c-designware-platdrv and intel-lpss it connects to took too long to runtime resume from runtime suspended state. This issue happens becuase the touchpad has a rather small buffer to store up to 13 input events, so if the host doesn't read those events in time (i.e. runtime resume takes too long), events are dropped from the touchpad's buffer. The bottleneck is D3cold delay it waits when transitioning from D3cold to D0, hence remove the delay to make the resume faster. I've tested some systems with intel-lpss and haven't seen any regression. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202683 Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-04mfd: arizona: Fix undefined behaviorArnd Bergmann
[ Upstream commit 5da6cbcd2f395981aa9bfc571ace99f1c786c985 ] When the driver is used with a subdevice that is disabled in the kernel configuration, clang gets a little confused about the control flow and fails to notice that n_subdevs is only uninitialized when subdevs is NULL, and we check for that, leading to a false-positive warning: drivers/mfd/arizona-core.c:1423:19: error: variable 'n_subdevs' is uninitialized when used here [-Werror,-Wuninitialized] subdevs, n_subdevs, NULL, 0, NULL); ^~~~~~~~~ drivers/mfd/arizona-core.c:999:15: note: initialize the variable 'n_subdevs' to silence this warning int n_subdevs, ret, i; ^ = 0 Ideally, we would rearrange the code to avoid all those early initializations and have an explicit exit in each disabled case, but it's much easier to chicken out and add one more initialization here to shut up the warning. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-08-04mfd: core: Set fwnode for created devicesRobert Hancock
[ Upstream commit c176c6d7e932662668bcaec2d763657096589d85 ] The logic for setting the of_node on devices created by mfd did not set the fwnode pointer to match, which caused fwnode-based APIs to malfunction on these devices since the fwnode pointer was null. Fix this. Signed-off-by: Robert Hancock <hancock@sedsystems.ca> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-10mfd: omap-usb-tll: Fix register offsetsArnd Bergmann
[ Upstream commit 993dc737c0996c163325961fb62a0ed9fd0308b4 ] gcc-8 notices that the register number calculation is wrong when the offset is an 'u8' but the number is larger than 256: drivers/mfd/omap-usb-tll.c: In function 'omap_tll_init': drivers/mfd/omap-usb-tll.c:90:46: error: overflow in conversion from 'int' to 'u8 {aka unsigned char}' chages value from 'i * 256 + 2070' to '22' [-Werror=overflow] This addresses it by always using a 32-bit offset number for the register. This is apparently an old problem that previous compilers did not find. Fixes: 16fa3dc75c22 ("mfd: omap-usb-tll: HOST TLL platform driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-22mfd: twl6040: Fix device init errors for ACCCTL registerTony Lindgren
[ Upstream commit 48171d0ea7caccf21c9ee3ae75eb370f2a756062 ] I noticed that we can get a -EREMOTEIO errors on at least omap4 duovero: twl6040 0-004b: Failed to write 2d = 19: -121 And then any following register access will produce errors. There 2d offset above is register ACCCTL that gets written on twl6040 powerup. With error checking added to the related regcache_sync() call, the -EREMOTEIO error is reproducable on twl6040 powerup at least duovero. To fix the error, we need to wait until twl6040 is accessible after the powerup. Based on tests on omap4 duovero, we need to wait over 8ms after powerup before register write will complete without failures. Let's also make sure we warn about possible errors too. Note that we have twl6040_patch[] reg_sequence with the ACCCTL register configuration and regcache_sync() will write the new value to ACCCTL. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-06-22mfd: intel-lpss: Set the device in reset state when initBinbin Wu
[ Upstream commit dad06532292d77f37fbe831a02948a593500f682 ] In virtualized setup, when system reboots due to warm reset interrupt storm is seen. Call Trace: <IRQ> dump_stack+0x70/0xa5 __report_bad_irq+0x2e/0xc0 note_interrupt+0x248/0x290 ? add_interrupt_randomness+0x30/0x220 handle_irq_event_percpu+0x54/0x80 handle_irq_event+0x39/0x60 handle_fasteoi_irq+0x91/0x150 handle_irq+0x108/0x180 do_IRQ+0x52/0xf0 common_interrupt+0xf/0xf </IRQ> RIP: 0033:0x76fc2cfabc1d Code: 24 28 bf 03 00 00 00 31 c0 48 8d 35 63 77 0e 00 48 8d 15 2e 94 0e 00 4c 89 f9 49 89 d9 4c 89 d3 e8 b8 e2 01 00 48 8b 54 24 18 <48> 89 ef 48 89 de 4c 89 e1 e8 d5 97 01 00 84 c0 74 2d 48 8b 04 24 RSP: 002b:00007ffd247c1fc0 EFLAGS: 00000293 ORIG_RAX: ffffffffffffffda RAX: 0000000000000000 RBX: 00007ffd247c1ff0 RCX: 000000000003d3ce RDX: 0000000000000000 RSI: 00007ffd247c1ff0 RDI: 000076fc2cbb6010 RBP: 000076fc2cded010 R08: 00007ffd247c2210 R09: 00007ffd247c22a0 R10: 000076fc29465470 R11: 0000000000000000 R12: 00007ffd247c1fc0 R13: 000076fc2ce8e470 R14: 000076fc27ec9960 R15: 0000000000000414 handlers: [<000000000d3fa913>] idma64_irq Disabling IRQ #27 To avoid interrupt storm, set the device in reset state before bringing out the device from reset state. Changelog v2: - correct the subject line by adding "mfd: " Signed-off-by: Binbin Wu <binbin.wu@intel.com> Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-28Merge tag 'v4.4.177' into toradex_vf_4.4-nextColibri-VF_LXDE-Image_2.8b6.183-20190331Marcel Ziswiler
This is the 4.4.177 stable release
2019-03-23mfd: mc13xxx: Fix a missing check of a register-read failureKangjie Lu
[ Upstream commit 9e28989d41c0eab57ec0bb156617a8757406ff8a ] When mc13xxx_reg_read() fails, "old_adc0" is uninitialized and will contain random value. Further execution uses "old_adc0" even when mc13xxx_reg_read() fails. The fix checks the return value of mc13xxx_reg_read(), and exits the execution when it fails. Signed-off-by: Kangjie Lu <kjlu@umn.edu> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23mfd: wm5110: Add missing ASRC rate registerCharles Keepax
[ Upstream commit 04c801c18ded421845324255e660147a6f58dcd6 ] Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23mfd: qcom_rpm: write fw_version to CTRL_REGJonathan Marek
[ Upstream commit 504e4175829c44328773b96ad9c538e4783a8d22 ] This is required as part of the initialization sequence on certain SoCs. If these registers are not initialized, the hardware can be unresponsive. This fixes the driver on apq8060 (HP TouchPad device). Signed-off-by: Jonathan Marek <jonathan@marek.ca> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23mfd: ab8500-core: Return zero in get_register_interruptible()Dan Carpenter
[ Upstream commit 10628e3ecf544fa2e4e24f8e112d95c37884dc98 ] This function is supposed to return zero on success or negative error codes on error. Unfortunately, there is a bug so it sometimes returns non-zero, positive numbers on success. I noticed this bug during review and I can't test it. It does appear that the return is sometimes propogated back to _regmap_read() where all non-zero returns are treated as failure so this may affect run time. Fixes: 47c1697508f2 ("mfd: Align ab8500 with the abx500 interface") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23mfd: db8500-prcmu: Fix some section annotationsNathan Chancellor
[ Upstream commit a3888f62fe66429fad3be7f2ba962e1e08c26fd6 ] When building the kernel with Clang, the following section mismatch warnings appear: WARNING: vmlinux.o(.text+0x7239cc): Section mismatch in reference from the function db8500_prcmu_probe() to the function .init.text:init_prcm_registers() The function db8500_prcmu_probe() references the function __init init_prcm_registers(). This is often because db8500_prcmu_probe lacks a __init annotation or the annotation of init_prcm_registers is wrong. WARNING: vmlinux.o(.text+0x723e28): Section mismatch in reference from the function db8500_prcmu_probe() to the function .init.text:fw_project_name() The function db8500_prcmu_probe() references the function __init fw_project_name(). This is often because db8500_prcmu_probe lacks a __init annotation or the annotation of fw_project_name is wrong. db8500_prcmu_probe should not be marked as __init so remove the __init annotation from fw_project_name and init_prcm_registers. Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23mfd: twl-core: Fix section annotations on {,un}protect_pm_masterNathan Chancellor
[ Upstream commit 8838555089f0345b87f4277fe5a8dd647dc65589 ] When building the kernel with Clang, the following section mismatch warning appears: WARNING: vmlinux.o(.text+0x3d84a3b): Section mismatch in reference from the function twl_probe() to the function .init.text:unprotect_pm_master() The function twl_probe() references the function __init unprotect_pm_master(). This is often because twl_probe lacks a __init annotation or the annotation of unprotect_pm_master is wrong. Remove the __init annotation on the *protect_pm_master functions so there is no more mismatch. Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-03-23mfd: ti_am335x_tscadc: Use PLATFORM_DEVID_AUTO while registering mfd cellsVignesh R
[ Upstream commit b40ee006fe6a8a25093434e5d394128c356a48f3 ] Use PLATFORM_DEVID_AUTO to number mfd cells while registering, so that different instances are uniquely identified. This is required in order to support registering of multiple instances of same ti_am335x_tscadc IP. Signed-off-by: Vignesh R <vigneshr@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-02-23mfd: as3722: Mark PM functions as __maybe_unusedArnd Bergmann
commit a7b956fd38dd217dd78e3058110929f5ac914df1 upstream. The newly introduced as3722_i2c_suspend/resume functions are built unconditionally, but only used when power management is enabled, so we get a warning otherwise: drivers/mfd/as3722.c:427:12: warning: 'as3722_i2c_suspend' defined but not used [-Wunused-function] drivers/mfd/as3722.c:438:12: warning: 'as3722_i2c_resume' defined but not used [-Wunused-function] This marks them both as __maybe_unused, which avoids an ugly #ifdef and gives us best compile-time coverage. When they are unused, the compiler will silently drop the functions from its output. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 35deff7eb212 ("mfd: as3722: Handle interrupts on suspend") Signed-off-by: Lee Jones <lee.jones@linaro.org> Cc: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-23mfd: as3722: Handle interrupts on suspendJon Hunter
commit 35deff7eb212b661b32177b6043f674fde6314d7 upstream. The as3722 device is registered as an irqchip and the as3722-rtc interrupt is one of it's interrupt sources. When using the as3722-rtc as a wake-up device from suspend, the following is seen: PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.001 seconds) done. Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done. Suspending console(s) (use no_console_suspend to debug) PM: suspend of devices complete after 161.119 msecs PM: late suspend of devices complete after 1.048 msecs PM: noirq suspend of devices complete after 0.756 msecs Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown Entering suspend state LP1 Enabling non-boot CPUs ... CPU1 is up CPU2 is up CPU3 is up PM: noirq resume of devices complete after 0.487 msecs as3722 4-0040: Failed to read IRQ status: -16 as3722 4-0040: Failed to read IRQ status: -16 as3722 4-0040: Failed to read IRQ status: -16 as3722 4-0040: Failed to read IRQ status: -16 ... The reason why the as3722 interrupt status cannot be read is because the as3722 interrupt is not masked during suspend and when the as3722-rtc interrupt occurs, to wake-up the device, the interrupt is seen before the i2c controller has been resumed in order to read the as3722 interrupt status. The as3722-rtc driver sets it's interrupt as a wake-up source during suspend, which gets propagated to the parent as3722 interrupt. However, the as3722-rtc driver cannot disable it's interrupt during suspend otherwise we would never be woken up and so the as3722 must disable it's interrupt instead. Fix this by disabling the as3722 interrupt during suspend. To ensure that a wake-up event from the as3722 is not missing, enable the as3722 interrupt as a wake-up source before disabling the interrupt on entering suspend. Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-26mfd: tps6586x: Handle interrupts on suspendJonathan Hunter
commit ac4ca4b9f4623ba5e1ea7a582f286567c611e027 upstream. The tps6586x driver creates an irqchip that is used by its various child devices for managing interrupts. The tps6586x-rtc device is one of its children that uses the tps6586x irqchip. When using the tps6586x-rtc as a wake-up device from suspend, the following is seen: PM: Syncing filesystems ... done. Freezing user space processes ... (elapsed 0.001 seconds) done. OOM killer disabled. Freezing remaining freezable tasks ... (elapsed 0.000 seconds) done. Disabling non-boot CPUs ... Entering suspend state LP1 Enabling non-boot CPUs ... CPU1 is up tps6586x 3-0034: failed to read interrupt status tps6586x 3-0034: failed to read interrupt status The reason why the tps6586x interrupt status cannot be read is because the tps6586x interrupt is not masked during suspend and when the tps6586x-rtc interrupt occurs, to wake-up the device, the interrupt is seen before the i2c controller has been resumed in order to read the tps6586x interrupt status. The tps6586x-rtc driver sets it's interrupt as a wake-up source during suspend, which gets propagated to the parent tps6586x interrupt. However, the tps6586x-rtc driver cannot disable it's interrupt during suspend otherwise we would never be woken up and so the tps6586x must disable it's interrupt instead. Prevent the tps6586x interrupt handler from executing on exiting suspend before the i2c controller has been resumed by disabling the tps6586x interrupt on entering suspend and re-enabling it on resuming from suspend. Cc: stable@vger.kernel.org Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Dmitry Osipenko <digetx@gmail.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-13Merge tag 'v4.4.167' into toradex_vf_4.4-nextMarcel Ziswiler
This is the 4.4.167 stable release
2018-11-10thermal: allow u8500-thermal driver to be a moduleArnd Bergmann
[ Upstream commit 26716ce124fce88f288f07738ef685d5dfe5c13f ] When the thermal subsystem is a loadable module, the u8500 driver fails to build: drivers/thermal/built-in.o: In function `db8500_thermal_probe': db8500_thermal.c:(.text+0x96c): undefined reference to `thermal_zone_device_register' drivers/thermal/built-in.o: In function `db8500_thermal_work': db8500_thermal.c:(.text+0xab4): undefined reference to `thermal_zone_device_update' This changes the symbol to a tristate, so Kconfig can track the dependency correctly. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Eduardo Valentin <edubezval@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2018-10-20mfd: omap-usb-host: Fix dts probe of childrenTony Lindgren
[ Upstream commit 10492ee8ed9188d6d420e1f79b2b9bdbc0624e65 ] It currently only works if the parent bus uses "simple-bus". We currently try to probe children with non-existing compatible values. And we're missing .probe. I noticed this while testing devices configured to probe using ti-sysc interconnect target module driver. For that we also may want to rebind the driver, so let's remove __init and __exit. Signed-off-by: Tony Lindgren <tony@atomide.com> Acked-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-27Merge tag 'v4.4.158' into HEADMarcel Ziswiler
This is the 4.4.158 stable release
2018-09-19mfd: ti_am335x_tscadc: Fix struct clk memory leakZumeng Chen
[ Upstream commit c2b1509c77a99a0dcea0a9051ca743cb88385f50 ] Use devm_elk_get() to let Linux manage struct clk memory to avoid the following memory leakage report: unreferenced object 0xdd75efc0 (size 64): comm "systemd-udevd", pid 186, jiffies 4294945126 (age 1195.750s) hex dump (first 32 bytes): 61 64 63 5f 74 73 63 5f 66 63 6b 00 00 00 00 00 adc_tsc_fck..... 00 00 00 00 92 03 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<c0a15260>] kmemleak_alloc+0x40/0x74 [<c0287a10>] __kmalloc_track_caller+0x198/0x388 [<c0255610>] kstrdup+0x40/0x5c [<c025565c>] kstrdup_const+0x30/0x3c [<c0636630>] __clk_create_clk+0x60/0xac [<c0630918>] clk_get_sys+0x74/0x144 [<c0630cdc>] clk_get+0x5c/0x68 [<bf0ac540>] ti_tscadc_probe+0x260/0x468 [ti_am335x_tscadc] [<c06f3c0c>] platform_drv_probe+0x60/0xac [<c06f1abc>] driver_probe_device+0x214/0x2dc [<c06f1c18>] __driver_attach+0x94/0xc0 [<c06efe2c>] bus_for_each_dev+0x90/0xa0 [<c06f1470>] driver_attach+0x28/0x30 [<c06f1030>] bus_add_driver+0x184/0x1ec [<c06f2b74>] driver_register+0xb0/0xf0 [<c06f3b4c>] __platform_driver_register+0x40/0x54 Signed-off-by: Zumeng Chen <zumeng.chen@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-09-15mfd: sm501: Set coherent_dma_mask when creating subdevicesGuenter Roeck
[ Upstream commit 2f606da78230f09cf1a71fde6ee91d0c710fa2b2 ] Instantiating the sm501 OHCI subdevice results in a kernel warning. sm501-usb sm501-usb: SM501 OHCI sm501-usb sm501-usb: new USB bus registered, assigned bus number 1 WARNING: CPU: 0 PID: 1 at ./include/linux/dma-mapping.h:516 ohci_init+0x194/0x2d8 Modules linked in: CPU: 0 PID: 1 Comm: swapper Tainted: G W 4.18.0-rc7-00178-g0b5b1f9a78b5 #1 PC is at ohci_init+0x194/0x2d8 PR is at ohci_init+0x168/0x2d8 PC : 8c27844c SP : 8f81dd94 SR : 40008001 TEA : 29613060 R0 : 00000000 R1 : 00000000 R2 : 00000000 R3 : 00000202 R4 : 8fa98b88 R5 : 8c277e68 R6 : 00000000 R7 : 00000000 R8 : 8f965814 R9 : 8c388100 R10 : 8fa98800 R11 : 8fa98928 R12 : 8c48302c R13 : 8fa98920 R14 : 8c48302c MACH: 00000096 MACL: 0000017c GBR : 00000000 PR : 8c278420 Call trace: [<(ptrval)>] usb_add_hcd+0x1e8/0x6ec [<(ptrval)>] _dev_info+0x0/0x54 [<(ptrval)>] arch_local_save_flags+0x0/0x8 [<(ptrval)>] arch_local_irq_restore+0x0/0x24 [<(ptrval)>] ohci_hcd_sm501_drv_probe+0x114/0x2d8 ... Initialize coherent_dma_mask when creating SM501 subdevices to fix the problem. Fixes: b6d6454fdb66f ("mfd: SM501 core driver") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-08-06mfd: cros_ec: Fail early if we cannot identify the ECVincent Palatin
[ Upstream commit 0dbbf25561b29ffab5ba6277429760abdf49ceff ] If we cannot communicate with the EC chip to detect the protocol version and its features, it's very likely useless to continue. Else we will commit all kind of uninformed mistakes (using the wrong protocol, the wrong buffer size, mixing the EC with other chips). Signed-off-by: Vincent Palatin <vpalatin@chromium.org> Acked-by: Benson Leung <bleung@chromium.org> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-07-09Merge tag 'v4.4.139' into toradex_vf_4.4-nextMax Krummenacher
This is the 4.4.139 stable release
2018-07-03mfd: intel-lpss: Program REMAP register in PIO modeAndy Shevchenko
commit d28b62520830b2d0bffa2d98e81afc9f5e537e8b upstream. According to documentation REMAP register has to be programmed in either DMA or PIO mode of the slice. Move the DMA capability check below to let REMAP register be programmed in PIO mode. Cc: stable@vger.kernel.org # 4.3+ Fixes: 4b45efe85263 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-06-21Merge tag 'v4.4.138' into toradex_vf_4.4-nextMax Krummenacher
This is the 4.4.138 stable release
2018-03-24mfd: palmas: Reset the POWERHOLD mux during power offKeerthy
[ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ] POWERHOLD signal has higher priority over the DEV_ON bit. So power off will not happen if the POWERHOLD is held high. Hence reset the MUX to GPIO_7 mode to release the POWERHOLD and the DEV_ON bit to take effect to power off the PMIC. PMIC Power off happens in dire situations like thermal shutdown so irrespective of the POWERHOLD setting go ahead and turn off the powerhold. Currently poweroff is broken on boards that have powerhold enabled. This fixes poweroff on those boards. Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <alexander.levin@microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-06-16 23:06:51 +0000