On 3/16/25 11:45 PM, Michal Luczaj wrote:
> Racing signal-interrupted connect() and sockmap update may result in an
> unconnected (and missing vsock transport) socket in a sockmap.
>
> Test spends 2 seconds attempting to reach WARN_ON_ONCE().
>
> connect
> / state = SS_CONNECTED /
>
Hi Antonio,
On Mon, Mar 17, 2025 at 5:23 PM Antonio Quartulli wrote:
> >> +static void ovpn_setup(struct net_device *dev)
> >> +{
> >> +netdev_features_t feat = NETIF_F_SG | NETIF_F_HW_CSUM |
> >> NETIF_F_RXCSUM |
> >
> > Do not advertise NETIF_F_HW_CSUM or NETIF_F_RXCSUM, as TX/RX checksum
On 3/17/25 09:23, Paolo Abeni wrote:
> On 3/16/25 11:45 PM, Michal Luczaj wrote:
>> Racing signal-interrupted connect() and sockmap update may result in an
>> unconnected (and missing vsock transport) socket in a sockmap.
>>
>> Test spends 2 seconds attempting to reach WARN_ON_ONCE().
>>
>> connect
Signal delivery during connect() may lead to a disconnect of an already
established socket. That involves removing socket from any sockmap and
resetting state to SS_UNCONNECTED. While it correctly restores socket's
proto, a call to vsock_bpf_recvmsg() might have been already under way in
another th
Signal delivery during connect() may disconnect an already established
socket. Problem is that such socket might have been placed in a sockmap
before the connection was closed.
PATCH 1 ensures this race won't lead to an unconnected vsock staying in the
sockmap. PATCH 2 selftests it.
PATCH 3 fixe
Racing signal-interrupted connect() and sockmap update may result in an
unconnected (and missing vsock transport) socket in a sockmap.
Test spends 2 seconds attempting to reach WARN_ON_ONCE().
connect
/ state = SS_CONNECTED /
sock_map_update_elem
if signal_pend
Signal delivery during connect() may result in a disconnect of an already
TCP_ESTABLISHED socket. Problem is that such established socket might have
been placed in a sockmap before the connection was closed. We end up with a
SS_UNCONNECTED vsock in a sockmap. And this, combined with the ability to
On 17/03/2025 10:41, Qingfang Deng wrote:
Hi Antonio,
On Mon, Mar 17, 2025 at 5:23 PM Antonio Quartulli wrote:
+static void ovpn_setup(struct net_device *dev)
+{
+netdev_features_t feat = NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_RXCSUM |
Do not advertise NETIF_F_HW_CSUM or NETIF_F_RXCSUM,
On 17/03/2025 11:10, Qingfang Deng wrote:
On Mon, Mar 17, 2025 at 6:00 PM Antonio Quartulli wrote:
On 17/03/2025 10:41, Qingfang Deng wrote:
Hi Antonio,
On Mon, Mar 17, 2025 at 5:23 PM Antonio Quartulli wrote:
+static void ovpn_setup(struct net_device *dev)
+{
+netdev_features_t feat =
Enable MU2 node and add mu2 root clock.
MU2 is used to communicate with DSP core.
Reviewed-by: Iuliana Prodan
Reviewed-by: Peng Fan
Signed-off-by: Daniel Baluta
---
arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts
On Fri, 14 Mar 2025 at 06:37, David Gow wrote:
>
> On Fri, 14 Mar 2025 at 03:27, Rae Moar wrote:
> >
> > A bug was identified where the KTAP below caused an infinite loop:
> >
> > TAP version 13
> > ok 4 test_case
> > 1..4
> >
> > The infinite loop was caused by the parser not parsing a test p
On Mon, Mar 17, 2025 at 06:52:57PM +0100, Thomas Weißschuh wrote:
> On 2025-03-17 08:37:46+0100, Willy Tarreau wrote:
> > On Sun, Mar 16, 2025 at 02:55:02PM +0100, Thomas Weißschuh wrote:
> > > Add support for 32bit and 64bit SPARC to nolibc.
> >
> > Oh nice!
> >
> > > Signed-off-by: Thomas Weißs
Am Montag, 17. März 2025, 14:33:03 CET schrieb Daniel Baluta:
> Enable MU2 node and add mu2 root clock.
> MU2 is used to communicate with DSP core.
>
> Reviewed-by: Iuliana Prodan
> Reviewed-by: Peng Fan
> Signed-off-by: Daniel Baluta
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 2 +-
>
From: Vladis Dronov
[ Upstream commit 65be5c95d08eedda570a6c888a12384c77fe7614 ]
The kernel requires X86_FEATURE_SGX_LC to be able to create SGX enclaves,
not just X86_FEATURE_SGX.
There is quite a number of hardware which has X86_FEATURE_SGX but not
X86_FEATURE_SGX_LC. A kernel running on such
On Mon, Mar 17, 2025 at 12:47 AM wrote:
>
> From: FengWei
>
> strncpy() is deprecated for NUL-terminated destination buffers. Use
> strscpy() instead and remove the manual NUL-termination.
>
> Signed-off-by: FengWei
> ---
> tools/testing/selftests/bpf/test_verifier.c | 3 +--
> 1 file changed,
On 10/19/24 12:06 PM, Luca Weiss wrote:
On Donnerstag, 6. Juni 2024 21:01:36 MESZ Luca Weiss wrote:
When the mailbox driver has not probed yet, the error message "failed to
parse smd edge" is just going to confuse users, so improve the error
prints a bit.
Cover the last remaining exits from qco
This change implements encryption/decryption and
encapsulation/decapsulation of OpenVPN packets.
Support for generic crypto state is added along with
a wrapper for the AEAD crypto kernel API.
Signed-off-by: Antonio Quartulli
---
drivers/net/Kconfig| 4 +
drivers/net/ovpn/Makefile
When sending an skb over a socket using skb_send_sock_locked(),
it is currently not possible to specify any flag to be set in
msghdr->msg_flags.
However, we may want to pass flags the user may have specified,
like MSG_NOSIGNAL.
Extend __skb_send_sock() with a new argument 'flags' and add a
new in
This specific structure is used in the ovpn kernel module
to wrap and carry around a standard kernel socket.
ovpn takes ownership of passed sockets and therefore an ovpn
specific objects is attached to them for status tracking
purposes.
Initially only UDP support is introduced. TCP will come in a
Packets received over the socket are forwarded to the user device.
Implementation is UDP only. TCP will be added by a later patch.
Note: no decryption/decapsulation exists yet, packets are forwarded as
they arrive without much processing.
Signed-off-by: Antonio Quartulli
---
drivers/net/ovpn/i
Userspace may want to pass the MSG_NOSIGNAL flag to
tcp_sendmsg() in order to avoid generating a SIGPIPE.
To pass this flag down the TCP stack a new skb sending API
accepting a flags argument is introduced.
Cc: Eric Dumazet
Cc: Paolo Abeni
Signed-off-by: Antonio Quartulli
---
drivers/net/ovpn
On Mon, Mar 17, 2025 at 11:38 AM Willy Tarreau wrote:
> OK thanks, but that remains quite strange to me. How can we end up
> here with such an unaligned stack ? At the very minimum I'd expect
> all offsets to be multiple of 8.
It's a peculiar feature of the version 9 SPARC architecture and runtim
Packets sent over the ovpn interface are processed and transmitted to the
connected peer, if any.
Implementation is UDP only. TCP will be added by a later patch.
Note: no crypto/encapsulation exists yet. Packets are just captured and
sent.
Signed-off-by: Antonio Quartulli
---
drivers/net/Kconf
Byte/packet counters for in-tunnel and transport streams
are now initialized and updated as needed.
To be exported via netlink.
Signed-off-by: Antonio Quartulli
---
drivers/net/ovpn/Makefile | 1 +
drivers/net/ovpn/io.c | 12 +++-
drivers/net/ovpn/peer.c | 2 ++
drivers/net/ovpn
Drivers with "memory-region" properties currently have to do their own
parsing of "memory-region" properties. The result is all the drivers
have similar patterns of a call to parse "memory-region" and then get
the region's address and size. As this is a standard property, it should
have common func
While there's a common function to parse "memory-region" properties for
DMA pool regions, there's not anything for driver private regions. As a
result, drivers have resorted to parsing "memory-region" properties
themselves repeating the same pattern over and over. To fix this, this
series adds 2 fu
Log write descriptors for the event queue, leveraging vhost_get_vq_desc()
to retrieve the array of write descriptors to obtain the log buffer.
There is only one path for event queue.
Suggested-by: Joao Martins
Signed-off-by: Dongli Zhang
---
drivers/vhost/scsi.c | 16 +++-
1 file c
The vhost-scsi I/O queue uses vhost_scsi_cmd. Allocate the log buffer
during vhost_scsi_cmd allocation or when VHOST_F_LOG_ALL is set. Free the
log buffer when vhost_scsi_cmd is reclaimed or when VHOST_F_LOG_ALL is
removed.
Fail vhost_scsi_set_endpoint or vhost_scsi_set_features() on allocation
fa
Since long time ago, the only user of vq->log is vhost-net. The concern is
to add support for more devices (i.e. vhost-scsi or vsock) may reveals
unknown issue in the vhost API. Add a WARNING.
Suggested-by: Joao Martins
Signed-off-by: Dongli Zhang
---
drivers/vhost/vhost.c | 18
Simplify of_dma_set_restricted_buffer() by using of_property_present()
and of_for_each_phandle() iterator.
Signed-off-by: Rob Herring (Arm)
---
drivers/of/device.c | 34 +-
1 file changed, 13 insertions(+), 21 deletions(-)
diff --git a/drivers/of/device.c b/drive
OpenVPN is a userspace software existing since around 2005 that allows
users to create secure tunnels.
So far OpenVPN has implemented all operations in userspace, which
implies several back and forth between kernel and user land in order to
process packets (encapsulate/decapsulate, encrypt/decrypt
This change introduces the netlink commands needed to add, get, delete
and swap keys for a specific peer.
Userspace is expected to use these commands to create, inspect (non
sensitive data only), destroy and rotate session keys for a specific
peer.
Signed-off-by: Antonio Quartulli
---
drivers/n
The ovpn-cli tool can be compiled and used as selftest for the ovpn
kernel module.
[NOTE: it depends on libmedtls for decoding base64-encoded keys]
ovpn-cli implements the netlink and RTNL APIs and can thus be integrated
in any script for more automated testing.
Along with the tool, a bunch of s
IV wrap-around is cryptographically dangerous for a number of ciphers,
therefore kill the key and inform userspace (via netlink) should the
IV space go exhausted.
Userspace has two ways of deciding when the key has to be renewed before
exhausting the IV space:
1) time based approach:
after X se
Implement support for basic ethtool functionality.
Note that ovpn is a virtual device driver, therefore
various ethtool APIs are just not meaningful and thus
not implemented.
Signed-off-by: Antonio Quartulli
Reviewed-by: Andrew Lunn
---
drivers/net/ovpn/main.c | 15 +++
1 file chan
On Mon, Mar 17, 2025 at 06:57:01PM -0700, Chris Torek wrote:
> On Mon, Mar 17, 2025 at 11:38 AM Willy Tarreau wrote:
> > OK thanks, but that remains quite strange to me. How can we end up
> > here with such an unaligned stack ? At the very minimum I'd expect
> > all offsets to be multiple of 8.
>
Although the support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 was
signaled by the commit 664ed90e621c ("vhost/scsi: Set
VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits"),
vhost_scsi_send_bad_target() still assumes the response in a single
descriptor.
In addition, although vhost_scsi_send_
On Tue, Mar 18, 2025 at 7:52 AM Dongli Zhang wrote:
>
> Although the support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 was
> signaled by the commit 664ed90e621c ("vhost/scsi: Set
> VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits"),
> vhost_scsi_send_bad_target() still assumes the response
On Tue, Mar 18, 2025 at 7:52 AM Dongli Zhang wrote:
>
> Although the support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 was
> signaled by the commit 664ed90e621c ("vhost/scsi: Set
> VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits"),
> vhost_scsi_send_bad_target() still assumes the response
Fix a typo in an email address.
Cc: sta...@vger.kernel.org
Reported-by: Konstantin Ryabitsev
Closes:
https://lore.kernel.org/all/20240925-rational-succinct-vulture-cca9fb@lemur/T/
Signed-off-by: Alexey Makhalov
---
MAINTAINERS | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -
On Tue, Mar 18, 2025 at 7:51 AM Dongli Zhang wrote:
>
> The vhost-scsi completion path may access vq->log_base when vq->log_used is
> already set to false.
>
> vhost-thread QEMU-thread
>
> vhost_scsi_complete_cmd_work()
> -> vhost_add_used()
>-> vhost_add_used_n()
>
On Tue, Mar 18, 2025 at 7:51 AM Dongli Zhang wrote:
>
> Currently, the only user of vhost_log_write() is vhost-net. The 'len'
> argument prevents logging of pages that are not tainted by the RX path.
>
> Adjustments are needed since more drivers (i.e. vhost-scsi) begin using
> vhost_log_write(). S
Currently, the only user of vhost_log_write() is vhost-net. The 'len'
argument prevents logging of pages that are not tainted by the RX path.
Adjustments are needed since more drivers (i.e. vhost-scsi) begin using
vhost_log_write(). So far vhost-net RX path may only partially use pages
shared by t
Hi Mike,
On 3/17/25 4:55 PM, Dongli Zhang wrote:
> The vhost-scsi I/O queue uses vhost_scsi_cmd. Allocate the log buffer
> during vhost_scsi_cmd allocation or when VHOST_F_LOG_ALL is set. Free the
> log buffer when vhost_scsi_cmd is reclaimed or when VHOST_F_LOG_ALL is
> removed.
>
> Fail vhost_s
The live migration with vhost-scsi has been enabled by QEMU commit
b3e89c941a85 ("vhost-scsi: Allow user to enable migration"), which
thoroughly explains the workflow that QEMU collaborates with vhost-scsi on
the live migration.
Although it logs dirty data for the used ring, it doesn't log any wri
The vhost-scsi completion path may access vq->log_base when vq->log_used is
already set to false.
vhost-thread QEMU-thread
vhost_scsi_complete_cmd_work()
-> vhost_add_used()
-> vhost_add_used_n()
if (unlikely(vq->log_used))
Log write descriptors for the control queue, leveraging
vhost_scsi_get_desc() and vhost_get_vq_desc() to retrieve the array of
write descriptors to obtain the log buffer.
For Task Management Requests, similar to the I/O queue, store the log
buffer during the submission path and log it in the compl
Although the support of VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 was
signaled by the commit 664ed90e621c ("vhost/scsi: Set
VIRTIO_F_ANY_LAYOUT + VIRTIO_F_VERSION_1 feature bits"),
vhost_scsi_send_bad_target() still assumes the response in a single
descriptor.
Similar issue in vhost_scsi_send_bad_t
Log write descriptors for the I/O queue, leveraging vhost_scsi_get_desc()
and vhost_get_vq_desc() to retrieve the array of write descriptors to
obtain the log buffer.
In addition, introduce a vhost-scsi specific function to log vring
descriptors. In this function, the 'partial' argument is set to
Adjust vhost_scsi_get_desc() to facilitate logging of vring descriptors.
Add new arguments to allow passing the log buffer and length to
vhost_get_vq_desc().
In addition, reset 'log_num' since vhost_get_vq_desc() may reset it only
after certain condition checks.
Suggested-by: Joao Martins
Signe
This commit introduces basic netlink support with family
registration/unregistration functionalities and stub pre/post-doit.
More importantly it introduces the YAML uAPI description along
with its auto-generated files:
- include/uapi/linux/ovpn.h
- drivers/net/ovpn/netlink-gen.c
- drivers/net/ovpn
Notable changes since v23:
* dropped call to netif_tx_start/stop_all_queues()
* dropped NETIF_F_HW_CSUM and NETIF_F_RXCSUM dev flags
* dropped conditional call to skb_checksum_help() due to the point above
* added call to dst_cache_reset() in nl_peer_modify()
* dropped obsolete comment in ovpn_peer
An ovpn interface configured in MP mode will keep carrier always
on and let the user decide when to bring it administratively up and
down.
This way a MP node (i.e. a server) will keep its interface always
up and running, even when no peer is connected.
Signed-off-by: Antonio Quartulli
---
drive
Add basic infrastructure for handling ovpn interfaces.
Tested-by: Donald Hunter
Signed-off-by: Antonio Quartulli
---
Documentation/netlink/specs/rt_link.yaml | 16 ++
drivers/net/ovpn/Makefile| 1 +
drivers/net/ovpn/io.c| 22 +++
drivers/net/ovpn/io.
With this change an ovpn instance will be able to stay connected to
multiple remote endpoints.
This functionality is strictly required when running ovpn on an
OpenVPN server.
Signed-off-by: Antonio Quartulli
---
drivers/net/ovpn/main.c | 64 +--
drivers/net/ovpn/ovpnpriv.h | 1
In case of UDP links, the local or remote endpoint used to communicate
with a given peer may change without a connection restart.
Add support for learning the new address in case of change.
Signed-off-by: Antonio Quartulli
---
drivers/net/ovpn/io.c | 8 ++
drivers/net/ovpn/peer.c | 213
With this change ovpn is allowed to communicate to peers also via TCP.
Parsing of incoming messages is implemented through the strparser API.
Note that ovpn redefines sk_prot and sk_socket->ops for the TCP socket
used to communicate with the peer.
For this reason it needs to access inet6_stream_op
This change introduces the netlink command needed to add, delete and
retrieve/dump known peers. Userspace is expected to use these commands
to handle known peer lifecycles.
Signed-off-by: Antonio Quartulli
---
drivers/net/ovpn/netlink.c | 678 -
driver
In a multi-peer scenario there are a number of situations when a
specific peer needs to be looked up.
We may want to lookup a peer by:
1. its ID
2. its VPN destination IP
3. its transport IP/port couple
For each of the above, there is a specific routing table referencing all
peers for fast look u
Add strict buffer parsing index check to avoid the following Smatch
warning:
net/core/pktgen.c:877 get_imix_entries()
warn: check that incremented offset 'i' is capped
Checking the buffer index i after every get_user/i++ step and returning
with error code immediately avoids the current indire
Add more imix_weights test cases (for incomplete input).
Signed-off-by: Peter Seiderer
---
tools/testing/selftests/net/proc_net_pktgen.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/tools/testing/selftests/net/proc_net_pktgen.c
b/tools/testing/selftests/net/proc_net_
On Fri, 14 Mar 2025, Filipe Xavier wrote:
> On 3/14/25 10:14 AM, Miroslav Benes wrote:
>
> > Hi,
> >
> >> +start_test "trace livepatched function and check that the live patch
> >> remains in effect"
> >> +
> >> +FUNCTION_NAME="livepatch_cmdline_proc_show"
> >> +
> >> +load_lp $MOD_LIVEPATCH
> >>
The k3_r5_core_of_get_internal_memories() and
k3_{/dsp/m4}_rproc_of_get_memories() functions initialize and assigns
memory regions used by the remote processor. Refactor these
implementations into ti_k3_common.c driver as k3_rproc_of_get_memories()
and align R5, DSP and M4 drivers to use this commo
The k3_{r5/dsp/m4}_release_tsp() functions release the TI-SCI processor
control of a remote processor, which is auto triggered upon device
removal. Refactor these functions into ti_k3_common.c driver as
k3_release_tsp() and align R5, DSP and M4 drivers to use this common
function throughout.
Signe
The ti_k3_m4_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_rproc_mem_data
structure to store memory information. This aligns with DSP and R5
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
---
drivers/remotepr
Hello,
A few comments since it seems you'll have to send one more version
(otherwise they could be fixed later).
2025-03-12, 21:54:27 +0100, Antonio Quartulli wrote:
> diff --git a/drivers/net/ovpn/netlink.c b/drivers/net/ovpn/netlink.c
> index
> 8d267d4c82283d9b5f989478102086ce385195d5..407b5b9
On Mon, 10 Mar 2025 at 15:11, Karel Balej wrote:
>
> Set the MMC_CAP_NEED_RSP_BUSY capability for the sdhci-pxav3 host to
> prevent conversion of R1B responses to R1. Without this, the eMMC card
> in the samsung,coreprimevelte smartphone using the Marvell PXA1908 SoC
> with this mmc host doesn't p
On Fri 2025-03-14 16:50:43, Tamir Duberstein wrote:
> On Fri, Mar 14, 2025 at 4:45 PM Kees Cook wrote:
> >
> > On Fri, Mar 14, 2025 at 02:29:40PM +0100, Petr Mladek wrote:
> > > On Fri 2025-03-07 06:27:33, Tamir Duberstein wrote:
> > > > This is one of just 3 remaining "Test Module" kselftests (th
On 3/14/25 18:10, Suren Baghdasaryan wrote:
> On Tue, Mar 4, 2025 at 11:08 AM Liam R. Howlett
> wrote:
>>
>> * Vlastimil Babka [250304 05:55]:
>> > On 2/25/25 21:26, Suren Baghdasaryan wrote:
>> > > On Mon, Feb 24, 2025 at 1:12 PM Suren Baghdasaryan
>> > > wrote:
>> > >>
>> > >> >
>> > >> > >
Hi,
I am sorry for the late reply. I have read the mail on Friday and then
forgot to come back to it last Monday...
On Fri 2025-03-07 10:50:42, Joe Lawrence wrote:
> On 3/7/25 07:26, Petr Mladek wrote:
> > On Thu 2025-03-06 17:54:41, Joe Lawrence wrote:
> >> Finally, the patchset adds .is_shadow
On Wed Feb 26, 2025 at 3:47 PM CET, Bryan O'Donoghue wrote:
> On 26/02/2025 14:13, Luca Weiss wrote:
>> Hi all,
>>
>> On Mon Dec 9, 2024 at 1:01 PM CET, Luca Weiss wrote:
>>> Since the hardware blocks on the SoCs generally support both D-PHY and
>>> C-PHY standards for camera, but the camss driver
From: FengWei
strncpy() is deprecated for NUL-terminated destination buffers. Use
strscpy() instead and remove the manual NUL-termination.
Signed-off-by: FengWei
---
tools/testing/selftests/bpf/test_verifier.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/tools/testing/
The TI K3 R5, DSP and M4 remoteproc drivers share the same data
structure definitions. Refactor the shared data structures into a new
common header file, 'ti_k3_common.h', and update the drivers to use the
unified data structures.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k3_common
The mailbox .rx_callback implementations in TI K3 R5, DSP and M4
remoteproc drivers handle inbound mailbox messages in the same way.
Introduce a common driver 'ti_k3_common.c' and refactor the
implementations into a common function 'k3_rproc_mbox_callback'() in it.
Signed-off-by: Beleswar Padhi
-
The .kick rproc ops implementations in TI K3 R5, DSP and M4 remoteproc
drivers sends a mailbox message to the remote processor in the same
way. Refactor the implementations into a common function
'k3_rproc_kick()' in the ti_k3_common.c driver.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc
This series refactors a lot of functions & callbacks from
ti_k3_dsp_remoteproc.c, ti_k3_r5_remoteproc.c and ti_k3_m4_remoteproc.c
drivers. This is a consolidated and final series as part of the
refactoring of K3 remoteproc drivers. Below is the breakdown:
1. PATCHES #1-#5 does the pre-cleanup and a
From: Siddharth Vadapalli
Commit ea1d6fb5b571 ("remoteproc: k3-dsp: Acquire mailbox handle during
probe routine") introduced a check in the "k3_dsp_rproc_mbox_callback()"
and "k3_dsp_rproc_kick()" callbacks, causing them to exit if the remote
core's state is "RPROC_DETACHED". However, the "__rpro
From: Siddharth Vadapalli
Commit f3f11cfe8907 ("remoteproc: k3-r5: Acquire mailbox handle during
probe routine") introduced a check in the "k3_r5_rproc_mbox_callback()"
and "k3_r5_rproc_kick()" callbacks, causing them to exit if the remote
core's state is "RPROC_DETACHED". However, the "__rproc_a
The existing implementation of the waiting mechanism in
"k3_r5_cluster_rproc_init()" waits for the "released_from_reset" flag to
be set as part of the firmware boot process in "k3_r5_rproc_start()".
The "k3_r5_cluster_rproc_init()" function is invoked in the probe
routine which causes unexpected fa
The k3_dsp_rproc_reset() function erroneously asserts the local reset
even for devices which do not support it. Even though it results in a
no-operation, Update the logic to explicitly assert the local reset for
devices that support it and only the global reset for those that do not.
Further, refa
The k3_dsp_rproc_start() function sets the boot address and releases the
reset on the remote processor. Whereas, the k3_m4_rproc_start() function
only needs to release the reset. Refactor the k3_m4_rproc_start() into
ti_k3_common.c as k3_rproc_start() and align the DSP and M4 drivers to
invoke this
The ti_k3_dsp_remoteproc.c driver asserts the local reset in probe and
releases the global reset in .prepare callback. Whereas, the
ti_k3_m4_remoteproc.c driver does both operations in .prepare callback,
which is more suitable as it ensures lreset is asserted for subsequent
core start operations fr
The .da_to_va rproc ops implementations in TI K3 R5, DSP and M4
remoteproc drivers return the Kernel virtual address for a
corresponding rproc device address. Refactor the implementations into
ti_k3_common.c driver as k3_rproc_da_to_va and align R5, DSP and M4
drivers to use this common function fo
The k3_{r5/dsp}_mem_release() and k3_m4_rproc_dev_mem_release()
functions release the reserved memory of the device, which get auto
triggered upon device removal. Refactor these functions into
ti_k3_common.c driver as k3_mem_release() and align R5, DSP and M4
drivers to use this common function thr
Currently, struct members such as mem, num_mems, reset, tsp, ti_sci and
ti_sci_id are part of the k3_r5_core structure. To align the rproc->priv
data structure of the R5 remote processor with that of the DSP and M4,
move the above members from k3_r5_core to k3_r5_rproc.
Additionally, introduce a v
The core's internal memory data structure will be refactored to be part
of the k3_r5_rproc structure in a future commit. As a result, internal
memory initialization will need to be performed inside
k3_r5_cluster_rproc_init() after rproc_alloc().
Therefore, move the internal memory initialization f
Introduce a void pointer in the k3_{m4/dsp}_rproc internal data
structure which can be used to point to any private data needed by the
driver. Currently, the M4/DSP drivers do not have any private data, so
the pointer can be left pointing to NULL. Additionally, add a pointer to
the rproc struct wit
The k3_{r5/dsp}_rproc_request_mbox() function acquires the mailbox
channel and sends a message through the acquired channel. The TI K3 M4
remoteproc driver acquires the mailbox channel in probe and sends the
message later in .attach()/.start() callbacks. Refactor the
k3_{r5/dsp}_rproc_request_mbox(
The .unprepare rproc ops implementations in ti_k3_dsp_remoteproc.c and
ti_k3_m4_remoteproc.c drivers assert the global reset on the remote
processor. Refactor the implementations into ti_k3_common.c driver as
k3_rproc_unprepare() and align DSP and M4 drivers to register this
common function as .unp
The .stop rproc ops implementations in ti_k3_dsp_remoteproc.c and
ti_k3_m4_remoteproc.c drivers put the remote processor into reset.
Refactor the implementations into ti_k3_common.c driver as
k3_rproc_stop() and align DSP and M4 drivers to register this common
function as .stop ops.
Further, do no
The k3_dsp_rproc_release() function erroneously deasserts the local
reset even for devices which do not support it. Even though it results
in a no-operation, Update the logic to explicitly deassert the local
reset for devices that support it and only the global reset for those
that do not.
Further
The .attach rproc ops implementations in TI K3 R5, DSP and M4 drivers
are NOPs. Refactor the implementations into ti_k3_common.c driver
as k3_rproc_attach() and align R5, DSP and M4 drivers to register this
common function as .attach ops.
Signed-off-by: Beleswar Padhi
---
drivers/remoteproc/ti_k
The .get_loaded_rsc_table rproc ops implementations in TI K3 R5, DSP and
M4 remoteproc drivers return a pointer to the resource table that was
pre-loaded at the base address of the DDR region reserved for firmware
usage. Refactor the implementations into ti_k3_common.c driver as
k3_get_loaded_rsc_t
The .detach rproc ops implementations in TI K3 R5, DSP and M4
remoteproc drivers are NOPs. Refactor the implementations into
ti_k3_common.c driver as k3_rproc_detach() and align R5, DSP and M4
drivers to register this common function as .detach ops.
Signed-off-by: Beleswar Padhi
---
drivers/remo
Hi Konrad,
On Fri Mar 14, 2025 at 11:08 PM CET, Konrad Dybcio wrote:
> On 3/14/25 10:17 AM, Luca Weiss wrote:
>> UFS host controller, when scaling gears, should choose appropriate
>> performance state of RPMh power domain controller along with clock
>> frequency. So let's add the OPP table support
The ti_k3_r5_remoteproc.c driver previously hardcoded device memory
region addresses and names. Change this to use the k3_r5_rproc_mem_data
structure to store memory information. This aligns with K3 DSP and M4
drivers, and can be refactored out later.
Signed-off-by: Beleswar Padhi
---
drivers/re
On Mon, Mar 17, 2025 at 6:00 PM Antonio Quartulli wrote:
>
> On 17/03/2025 10:41, Qingfang Deng wrote:
> > Hi Antonio,
> >
> > On Mon, Mar 17, 2025 at 5:23 PM Antonio Quartulli
> > wrote:
> +static void ovpn_setup(struct net_device *dev)
> +{
> +netdev_features_t feat = NETIF_
On 3/12/25 16:14, Suren Baghdasaryan wrote:
> On Wed, Mar 12, 2025 at 7:58 AM Vlastimil Babka wrote:
>> > I find the program flow in this function quite complex and hard to
>> > follow. I think refactoring the above block starting from "pcs =
>> > this_cpu_ptr(s->cpu_sheaves)" would somewhat simpl
kip("%s failed with ENOENT. Filesystem might be buggy
(9pfs?)\n", op_name);
+}
+
uint64_t pagemap_get_entry(int fd, char *start);
bool pagemap_is_softdirty(int fd, char *start);
bool pagemap_is_swapped(int fd, char *start);
---
base-commit: a91aaf8dd549dcee9caab227ecaa6cbc243bbc5a
change-id: 20250317-9pfs-comments-24b6fa5417cd
Best regards,
--
Brendan Jackman
On Sun, Mar 16, 2025 at 02:55:02PM +0100, Thomas Weißschuh wrote:
> Add support for 32bit and 64bit SPARC to nolibc.
Oh nice!
> Signed-off-by: Thomas Weißschuh
> ---
> This is only tested on QEMU.
> Any tests on real hardware would be very welcome.
I still have a working U60 here, but under sol
1 - 100 of 136 matches
Mail list logo
