kernel/linux.git/drivers/mfd, branch v6.1.124

mfd: rt5033: Fix missing regmap_del_irq_chip()

2024-12-14T18:53:40+00:00

[ Upstream commit d256d612f47529ed0b332298e2d5ea981a4dd5b8 ] Fix missing call to regmap_del_irq_chip() in error handling path by using devm_regmap_add_irq_chip(). Fixes: 0b271258544b ("mfd: rt5033: Add Richtek RT5033 driver core.") Signed-off-by: Zhang Changzhong Link: https://lore.kernel.org/r/1730302867-8391-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices

2024-12-14T18:53:36+00:00

[ Upstream commit 0350d783ab888cb1cb48ced36cc28b372723f1a4 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Tested-by: Zhang Ning Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241005193029.1929139-4-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device

2024-12-14T18:53:36+00:00

[ Upstream commit 9b79d59e6b2b515eb9a22bc469ef7b8f0904fc73 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 957ae5098185 ("platform/x86: Add Whiskey Cove PMIC TMU support") Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Reported-by: Zhang Ning Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com Tested-by: Zhang Ning Acked-by: Hans de Goede Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241005193029.1929139-3-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device

2024-12-14T18:53:35+00:00

[ Upstream commit 686fb77712a4bc94b76a0c5ae74c60118b7a0d79 ] While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platform_get_irq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ). Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them. Fixes: 9c6235c86332 ("mfd: intel_soc_pmic_bxtwc: Add bxt_wcove_usbc device") Fixes: d2061f9cc32d ("usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY") Fixes: 57129044f504 ("mfd: intel_soc_pmic_bxtwc: Use chained IRQs for second level IRQ chips") Reported-by: Zhang Ning Closes: https://lore.kernel.org/r/TY2PR01MB3322FEDCDC048B7D3794F922CDBA2@TY2PR01MB3322.jpnprd01.prod.outlook.com Tested-by: Zhang Ning Signed-off-by: Andy Shevchenko Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20241005193029.1929139-2-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: da9052-spi: Change read-mask to write-mask

2024-12-14T18:53:35+00:00

[ Upstream commit 2e3378f6c79a1b3f7855ded1ef306ea4406352ed ] Driver has mixed up the R/W bit. The LSB bit is set on write rather than read. Change it to avoid nasty things to happen. Fixes: e9e9d3973594 ("mfd: da9052: Avoid setting read_flag_mask for da9052-i2c driver") Signed-off-by: Marcus Folkesson Link: https://lore.kernel.org/r/20240925-da9052-v2-1-f243e4505b07@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race

2024-12-14T18:53:35+00:00

[ Upstream commit 2174f9a8c9db50f74df769edd5a4ab822c73b6d2 ] As the comment said, disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 72cd799544f2 ("[PATCH] I2C: add i2c driver for TPS6501x") Signed-off-by: Jinjie Ruan Link: https://lore.kernel.org/r/20240912031530.2211654-1-ruanjinjie@huawei.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: omap-usb-tll: Use struct_size to allocate tll

2024-08-03T06:49:15+00:00

[ Upstream commit 40176714c818b0b6a2ca8213cdb7654fbd49b742 ] Commit 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") changed the memory allocation of 'tll' to consolidate it into a single allocation, introducing an incorrect size calculation. In particular, the allocation for the array of pointers was converted into a single-pointer allocation. The memory allocation used to occur in two steps: tll = devm_kzalloc(dev, sizeof(struct usbtll_omap), GFP_KERNEL); tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk *) * tll->nch, GFP_KERNEL); And it turned that into the following allocation: tll = devm_kzalloc(dev, sizeof(*tll) + sizeof(tll->ch_clk[nch]), GFP_KERNEL); sizeof(tll->ch_clk[nch]) returns the size of a single pointer instead of the expected nch pointers. This bug went unnoticed because the allocation size was small enough to fit within the minimum size of a memory allocation for this particular case [1]. The complete allocation can still be done at once with the struct_size macro, which comes in handy for structures with a trailing flexible array. Fix the memory allocation to obtain the original size again. Link: https://lore.kernel.org/all/202406261121.2FFD65647@keescook/ [1] Fixes: 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") Reviewed-by: Kees Cook Signed-off-by: Javier Carrasco Fixes: commit 16c2004d9e4d ("mfd: omap-usb-tll: Allocate driver data at once") Link: https://lore.kernel.org/r/20240626-omap-usb-tll-counted_by-v2-1-4bedf20d1b51@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: rsmu: Split core code into separate module

2024-08-03T06:49:15+00:00

[ Upstream commit c879a8c39dd55e7fabdd8d13341f7bc5200db377 ] Linking a file into two modules can have unintended side-effects and produces a W=1 warning: scripts/Makefile.build:236: drivers/mfd/Makefile: rsmu_core.o is added to multiple modules: rsmu-i2c rsmu-spi Make this one a separate module instead. Fixes: a1867f85e06e ("mfd: Add Renesas Synchronization Management Unit (SMU) support") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20240529094856.1869543-1-arnd@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: stpmic1: Fix swapped mask/unmask in irq chip

2024-05-25T14:21:30+00:00

commit c79e387389d5add7cb967d2f7622c3bf5550927b upstream. The usual behavior of mask registers is writing a '1' bit to disable (mask) an interrupt; similarly, writing a '1' bit to an unmask register enables (unmasks) an interrupt. Due to a longstanding issue in regmap-irq, mask and unmask registers were inverted when both kinds of registers were present on the same chip, ie. regmap-irq actually wrote '1's to the mask register to enable an IRQ and '1's to the unmask register to disable an IRQ. This was fixed by commit e8ffb12e7f06 ("regmap-irq: Fix inverted handling of unmask registers") but the fix is opt-in via mask_unmask_non_inverted = true because it requires manual changes for each affected driver. The new behavior will become the default once all drivers have been updated. The STPMIC1 has a normal mask register with separate set and clear registers. The driver intends to use the set & clear registers with regmap-irq and has compensated for regmap-irq's inverted behavior, and should currently be working properly. Thus, swap mask_base and unmask_base, and opt in to the new non-inverted behavior. Signed-off-by: Aidan MacDonald Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20221112151835.39059-16-aidanmacdonald.0x0@gmail.com Cc: Yoann Congal Signed-off-by: Greg Kroah-Hartman

mfd: altera-sysmgr: Call of_node_put() only when of_parse_phandle() takes a ref

2024-03-26T22:20:50+00:00

[ Upstream commit e28c28a34ee9fa2ea671a20e5e7064e6220d55e7 ] of_parse_phandle() returns a device_node with refcount incremented, which the callee needs to call of_node_put() on when done. We should only call of_node_put() when the property argument is provided though as otherwise nothing has taken a reference on the node. Fixes: f36e789a1f8d ("mfd: altera-sysmgr: Add SOCFPGA System Manager") Signed-off-by: Peter Griffin Link: https://lore.kernel.org/r/20240220115012.471689-4-peter.griffin@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin