For SOCK_STREAM sockets, if user buffer size (len) is less
than skb size (skb->len), the remaining data from skb
will be lost after calling kfree_skb().
To fix this, move the statement for partial reading
above skb deletion.
Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org)
Fixes: 30a584d944 ("[LLX]: SOCK_DGRAM interface fixes")
Cc: stable@vger.kernel.org
Signed-off-by: Ilia Gavrilov <Ilia.Gavrilov@infotecs.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
- update MAINTAINERS entry for ovpn
- extend selftest with more cases
- avoid crash in selftest in case of getaddrinfo() failure
- fix ndo_start_xmit return value on error
- set ignore_df flag for IPv6 packets
- drop useless reg_state check in keepalive worker
- retain skb's dst when entering xmit function
- fix check on skb_to_sgvec_nomark() return value
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEmavcbPjUEuTeX8D8C3DlOqA41YcFAmgly3gACgkQC3DlOqA4
1Yce5QgAq0UK170Dk8yrq97PevhAc35OekOvZ2kC7rS/Mp7E7de6puVR0Xawh9rU
xLJC9ldAXCFS8jKzW/9yd6hJqe03KXVULtHD0tdOCoxkp5jfQCx+RWG9BaHljs9T
NWIqKP93Fe83qqWgnSjtG1lTPPNbx++JD61xvnl/eMEh/xU0kVeuhxuqhdyoj1NT
8IzSSFIJBnh4LtgCzGxhNkA8Ar+SShKdFkc+4nL3AoD9DTRx5NiFDfG6OKWTK75h
GA0VB3Ip7Jt8PTFBdxXYcEEe7sYXGtjkiNUHYa+sv4VdU83BTfYgyBi+6PeIADjq
N9BI418qfSkt2VBV1cYHZwe+O89fvw==
=nC7o
-----END PGP SIGNATURE-----
Merge tag 'ovpn-net-next-20250515' of https://github.com/OpenVPN/ovpn-net-next
Antonio Quartulli says:
====================
ovpn: pull request for net-next: ovpn 2025-05-15
this is a new version of the previous pull request.
These time I have removed the fixes that we are still discussing,
so that we don't hold the entire series back.
There is a new fix though: it's about properly checking the return value
of skb_to_sgvec_nomark(). I spotted the issue while testing pings larger
than the iface's MTU on a TCP VPN connection.
I have added various Closes and Link tags where applicable, so
that we have references to GitHub tickets and other public discussions.
Since I have resent the PR, I have also added Andrew's Reviewed-by to
the first patch.
Please pull or let me know if something should be changed!
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Patchset highlights:
- update MAINTAINERS entry for ovpn
- extend selftest with more cases
- avoid crash in selftest in case of getaddrinfo() failure
- fix ndo_start_xmit return value on error
- set ignore_df flag for IPv6 packets
- drop useless reg_state check in keepalive worker
- retain skb's dst when entering xmit function
- fix check on skb_to_sgvec_nomark() return value
Add compatibles for sound card on Qualcomm QCS9100 and
QCS9075 boards.
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Link: https://patch.msgid.link/20250519083244.4070689-3-mohammad.rafi.shaik@oss.qualcomm.com
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Document the bindings for the Qualcomm QCS9100 and QCS9075 board
specific sound card.
The bindings are the same as for other newer Qualcomm ADSP sound cards,
thus keep them in existing qcom,sm8250.yaml file, even though Linux driver
is separate.
Signed-off-by: Mohammad Rafi Shaik <mohammad.rafi.shaik@oss.qualcomm.com>
Link: https://patch.msgid.link/20250519083244.4070689-2-mohammad.rafi.shaik@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
We don't (and can't) configure the hardware correctly if the number of
channels exceeds the weight of the TDM mask. Report that constraint in
startup of FE.
Fixes: 3df5d0d972 ("ASoC: apple: mca: Start new platform driver")
Signed-off-by: Martin Povišer <povik+lin@cutebit.org>
Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
Link: https://patch.msgid.link/20250518-mca-fixes-v1-1-ee1015a695f6@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The maximum DMA transfer size is limited by the maximum values that can
be written to the word count fields (WDLENx) in the Transmit and Control
Data Registers (SITDR2/SIRDR2). As all MSIOF variants support
transferring data of multiple (two or four) groups, the maximum size can
be doubled by using two groups instead of one, thus reducing setup
overhead for very large SPI transfers.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/bad522c76b8d225c195433977b22f95015cf2612.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
The MSIOF transmit FIFOs on R-Car V4H and V4M have 256 stages.
Add a new family-specific match entry to handle this.
Add quirk match entries for older R-Car Gen4 Socs (R-Car V3U and S4-8)
that have transmit FIFOs with only 64 stages, just like on R-Car Gen3.
Update the (unused) definition of SIFCTR_TFUA for consistency.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/69cb5fc48f034d37484fa127b9864a1971a83417.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
According to the R-Car Gen3 Hardware Manual Errata for Rev 0.55 of
September 28, 2017, the MSIOF receive FIFOs on R-Car Gen3 SoCs have room
for 256 words of 32 bits.
Note that this change has no actual impact on the behavior of the
driver, as SPI_CONTROLLER_MUST_TX is set, and transfer size is currenty
limited to the minimum of the transmit and receive FIFO sizes.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/6f74508ea4681aa0b7c6bf6810eab026725e75a3.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
According to Renesas Technical Updates TN-RCS-S068A/E, the MSIOF receive
FIFOs on R-Car Gen2 SoCs have room for 128 words of 32 bits.
Note that this change has no actual impact on the behavior of the
driver, as SPI_CONTROLLER_MUST_TX is set, and transfer size is currenty
limited to the minimum of the transmit and receive FIFO sizes.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/fd11933f932df81d84f417a21e2179bd4fdcfdc1.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
All MSIOF variants support transferring data of multiple (2 or 4)
groups. Add definitions for the register bits related to multiple
groups, and enhance sh_msiof_spi_set_mode_regs() to accept a second
group size.
For now the second group is unused.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/be75e20cfcd2a6c0d73ab09e0126f902911adc69.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
The Group Output Mask is not a single bit, but a bit field, containing
one bit for each of the four possible groups. Correct the definition.
Note that this change has no direct impact, as the driver only uses
the first group.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/ad268d67807cb7e544eddaf7a056793482a965d4.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
The maximum amount of data to transfer in a single DMA request is
calculated from the FIFO sizes (which is technically not 100% correct,
but a simplification, as it is limited by the maximum word count values
in the Transmit and Control Data Registers). However, in case there is
both data to transmit and to receive, the transmit limit is overwritten
by the receive limit.
Fix this by using the minimum applicable FIFO size instead. Move the
calculation outside the loop, so it is not repeated for each individual
DMA transfer.
As currently tx_fifo_size is always equal to rx_fifo_size, this bug had
no real impact.
Fixes: fe78d0b769 ("spi: sh-msiof: Fix FIFO size to 64 word from 256 word")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/d9961767a97758b2614f2ee8afe1bd56dc900a60.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
The Clock-Synchronized Serial Interfaces with FIFO (MSIOF) driver
matches against both SoC-specific and family-specific compatible values
to maintain backwards-compatibility with old DTBs predating the
introduction of the family-specific compatible values.
For RZ/G1, the SoC-specific compatible match entry can be removed from
the driver: their DT always had the family-specific compatible values,
and thus there was never a need to add the SoC-specific compatible
values to the driver.
For R-Car Gen2 and M3-W, the SoC-specific compatible match entries can
be removed, too, as there are a few points in time where DT
backwards-compatibility was broken for other reasons:
- Legacy DT clock support is no longer supported since commit
58256143cf ("clk: renesas: Remove R-Car Gen2 legacy DT clock
support") in v5.5, and the addition of "renesas,rcar-gen2-msiof" to
DTS in v4.11 predates the completion of the clock conversion in
v4.15,
- Legacy DT LVDS support is no longer supported since commit
841281fe52 ("drm: rcar-du: Drop LVDS device tree backward
compatibility") in v5.18, and the addition of
"renesas,rcar-gen3-msiof" in commit 8b51f97138 ("arm64: dts:
r8a7796: Use R-Car Gen 3 fallback binding for msiof nodes") in v4.11
predates the LVDS conversion in commit 58e8ed2ee9 ("arm64:
dts: renesas: Convert to new LVDS DT bindings") in v4.20.
For R-Car H3, the SoC-specific compatible match entry cannot be removed,
as its purpose is to handle an SoC-specific quirk.
Suggested-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://patch.msgid.link/d33393ac7536bc3f0f624b079f70d80dd19843db.1747401908.git.geert+renesas@glider.be
Signed-off-by: Mark Brown <broonie@kernel.org>
'struct spmi_voltage_range' are only modified at runtime to compile a
field, n_voltages, that could be computed at compile time.
So, simplify spmi_calculate_num_voltages() and compute n_voltages at
compile time within the SPMI_VOLTAGE_RANGE macro.
Constifying these structures moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
85437 26776 512 112725 1b855 drivers/regulator/qcom_spmi-regulator.o
After:
=====
text data bss dec hex filename
86857 24760 512 112129 1b601 drivers/regulator/qcom_spmi-regulator.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://patch.msgid.link/ef2a4b6df61e19470ddf6cbd1f3ca1ce88a3c1a0.1747570556.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Drop the I2C in one comment, for these registers are also used in SPI
driver; Move the macro definition of TASDEVICE_CMD_XXX from tas2781.h to
tas2781_fmwlib.c, because the macros are only referenced in only fwlib.
Signed-off-by: Shenghao Ding <shenghao-ding@ti.com>
Link: https://patch.msgid.link/20250518132451.707-1-shenghao-ding@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The architecture introduces a trap for TSB CSYNC that fits in
the same EC as LS64 and PSB CSYNC. Let's deal with it in a similar
way.
It's not that we expect this to be useful any time soon anyway.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Just like we allow sysreg ranges for Coarse Grained Trap descriptors,
allow them for Fine Grain Traps as well.
This comes with a warning that not all ranges are suitable for this
particular definition of ranges.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Just like the rest of the FGT registers, perform a switch of the
FGT2 equivalent. This avoids the host configuration leaking into
the guest...
Signed-off-by: Marc Zyngier <maz@kernel.org>
Similarly to the FEAT_FGT registers, pick the correct FEAT_FGT2
register when a sysreg trap indicates they could be responsible
for the exception.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Just like the FEAT_FGT registers, treat the FGT2 variant the same
way. THis is a large update, but a fairly mechanical one.
The config dependencies are extracted from the 2025-03 JSON drop.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
The FEAT_FGT2 registers are part of the VNCR page. Describe the
corresponding offsets and add them to the vcpu sysreg enumeration.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Similarly to other registers, describe which HCR_EL2 bit depends
on which feature, and use this to compute the RES0 status of these
bits.
An additional complexity stems from the status of some bits such
as E2H and RW, which do not had a RESx status, but still take
a fixed value due to implementation choices in KVM.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Similarly to other registers, describe which HCR_EL2 bit depends
on which feature, and use this to compute the RES0 status of these
bits.
Signed-off-by: Marc Zyngier <maz@kernel.org>
In order to be able to write more compact (and easier to read) code,
let kvm_has_feat() and co take variable arguments. This enables
constructs such as:
#define FEAT_SME ID_AA64PFR1_EL1, SME, IMP
if (kvm_has_feat(kvm, FEAT_SME))
[...]
which is admitedly more readable.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Another benefit of mapping bits to features is that it becomes trivial
to define which bits should be handled as RES0.
Let's apply this principle to the guest's view of the FGT registers.
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Update text binding to YAML.
Changes during conversion:
Add appropriate include statements for interrupts and clock-names
to resolve errors identified by `dt_binding_check` and `dtbs_check`.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20250507-mchp-sdhci-v1-2-ed29de05295a@gmail.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Use kmemdup_array() to avoid multiplication and possible overflows.
Signed-off-by: Zhang Enpei <zhang.enpei@zte.com.cn>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
The register EMP_AS_SDP_TL (MTL) was introduced for configuring the
double buffering point and transmission line for all
HDMI2.1 Extended Metadata Packets (VT-EMP for VRR, CVT-EMP for DSC etc).
This was also intended to be configured for DP to HDMI2.1 PCON to
support VRR.
From BMG and LNL+ onwards, this register was extended to Display Port
Adaptive Sync SDP to have a common register to configure double
buffering point and transmission line for both HDMI EMPs and DP VRR related
packets.
Currently, we do not support VRR for either native HDMI or via PCON.
However we need to configure this for DP SDP case. As per the spec,
program the register to set Vsync start as the double buffering point
for DP AS SDP.
v2:
-Make the helper more readable. (Jani)
-Add more information in commit message and comment.
Bspec:70984, 71197
Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Tested-by: Jouni Högander <jouni.hogander@intel.com>
Reviewed-by: Jouni Högander <jouni.hogander@intel.com>
Link: https://lore.kernel.org/r/20250505033911.393628-1-ankit.k.nautiyal@intel.com
When DP connected to a device with HDR capability,
the hdr structure was filled.Then connected to another
sink device without hdr capability, but the hdr info
still exist.
Fixes: e85959d6cb ("drm: Parse HDR metadata info from EDID")
Cc: <stable@vger.kernel.org> # v5.3+
Signed-off-by: "feijuan.li" <feijuan.li@samsung.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://lore.kernel.org/r/20250514063511.4151780-1-feijuan.li@samsung.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Remove all the code related to changing compression on the fly because
it's not safe and not maintainable.
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Add initial abstractions for the clk APIs. These provide the minimal
functionality needed for common use cases, making them straightforward
to introduce in the first iteration.
These will be used by Rust based cpufreq / OPP layers to begin with.
Tested-by: Daniel Almeida <daniel.almeida@collabora.com>
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Non-trivial C macros and inlined C functions cannot be used directly
in the Rust code and are used via functions ("helpers") that wrap
those so that they can be called from Rust.
In order to prepare for adding Rust abstractions for the clock APIs,
add clock helpers required by the Rust implementation.
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Update the MAINTAINERS file to include the Rust abstractions for cpumask
API.
Yury has indicated that he does not wish to maintain the Rust code but
would like to be listed as a reviewer.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Yury Norov <yury.norov@gmail.com>
Add initial Rust abstractions for struct cpumask, covering a subset of
its APIs. Additional APIs can be added as needed.
These abstractions will be used in upcoming Rust support for cpufreq and
OPP frameworks.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Yury Norov [NVIDIA] <yury.norov@gmail.com>
