adi,ad5360
- Use a signed int type to be able to hold a potential error return.
adi,ad5421
- Use a signed int type to be able to hold a potential error return.
adi,adf4350
- Ensure rules on VCO frequency and prescaler values are met.
- Fix a wrong offset for the clock divisor control field.
xilinx,ams
- Unmask alarms correctly if an event is disabled and re-enabled.
- Fix a wrong register field mask.
-----BEGIN PGP SIGNATURE-----
iQJFBAABCgAvFiEEbilms4eEBlKRJoGxVIU0mcT0FogFAmjJGHERHGppYzIzQGtl
cm5lbC5vcmcACgkQVIU0mcT0FohYZRAAihwyDUJy9t5DkfxBsfVj6y+PvgSOy6g6
74ipeo6Bg7JNuvG+S7gTbc0qa3FwQXh8NVR2DBZRsQAB8EfWLS7VchbiRHiIg0Ia
HYoAnMLwYTZ181ig21Avgo3K6hBEEUCmilhpM3ZGiZdrto1GTQvFYZ73yVPxmdiB
Y+g7W2bjYdHawZCJCnluRrJqyV+cxaXyoNS7Pgqz/vAww9oFNOB2Xc+Dt8lqqP8p
k0VFs1NIC7+58nWuwNbfAFfXJxpVcqtgWWLJKC860/DGwjE41zxnJSipfH0r7+kX
IJ5k7CsyYaaTFYdXhpNf3EIjZ2j0eg5I7A/Rq0eQYLswxY9oZWAx6ds6Tz+0iqQb
i5oRn1xKPrY1K/g6sMFL9fs20US9EKn3RVYHy535ZjNJO9A1vwMhoOR/e5oZbZkC
WA8jInyw8nAyVvKStidB7k1CTLydrBbEzuueYD6vgF/JcqDQTC4uX14qTeMrF9lB
CMFuUgPmer9wTT9s7en5vqwR+nORSEy3aew6aAVRiiwaAwvdDQuR1j+mJANGjlpz
bM3JOkBfvElo50OhtR80PO23v9lE+jn+u+2vRzuvz7eWTpBJkhThUniunDWTDZsF
QRkAHBIo4jibBGYqEsFxUhJOK3H0nxj7wkmhmoDMjzKCSQd8nTTUarEaiRDED1cd
jnYME2cq3Mc=
=YwFX
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-6.17b' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-next
Jonathan writes:
IIO: 2nd set of fixes for the 6.17 cycle (or 6.18 merge window)
adi,ad5360
- Use a signed int type to be able to hold a potential error return.
adi,ad5421
- Use a signed int type to be able to hold a potential error return.
adi,adf4350
- Ensure rules on VCO frequency and prescaler values are met.
- Fix a wrong offset for the clock divisor control field.
xilinx,ams
- Unmask alarms correctly if an event is disabled and re-enabled.
- Fix a wrong register field mask.
* tag 'iio-fixes-for-6.17b' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio:
iio: dac: ad5421: use int type to store negative error codes
iio: dac: ad5360: use int type to store negative error codes
iio: frequency: adf4350: Fix ADF4350_REG3_12BIT_CLKDIV_MODE
iio: frequency: adf4350: Fix prescaler usage.
iio: xilinx-ams: Fix AMS_ALARM_THR_DIRECT_MASK
iio: xilinx-ams: Unmask interrupts after updating alarms
iio/adc/pac1934: fix channel disable configuration
Includes a cleanup of the Counter subsystem sysfs attributes
documentation component_id list to alphabetical order, and replaces
superfluous error handling code in ecap_cnt_probe() with a call to
device-managed devm_pm_runtime_enable().
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCaMjsqgAKCRC1SFbKvhIj
KyPXAP0Xo2N8oKbfzU6sqDbk7cdSyD6hyo8l5lWtHQv9vCG8JAD9HxV6lQcuIXJw
9UrKowAXPr/waaecJVE9aODCRFalywM=
=w2NV
-----END PGP SIGNATURE-----
Merge tag 'counter-updates-for-6.18' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-next
William writes:
Counter updates for 6.18
Includes a cleanup of the Counter subsystem sysfs attributes
documentation component_id list to alphabetical order, and replaces
superfluous error handling code in ecap_cnt_probe() with a call to
device-managed devm_pm_runtime_enable().
* tag 'counter-updates-for-6.18' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter:
counter: ti-ecap-capture: Use devm_pm_runtime_enable()
counter: Alphabetize component_id sysfs attributes Documentation list
Add support for Airoha AN8855 Switch EFUSE. These EFUSE might be used
for calibration data for the internal switch PHYs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131415.303407-6-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Document support for Airoha AN8855 Switch EFUSE used to calibrate
internal PHYs and store additional configuration info.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131415.303407-5-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The Kontron SMARC-sAM67 has the same nvmem layout as the SMARC-sAL28. To
To be prepared for any board specific quirks, add a specific compatible.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131415.303407-4-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add bindings to expose the On Chip One-Time Programmable Controller
(OCOTP) for the NXP s32g chipset. There are three versions of this
chip but they're compatible so we can fall back to the nxp,s32g2-ocotp
compatible.
Signed-off-by: Ciprian Costea <ciprianmarian.costea@nxp.com>
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131415.303407-2-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some platforms (like lemans) feature one or more GPDSPs (General
Purpose DSPs). Similar to other kinds of Hexagon DSPs, they provide
a FastRPC implementation, allowing code execution in both signed and
unsigned protection domains. Extend the checks to allow domain names
starting with "gdsp" (possibly followed by an index).
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Signed-off-by: Ling Xu <quic_lxu5@quicinc.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131302.303199-5-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently the domain ids are added for each instance of domains, this is
totally not scalable approach. Clean this mess and create domain ids for
only domains not its instances.
Co-developed-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Signed-off-by: Ling Xu <quic_lxu5@quicinc.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131302.303199-4-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Domain ID in the uAPI is misleading. Remove checks and log messages
related to 'domain' field in capability structure. Update UAPI to
mark the field as unused.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Signed-off-by: Ling Xu <quic_lxu5@quicinc.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131302.303199-3-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There are some products which support GDSP remoteprocs. GDSP is General
Purpose DSP where tasks can be offloaded. There are 2 GDSPs named gdsp0
and gdsp1. Add "gdsp0" and "gdsp1" as the new supported labels for GDSP
fastrpc domains.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Ekansh Gupta <ekansh.gupta@oss.qualcomm.com>
Signed-off-by: Ling Xu <quic_lxu5@quicinc.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131302.303199-2-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Qcom Slimbus controller driver is totally unused and dead code, there is
no point in keeping this driver in the kernel without users.
This patch removes the driver along with device tree bindings.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250912131202.303026-2-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
1. Correct missing interrupts in IMX 1-Wire Devicetree bindings.
2. Drop old, dead code from Matrox driver.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmjAblkQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD1/dyD/0RvERKpD3j3PqLsNky9QmldpuaZU/Yhlja
vnoxIVGhfu/llQhSHG/e+AGQJi9icH9Z271TkPyb/TJtboWrePBT5UnFtz82dfxq
m+9rc8wX77Q3h3fl/cEGNeHUTZi9Xmi/1lPkhRfm167WHpDyGnokFyRqdfZbPpMf
a0LZSAzPS9nyt6pX3Ie97qacHnWUytxqFfG/X3C4nHPYrZejF7zn0/moadSiT+hW
D6TyyGs8wfseJNf/AHJlEuWEDviDf1tpAcBvwbQ7/pAOnJanHVWdUrtHaQy2BgAZ
k77MfUVvENLHtXuPifh4vNgek4km/XIMMGuh2HaXeB0Kr7jFsL4MibfXYNmESvaY
g8dnSPIzBl7YYtwrkLVcaJZ6Tomc8yc9vu/g4wUczBpna9DeUNcwb4gRUN4NaZ5h
Yj8q1tuHhDaWdf4bLOmr7wGKho0kao6/V3r88OCEHsNN2qw1EEzWqGzWbAz6AXxn
Fl50tdlJDj7uiMo3o2GXgA+GmX/eQrm80wAInInA4SHT3O6t8y8Gjz4Bk+1p0qAK
euTLv8bHP8OsdZCH52cNk+mqnDulm2va2rnByhBnXKYtaOSyjSbqSY0QYuHmSELh
GH9BW6Alxvt79loO999JW0bPVWamq+d9RZu1PgiwPHuM8S9aJs9+Wgrnc9MSRYUL
QMyeKx7r1g==
=V4Gk
-----END PGP SIGNATURE-----
Merge tag 'w1-drv-6.18' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/krzk/linux-w1 into char-misc-next
Krzysztof writes:
1-Wire bus drivers for v6.18
1. Correct missing interrupts in IMX 1-Wire Devicetree bindings.
2. Drop old, dead code from Matrox driver.
* tag 'w1-drv-6.18' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/krzk/linux-w1:
w1: matrox: Remove some deadcode in matrox_w1_remove()
dt-bindings: w1: imx: Add an entry for the interrupts property
mei_device lifetime was managed by devm procedure of parent device.
But such memory is freed on device_del.
Mei_device object is used by client object that may be alive after
parent device is removed.
It may lead to use-after-free if discrete graphics driver unloads
mei_gsc auxiliary device while user-space holds open handle to mei
character device.
Connect mei_device structure lifteme to mei class device lifetime
by adding mei_device free to class device remove callback.
Move exising parent device pointer to separate field in mei_device
to avoid misuse.
Allocate character device dynamically and allow to control its own
lifetime as it may outlive mei_device structure while character
device closes after parent device is removed from the system.
Leave power management on parent device as we overwrite pci runtime
pm procedure and user-space is expecting it there.
Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14201
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Link: https://lore.kernel.org/r/20250826125617.1166546-1-alexander.usyskin@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, misc_deregister() uses list_del() to remove the device
from the list. After list_del(), the list pointers are set to
LIST_POISON1 and LIST_POISON2, which may help catch use-after-free bugs,
but does not reset the list head.
If misc_deregister() is called more than once on the same device,
list_empty() will not return true, and list_del() may be called again,
leading to undefined behavior.
Replace list_del() with list_del_init() to reinitialize the list head
after deletion. This makes the code more robust against double
deregistration and allows safe usage of list_empty() on the miscdevice
after deregistration.
[ Note, this seems to keep broken out-of-tree drivers from doing foolish
things. While this does not matter for any in-kernel drivers,
external drivers could use a bit of help to show them they shouldn't
be doing stuff like re-registering misc devices - gregkh ]
Signed-off-by: Xion Wang <xion.wang@mediatek.com>
Link: https://lore.kernel.org/r/20250904063714.28925-2-xion.wang@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The WARN_ON(list_empty(&misc->list)) in misc_deregister() does
not catch any practical error conditions:
- For statically allocated miscdevice structures, the list pointers
are zero-initialized, so list_empty() returns false, not true.
- After list_del(), the pointers are set to LIST_POISON1 and LIST_POISON2,
so repeated deregistration also fails to trigger the check.
Signed-off-by: Xion Wang <xion.wang@mediatek.com>
Link: https://lore.kernel.org/r/20250827024201.21407-2-xion.wang@mediatek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The ADLink PCI-7250, LPCI-7250, and LPCIe-7250 are PCI/PCIe boards with
8 relay outputs and 8 isolated digital inputs. Add a new Comedi driver
"adl_pci7250" to support them.
It is possible to add up to three PCI-7251 plug-in modules to the
PCI-7250, with 8 relay outputs and 8 isolated digital inputs per plug-in
module. We cannot reliably detect whether the modules are fitted
without changing their state. It is harmless to assume the modules are
fitted; they just won't do anything, so the driver allows all 32 relay
outputs to be written (and their initial state to be read), and all 32
digital inputs to be read.
The LPCI-7250 and LPCIe-7250 are low-profile boards that do not support
the plug-in modules, but except for a newer variant of the LPCIe-7250,
they cannot be distinguished from the full-height boards by their PCI
IDs. For the newer variant of the LPCIe-7250, we can assume that there
are no plug-in modules fitted and limit the number of channels
accordingly. This newer variant of the LPCIe-7250 uses memory-mapped
registers, whereas all the other boards use port-mapped registers.
I have tested the PCI-7250. The new variant of the LPCIe-7250 has been
tested in an out-of-tree version of the Comedi drivers by someone else.
Tested-by: Ian Abbott <abbotti@mev.co.uk> # PCI-7250 only
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Link: https://lore.kernel.org/r/20250821145914.10445-1-abbotti@mev.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Replace kzalloc() followed by copy_from_user() with memdup_user_nul() to
improve and simplify remote_settings_file_write().
No functional changes intended.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://lore.kernel.org/r/20250905103247.423840-2-thorsten.blum@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Without CONFIG_REGMAP, rmi-i2c.c fails to build because struct
regmap_config is not defined:
drivers/misc/amd-sbi/rmi-i2c.c: In function ‘sbrmi_i2c_probe’:
drivers/misc/amd-sbi/rmi-i2c.c:57:16: error: variable ‘sbrmi_i2c_regmap_config’ has initializer but incomplete type
57 | struct regmap_config sbrmi_i2c_regmap_config = {
| ^~~~~~~~~~~~~
Additionally, CONFIG_REGMAP_I2C is needed for devm_regmap_init_i2c():
ld: drivers/misc/amd-sbi/rmi-i2c.o: in function `sbrmi_i2c_probe':
drivers/misc/amd-sbi/rmi-i2c.c:69:(.text+0x1c0): undefined reference to `__devm_regmap_init_i2c'
Fixes: 013f7e7131 ("misc: amd-sbi: Use regmap subsystem")
Cc: stable@vger.kernel.org
Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
Tested-by: Akshay Gupta <Akshay.Gupta@amd.com>
Reviewed-by: Akshay Gupta <Akshay.Gupta@amd.com>
Link: https://lore.kernel.org/r/20250829091442.1112106-1-max.kellermann@ionos.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Similar to previous commit 2a934fdb01 ("media: v4l2-dev: fix error
handling in __video_register_device()"), the release hook should be set
before device_register(). Otherwise, when device_register() return error
and put_device() try to callback the release function, the below warning
may happen.
------------[ cut here ]------------
WARNING: CPU: 1 PID: 4760 at drivers/base/core.c:2567 device_release+0x1bd/0x240 drivers/base/core.c:2567
Modules linked in:
CPU: 1 UID: 0 PID: 4760 Comm: syz.4.914 Not tainted 6.17.0-rc3+ #1 NONE
RIP: 0010:device_release+0x1bd/0x240 drivers/base/core.c:2567
Call Trace:
<TASK>
kobject_cleanup+0x136/0x410 lib/kobject.c:689
kobject_release lib/kobject.c:720 [inline]
kref_put include/linux/kref.h:65 [inline]
kobject_put+0xe9/0x130 lib/kobject.c:737
put_device+0x24/0x30 drivers/base/core.c:3797
pps_register_cdev+0x2da/0x370 drivers/pps/pps.c:402
pps_register_source+0x2f6/0x480 drivers/pps/kapi.c:108
pps_tty_open+0x190/0x310 drivers/pps/clients/pps-ldisc.c:57
tty_ldisc_open+0xa7/0x120 drivers/tty/tty_ldisc.c:432
tty_set_ldisc+0x333/0x780 drivers/tty/tty_ldisc.c:563
tiocsetd drivers/tty/tty_io.c:2429 [inline]
tty_ioctl+0x5d1/0x1700 drivers/tty/tty_io.c:2728
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:598 [inline]
__se_sys_ioctl fs/ioctl.c:584 [inline]
__x64_sys_ioctl+0x194/0x210 fs/ioctl.c:584
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x5f/0x2a0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
Before commit c79a39dc8d ("pps: Fix a use-after-free"),
pps_register_cdev() call device_create() to create pps->dev, which will
init dev->release to device_create_release(). Now the comment is outdated,
just remove it.
Thanks for the reminder from Calvin Owens, 'kfree_pps' should be removed
in pps_register_source() to avoid a double free in the failure case.
Link: https://lore.kernel.org/all/20250827065010.3208525-1-wangliang74@huawei.com/
Fixes: c79a39dc8d ("pps: Fix a use-after-free")
Signed-off-by: Wang Liang <wangliang74@huawei.com>
Reviewed-By: Calvin Owens <calvin@wbinvd.org>
Link: https://lore.kernel.org/r/20250830075023.3498174-1-wangliang74@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The function parameter 'size_t count' is unsigned and cannot be less
than zero. Remove the redundant condition.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://lore.kernel.org/r/20250903202350.182446-2-thorsten.blum@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
There is a dev_err message that is reporting the value of
cmd->asiv_length when it should be reporting cmd->asv_length
instead. Fix this.
Fixes: eaf4722d46 ("GenWQE Character device and DDCB queue")
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Link: https://lore.kernel.org/r/20250902113712.2624743-1-colin.i.king@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The dev_err_probe() doesn't do anything when error is '-ENOMEM'.
Therefore, remove the useless call to dev_err_probe(), and just
return the value instead.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Acked-by: Thorsten Scherer <t.scherer@eckelmann.de>
Link: https://lore.kernel.org/r/20250819121749.613584-1-zhao.xichao@vivo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove hard-coded strings by using the str_enabled_disabled() helper
function and silence the following Coccinelle/coccicheck warning
reported by string_choices.cocci:
opportunity for str_enabled_disabled(..)
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://lore.kernel.org/r/20250820102734.760844-2-thorsten.blum@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove hard-coded strings by using the str_write_read() helper function
and silence the following two Coccinelle/coccicheck warnings reported by
string_choices.cocci:
opportunity for str_write_read(write)
opportunity for str_write_read(write)
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://lore.kernel.org/r/20250820102108.760382-2-thorsten.blum@linux.dev
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The error description would be wrong in case the "size" Devicetree
property is missing for an FRAM without device ID.
Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20250815095839.4219-4-m.heidelberg@cab.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Not all FRAM chips have a device ID and implement the corresponding read
command. For such chips this led to the following error on module
loading:
at25 spi2.0: Error: no Cypress FRAM (id 00)
The device ID contains the memory size, so devices without this ID are
supported now by setting the size manually in Devicetree using the
"size" property.
Tested with FM25L16B and "size = <2048>;":
at25 spi2.0: 2 KByte fm25 fram, pagesize 4096
According to Infineon/Cypress datasheets, these FRAMs have a device ID:
FM25V01A
FM25V02A
FM25V05
FM25V10
FM25V20A
FM25VN10
but these do not:
FM25040B
FM25640B
FM25C160B
FM25CL64B
FM25L04B
FM25L16B
FM25W256
So all "FM25V*" FRAMs and only these have a device ID. The letter after
"FM25" (V/C/L/W) only describes the voltage range, though.
Link: https://lore.kernel.org/all/20250401133148.38330-1-m.heidelberg@cab.de/
Signed-off-by: Markus Heidelberg <m.heidelberg@cab.de>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://lore.kernel.org/r/20250815095839.4219-3-m.heidelberg@cab.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove the logic to set interrupt mask by default in uio_hv_generic
driver as the interrupt mask value is supposed to be controlled
completely by the user space. If the mask bit gets changed
by the driver, concurrently with user mode operating on the ring,
the mask bit may be set when it is supposed to be clear, and the
user-mode driver will miss an interrupt which will cause a hang.
For eg- when the driver sets inbound ring buffer interrupt mask to 1,
the host does not interrupt the guest on the UIO VMBus channel.
However, setting the mask does not prevent the host from putting a
message in the inbound ring buffer. So let’s assume that happens,
the host puts a message into the ring buffer but does not interrupt.
Subsequently, the user space code in the guest sets the inbound ring
buffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.
User space code then calls pread() to wait for an interrupt.
Then one of two things happens:
* The host never sends another message. So the pread() waits forever.
* The host does send another message. But because there’s already a
message in the ring buffer, it doesn’t generate an interrupt.
This is the correct behavior, because the host should only send an
interrupt when the inbound ring buffer transitions from empty to
not-empty. Adding an additional message to a ring buffer that is not
empty is not supposed to generate an interrupt on the guest.
Since the guest is waiting in pread() and not removing messages from
the ring buffer, the pread() waits forever.
This could be easily reproduced in hv_fcopy_uio_daemon if we delay
setting interrupt mask to 0.
Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,
there’s a race condition. Once user space empties the inbound ring
buffer, but before user space sets interrupt_mask to 0, the host could
put another message in the ring buffer but it wouldn’t interrupt.
Then the next pread() would hang.
Fix these by removing all instances where interrupt_mask is changed,
while keeping the one in set_event() unchanged to enable userspace
control the interrupt mask by writing 0/1 to /dev/uioX.
Fixes: 95096f2fbd ("uio-hv-generic: new userspace i/o driver for VMBus")
Suggested-by: John Starks <jostarks@microsoft.com>
Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
Cc: stable@vger.kernel.org
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Reviewed-by: Long Li <longli@microsoft.com>
Reviewed-by: Tianyu Lan <tiala@microsoft.com>
Tested-by: Tianyu Lan <tiala@microsoft.com>
Link: https://lore.kernel.org/r/20250828044200.492030-1-namjain@linux.microsoft.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since commit 63d00be693 ("PM: runtime: Allow unassigned
->runtime_suspend|resume callbacks"), unassigned
.runtime_{suspend,resume}() callbacks are treated the same as dummy
callbacks that just return zero.
As the Runtime PM callbacks were the only driver-specific PM handling,
all PM handling can be removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/a5495b6068dd4e40ae7e0fb66b067fd5b5c210b2.1756999260.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Since commit 63d00be693 ("PM: runtime: Allow unassigned
->runtime_suspend|resume callbacks"), unassigned
.runtime_{suspend,resume}() callbacks are treated the same as dummy
callbacks that just return zero.
As the Runtime PM callbacks were the only driver-specific PM handling,
all PM handling can be removed.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/121921f66a2baa125ea62be9436e8b5b12a4ad4d.1756999182.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The struct of_device_id list here is filled in at load time since
commit 05c3e0bb56 ("UIO: allow binding uio_pdrv_genirq.c to devices using
command line option").
However, this does not work with MODULE_DEVICE_TABLE, which generates an
alias at build time. In this case, it generates the aliases "of:N*T*"
and "of:N*T*C*", which matches *any* OF device node, which is obviously
not intended. It confuses userspace into loading this module for any OF
device, and confuses anyone trying to resolve an OF modalias.
Remove this broken MODULE_DEVICE_TABLE.
Suggested-by: Emily <hello@emily.moe>
Fixes: 05c3e0bb56 ("UIO: allow binding uio_pdrv_genirq.c to devices using command line option")
Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
Link: https://lore.kernel.org/r/20250826-uio-no-modalias-v2-1-495afa9e8a5b@iscas.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
'struct pci_device_id' is not modified in these drivers.
Constifying this structure moves some data to a read-only section, so
increases overall security.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
4073 1336 0 5409 1521 drivers/uio/uio_cif.o
After:
=====
text data bss dec hex filename
4233 1176 0 5409 1521 drivers/uio/uio_cif.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/114791f85f0f81531ca2169721eac4911dbe0865.1755629302.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alice Ryhl <aliceryhl@google.com> says:
This series adds support for the `struct iov_iter` type. This type
represents an IO buffer for reading or writing, and can be configured
for either direction of communication.
In Rust, we define separate types for reading and writing. This will
ensure that you cannot mix them up and e.g. call copy_from_iter in a
read_iter syscall.
To use the new abstractions, miscdevices are given new methods read_iter
and write_iter that can be used to implement the read/write syscalls on
a miscdevice. The miscdevice sample is updated to provide read/write
operations.
Intended for Greg's miscdevice tree.
Link: https://lore.kernel.org/r/20250822-iov-iter-v5-0-6ce4819c2977@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A userland application can now operate on the char device with read() in
order to consume a locally held buffer. Memory for the buffer is to be
provisioned and the buffer populated in its subsequently provided
write() counterpart.
Signed-off-by: Lee Jones <lee@kernel.org>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Co-developed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250822-iov-iter-v5-5-6ce4819c2977@google.com
These will be used for the read_iter() and write_iter() callbacks, which
are now the preferred back-ends for when a user operates on a char device
with read() and write() respectively.
Co-developed-by: Lee Jones <lee@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250822-iov-iter-v5-4-6ce4819c2977@google.com
This adds a very simple Kiocb struct that lets you access the inner
file's private data and the file position. For now, nothing else is
supported.
Cc: Christian Brauner <brauner@kernel.org>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250822-iov-iter-v5-3-6ce4819c2977@google.com
This adds abstractions for the iov_iter type in the case where
data_source is ITER_DEST. This will make Rust implementations of
fops->read_iter possible.
This series only has support for using existing IO vectors created by C
code. Additional abstractions will be needed to support the creation of
IO vectors in Rust code.
These abstractions make the assumption that `struct iov_iter` does not
have internal self-references, which implies that it is valid to move it
between different local variables.
This patch adds an IovIterDest struct that is very similar to the
IovIterSource from the previous patch. However, as the methods on the
two structs have very little overlap (just getting the length and
advance/revert), I do not think it is worth it to try and deduplicate
this logic.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250822-iov-iter-v5-2-6ce4819c2977@google.com
This adds abstractions for the iov_iter type in the case where
data_source is ITER_SOURCE. This will make Rust implementations of
fops->write_iter possible.
This series only has support for using existing IO vectors created by C
code. Additional abstractions will be needed to support the creation of
IO vectors in Rust code.
These abstractions make the assumption that `struct iov_iter` does not
have internal self-references, which implies that it is valid to move it
between different local variables.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://lore.kernel.org/r/20250822-iov-iter-v5-1-6ce4819c2977@google.com
Change the 'ret' variable in ad5421_update_ctrl() from unsigned int to
int, as it needs to store either negative error codes or zero returned
by ad5421_write_unlocked().
Fixes: 5691b23489 ("staging:iio:dac: Add AD5421 driver")
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20250901135726.17601-3-rongqianfeng@vivo.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Change the 'ret' variable in ad5360_update_ctrl() from unsigned int to
int, as it needs to store either negative error codes or zero returned
by ad5360_write_unlocked().
Fixes: a3e2940c24 ("staging:iio:dac: Add AD5360 driver")
Signed-off-by: Qianfeng Rong <rongqianfeng@vivo.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: https://patch.msgid.link/20250901135726.17601-2-rongqianfeng@vivo.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The clk div bits (2 bits wide) do not start in bit 16 but in bit 15. Fix it
accordingly.
Fixes: e31166f0fd ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers")
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Link: https://patch.msgid.link/20250829-adf4350-fix-v2-2-0bf543ba797d@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
The ADF4350/1 features a programmable dual-modulus prescaler of 4/5 or 8/9.
When set to 4/5, the maximum RF frequency allowed is 3 GHz.
Therefore, when operating the ADF4351 above 3 GHz, this must be set to 8/9.
In this context not the RF output frequency is meant
- it's the VCO frequency.
Therefore move the prescaler selection after we derived the VCO frequency
from the desired RF output frequency.
This BUG may have caused PLL lock instabilities when operating the VCO at
the very high range close to 4.4 GHz.
Fixes: e31166f0fd ("iio: frequency: New driver for Analog Devices ADF4350/ADF4351 Wideband Synthesizers")
Signed-off-by: Michael Hennerich <michael.hennerich@analog.com>
Signed-off-by: Nuno Sá <nuno.sa@analog.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://patch.msgid.link/20250829-adf4350-fix-v2-1-0bf543ba797d@analog.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
A small change in peci-npcm driver that removes unneeded 'fast_io'
parameter in regmap_config picked up as a part of wider refactoring.
-----BEGIN PGP SIGNATURE-----
iQJOBAABCAA4FiEEVeIYQcCloMPRsCC93RgStozwYHYFAmiwy/0aHGl3b25hLndp
bmlhcnNrYUBpbnRlbC5jb20ACgkQ3RgStozwYHZMYRAAjHQ2TqoqWQHdlTPoZ9DT
93Dr42eJJ9+7ClA4Lkt4+EfecofnbEWEVhFRZJOssf0jOqlWtywVTMukBg0sDPwY
xVdULfQGG5A1euK9N6bG7zCpTQzN2CorJR25om0lueGiVYo/7Z0FokYU933C9j5z
vmO8u4Lblmev5bue9UYY03/43zUek/eg8/CMZFORnm29o61BHEUjOHgyJUC4SW0x
7fCReYzJBWxomI7UobafvXhgZN51NlExm4iun4wXn7ikVk2g9uDdyiU0iyvpn8dT
Dybafs9oKD0T9Ri5frXSShUCR958wU5RuX4Ctk9XPU1VcQ5RH+hJWNqvpfADCrID
N4pK/RHbTofAC76tGB9OYKzQkgR41T9+Rmi7b6nMi/xZtZlByILAN8WbI2DwRZ2m
TxTPQ+v+RwbYbiXdPp5fMdlwsxjzFjOOqMQcqWbniApRbbugF0O6H3WRHPowS9Lk
p6jo+jLdW8mUrtuqjzkt1loOMhiObcN7YyXoigrOOWj49LNo3SRM2s6pvHlDA4eP
Jhsjs6ss6ml+uGFNaXVtc0JOunCaWhjI+VGuw/7IYmiQ3SSGgQqNER7oiRw+UhsM
mo2q32lr8ImroAkCVCJ3hGIt3T0fDoFfT18ILan2cGXFEpUq6j7v89qbltsL8ybV
nOYIwwPmNA+kDHpHHtawrek=
=rYWp
-----END PGP SIGNATURE-----
Merge tag 'peci-next-6.18-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/iwi/linux into char-misc-next
Iwona writes:
Update peci-next for v6.18-rc1
A small change in peci-npcm driver that removes unneeded 'fast_io'
parameter in regmap_config picked up as a part of wider refactoring.
* tag 'peci-next-6.18-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/iwi/linux:
peci: remove unneeded 'fast_io' parameter in regmap_config
When using MMIO with regmap, fast_io is implied. No need to set it
again.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Link: https://lore.kernel.org/r/20250813161517.4746-12-wsa+renesas@sang-engineering.com
Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com>
