summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-07-24gpiolib: make legacy interfaces optionalArnd Bergmann
The traditional interfaces are only used on a small number of ancient boards. Make these optional now so they can be disabled by default. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20250722153634.3683927-1-arnd@kernel.org Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-07-24tracing: Have eprobes handle arraysSteven Rostedt
eprobes are dynamic events that can read other events using their fields to create new events. Currently it doesn't work with arrays. When the new event field is attached to the old event field, it looks at the size of the field to determine what type of field the new field should be. For 1 byte fields it's a char, for 2 bytes, it's a short and for 4 bytes it's an integer. For all other sizes it just defaults to "long". This also reads the contents of the field for such cases. For arrays that are bigger than the size of long, return the value of the address of the content itself. This will allow eprobes to read other values in the array of the old event. This is useful when raw_syscalls is enabled but the syscall events are not. The syscall events are created from the raw_syscalls as they have an array of "args" that holds the 6 long words passed to the syscall entry point. To read the value of "filename" from sys_openat, the eprobe could attach to the raw_syscall and read the second value. It can then even be passed to a synthetic event and converted back to another eprobe to get the value of "filename" after it has been read by the kernel during the system call: [ Create an eprobe called "sys" and attach it to sys_enter. Read the id of the system call and the second argument ] # echo 'e:sys raw_syscalls.sys_enter nr=$id:u32 arg2=+8($args):u64' >> /sys/kernel/tracing/dynamic_events [ Create a synthetic event "path" that will hold the address of the sys_openat filename. This is on a 64bit machine, so make it 64 bits ] # echo 's:path u64 file;' >> /sys/kernel/tracing/dynamic_events [ Add a histogram to the eprobe/sys which tiggers if the "nr" field is 257 (sys_openat), and save the filename in the "file" variable. ] # echo 'hist:keys=common_pid:file=arg2 if nr == 257' > /sys/kernel/tracing/events/eprobes/sys/trigger [ Attach a histogram to sys_exit event that triggers the "path" synthetic event and records the "filename" that was passed from the sys eprobe. ] # echo 'hist:keys=common_pid:f=$file:onmatch(eprobes.sys).trace(path,$f)' >> /sys/kernel/tracing/events/raw_syscalls/sys_exit/trigger [ Create another eprobe that dereferences the "file" field as a user space string and displays it. ] # echo 'e:open synthetic.path file=+0($file):ustring' >> /sys/kernel/tracing/dynamic_events # echo 1 > /sys/kernel/tracing/events/eprobes/open/enable # cat trace_pipe cat-1142 [003] ...5. 799.521912: open: (synthetic.path) file="/etc/ld.so.cache" cat-1142 [003] ...5. 799.521934: open: (synthetic.path) file="/etc/ld.so.cache" cat-1142 [003] ...5. 799.522065: open: (synthetic.path) file="/etc/ld.so.cache" cat-1142 [003] ...5. 799.522080: open: (synthetic.path) file="/etc/ld.so.cache" cat-1142 [003] ...5. 799.522296: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libc.so.6" cat-1142 [003] ...5. 799.522319: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libc.so.6" less-1143 [005] ...5. 799.522327: open: (synthetic.path) file="/etc/ld.so.cache" cat-1142 [003] ...5. 799.522333: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libc.so.6" cat-1142 [003] ...5. 799.522348: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libc.so.6" less-1143 [005] ...5. 799.522349: open: (synthetic.path) file="/etc/ld.so.cache" cat-1142 [003] ...5. 799.522363: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libc.so.6" less-1143 [005] ...5. 799.522477: open: (synthetic.path) file="/etc/ld.so.cache" cat-1142 [003] ...5. 799.522489: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libc.so.6" less-1143 [005] ...5. 799.522492: open: (synthetic.path) file="/etc/ld.so.cache" less-1143 [005] ...5. 799.522720: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libtinfo.so.6" less-1143 [005] ...5. 799.522744: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libtinfo.so.6" less-1143 [005] ...5. 799.522759: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libtinfo.so.6" cat-1142 [003] ...5. 799.522850: open: (synthetic.path) file="/lib/x86_64-linux-gnu/libc.so.6" Link: https://lore.kernel.org/all/20250723124202.4f7475be@batman.local.home/ Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-07-24bootconfig: Fix unaligned access when building footerBen Hutchings
Currently we add padding between the bootconfig text and footer to ensure that the footer is aligned within the initramfs image. However, because only the bootconfig data is held in memory, not the full initramfs image, the footer may not be naturally aligned in memory. This can result in an alignment fault (SIGBUS) when writing the footer on some architectures, such as sparc. Build the footer in a struct on the stack before adding it to the buffer. References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sparc64&ver=6.16%7Erc7-1%7Eexp1&stamp=1753209801&raw=0 Link: https://lore.kernel.org/all/aIC-NTw-cdm9ZGFw@decadent.org.uk/ Signed-off-by: Ben Hutchings <benh@debian.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
2025-07-24Merge tag 'ipsec-next-2025-07-23' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== pull request (net-next): ipsec-next 2025-07-23 1) Optimize to hold device only for the asynchronous decryption, where it is really needed. From Jianbo Liu. 2) Align our inbund SA lookup to RFC 4301. Only SPI and protocol should be used for an inbound SA lookup. From Aakash Kumar S. 3) Skip redundant statistics update for xfrm crypto offload. From Jianbo Liu. Please pull or let me know if there are problems. * tag 'ipsec-next-2025-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next: xfrm: Skip redundant statistics update for crypto offload xfrm: Duplicate SPI Handling xfrm: hold device only for the asynchronous decryption ==================== Link: https://patch.msgid.link/20250723080402.3439619-1-steffen.klassert@secunet.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-24spi: Add driver for the RZ/V2H(P) RSPI IPFabrizio Castro
The Renesas RZ/V2H(P) RSPI IP supports 4-wire and 3-wire serial communications in both host role and target role. It can use a DMA, but the I/O can also be driven by the processor. RX-only, TX-only, and RX-TX operations are available in DMA mode, while in processor I/O mode it only RX-TX operations are supported. Add a driver to support 4-wire serial communications as host role in processor I/O mode. Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Link: https://patch.msgid.link/20250704162036.468765-3-fabrizio.castro.jz@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24spi: dt-bindings: Document the RZ/V2H(P) RSPIFabrizio Castro
Add dt-bindings for the RSPI IP found inside the Renesas RZ/V2H(P) SoC. Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250704162036.468765-2-fabrizio.castro.jz@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24ASoC: dt-bindings: atmel,at91-ssc: add microchip,sam9x7-sscVarshini Rajendran
Add microchip,sam9x7-ssc to DT bindings documentation. Signed-off-by: Varshini Rajendran <varshini.rajendran@microchip.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20250610065005.64070-1-varshini.rajendran@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24ASoC: imx-card: Add WM8524 supportChancel Liu
WM8524 is a stereo DAC. Add support for this codec in imx-card ASoC machine driver. Signed-off-by: Chancel Liu <chancel.liu@nxp.com> Link: https://patch.msgid.link/20250723073725.787844-1-chancel.liu@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24Merge tag 'asoc-v6.17' of ↵Takashi Iwai
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next ASoC: Updates for v6.17 There's a few new drivers here and quite a lot of cleanup work from Morimoto-san but generally this has been quite a quiet release, resulting in a fairly small diffstat. Highlights include: - Refactoring of the Kconfig menus to be hopefully more consistant and easier to navigate. - Refactoring of the DAPM code, mainly hiding functionality that doesn't need to be exposed to drivers. - Removal of the unused upstream weak paths DAPM functionality. - Further work on the generic handling for SoundWire SDCA devices. - Cleanups of our usage of the PM autosuspend functions, this pulls in some PM core changes on a shared tag. - Support for AMD ACP7.2 and SoundWire on ACP 7.1, Fairphone 4 & 5, various Intel systems, Qualcomm QCS8275, Richtek RTQ9124 and TI TAS5753.
2025-07-24Merge branch 'for-linus' into for-nextTakashi Iwai
Merge the last-piece from 6.16 devel branch to sync the code base. Signed-off-by: Takashi Iwai <tiwai@suse.de>
2025-07-24ASoC: fsl_xcvr: get channel status data with firmware existsShengjiu Wang
For the XCVR module on i.MX95, even though it only supports SPDIF, the channel status needs to be obtained from RAM space, which is processed by firmware. Firmware is necessary to trigger the FSL_XCVR_IRQ_NEW_CS interrupt. This change also applies for the SPDIF & ARC function on i.MX8MP which has the firmware. Fixes: e6a9750a346b ("ASoC: fsl_xcvr: Add suspend and resume support") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://patch.msgid.link/20250710030405.3370671-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24ASoC: fsl_xcvr: get channel status data when PHY is not existsShengjiu Wang
There is no PHY for the XCVR module on i.MX93, the channel status needs to be obtained from FSL_XCVR_RX_CS_DATA_* registers. And channel status acknowledge (CSA) bit should be set once channel status is processed. Fixes: e240b9329a30 ("ASoC: fsl_xcvr: Add support for i.MX93 platform") Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Link: https://patch.msgid.link/20250710030405.3370671-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24MAINTAINERS: Add an entry for Amlogic spi driverXianwei Zhao
Add Amlogic spi entry to MAINTAINERS to clarify the maintainers. Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20250718-spisg-v5-3-b8f0f1eb93a2@amlogic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24spi: Add Amlogic SPISG driverSunny Luo
Introduced support for the new SPI IP (SPISG) driver. The SPISG is a communication-oriented SPI controller from Amlogic,supporting three operation modes: PIO, block DMA, and scatter-gather DMA. Due to there is no FIFO, PIO mode can only transfer one word at a time, which is extremely slow. Therefore, this mode was not implemented. Signed-off-by: Sunny Luo <sunny.luo@amlogic.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20250718-spisg-v5-2-b8f0f1eb93a2@amlogic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24spi: dt-bindings: Add binding document of Amlogic SPISG controllerSunny Luo
The SPISG is a new communication oriented SPI controller of Amlogic, which supports PIO, block DMA and scatter-gather DMA three operation modes. Signed-off-by: Sunny Luo <sunny.luo@amlogic.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Link: https://patch.msgid.link/20250718-spisg-v5-1-b8f0f1eb93a2@amlogic.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24spi: spi-sg2044-nor: Add SPI-NOR controller for SG2042Zixian Zeng
Add support for SOPHGO SG2042 SPI-NOR flash controller. Signed-off-by: Zixian Zeng <sycamoremoon376@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> & Tested-by: Chen Wang Link: https://patch.msgid.link/20250720-sfg-spifmc-v4-3-033188ad801e@gmail.com Reviewed-by: Chen Wang <unicorn_wang@outlook.com> & Tested-by: Chen Wang Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24spi: spi-sg2044-nor: Add configurable chip_infoZixian Zeng
SG2044 and SG2042 have similar SPI-NOR flash controller design, but have incompatibility which causes existing driver not working on SG2042: 1. SPI-NOR flash controller on SG2042 have no OPT register. 2. FIFO trigger level on SG2042 should be strictly less than 8. So introduce a new configurable chip_info structure to hold the different configuration. Link: https://github.com/sophgo/sophgo-doc/blob/main/SG2042/TRM/source/SPI-flash.rst Signed-off-by: Zixian Zeng <sycamoremoon376@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> & Tested-by: Chen Wang Link: https://patch.msgid.link/20250720-sfg-spifmc-v4-2-033188ad801e@gmail.com Reviewed-by: Chen Wang <unicorn_wang@outlook.com> & Tested-by: Chen Wang Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24spi: dt-bindings: spi-sg2044-nor: Change SOPHGO SG2042Zixian Zeng
With further testing, directly using the spi-sg2044-nor driver on SG2042 does not work. SG2042 is found to lack full compatibility with SG2044. SG2044 has OPT register and it's necessary to write but SG2042 does not. Due to other possible hardware detail differences, it is better to bind SG2042 independently. Fixes: 8450f1e0d3d0 ("spi: dt-bindings: spi-sg2044-nor: Add SOPHGO SG2042") Signed-off-by: Zixian Zeng <sycamoremoon376@gmail.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> & Tested-by: Chen Wang Link: https://patch.msgid.link/20250720-sfg-spifmc-v4-1-033188ad801e@gmail.com Reviewed-by: Chen Wang <unicorn_wang@outlook.com> & Tested-by: Chen Wang Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24ASoC: SDCA: Add support for -cn- value propertiesCharles Keepax
Many of the DisCo properties that specify Control values have an additional variant that specifies a separate value for each Control Number. Add support for these. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250718135432.1048566-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24ASoC: SDCA: Fix some holes in the regmap readable/writeable helpersCharles Keepax
The current regmap readable/writeable helper functions always allow the Next flag and allows any Control Number. Mask the Next flag based on SDCA_ACCESS_MODE_DUAL which is the only Mode that supports it. Also check that the Control Number is valid for the given control. Fixes: e3f7caf74b79 ("ASoC: SDCA: Add generic regmap SDCA helpers") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250718135432.1048566-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24erofs: support to readahead dirent blocks in erofs_readdir()Chao Yu
This patch supports to readahead more blocks in erofs_readdir(), it can enhance readdir performance in large direcotry. readdir test in a large directory which contains 12000 sub-files. files_per_second Before: 926385.54 After: 2380435.562 Meanwhile, let's introduces a new sysfs entry to control readahead bytes to provide more flexible policy for readahead of readdir(). - location: /sys/fs/erofs/<disk>/dir_ra_bytes - default value: 16384 - disable readahead: set the value to 0 Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20250721021352.2495371-1-chao@kernel.org [ Gao Xiang: minor styling adjustment. ] Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2025-07-24erofs: implement metadata compressionBo Liu (OpenAnolis)
Thanks to the meta buffer infrastructure, metadata-compressed inodes are just read from the metabox inode instead of the blockdevice (or backing file) inode. The same is true for shared extended attributes. When metadata compression is enabled, inode numbers are divided from on-disk NIDs because of non-LTS 32-bit application compatibility. Co-developed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: Bo Liu (OpenAnolis) <liubo03@inspur.com> Acked-by: Chao Yu <chao@kernel.org> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20250722003229.2121752-1-hsiangkao@linux.alibaba.com
2025-07-24erofs: add on-disk definition for metadata compressionGao Xiang
Filesystem metadata has a high degree of redundancy, so it should compress well in the general case. Although metadata compression can increase overall I/O latency, many users care more about minimized image sizes than extreme runtime performance. Let's implement metadata compression in response to user requests [1]. Actually, it's quite simple to implement metadata compression: since EROFS already supports per-inode compression, we can simply treat a special inode (called `the metabox inode`) as a container for compressed inode metadata. Since EROFS supports multiple algorithms, users can even specify LZ4 for metadata and LZMA for data. To better support incremental builds, the MSB of NIDs indicates where the inode metadata is located: if bit 63 is set, the inode itself should be read from `the metabox inode`. Optionally, shared xattrs can also be kept in `the metabox inode` if COMPAT_SHARED_EA_IN_METABOX is set. [1] https://issues.redhat.com/browse/RHEL-75783 Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Acked-by: Chao Yu <chao@kernel.org> Link: https://lore.kernel.org/r/20250717070804.1446345-2-hsiangkao@linux.alibaba.com
2025-07-24erofs: fix build error with CONFIG_EROFS_FS_ZIP_ACCEL=yBo Liu (OpenAnolis)
fix build err: ld.lld: error: undefined symbol: crypto_req_done referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a ld.lld: error: undefined symbol: crypto_acomp_decompress referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_decompress) in archive vmlinux.a ld.lld: error: undefined symbol: crypto_alloc_acomp referenced by decompressor_crypto.c fs/erofs/decompressor_crypto.o:(z_erofs_crypto_enable_engine) in archive vmlinux.a Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202507161032.QholMPtn-lkp@intel.com/ Fixes: b4a29efc5146 ("erofs: support DEFLATE decompression by using Intel QAT") Signed-off-by: Bo Liu (OpenAnolis) <liubo03@inspur.com> Link: https://lore.kernel.org/r/20250718033039.3609-1-liubo03@inspur.com Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2025-07-24erofs: remove ENOATTR definitionGao Xiang
ENOATTR is not defined in Linux; use ENODATA instead. Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20250717042317.1218597-1-hsiangkao@linux.alibaba.com
2025-07-24erofs: refine erofs_iomap_begin()Gao Xiang
- Avoid calling erofs_map_dev() for unmapped extents; - Assign `iomap->addr` for inline extents too (since they have physical location). Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20250716092254.3826715-1-hsiangkao@linux.alibaba.com
2025-07-24erofs: unify meta buffers in z_erofs_fill_inode()Gao Xiang
There is no need to keep additional local metabufs since we already have one in `struct erofs_map_blocks`. This was actually a leftover when applying meta buffers to zmap operations, see commit 09c543798c3c ("erofs: use meta buffers for zmap operations"). Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20250716064152.3537457-1-hsiangkao@linux.alibaba.com
2025-07-24erofs: remove need_kmap in erofs_read_metabuf()Gao Xiang
- need_kmap is always true except for a ztailpacking case; thus, just open-code that one; - The upcoming metadata compression will add a new boolean, so simplify this first. Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by: Chao Yu <chao@kernel.org> Link: https://lore.kernel.org/r/20250714090907.4095645-1-hsiangkao@linux.alibaba.com
2025-07-24erofs: do sanity check on m->type in z_erofs_load_compact_lcluster()Chao Yu
All below functions will do sanity check on m->type, let's move sanity check to z_erofs_load_compact_lcluster() for cleanup. - z_erofs_map_blocks_fo - z_erofs_get_extent_compressedlen - z_erofs_get_extent_decompressedlen - z_erofs_extent_lookback Reviewed-by: Hongbo Li <lihongbo22@huawei.com> Signed-off-by: Chao Yu <chao@kernel.org> Reviewed-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20250708110928.3110375-1-chao@kernel.org Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
2025-07-24erofs: get rid of {get,put}_page() for ztailpacking dataGao Xiang
The compressed data for the ztailpacking feature is fetched from the metadata inode (e.g., bd_inode), which is folio-based. Therefore, the folio interface should be used instead. Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com> Link: https://lore.kernel.org/r/20250626085459.339830-1-hsiangkao@linux.alibaba.com
2025-07-24regulator: Kconfig: Fix spelling mistake "regualtor" -> "regulator"Colin Ian King
There is a spelling mistake in the REGULATOR_RT4803 config. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Link: https://patch.msgid.link/20250724113113.143009-1-colin.i.king@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-07-24Merge tag 'ib-mfd-gpio-power-soc-v6.17' of ↵Bartosz Golaszewski
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd into gpio/for-next Immutable branch between MFD, GPIO, Power and SoC due for the v6.17 merge window
2025-07-24Merge tag 'usb-serial-6.17-rc1-2' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB serial device id for 6.17-rc1 Here's a new modem device id. This has been in linux-next with no reported issues. * tag 'usb-serial-6.17-rc1-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: option: add Foxconn T99W709
2025-07-24Merge tag 'usb-serial-6.17-rc1' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-next Johan writes: USB serial updates for 6.17-rc1 Here are the USB serial updates for 6.17-rc1, including - switch to new gpiolib interface that can return errors All have been in linux-next with no reported issues. * tag 'usb-serial-6.17-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial: USB: serial: cp210x: use new GPIO line value setter callbacks USB: serial: ftdi_sio: use new GPIO line value setter callbacks
2025-07-24Merge tag 'ipsec-2025-07-23' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec Steffen Klassert says: ==================== pull request (net): ipsec 2025-07-23 1) Premption fixes for xfrm_state_find. From Sabrina Dubroca. 2) Initialize offload path also for SW IPsec GRO. This fixes a performance regression on SW IPsec offload. From Leon Romanovsky. 3) Fix IPsec UDP GRO for IKE packets. From Tobias Brunner, 4) Fix transport header setting for IPcomp after decompressing. From Fernando Fernandez Mancera. 5) Fix use-after-free when xfrmi_changelink tries to change collect_md for a xfrm interface. From Eyal Birger . 6) Delete the special IPcomp x->tunnel state along with the state x to avoid refcount problems. From Sabrina Dubroca. Please pull or let me know if there are problems. * tag 'ipsec-2025-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec: Revert "xfrm: destroy xfrm_state synchronously on net exit path" xfrm: delete x->tunnel as we delete x xfrm: interface: fix use-after-free after changing collect_md xfrm interface xfrm: ipcomp: adjust transport header after decompressing xfrm: Set transport header to fix UDP GRO handling xfrm: always initialize offload path xfrm: state: use a consistent pcpu_id in xfrm_state_find xfrm: state: initialize state_ptrs earlier in xfrm_state_find ==================== Link: https://patch.msgid.link/20250723075417.3432644-1-steffen.klassert@secunet.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-07-24mfd: mt6397: Do not use generic name for keypad sub-devicesDmitry Torokhov
Do not use "mtk-pmic-keys" when creating sub-device for the keypad to make sure the keypad driver will only bind to the sub-device if it has support for the variant/has matching compatible. Cc: stable@vger.kernel.org Fixes: 6e31bb8d3a63 ("mfd: mt6397: Add initial support for MT6328") Fixes: de58cee8c6b8 ("mfd: mt6397-core: Add MT6357 PMIC support") Fixes: 4a901e305011 ("mfd: mt6397-core: Add resources for PMIC keys for MT6359") Reported-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Tested-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com> # on Link: https://lore.kernel.org/r/r4k3pgd3ew3ypne7ernxuzwgniiyvzosbce4cfajbcu7equblt@yato35tjb3lw Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: axp20x: Set explicit ID for regulator cell if no IRQ line is presentChen-Yu Tsai
Originally an explicit ID for the AXP313/AXP323 regulator was set to avoid a conflict with the primary AXP717 PMIC on Allwinner A523 family boards. This didn't entirely work since on some or all of these boards, the interrupt line on this secondary PMIC was left unconnected, and thus the driver would fall back to the generic "no interrupt; only regulators" case, which didn't have the explicit ID set, thus undoing the intended fix. Also set an explicit ID for the regulator cell in the no IRQ generic fall back case. This fixes the conflict for the AXP717 + AXP313/AXP323 case. For the actual single PMIC with no IRQ connected case, the ID does not affect functionality, only the device naming of the regulator cell, and by extension the name and path under sysfs. Fixes: 249abf9b1e25 ("mfd: axp20x: Set explicit ID for AXP313 regulator") Signed-off-by: Chen-Yu Tsai <wens@csie.org> Link: https://lore.kernel.org/r/20250701163652.252010-1-wens@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: mt6370: Fix the interrupt naming typoChiYuan Huang
Modify the lowercase character to uppercase. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Link: https://lore.kernel.org/r/a6ab943f4660e39b8112ff58fa97af0507cd89e9.1752026324.git.cy_huang@richtek.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: rk8xx-core: Allow to customize RK806 reset modeQuentin Schulz
The RK806 PMIC has a bitfield for configuring the restart/reset behavior (which I assume Rockchip calls "function") whenever the PMIC is reset either programmatically (c.f. DEV_RST in the datasheet) or via PWRCTRL or RESETB pins. For RK806, the following values are possible for RST_FUN: 0b00 means "Restart PMU" 0b01 means "Reset all the power off reset registers, forcing the state to switch to ACTIVE mode" 0b10 means "Reset all the power off reset registers, forcing the state to switch to ACTIVE mode, and simultaneously pull down the RESETB PIN for 5mS before releasing" 0b11 means the same as for 0b10 just above. This adds the appropriate logic in the driver to parse the new rockchip,reset-mode DT property to pass this information. It just happens that the values in the binding match the values to write in the bitfield so no mapping is necessary. If it is missing, the register is left untouched and relies either on the silicon default or on whatever was set earlier in the boot stages (e.g. the bootloader). Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-2-ce05d041b45f@cherry.de Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24dt-bindings: mfd: rk806: Allow to customize PMIC reset modeQuentin Schulz
The RK806 PMIC allows to configure its reset/restart behavior whenever the PMIC is reset either programmatically or via some external pins (e.g. PWRCTRL or RESETB). The following modes exist: - 0; restart PMU, - 1; reset all power off reset registers and force state to switch to ACTIVE mode, - 2; same as mode 1 and also pull RESETB pin down for 5ms, For example, some hardware may require a full restart (mode 0) in order to function properly as regulators are shortly interrupted in this mode. This is the case for RK3588 Jaguar and RK3588 Tiger which have a companion microcontroller running on an independent power supply and monitoring the PMIC power rail to know the state of the main system. When it detects a restart, it resets its own IPs exposed to the main system as if to simulate its own reset. Failing to perform this fake reset of the microcontroller may break things (e.g. watchdog not automatically disabled, buzzer still running until manually disabled, leftover configuration from previous main system state, etc...). Some other systems may be depending on the power rails to not be interrupted even for a small amount of time[1]. This allows to specify how the PMIC should perform on the hardware level and may differ between hardware designs, so a DT property seems warranted. I unfortunately do not see how this could be made generic enough to make it a non-vendor property. [1] https://lore.kernel.org/linux-rockchip/2577051.irdbgypaU6@workhorse/ Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org> Link: https://lore.kernel.org/r/20250627-rk8xx-rst-fun-v4-1-ce05d041b45f@cherry.de Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: syscon: atmel-smc: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250627164414.1043434-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: madera: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20250626154544.324724-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: wm8350-core: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20250626155951.325683-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24dt-bindings: mfd: samsung,s2mps11: Add comment about interrupts propertiesAndré Draszik
Document why the binding uses oneOf when specifying just one of the interrupt properties is supposed to be enough. dtschema's fixups.py has special treatment of the interrupts and interrupts-extended properties, but that appears to work at the top level only. Elsewhere, an explicit oneOf is required. Signed-off-by: André Draszik <andre.draszik@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250627-s2mpg10-binding-comment-v1-1-f37e5187f0fd@linaro.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: davinci_voicecodec: Don't use "proxy" headersAndy Shevchenko
Update header inclusions to follow IWYU (Include What You Use) principle. Note that kernel.h is discouraged to be included as it's written at the top of that file. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20250626154354.324439-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: pcf50633: Remove the header file core.hDr. David Alan Gilbert
The patches to remove all of the pieces of the pcf50633 have gone in and we're left with the header. Remove it. The pcf50633 was used as part of the OpenMoko devices but the support for its main chip was recently removed in: commit 61b7f8920b17 ("ARM: s3c: remove all s3c24xx support") See https://lore.kernel.org/all/Z8z236h4B5A6Ki3D@gallifrey/ Signed-off-by: "Dr. David Alan Gilbert" <linux@treblig.org> Link: https://lore.kernel.org/r/20250701145625.204048-1-linux@treblig.org Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: tps65219: Remove another unused field from 'struct tps65219'Christophe JAILLET
The 'chip_id' field from 'struct tps65219' is unused. Remove it. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/f20443e6e13b0b101648a41010a19ee56589fa0b.1750530460.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: tps65219: Remove an unused field from 'struct tps65219'Christophe JAILLET
Since commit 3df4c6367520 ("mfd: tps65219: Add support for soft shutdown via sys-off API"), the 'nb' field from 'struct tps65219' is unused. Remove it. Also remove the now useless #include <linux/notifier.h> for the same reason. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/8a264c3a92b8e62c1dadd374f2685030e042eb08.1750530460.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: tps65219: Constify struct regmap_irq_sub_irq_map and tps65219_chip_dataChristophe JAILLET
'struct regmap_irq_sub_irq_map' and 'struct tps65219_chip_data' are not modified in this driver. Constifying these structures moves some data to a read-only section, so increases overall security. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 27804 10016 256 38076 94bc drivers/mfd/tps65219.o After: ===== text data bss dec hex filename 27893 9792 256 37941 9435 drivers/mfd/tps65219.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/117946696551de41b706ea9b973a7ccaacea5178.1750530460.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2025-07-24mfd: rohm-bd71828: Constify some structuresChristophe JAILLET
Several structures are not modified in this driver. Constifying them moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. This is the case for 'gpio_keys_platform_data' and 'mfd_cell'. On a x86_64, with allmodconfig: Before: ====== text data bss dec hex filename 18321 13952 192 32465 7ed1 drivers/mfd/rohm-bd71828.o After: ===== text data bss dec hex filename 22897 9376 192 32465 7ed1 drivers/mfd/rohm-bd71828.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com> Link: https://lore.kernel.org/r/037e28e587ae899da9acdb45c606d75ec61f858b.1750501700.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-20 02:47:33 +0000