kernel/linux.git/include/linux/mfd, branch v5.10.257

mfd: wm8350-core: Use IRQF_ONESHOT

2026-03-04T12:19:25+00:00

[ Upstream commit 553b4999cbe231b5011cb8db05a3092dec168aca ] Using a threaded interrupt without a dedicated primary handler mandates the IRQF_ONESHOT flag to mask the interrupt source while the threaded handler is active. Otherwise the interrupt can fire again before the threaded handler had a chance to run. Mark explained that this should not happen with this hardware since it is a slow irqchip which is behind an I2C/ SPI bus but the IRQ-core will refuse to accept such a handler. Set IRQF_ONESHOT so the interrupt source is masked until the secondary handler is done. Fixes: 1c6c69525b40e ("genirq: Reject bogus threaded irq requests") Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Thomas Gleixner Reviewed-by: Charles Keepax Reviewed-by: Andy Shevchenko Link: https://patch.msgid.link/20260128095540.863589-16-bigeasy@linutronix.de Signed-off-by: Sasha Levin

mfd: core: Un-constify mfd_cell.of_reg

2023-11-20T10:06:52+00:00

[ Upstream commit 3c70342f1f0045dc827bb2f02d814ce31e0e0d05 ] Enable dynamically filling in the whole mfd_cell structure. All other fields already allow that. Fixes: 466a62d7642f ("mfd: core: Make a best effort attempt to match devices with the correct of_nodes") Signed-off-by: Michał Mirosław Link: https://lore.kernel.org/r/b73fe4bc4bd6ba1af90940a640ed65fe254c0408.1693253717.git.mirq-linux@rere.qmqm.pl Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: t7l66xb: Drop platform disable callback

2022-08-21T13:16:09+00:00

[ Upstream commit 128ac294e1b437cb8a7f2ff8ede1cde9082bddbe ] None of the in-tree instantiations of struct t7l66xb_platform_data provides a disable callback. So better don't dereference this function pointer unconditionally. As there is no user, drop it completely instead of calling it conditional. This is a preparation for making platform remove callbacks return void. Fixes: 1f192015ca5b ("mfd: driver for the T7L66XB TMIO SoC") Signed-off-by: Uwe Kleine-König Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20220530192430.2108217-3-u.kleine-koenig@pengutronix.de Signed-off-by: Sasha Levin

regulator: rt5033: Fix n_voltages settings for BUCK and LDO

2021-08-08T07:05:22+00:00

[ Upstream commit 6549c46af8551b346bcc0b9043f93848319acd5c ] For linear regulators, the n_voltages should be (max - min) / step + 1. Buck voltage from 1v to 3V, per step 100mV, and vout mask is 0x1f. If value is from 20 to 31, the voltage will all be fixed to 3V. And LDO also, just vout range is different from 1.2v to 3v, step is the same. If value is from 18 to 31, the voltage will also be fixed to 3v. Signed-off-by: Axel Lin Reviewed-by: ChiYuan Huang Link: https://lore.kernel.org/r/20210627080418.1718127-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

power: supply: ab8500: Fix an old bug

2021-07-19T07:45:00+00:00

commit f1c74a6c07e76fcb31a4bcc1f437c4361a2674ce upstream. Trying to get the AB8500 charging driver working I ran into a bit of bitrot: we haven't used the driver for a while so errors in refactorings won't be noticed. This one is pretty self evident: use argument to the macro or we end up with a random pointer to something else. Cc: stable@vger.kernel.org Cc: Krzysztof Kozlowski Cc: Marcus Cooper Fixes: 297d716f6260 ("power_supply: Change ownership from driver to core") Signed-off-by: Linus Walleij Signed-off-by: Sebastian Reichel Signed-off-by: Greg Kroah-Hartman

regulator: bd70528: Fix off-by-one for buck123 .n_voltages setting

2021-06-23T12:42:47+00:00

