user/sven/linux.git/drivers/mfd, branch v6.12.32

mfd: axp20x: AXP717: Add AXP717_TS_PIN_CFG to writeable regs

2025-05-29T09:02:43Z

[ Upstream commit bfad07fe298bfba0c7ddab87c5b5325970203a1e ] Add AXP717_TS_PIN_CFG (register 0x50) to the table of writeable registers so that the temperature sensor can be configured by the battery driver. Signed-off-by: Chris Morgan Link: https://lore.kernel.org/r/20250204155835.161973-3-macroalpha82@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: tps65219: Remove TPS65219_REG_TI_DEV_ID check

2025-05-29T09:02:18Z

[ Upstream commit 76b58d5111fdcffce615beb71520bc7a6f1742c9 ] The chipid macro/variable and regmap_read function call is not needed because the TPS65219_REG_TI_DEV_ID register value is not a consistent value across TPS65219 PMIC config versions. Reading from the DEV_ID register without a consistent value to compare it to isn't useful. There isn't a way to verify the match data ID is the same ID read from the DEV_ID device register. 0xF0 isn't a DEV_ID value consistent across TPS65219 NVM configurations. For TPS65215, there is a consistent value in bits 5-0 of the DEV_ID register. However, there are other error checks in place within probe() that apply to both PMICs rather than keeping this isolated check for one PMIC. Signed-off-by: Shree Ramamoorthy Link: https://lore.kernel.org/r/20250206173725.386720-4-s-ramamoorthy@ti.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: ene-kb3930: Fix a potential NULL pointer dereference

2025-04-20T08:15:44Z

commit 4cdf1d2a816a93fa02f7b6b5492dc7f55af2a199 upstream. The off_gpios could be NULL. Add missing check in the kb3930_probe(). This is similar to the issue fixed in commit b1ba8bcb2d1f ("backlight: hx8357: Fix potential NULL pointer dereference"). This was detected by our static analysis tool. Cc: stable@vger.kernel.org Fixes: ede6b2d1dfc0 ("mfd: ene-kb3930: Add driver for ENE KB3930 Embedded Controller") Suggested-by: Lee Jones Signed-off-by: Chenyuan Yang Link: https://lore.kernel.org/r/20250224233736.1919739-1-chenyuan0y@gmail.com Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman

mfd: sm501: Switch to BIT() to mitigate integer overflows

2025-04-10T12:39:21Z

[ Upstream commit 2d8cb9ffe18c2f1e5bd07a19cbce85b26c1d0cf0 ] If offset end up being high enough, right hand expression in functions like sm501_gpio_set() shifted left for that number of bits, may not fit in int type. Just in case, fix that by using BIT() both as an option safe from overflow issues and to make this step look similar to other gpio drivers. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: f61be273d369 ("sm501: add gpiolib support") Signed-off-by: Nikita Zhandarovich Link: https://lore.kernel.org/r/20250115171206.20308-1-n.zhandarovich@fintech.ru Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: lpc_ich: Add another Gemini Lake ISA bridge PCI device-id

2025-02-17T09:04:50Z

[ Upstream commit 1e89d21f8189d286f80b900e1b7cf57cb1f3037e ] On N4100 / N4120 Gemini Lake SoCs the ISA bridge PCI device-id is 31e8 rather the 3197 found on e.g. the N4000 / N4020. While at fix the existing GLK PCI-id table entry breaking the table being sorted by device-id. Signed-off-by: Hans de Goede Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241114193808.110132-1-hdegoede@redhat.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: syscon: Fix race in device_node_get_regmap()

2025-02-08T08:57:11Z

[ Upstream commit 805f7aaf7fee14a57b56af01d270edf6c10765e8 ] It is possible for multiple, simultaneous callers calling device_node_get_regmap() with the same node to fail to find an entry in the syscon_list. There is a period of time while the first caller is calling of_syscon_register() that subsequent callers also fail to find an entry in the syscon_list and then call of_syscon_register() a second time. Fix this by keeping the lock held until after of_syscon_register() completes and adds the node to syscon_list. Convert the spinlock to a mutex as many of the functions called in of_syscon_register() such as kzalloc() and of_clk_get() may sleep. Fixes: bdb0066df96e ("mfd: syscon: Decouple syscon interface from platform devices") Signed-off-by: Rob Herring (Arm) Reviewed-by: Krzysztof Kozlowski Tested-by: Krzysztof Kozlowski Tested-by: Will McVicker Tested-by: Pankaj Dubey Reviewed-by: Pankaj Dubey Link: https://lore.kernel.org/r/20241217-syscon-fixes-v2-1-4f56d750541d@kernel.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: rt5033: Fix missing regmap_del_irq_chip()

2024-12-05T13:02:10Z

[ 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: Fix IRQ domain names duplication

2024-12-05T13:02:04Z

[ Upstream commit 3727c0b4ff6ba0e61203544b4c831f7f8899753b ] For all of the devices regmap IRQ may try to created the folder with the same name which is impossible and fails with: debugfs: File '\_SB.IPC1.PMIC' in directory 'domains' already present! Add domain_suffix to all of the IRQ chips driver registers to solve the issue. Fixes: 39d047c0b1c8 ("mfd: add Intel Broxton Whiskey Cove PMIC driver") 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") Depends-on: dde286ee5770 ("regmap: Allow setting IRQ domain name suffix") Signed-off-by: Andy Shevchenko Link: https://lore.kernel.org/r/20241005193029.1929139-5-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices

2024-12-05T13:02:04Z

[ 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-05T13:02:04Z

[ 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