Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
Merge the last-piece from 6.16 devel branch to sync the code base.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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
|
|
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>
|
|
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
|
|
- 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
|
|
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
|
|
- 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
|
|
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>
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
'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>
|
|
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>
|
|
commit b0a5cde57cf1 ("dt-bindings: mfd: Explain lack of child dependency
in simple-mfd") pointed out that it's a mistake for a child device of
a simple MFD device to depend on the simple MFD device's clock resources.
fsl,imx8qxp-csr.yaml happens to make that mistake. To fix that, remove
fsl,imx8qxp-csr.yaml and use "simple-pm-bus" and "syscon" as the CSR node's
compatible strings in the examples of fsl,imx8qxp-pixel-link-msi-bus.yaml
to replace the wrong compatible strings which include "simple-mfd" and
"fsl,imx8qxp-mipi-lvds-csr". Since fsl,imx8qxp-pixel-link-msi-bus.yaml
as the last user of the CSR compatible strings no longer uses them, it's
safe to remove the fsl,imx8qxp-csr.yaml binding documentation.
Fixes: 9b2c55b5403f ("dt-bindings: mfd: Add i.MX8qm/qxp Control and Status Registers module binding")
Fixes: c08645ea215c ("dt-bindings: bus: Add Freescale i.MX8qxp pixel link MSI bus binding")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20250620022537.3072877-1-victor.liu@nxp.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
On newer boards featuring the A523 SoC, the AXP323 (related to the
AXP313) is paired with the AXP717 and serves as a secondary PMIC
providing additional regulator outputs. However the MFD cells are all
registered with PLATFORM_DEVID_NONE, which causes the regulator cells
to conflict with each other.
Commit e37ec3218870 ("mfd: axp20x: Allow multiple regulators") attempted
to fix this by switching to PLATFORM_DEVID_AUTO so that the device names
would all be different, however that broke IIO channel mapping, which is
also tied to the device names. As a result the change was later reverted.
Instead, here we attempt to make sure the AXP313/AXP323 regulator cell
does not conflict by explicitly giving it an ID number. This was
previously done for the AXP809+AXP806 pair used with the A80 SoC.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20250619173207.3367126-1-wens@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
irq_domain_create_simple() takes fwnode as the first argument. It can be
extracted from the struct device using dev_fwnode() helper instead of
using of_node with of_fwnode_handle().
So use the dev_fwnode() helper.
Signed-off-by: "Jiri Slaby (SUSE)" <jirislaby@kernel.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20250611104348.192092-13-jirislaby@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
After commit a934a57a42f6 ("scripts/misc-check: check missing #include
<linux/export.h> when W=1") and commit 7d95680d64ac ("scripts/misc-check:
check unnecessary #include <linux/export.h> when W=1") we get the build
warning with W=1:
drivers/mfd/stm32-timers.c: warning: EXPORT_SYMBOL() is used, but #include <linux/export.h> is missing
Fix it.
Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com>
Acked-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/20250610124855.269158-6-antonio.borneo@foss.st.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
twl6030_mmc_card_detect() and twl6030_mmc_card_detect_config() have been
unused since 2013's commit b2ff4790612b ("ARM: OMAP2+: Remove legacy
omap4_twl6030_hsmmc_init")
Remove them.
Signed-off-by: "Dr. David Alan Gilbert" <linux@treblig.org>
Link: https://lore.kernel.org/r/20250607202232.265344-1-linux@treblig.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
phy-lpc18xx-usb-otg to YAML format
Combine the following separate plain text based bindings to YAML:
lpc1850-creg-clk.txt
pc1850-dmamux.txt
phy-lpc18xx-usb-otg.txt
Additional changes:
- remove label in example.
- remove dmamux consumer in example.
- remove clock consumer in example.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: "Rob Herring (Arm)" <robh@kernel.org>
Link: https://lore.kernel.org/r/20250602143612.943516-1-Frank.Li@nxp.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Convert the Freescale MXS Low-Resoulution ADC (LRADC) device tree
binding documentation to json-schema.
The clocks and #io-channel-cells properties have also been added; They
are present in the respective SoC DTSI files but were missing from the
old mxs-lradc.txt file.
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20250530160748.2476088-2-dario.binacchi@amarulasolutions.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Static 'struct reg_sequence' array, 'struct regmap_irq_sub_irq_map' and
'struct regmap_irq_chip ' are not modified so can be changed to const
for more safety.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20250528194416.567127-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The charge-control subsystem in the ChromeOS EC is not strictly tied to
its USB-PD subsystem.
Since commit 7613bc0d116a ("mfd: cros_ec: Don't load charger with UCSI")
the presence of EC_FEATURE_UCSI_PPM would inhibit the probing of the
charge-control driver.
Furthermore recent versions of the EC firmware in Framework laptops
hard-disable EC_FEATURE_USB_PD to avoid probing cros-usbpd-charger,
which then also breaks cros-charge-control.
Instead use the dedicated EC_FEATURE_CHARGER.
Cc: stable@vger.kernel.org
Link: https://github.com/FrameworkComputer/EmbeddedController/commit/1d7bcf1d50137c8c01969eb65880bc83e424597e
Fixes: 555b5fcdb844 ("mfd: cros_ec: Register charge control subdevice")
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Tested-by: Tom Vincent <linux@tlvince.com>
Link: https://lore.kernel.org/r/20250521-cros-ec-mfd-chctl-probe-v1-1-6ebfe3a6efa7@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|