[ Upstream commit 0514582a1a5b4ac1a3fd64792826d392d7ae9ddc ] The valid selectors for bd70528 bucks are 0 ~ 0xf, so the .n_voltages should be 16 (0x10). Use 0x10 to make it consistent with BD70528_LDO_VOLTS. Also remove redundant defines for BD70528_BUCK_VOLTS. Signed-off-by: Axel Lin Acked-by: Matti Vaittinen Link: https://lore.kernel.org/r/20210523071045.2168904-1-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin

regulator: bd71828: Fix .n_voltages settings

2021-06-16T10:01:43+00:00

commit 4c668630bf8ea90a041fc69c9984486e0f56682d upstream. Current .n_voltages settings do not cover the latest 2 valid selectors, so it fails to set voltage for the hightest voltage support. The latest linear range has step_uV = 0, so it does not matter if we count the .n_voltages to maximum selector + 1 or the first selector of latest linear range + 1. To simplify calculating the n_voltages, let's just set the .n_voltages to maximum selector + 1. Fixes: 522498f8cb8c ("regulator: bd71828: Basic support for ROHM bd71828 PMIC regulators") Signed-off-by: Axel Lin Reviewed-by: Matti Vaittinen Link: https://lore.kernel.org/r/20210523071045.2168904-2-axel.lin@ingics.com Signed-off-by: Mark Brown Signed-off-by: Greg Kroah-Hartman

mfd: da9063: Support SMBus and I2C mode

2021-05-11T12:47:31+00:00

[ Upstream commit 586478bfc9f7e16504d6f64cf18bcbdf6fd0cbc9 ] By default the PMIC DA9063 2-wire interface is SMBus compliant. This means the PMIC will automatically reset the interface when the clock signal ceases for more than the SMBus timeout of 35 ms. If the I2C driver / device is not capable of creating atomic I2C transactions, a context change can cause a ceasing of the clock signal. This can happen if for example a real-time thread is scheduled. Then the DA9063 in SMBus mode will reset the 2-wire interface. Subsequently a write message could end up in the wrong register. This could cause unpredictable system behavior. The DA9063 PMIC also supports an I2C compliant mode for the 2-wire interface. This mode does not reset the interface when the clock signal ceases. Thus the problem depicted above does not occur. This patch tests for the bus functionality "I2C_FUNC_I2C". It can reasonably be assumed that the bus cannot obey SMBus timings if this functionality is set. SMBus commands most probably are emulated in this case which is prone to the latency issue described above. This patch enables the I2C bus mode if I2C_FUNC_I2C is set or otherwise keeps the default SMBus mode. Signed-off-by: Hubert Streidl Signed-off-by: Mark Jonas Reviewed-by: Wolfram Sang Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: intel-m10-bmc: Fix the register access range

2021-05-11T12:47:31+00:00

[ Upstream commit d9b326b2c3673f939941806146aee38e5c635fd0 ] This patch fixes the max register address of MAX 10 BMC. The range 0x20000000 ~ 0x200000fc are for control registers of the QSPI flash controller, which are not accessible to host. Signed-off-by: Xu Yilun Reviewed-by: Tom Rix Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

regulator: bd718x7, bd71828, Fix dvs voltage levels

2021-03-04T10:38:07+00:00

[ Upstream commit c294554111a835598b557db789d9ad2379b512a2 ] The ROHM BD718x7 and BD71828 drivers support setting HW state specific voltages from device-tree. This is used also by various in-tree DTS files. These drivers do incorrectly try to compose bit-map using enum values. By a chance this works for first two valid levels having values 1 and 2 - but setting values for the rest of the levels do indicate capability of setting values for first levels as well. Luckily the regulators which support setting values for SUSPEND/LPSR do usually also support setting values for RUN and IDLE too - thus this has not been such a fatal issue. Fix this by defining the old enum values as bits and fixing the parsing code. This allows keeping existing IC specific drivers intact and only slightly changing the rohm-regulator.c Fixes: 21b72156ede8b ("regulator: bd718x7: Split driver to common and bd718x7 specific parts") Signed-off-by: Matti Vaittinen Acked-by: Lee Jones Link: https://lore.kernel.org/r/20210212080023.GA880728@localhost.localdomain Signed-off-by: Mark Brown Signed-off-by: Sasha Levin