Using Linux code style for struct gpib_board.
Adhering to Linux code style.
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Acked-By: Dave Penkler <dpenkler@gmail.com>
Link: https://lore.kernel.org/r/20250319215924.19387-3-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Using Linux code style for gpib_board struct in .h to allow drivers to migrate.
Adhering to Linux code style.
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Acked-By: Dave Penkler <dpenkler@gmail.com>
Link: https://lore.kernel.org/r/20250319215924.19387-2-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adhere to Linux kernel coding style and remove duplicate enums.
Reported by checkpatch
CHECK: Avoid CamelCase
Signed-off-by: Michael Rubin <matchstick@neverthere.org>
Acked-By: Dave Penkler <dpenkler@gmail.com>
Link: https://lore.kernel.org/r/20250319211827.9854-2-matchstick@neverthere.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the agilent usb dongle is disconnected subsequent calls to the
driver cause a NULL dereference Oops as the bus_interface
is set to NULL on disconnect.
This problem was introduced by setting usb_dev from the bus_interface
for dev_xxx messages.
Previously bus_interface was checked for NULL only in the functions
directly calling usb_fill_bulk_urb or usb_control_msg.
Check for valid bus_interface on all interface entry points
and return -ENODEV if it is NULL.
Fixes: fbae7090f3 ("staging: gpib: Update messaging and usb_device refs in agilent_usb")
Cc: stable <stable@kernel.org>
Signed-off-by: Dave Penkler <dpenkler@gmail.com>
Link: https://lore.kernel.org/r/20250222204515.5104-1-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
If the usb dongle is disconnected subsequent calls to the
driver cause a NULL dereference Oops as the bus_interface
is set to NULL on disconnect.
This problem was introduced by setting usb_dev from the bus_interface
for dev_xxx messages.
Previously bus_interface was checked for NULL only in the the functions
directly calling usb_fill_bulk_urb or usb_control_msg.
Check for valid bus_interface on all interface entry points
and return -ENODEV if it is NULL.
Fixes: 4934b98bb2 ("staging: gpib: Update messaging and usb_device refs in ni_usb")
Cc: stable <stable@kernel.org>
Signed-off-by: Dave Penkler <dpenkler@gmail.com>
Link: https://lore.kernel.org/r/20250222165817.12856-1-dpenkler@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CoreSight self-hosted tracing driver subsystem update for Linux v6.15.
The update includes:
- CoreSight trace capture for Panic/Watchdog timeouts
- Fixes to ETM4x driver to synchronize register reads as required by the TRM
- Support for Qualcomm CoreSight TMC Control Unit driver
- Conversion of device locks to raw_spinlock for components that are used
by the Perf mode.
- Miscellaneous fixes for the subsystem
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuFy0byloRoXZHaWBxcXRZPKyBqEFAmfX/2cACgkQxcXRZPKy
BqELPRAAr13epBAdkcWFlCZ5fCu0Uun5NsYwXXLTNK+FQFFikJ+3dEvca3XF9A8F
DCmOowgxAf70WHzrgyPY4bc3ouAimofYG2VUlF0kPDh2QL8elvjGm1kD18d7Liz3
8ZAontYErHl4AVywzS8HhPQD2hvLgZxbDEQ5zBjMBcsu8/DLf6zWq1je1jFHqAIv
kgqNVwzeS9BOgvVAJkj5Q8T0NN5nIzQgi3HYTlcakDWR/fp+UKMKU+RkVvkk19hm
qeuKUSNVUSmFpu7ZoYzPn6Yabl9uEGHrDsapWHFQWCXfOGbz2DKMmAyULwjTf+at
tOBGcbEz/1O/yBQccWFXrhDX1gYLnn2u38vZAXB3AvVAp5sq6CoYq5Izcc08eHrj
1P2IcqLIB7j3elgUrx6tkEVNou+nfL6Q02vTXwKe5RFRMNzorK8wK9yuggmjxVwi
gdLi4XayKKMJKFhVpHZS0sYvBfYfh9xY3zxC1IZ6te2D8RlXKfeV8tuITN3ftolf
adipGZLI99JQsHw+UVfd0t28XEcOKIDEl8iAmz978SFtl+dcDSqSpLD+DiFDdOC3
/a5aGbACHpePA6CkgP7Gcb0pvYMV5Ja9URNkf2sidOIKOkylOElXz+aBDFF+BRCQ
MuApJH5xFWGSWu+tAcap+XjssoZR5/wv9ODxZkqDwT8IIxtLsy8=
=sX5/
-----END PGP SIGNATURE-----
Merge tag 'coresight-next-v6.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux into char-misc-next
Suzuki writes:
coresight: updates for Linux v6.15
CoreSight self-hosted tracing driver subsystem update for Linux v6.15.
The update includes:
- CoreSight trace capture for Panic/Watchdog timeouts
- Fixes to ETM4x driver to synchronize register reads as required by the TRM
- Support for Qualcomm CoreSight TMC Control Unit driver
- Conversion of device locks to raw_spinlock for components that are used
by the Perf mode.
- Miscellaneous fixes for the subsystem
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
* tag 'coresight-next-v6.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/coresight/linux: (41 commits)
Coresight: Fix a NULL vs IS_ERR() bug in probe
coresight: configfs: Constify struct config_item_type
coresight: docs: Remove target sink from examples
coresight/ultrasoc: change smb_drv_data spinlock's type to raw_spinlock_t
coresight-tmc: change tmc_drvdata spinlock's type to raw_spinlock_t
coresight-replicator: change replicator_drvdata spinlock's type to raw_spinlock_t
coresight-funnel: change funnel_drvdata spinlock's type to raw_spinlock_t
coresight-etb10: change etb_drvdata spinlock's type to raw_spinlock_t
coresight-cti: change cti_drvdata spinlock's type to raw_spinlock_t
coresight: change coresight_trace_id_map's lock type to raw_spinlock_t
coresight-etm4x: change etmv4_drvdata spinlock type to raw_spinlock_t
coresight: change coresight_device lock type to raw_spinlock_t
coresight: add verification process for coresight_etm_get_trace_id
Coresight: Add Coresight TMC Control Unit driver
dt-bindings: arm: Add Coresight TMC Control Unit hardware
Coresight: Change functions to accept the coresight_path
Coresight: Change to read the trace ID from coresight_path
Coresight: Allocate trace ID after building the path
Coresight: Introduce a new struct coresight_path
Coresight: Use coresight_etm_get_trace_id() in traceid_show()
...
The TI sn65dsi86 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC.
This bridge driver uses the atomic hooks already, but dereferences the
drm_encoder->crtc pointer in functions that don't have access to it.
Let's rework the driver to pass the state where needed, and remove the
need for the drm_encoder->crtc dereference.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-16-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The tc358768 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC.
Let's convert this bridge driver to atomic so we can get rid of the
drm_encoder->crtc dereference.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-15-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The tc358768 bridge driver, if enabling it fails, tries to disable it.
This is pretty uncommon in bridge drivers, and also stands in the way
for further reworks.
Worse, since pre_enable and enable aren't expected to fail, disable and
post_disable might be called twice: once to handle the failure, and once
to actually disable the bridge.
Since post_disable uses regulators and clocks, this would lead to enable
count imbalances.
In order to prevent that imbalance, and to allow further reworks, let's
drop the calls to disable and post_disable, but keep the warning to let
users know about what's going on.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-14-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The tc358775 driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC.
Let's convert this bridge driver to atomic so we can get rid of the
drm_encoder->crtc dereference.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-13-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The Cadence DSI driver follows the drm_encoder->crtc pointer that is
deprecated and shouldn't be used by atomic drivers.
Fortunately, the atomic hooks provide the drm_atomic_state and we can
access our current CRTC from that, going from the bridge to its encoder,
to its connector, and to its CRTC.
Let's convert this bridge driver to atomic so we can get rid of the
drm_encoder->crtc dereference.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-12-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Now that we have a helper for bridge drivers to call to reset the output
pipeline, let's use it.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Tested-by: Herve Codina <herve.codina@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-10-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Let's provide an helper to make it easier for bridge drivers to
power-cycle their bridge.
In order to avoid a circular dependency between that new helper and
drm_atomic_helper_reset_crtc(), this new helper will be in a
drm_bridge_helper.c file to follow the pattern we have for other
objects.
Reviewed-by: Herve Codina <herve.codina@bootlin.com>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Tested-by: Herve Codina <herve.codina@bootlin.com>
Co-developed-by: Simona Vetter <simona.vetter@intel.com>
Signed-off-by: Simona Vetter <simona.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-8-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
We don't have a set of kunit tests for the functions under drm_atomic.h.
Let's use the introduction of drm_atomic_get_connector_for_encoder() to
create some tests for it and thus create that set.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-7-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
With the bridges switching over to drm_bridge_connector, the direct
association between a bridge driver and its connector was lost.
This is mitigated for atomic bridge drivers by the fact you can access
the encoder, and then call drm_atomic_get_old_connector_for_encoder() or
drm_atomic_get_new_connector_for_encoder() with drm_atomic_state.
This was also made easier by providing drm_atomic_state directly to all
atomic hooks bridges can implement.
However, bridge drivers don't have a way to access drm_atomic_state
outside of the modeset path, like from the hotplug interrupt path or any
interrupt handler.
Let's introduce a function to retrieve the connector currently assigned
to an encoder, without using drm_atomic_state, to make these drivers'
life easier.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Tested-by: Herve Codina <herve.codina@bootlin.com>
Co-developed-by: Simona Vetter <simona.vetter@intel.com>
Signed-off-by: Simona Vetter <simona.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-4-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The drm_bridge structure contains an encoder pointer that is widely used
by bridge drivers. This pattern is largely documented as deprecated in
other KMS entities for atomic drivers.
However, one of the main use of that pointer is done in attach to just
call drm_bridge_attach on the next bridge to add it to the bridge list.
While this dereferences the bridge->encoder pointer, it's effectively
the same encoder the bridge was being attached to.
We can make it more explicit by adding the encoder the bridge is
attached to to the list of attach parameters. This also removes the need
to dereference bridge->encoder in most drivers.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20250313-bridge-connector-v6-1-511c54a604fb@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
This includes following USB4/Thunderbolt changes for the v6.15 merge
window:
- Move retimer scanning to happen bit later to work better with
Pluggable USB4 devices.
- No need to add non-active NVM for retimers if NVM upgrade is not
supported.
- Cleanup for tb_tunnel_alloc_usb3().
- MAINTAINERS update.
All these have been in linux-next with no reported issues.
-----BEGIN PGP SIGNATURE-----
iQJUBAABCgA+FiEEVTdhRGBbNzLrSUBaAP2fSd+ZWKAFAmfb+XggHG1pa2Eud2Vz
dGVyYmVyZ0BsaW51eC5pbnRlbC5jb20ACgkQAP2fSd+ZWKBwmg//XsCCVQISQsnr
X30Gg/uYQ5aD8al1vNjZbA+uj6UQBvPEG9LHXsyfUaHbTeKMnrTPYXmIxQM815ws
JIZwCBo3eK+OF+hjik8d/QWcccBpYkgdyQJGasHWDVfeL/0UugR2PQwLPNfpD7a9
+OySbFADDauqTj3yLZv6Tbbh2GIqiUsJ2ItaQCye2ASQ/v4u99cKQ6XJ7nQiliyp
BdcVRp/cgtHPuqIChLxBSBvL2wG4jXsYjOSZ35oeDHW1FVpbSOAqv/lZXtL8Si84
PmGBI07kTnv29NOnBs89pnn2dBae0hABazjNtyf5kLhEqtIJ3zOFeOHTdMB0hGzj
WWjZQg+mWcu50S4cg/Tchyms+uIgR8DcBXhSapoOkyLr1U7hn0KxK+kvwOdVA+Xv
qae62JGOd1857UfEtKD5A+z780FoetvxDMf7yWHK/EHfIp9QorQNSqSYwnn8IgMr
LeSTCv2Zybj6wF/qqf1pm9yfGbrC4yN2fdVl6NTUFNFuXX/vBSHVw9Q5tLhid89h
mfy9hszogrQEl96jWJaAxZjW2q3gB2/V3kr/CCP/d5zhLLEE0/LhiuL1JMo2MUBI
D0xC//WfVrIs/lwWIWBA0gHpuM3j1IdlUYX8LirwJy7FprqncdZ0csLr4Zk0yEGa
608edZ0HSaD2o9VYjUsiraaAJpoc8Zs=
=vyZE
-----END PGP SIGNATURE-----
Merge tag 'thunderbolt-for-v6.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Changes for v6.15 merge window
This includes following USB4/Thunderbolt changes for the v6.15 merge
window:
- Move retimer scanning to happen bit later to work better with
Pluggable USB4 devices.
- No need to add non-active NVM for retimers if NVM upgrade is not
supported.
- Cleanup for tb_tunnel_alloc_usb3().
- MAINTAINERS update.
All these have been in linux-next with no reported issues.
* tag 'thunderbolt-for-v6.15-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Do not add non-active NVM if NVM upgrade is disabled for retimer
thunderbolt: Scan retimers after device router has been enumerated
thunderbolt: Make tb_tunnel_alloc_usb3() error paths consistent with the rest
MAINTAINERS: Use my kernel.org address for USB4/Thunderbolt work
irq allocated with devm_request_irq() will be freed in devm_irq_release(),
using free_irq() in ->remove() will causes a dangling pointer, and a
subsequent double free. So remove the free_irq() in the error path and
remove path.
Fixes: 969864efae ("i2c: amd-mp2: use msix/msi if the hardware supports")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Acked-by: Shyam Sundar S K <Shyam-sundar.S-k@amd.com>
Link: https://lore.kernel.org/r/20221103121146.99836-1-yangyingliang@huawei.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
There is an issue in the kernel:
In tmpfs, when using the "ls" command to list the contents
of a directory with a large number of files, glibc performs
the getdents call in multiple rounds. If a concurrent unlink
occurs between these getdents calls, it may lead to duplicate
directory entries in the ls output. One possible reproduction
scenario is as follows:
Create 1026 files and execute ls and rm concurrently:
for i in {1..1026}; do
echo "This is file $i" > /tmp/dir/file$i
done
ls /tmp/dir rm /tmp/dir/file4
->getdents(file1026-file5)
->unlink(file4)
->getdents(file5,file3,file2,file1)
It is expected that the second getdents call to return file3
through file1, but instead it returns an extra file5.
The root cause of this problem is in the offset_dir_lookup
function. It uses mas_find to determine the starting position
for the current getdents call. Since mas_find locates the first
position that is greater than or equal to mas->index, when file4
is deleted, it ends up returning file5.
It can be fixed by replacing mas_find with mas_find_rev, which
finds the first position that is less than or equal to mas->index.
Fixes: b9b588f22a ("libfs: Use d_children list to iterate simple_offset directories")
Signed-off-by: Yongjian Sun <sunyongjian1@huawei.com>
Link: https://lore.kernel.org/r/20250320034417.555810-1-sunyongjian@huaweicloud.com
Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
The WM8904 codec supports both ADC and DMIC inputs.
Get input pin functionality from the platform data and add the necessary
controls depending on the possible additional routing.
The ADC and DMIC share the IN1L/DMICDAT1 and IN1R/DMICDAT2 pins.
This leads to a few scenarios requiring different DAPM routing:
- When both are connected to an analog input, only the ADC is used.
- When one line is a DMIC and the other an analog input, the DMIC source
is set from the platform data and a mux is added to select whether to
use the ADC or DMIC.
- When both are connected to a DMIC, another mux is added to this to
select the DMIC source. Note that we still need to be able to select
the ADC system for use with the IN2L, IN2R, IN3L and IN3R pins.
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250319142059.46692-6-francesco@dolcini.it
Signed-off-by: Mark Brown <broonie@kernel.org>
Read in optional codec-specific properties from the device tree.
The platform_data structure is not populated when using device trees.
This change parses optional dts properties to populate it.
- wlf,in1l-as-dmicdat1
- wlf,in1r-as-dmicdat2
- wlf,gpio-cfg
- wlf,micbias-cfg
- wlf,drc-cfg-regs
- wlf,drc-cfg-names
- wlf,retune-mobile-cfg-regs
- wlf,retune-mobile-cfg-names
- wlf,retune-mobile-cfg-hz
Datasheet: https://statics.cirrus.com/pubs/proDatasheet/WM8904_Rev4.1.pdf
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250319142059.46692-5-francesco@dolcini.it
Signed-off-by: Mark Brown <broonie@kernel.org>
Add two properties to select the IN1L/DMICDAT1 and IN2R/DMICDAT2
functionality:
- wlf,in1l-as-dmicdat1
- wlf,in1r-as-dmicdat2
Add a property to describe the GPIO configuration registers, that can be
used to set the four multifunction pins:
- wlf,gpio-cfg
Add a property to describe the mic bias control registers:
- wlf,micbias-cfg
Add two properties to describe the Dynamic Range Controller (DRC),
allowing multiple named configurations where each config sets the 4 DRC
registers (R40-R43):
- wlf,drc-cfg-regs
- wlf,drc-cfg-names
Add three properties to describe the equalizer (ReTune Mobile), allowing
multiple named configurations (associated with a samplerate) that set
the 24 (R134-R157) EQ registers:
- wlf,retune-mobile-cfg-regs
- wlf,retune-mobile-cfg-hz
- wlf,retune-mobile-cfg-rates
The set of names and configurations for DRC and ReTune Mobile are
specified by system integrators. The names are exposed directly to
userspace as options that can be selected at runtime.
Adding the DRC and ReTune Mobile data to the DT eases the transition
from pdata, which has handled them this way for over a decade. The
parameters filled in here are almost certainly specific tuning for the
hardware so it makes sense to ship them with the hardware description.
Datasheet: https://statics.cirrus.com/pubs/proDatasheet/WM8904_Rev4.1.pdf
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250319142059.46692-4-francesco@dolcini.it
Signed-off-by: Mark Brown <broonie@kernel.org>
When updating the GPIO registers, do nothing for all fields of gpio_cfg
that are "0xFFFF".
This "do nothing" flag used to be 0 to easily check whether the gpio_cfg
field was actually set inside pdata or left empty (default).
However, 0 is a valid configuration for these registers, while 0xFFFF is
not.
With this change, users can explicitly set them to 0.
Not setting gpio_cfg in the platform data will now lead to setting all
GPIO registers to 0 instead of leaving them unset.
No one is using this platform data with this codec.
The change gets the driver ready to properly set gpio_cfg from the DT.
Datasheet: https://statics.cirrus.com/pubs/proDatasheet/WM8904_Rev4.1.pdf
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250319142059.46692-3-francesco@dolcini.it
Signed-off-by: Mark Brown <broonie@kernel.org>
There is an of_property_read_u32_index and of_property_read_u64_index.
This patch adds a similar helper for u16.
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20250319142059.46692-2-francesco@dolcini.it
Signed-off-by: Mark Brown <broonie@kernel.org>
Many spi-mem controller drivers have a very similar debug log at the
beginning of their ->exec_op() callback implementation. This debug log is
effectively useful, so let's create one that is complete and concise
enough, so developers no longer need to write their own. The verbosity
being high, VERBOSE_DEBUG will be required in this case.
Remove the debug log from individual drivers and propose a common one.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://patch.msgid.link/20250320115644.2231240-1-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
There are 5 mandatory peripheral properties. They are described in a
separate binding but not explicitly required. Make sure they are
correctly marked required and update the example to reflect this.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20250319094651.1290509-4-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The initial SPI controller IP from Cadence has always been implemented
into controllers from various hardware manufacturers and because of
that, it has always been (rightfully) doubled with a more specific
compatible. There are likely no reasons to keep this compatible
legitimate, alone. Make sure people do not get mislead by officially
deprecating this compatible.
While at deprecating, let's update the examples to avoid documenting
deprecated properties.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20250319094651.1290509-3-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Despite being very common in commit logs, SPI NOR controllers simply do
not exist. At least, they are not as specific as the name implies. There
are SPI memory controllers which are indeed "specialized" and optimized
for handling "memories", but most of them are just generic and accept
almost any kind of opcode, address, dummy and data cycles, making them
as suitable for NANDs than NORs.
Furthermore, this controller supports any kind of bus, from single to
octal NAND, so make it clear.
Also add a comment to mention that the initial compatible naming is too
specific (but obviously kept for backward compatibility reasons).
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20250319094651.1290509-2-miquel.raynal@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As both locks are highly contended during significant inode churn,
holding the inode hash lock while waiting for the sb list lock
exacerbates the problem.
Why moving it out is safe: the inode at hand still has I_NEW set and
anyone who finds it through legitimate means waits for the bit to clear,
by which time inode_sb_list_add() is guaranteed to have finished.
This significantly drops hash lock contention for me when stating 20
separate trees in parallel, each with 1000 directories * 1000 files.
However, no speed up was observed as contention increased on the other
locks, notably dentry LRU.
Even so, removal of the lock ordering will help making this faster
later.
Signed-off-by: Mateusz Guzik <mjguzik@gmail.com>
Link: https://lore.kernel.org/r/20250320004643.1903287-1-mjguzik@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
The /sys/block/<disk>/integrity fields are historically set
if T10 protection Information is enabled.
It is not set if some upper layer uses integrity metadata.
Document it.
Signed-off-by: Milan Broz <gmazyland@gmail.com>
Co-developed-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20250318154447.370786-1-gmazyland@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
In some cases, we need to call test-only code from outside the test
case, for example, to mock a function or a module.
In order to check whether we are in a test or not, we need to test if
`CONFIG_KUNIT` is set.
Unfortunately, we cannot rely only on this condition because:
- a test could be running in another thread,
- some distros compile KUnit in production kernels, so checking at runtime
that `current->kunit_test != NULL` is required.
Forturately, KUnit provides an optimised check in
`kunit_get_current_test()`, which checks CONFIG_KUNIT, a global static
key, and then the current thread's running KUnit test.
Add a safe wrapper function around this to know whether or not we are in
a KUnit test and examples showing how to mock a function and a module.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Co-developed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Co-developed-by: David Gow <davidgow@google.com>
Signed-off-by: David Gow <davidgow@google.com>
Link: https://lore.kernel.org/r/20250307090103.918788-4-davidgow@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add a new procedural macro (`#[kunit_tests(kunit_test_suit_name)]`) to
run KUnit tests using a user-space like syntax.
The macro, that should be used on modules, transforms every `#[test]`
in a `kunit_case!` and adds a `kunit_unsafe_test_suite!` registering
all of them.
The only difference with user-space tests is that instead of using
`#[cfg(test)]`, `#[kunit_tests(kunit_test_suit_name)]` is used.
Note that `#[cfg(CONFIG_KUNIT)]` is added so the test module is not
compiled when `CONFIG_KUNIT` is set to `n`.
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Co-developed-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Co-developed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Tamir Duberstein <tamird@gmail.com>
Signed-off-by: David Gow <davidgow@google.com>
Link: https://lore.kernel.org/r/20250307090103.918788-3-davidgow@google.com
[ Removed spurious (in rendered form) newline in docs. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Add a couple of Rust const functions and macros to allow to develop
KUnit tests without relying on generated C code:
- The `kunit_unsafe_test_suite!` Rust macro is similar to the
`kunit_test_suite` C macro. It requires a NULL-terminated array of
test cases (see below).
- The `kunit_case` Rust function is similar to the `KUNIT_CASE` C macro.
It generates as case from the name and function.
- The `kunit_case_null` Rust function generates a NULL test case, which
is to be used as delimiter in `kunit_test_suite!`.
While these functions and macros can be used on their own, a future
patch will introduce another macro to create KUnit tests using a
user-space like syntax.
Signed-off-by: José Expósito <jose.exposito89@gmail.com>
Co-developed-by: Matt Gilbride <mattgilbride@google.com>
Signed-off-by: Matt Gilbride <mattgilbride@google.com>
Co-developed-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Co-developed-by: David Gow <davidgow@google.com>
Signed-off-by: David Gow <davidgow@google.com>
Link: https://lore.kernel.org/r/20250307090103.918788-2-davidgow@google.com
[ Applied Markdown in comment. - Miguel ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
'event_trigger_ops mwifiex_if_ops' are not modified in these drivers.
Constifying these structures moves some data to a read-only section, so
increase overall security, especially when the structure holds some
function pointers.
On a x86_64, with allmodconfig, as an example:
Before:
======
text data bss dec hex filename
31368 9024 6200 46592 b600 kernel/trace/trace_events_trigger.o
After:
=====
text data bss dec hex filename
31752 8608 6200 46560 b5e0 kernel/trace/trace_events_trigger.o
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Link: https://lore.kernel.org/66e8f990e649678e4be37d4d1a19158ca0dea2f4.1741521295.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
The conversion to EXPORT_SIMPLE_DEV_PM_OPS() also replaced the pm ops
assignment with pm_ptr() macro, but this made difference from the
original code; it had conditional with ifdef CONFIG_PM_SLEEP, while
we have now with CONFIG_PM, instead. This seems causing build errors
with randomconfig.
For fixing the inconsistency, replace pm_ptr() with pm_sleep_ptr().
Fixes: 5ea0a2206b ("ALSA: oxygen: Convert to EXPORT_SIMPLE_DEV_PM_OPS()")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202503201853.7kB0BPRw-lkp@intel.com/
Link: https://patch.msgid.link/20250320105721.10789-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Justin Iurman says:
====================
net: fix lwtunnel reentry loops
When the destination is the same after the transformation, we enter a
lwtunnel loop. This is true for most of lwt users: ioam6, rpl, seg6,
seg6_local, ila_lwt, and lwt_bpf. It can happen in their input() and
output() handlers respectively, where either dst_input() or dst_output()
is called at the end. It can also happen in xmit() handlers.
Here is an example for rpl_input():
dump_stack_lvl+0x60/0x80
rpl_input+0x9d/0x320
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
[...]
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
lwtunnel_input+0x64/0xa0
ip6_sublist_rcv_finish+0x85/0x90
ip6_sublist_rcv+0x236/0x2f0
... until rpl_do_srh() fails, which means skb_cow_head() failed.
This series provides a fix at the core level of lwtunnel to catch such
loops when they're not caught by the respective lwtunnel users, and
handle the loop case in ioam6 which is one of the users. This series
also comes with a new selftest to detect some dst cache reference loops
in lwtunnel users.
====================
Link: https://patch.msgid.link/20250314120048.12569-1-justin.iurman@uliege.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
As recently specified by commit 0ea09cbf83 ("docs: netdev: add a note
on selftest posting") in net-next, the selftest is therefore shipped in
this series. However, this selftest does not really test this series. It
needs this series to avoid crashing the kernel. What it really tests,
thanks to kmemleak, is what was fixed by the following commits:
- commit c71a192976 ("net: ipv6: fix dst refleaks in rpl, seg6 and
ioam6 lwtunnels")
- commit 92191dd107 ("net: ipv6: fix dst ref loops in rpl, seg6 and
ioam6 lwtunnels")
- commit c64a0727f9 ("net: ipv6: fix dst ref loop on input in seg6
lwt")
- commit 13e55fbaec ("net: ipv6: fix dst ref loop on input in rpl
lwt")
- commit 0e7633d7b9 ("net: ipv6: fix dst ref loop in ila lwtunnel")
- commit 5da15a9c11 ("net: ipv6: fix missing dst ref drop in ila
lwtunnel")
Signed-off-by: Justin Iurman <justin.iurman@uliege.be>
Link: https://patch.msgid.link/20250314120048.12569-4-justin.iurman@uliege.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Fix the lwtunnel_output() reentry loop in ioam6_iptunnel when the
destination is the same after transformation. Note that a check on the
destination address was already performed, but it was not enough. This
is the example of a lwtunnel user taking care of loops without relying
only on the last resort detection offered by lwtunnel.
Fixes: 8cb3bf8bff ("ipv6: ioam: Add support for the ip6ip6 encapsulation")
Signed-off-by: Justin Iurman <justin.iurman@uliege.be>
Link: https://patch.msgid.link/20250314120048.12569-3-justin.iurman@uliege.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
This patch acts as a parachute, catch all solution, by detecting
recursion loops in lwtunnel users and taking care of them (e.g., a loop
between routes, a loop within the same route, etc). In general, such
loops are the consequence of pathological configurations. Each lwtunnel
user is still free to catch such loops early and do whatever they want
with them. It will be the case in a separate patch for, e.g., seg6 and
seg6_local, in order to provide drop reasons and update statistics.
Another example of a lwtunnel user taking care of loops is ioam6, which
has valid use cases that include loops (e.g., inline mode), and which is
addressed by the next patch in this series. Overall, this patch acts as
a last resort to catch loops and drop packets, since we don't want to
leak something unintentionally because of a pathological configuration
in lwtunnels.
The solution in this patch reuses dev_xmit_recursion(),
dev_xmit_recursion_inc(), and dev_xmit_recursion_dec(), which seems fine
considering the context.
Closes: https://lore.kernel.org/netdev/2bc9e2079e864a9290561894d2a602d6@akamai.com/
Closes: https://lore.kernel.org/netdev/Z7NKYMY7fJT5cYWu@shredder/
Fixes: ffce41962e ("lwtunnel: support dst output redirect function")
Fixes: 2536862311 ("lwt: Add support to redirect dst.input")
Fixes: 14972cbd34 ("net: lwtunnel: Handle fragmentation")
Signed-off-by: Justin Iurman <justin.iurman@uliege.be>
Link: https://patch.msgid.link/20250314120048.12569-2-justin.iurman@uliege.be
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Currently the API emac_update_hardware_stats() reads different ICSSG
stats without any lock protection.
This API gets called by .ndo_get_stats64() which is only under RCU
protection and nothing else. Add lock to this API so that the reading of
statistics happens during lock.
Fixes: c1e10d5dc7 ("net: ti: icssg-prueth: Add ICSSG Stats")
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20250314102721.1394366-1-danishanwar@ti.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
The ->send() operation frees skb so save the length before calling
->send() to avoid a use after free.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/c751531d-4af4-42fe-affe-6104b34b791d@stanley.mountain
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
