suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Arnaud-Pouliquen/remoteproc-Add-TEE-support/20240115-215613
base: git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux.git
From: Arnd Bergmann
[ Upstream commit 64bac5ea17d527872121adddfee869c7a0618f8f ]
The prototype was hidden in an #ifdef on x86, which causes a warning:
kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise'
[-Werror=missing-prototypes]
Some architectures have a
From: Arnd Bergmann
[ Upstream commit 64bac5ea17d527872121adddfee869c7a0618f8f ]
The prototype was hidden in an #ifdef on x86, which causes a warning:
kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise'
[-Werror=missing-prototypes]
Some architectures have a
From: Arnd Bergmann
[ Upstream commit 64bac5ea17d527872121adddfee869c7a0618f8f ]
The prototype was hidden in an #ifdef on x86, which causes a warning:
kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise'
[-Werror=missing-prototypes]
Some architectures have a
From: Arnd Bergmann
[ Upstream commit 64bac5ea17d527872121adddfee869c7a0618f8f ]
The prototype was hidden in an #ifdef on x86, which causes a warning:
kernel/irq_work.c:72:13: error: no previous prototype for 'arch_irq_work_raise'
[-Werror=missing-prototypes]
Some architectures have a
On Mon, 15 Jan 2024 11:23:59 -0500
Steven Rostedt wrote:
> On Mon, 15 Jan 2024 11:09:38 -0500
> Steven Rostedt wrote:
>
> > No. The ring buffer logic should not care if the user of it is swapping
> > the entire ring buffer or not. It only cares if parts of the ring
> > buffer is being swapped
On Mon, Jan 15, 2024 at 09:48:40PM +0200, Andrew Melnychenko wrote:
> When the Qemu launched with vhost but without tap vnet_hdr,
> vhost tries to copy vnet_hdr from socket iter with size 0
> to the page that may contain some trash.
> That trash can be interpreted as unpredictable values for
>
See also https://issues.redhat.com/browse/RHEL-1303
On Mon, Jan 15, 2024 at 9:48 PM Andrew Melnychenko wrote:
>
> When the Qemu launched with vhost but without tap vnet_hdr,
> vhost tries to copy vnet_hdr from socket iter with size 0
> to the page that may contain some trash.
> That trash can
ida_alloc() and ida_free() should be preferred to the deprecated
ida_simple_get() and ida_simple_remove().
Note that the upper limit of ida_simple_get() is exclusive, buInputt the one of
ida_alloc_max() is inclusive. So a -1 has been added when needed.
Signed-off-by: Christophe JAILLET
---
When the Qemu launched with vhost but without tap vnet_hdr,
vhost tries to copy vnet_hdr from socket iter with size 0
to the page that may contain some trash.
That trash can be interpreted as unpredictable values for
vnet_hdr.
That leads to dropping some packets and in some cases to
stalling vhost
Hi Christophe,
On Sun, Jan 14, 2024 at 10:37:43AM +0100, Christophe JAILLET wrote:
> ida_alloc() and ida_free() should be preferred to the deprecated
> ida_simple_get() and ida_simple_remove().
>
> Note that the upper limit of ida_simple_get() is exclusive, but the one of
> ida_alloc_max() is
dtschema package defines firmware-name as string-array, so individual
bindings should not make it a string but instead just narrow the number
of expected firmware file names.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml | 4 ++--
Hi Tanmay,
Thanks for the refactoring, this is in line with what Bjorn and I have talked
about at Plumbers. Please see my comments below.
On Wed, Jan 03, 2024 at 02:11:24PM -0800, Tanmay Shah wrote:
> From: Mathieu Poirier
>
> Multi-cluster remoteproc designs typically have the following DT
>
On Mon, 15 Jan 2024 17:29:09 +
Vincent Donnefort wrote:
> >
> > What needs to be done, and feel free to add this as a separate patch,
> > is to have checks where snapshot is used.
> >
> > (All errors return -EBUSY)
> >
> > Before allowing mapping, check to see if:
> >
> > 1) the
On Mon, Jan 15, 2024 at 11:23:59AM -0500, Steven Rostedt wrote:
> On Mon, 15 Jan 2024 11:09:38 -0500
> Steven Rostedt wrote:
>
> > No. The ring buffer logic should not care if the user of it is swapping
> > the entire ring buffer or not. It only cares if parts of the ring
> > buffer is being
On Mon, 15 Jan 2024 11:09:38 -0500
Steven Rostedt wrote:
> No. The ring buffer logic should not care if the user of it is swapping
> the entire ring buffer or not. It only cares if parts of the ring
> buffer is being swapped or not. That's not the level of scope it should
> care about. If we do
On Mon, 15 Jan 2024 15:37:31 +
Vincent Donnefort wrote:
> > > @@ -5418,6 +5446,11 @@ int ring_buffer_swap_cpu(struct trace_buffer
> > > *buffer_a,
> > > cpu_buffer_a = buffer_a->buffers[cpu];
> > > cpu_buffer_b = buffer_b->buffers[cpu];
> > >
> > > + if
On Mon, Jan 15, 2024 at 01:43:03PM +0900, Masami Hiramatsu wrote:
> On Thu, 11 Jan 2024 16:17:09 +
> Vincent Donnefort wrote:
>
> > In preparation for allowing the user-space to map a ring-buffer, add
> > a set of mapping functions:
> >
> > ring_buffer_{map,unmap}()
> >
Inside decrement_ttl() upon discovering that the packet ttl has exceeded,
__IP_INC_STATS and __IP6_INC_STATS macros can be called from preemptible
context having the following backtrace:
check_preemption_disabled: 48 callbacks suppressed
BUG: using __this_cpu_add() in preemptible [] code:
test %al,(%rax)
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20240115/202401152142.bfc28861-oliver.s...@intel.com
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
From: Anton Yakovlev
Implementation of support for audio controls in accordance with the
extension of the virtio sound device specification [1] planned for
virtio-v1.3-cs01.
The device can announce the VIRTIO_SND_F_CTLS feature. If the feature is
negotiated, then an additional field appears in
From: Anton Yakovlev
Changes in v2
- Fix reporting of incorrect number of items for ENUMERATED controls
Implementation of support for audio controls in accordance with the
extension of the virtio sound device specification[1] planned for
virtio-v1.3-cs01.
Design of virtual audio controls is
To prepare for the support of TEE remoteproc, create sub-functions
that can be used in both cases, with and without TEE support.
Signed-off-by: Arnaud Pouliquen
---
drivers/remoteproc/stm32_rproc.c | 84 +++-
1 file changed, 51 insertions(+), 33 deletions(-)
diff
From: Arnaud Pouliquen
Add a remoteproc TEE (Trusted Execution Environment) device
that will be probed by the TEE bus. If the associated Trusted
application is supported on secure part this device offers a client
interface to load a firmware in the secure part.
This firmware could be
The "st,stm32mp1-m4-tee" compatible is utilized in a system configuration
where the Cortex-M4 firmware is loaded by the Trusted execution Environment
(TEE).
This compatible is used in both the Linux and OP-TEE device-tree.
- In OP-TEE, a node is defined in the device tree with the
The new TEE remoteproc device is used to manage remote firmware in a
secure, trusted context. The 'st,stm32mp1-m4-tee' compatibility is
introduced to delegate the loading of the firmware to the trusted
execution context. In such cases, the firmware should be signed and
adhere to the image format
This series proposes the implementation of a remoteproc tee driver to
communicate with a TEE trusted application responsible for authenticating and
loading the remoteproc firmware image in an Arm secure context.
1) Principle:
The remoteproc tee driver provides services to communicate with the
Hi Marcin,
I have pushed v2 of the patches with a fix today. The feature development is
complete and the patch awaits review.
Thanks for any support in testing or review.
Best Regards,
Aiswarya Cyriac
Software Engineer
OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin
EMail:
On 15.01.2024 14:54, Stefano Garzarella wrote:
> Hi Arseniy,
> thanks for this patch!
>
> On Sat, Jan 13, 2024 at 12:21:10AM +0300, Arseniy Krasnov wrote:
>> Implement port for given CID as input argument instead of using
>> hardcoded value '1234'. This allows to run different test instances
Hi Arseniy,
thanks for this patch!
On Sat, Jan 13, 2024 at 12:21:10AM +0300, Arseniy Krasnov wrote:
Implement port for given CID as input argument instead of using
hardcoded value '1234'. This allows to run different test instances
on a single CID. Port argument is not required parameter and if
On 1/10/24 22:35, Tanmay Shah wrote:
Add properties as per new bindings in zynqmp remoteproc node
to represent TCM address and size.
This patch also adds alternative remoteproc node to represent
remoteproc cluster in split mode. By default lockstep mode is
enabled and users should disable it
31 matches
Mail list logo
