On Mon, Jul 8, 2024 at 2:56 PM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
Great.
>
> Signed-off-by: Cindy Lu
I guess this should be part of the ser
On Mon, Jul 8, 2024 at 2:48 PM Cindy Lu wrote:
>
> Add new UAPI to support the mac address from vdpa tool
> Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> new MAC address from the vdpa tool and then set it to the device.
>
> The usage is: vdpa dev set name vdpa_name mac **:**:**:**:**:**
On Fri, 5 Jul 2024 at 20:42, Stefano Garzarella wrote:
>
> On Fri, Jul 05, 2024 at 07:30:51AM GMT, Michael S. Tsirkin wrote:
> >On Fri, Jul 05, 2024 at 01:28:21PM +0200, Stefano Garzarella wrote:
> >> The vDPA block simulator always allocated a 128 MiB ram-disk, but some
> >> filesystems (e.g. XFS
On Mon, Jul 8, 2024 at 2:48 PM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa_sim_net, the driver will write the MAC address
> to the config space, and other devices can implement
> their own functions to support this.
>
> Signed-off-by: Cindy Lu
> ---
> driv
On Mon, 8 Jul 2024 at 15:06, Jason Wang wrote:
>
> On Mon, Jul 8, 2024 at 2:48 PM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa_sim_net, the driver will write the MAC address
> > to the config space, and other devices can implement
> > their own functio
On Mon, 2024-07-08 at 14:55 +0800, Cindy Lu wrote:
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c |
Le 01/07/2024 à 11:59, Hari Nagalla a écrit :
On 6/21/24 10:00, Richard Genoud wrote:
Richard Genoud (4):
remoteproc: k3-r5: Fix IPC-only mode detection
remoteproc: k3-r5: Introduce PM suspend/resume handlers
remoteproc: k3-r5: k3_r5_rproc_stop: code reorder
remoteproc: k3-r5: suppor
On Mon, Jul 8, 2024 at 3:06 PM Cindy Lu wrote:
>
> On Fri, 5 Jul 2024 at 20:42, Stefano Garzarella wrote:
> >
> > On Fri, Jul 05, 2024 at 07:30:51AM GMT, Michael S. Tsirkin wrote:
> > >On Fri, Jul 05, 2024 at 01:28:21PM +0200, Stefano Garzarella wrote:
> > >> The vDPA block simulator always alloc
On Mon, Jul 8, 2024 at 3:19 PM Cindy Lu wrote:
>
> On Mon, 8 Jul 2024 at 15:06, Jason Wang wrote:
> >
> > On Mon, Jul 8, 2024 at 2:48 PM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa_sim_net, the driver will write the MAC address
> > > to the con
Hi Cindy, Jason,
On Mon, Jul 08, 2024 at 03:59:34PM GMT, Jason Wang wrote:
On Mon, Jul 8, 2024 at 3:06 PM Cindy Lu wrote:
On Fri, 5 Jul 2024 at 20:42, Stefano Garzarella wrote:
>
> On Fri, Jul 05, 2024 at 07:30:51AM GMT, Michael S. Tsirkin wrote:
> >On Fri, Jul 05, 2024 at 01:28:21PM +0200,
'--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Cindy-Lu/vdpa-support-set-mac-address-from-vdpa-tool/20240708-144942
base: linus/master
patch link:
https://lore.ke
On Sat, Jul 06, 2024 at 04:14:39PM +0100, David Woodhouse wrote:
> From: David Woodhouse
>
> The vmclock "device" provides a shared memory region with precision clock
> information. By using shared memory, it is safe across Live Migration.
>
> Like the KVM PTP clock, this can convert TSC-based c
On Mon, 2024-07-08 at 10:17 +0100, Simon Horman wrote:
> Hi David,
>
> As per my comment on v2, although it is harmless in this case,
> it would be nicer to use strscpy() here and avoid fortification
> warnings.
>
Oh, pants! I have fixed that; must have sent the wrong version.
V4 coming up short
From: David Woodhouse
The vmclock "device" provides a shared memory region with precision clock
information. By using shared memory, it is safe across Live Migration.
Like the KVM PTP clock, this can convert TSC-based cross timestamps into
KVM clock values. Unlike the KVM PTP clock, it does so o
On Fri, Jul 05, 2024 at 03:38:12PM +0200, Jiri Olsa wrote:
> > Agreed. BTW, even if the uprobe is removed, the ret_handler should be
> > called?
> > I think both 1 and 2 case, we should skip ret_handler.
>
> do you mean what happens when the uretprobe is installed and its consumer
> is unregiste
On Mon, Jul 8, 2024 at 9:16 AM maobibo wrote:
>
>
>
> On 2024/7/6 下午5:41, Huacai Chen wrote:
> > On Sat, Jul 6, 2024 at 2:59 PM maobibo wrote:
> >>
> >> Huacai,
> >>
> >> On 2024/7/6 上午11:00, Huacai Chen wrote:
> >>> Hi, Bibo,
> >>>
> >>> On Fri, May 24, 2024 at 3:38 PM Bibo Mao wrote:
>
>
On Wed, 2024-07-03 at 18:01 +0200, Eugenio Perez Martin wrote:
> On Wed, Jun 26, 2024 at 11:27 AM Dragos Tatulea wrote:
> >
> > On Wed, 2024-06-19 at 17:54 +0200, Eugenio Perez Martin wrote:
> > > On Mon, Jun 17, 2024 at 5:09 PM Dragos Tatulea
> > > wrote:
> > > >
> > > > Currently, hardware V
On Mon, Jul 08, 2024 at 11:01:39AM +, Dragos Tatulea wrote:
> On Wed, 2024-07-03 at 18:01 +0200, Eugenio Perez Martin wrote:
> > On Wed, Jun 26, 2024 at 11:27 AM Dragos Tatulea wrote:
> > >
> > > On Wed, 2024-06-19 at 17:54 +0200, Eugenio Perez Martin wrote:
> > > > On Mon, Jun 17, 2024 at 5:
On Mon, 2024-07-08 at 07:11 -0400, Michael S. Tsirkin wrote:
> On Mon, Jul 08, 2024 at 11:01:39AM +, Dragos Tatulea wrote:
> > On Wed, 2024-07-03 at 18:01 +0200, Eugenio Perez Martin wrote:
> > > On Wed, Jun 26, 2024 at 11:27 AM Dragos Tatulea
> > > wrote:
> > > >
> > > > On Wed, 2024-06-19
On Mon, Jul 08, 2024 at 11:17:06AM +, Dragos Tatulea wrote:
> On Mon, 2024-07-08 at 07:11 -0400, Michael S. Tsirkin wrote:
> > On Mon, Jul 08, 2024 at 11:01:39AM +, Dragos Tatulea wrote:
> > > On Wed, 2024-07-03 at 18:01 +0200, Eugenio Perez Martin wrote:
> > > > On Wed, Jun 26, 2024 at 11:
On Mon, Jul 08, 2024 at 02:55:49PM +0800, Cindy Lu wrote:
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
Is this on top of your other patchset
According to the measurements for vDPA Live Migration downtime [0], one
large source of downtime is the creation of hardware VQs and their
associated resources on the devices on the destination VM.
Previous series ([1], [2]) addressed the source part of the Live
Migration downtime. This series add
setup_driver()/teardown_driver() are a bit vague. These functions are
used for virtqueue resources.
Same for alloc_resources()/teardown_resources(): they represent fixed
resources that are meant to exist during the device lifetime.
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-off-by
No need to iterate over max number of VQs.
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/ml
... by changing the setup_vq_resources() parameter type.
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/dri
The hardware VQ configuration is mirrored by data in struct
mlx5_vdpa_virtqueue . Instead of clearing just a few fields at reset,
fully clear the struct and initialize with the appropriate default
values.
As clear_vqs_ready() is used only during reset, get rid of it.
Reviewed-by: Cosmin Ratiu
Ac
Function is used to set default values, so name it accordingly.
Reviewed-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/ne
The check is done inside teardown_vq().
Reviewed-by: Cosmin Ratiu
Reviewed-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5
This is done in preparation for the pre-creation of hardware virtqueues
at device add time.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 16
include/linux/mlx5/mlx5_ifc_vdpa.h | 1 +
2 files changed, 17 insertions(+)
diff --
This is done in preparation for the pre-creation of hardware virtqueues
at device add time.
Signed-off-by: Dragos Tatulea
Reviewed-by: Cosmin Ratiu
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 12 +++-
include/linux/mlx5/mlx5_ifc_vdpa.h | 1 +
2 files changed, 12 insertions(+), 1 deletion(
Use the dedicated suspend_vqs() function instead.
Reviewed-by: Cosmin Ratiu
Reviewed-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa
Originally, the second loop initialized the CVQ. But (acde3929492b
("vdpa/mlx5: Use consistent RQT size") initialized all the queues in the
first loop, so the second iteration in init_mvqs() is never called
because the first one will iterate up to max_vqs.
Reviewed-by: Cosmin Ratiu
Acked-by: Euge
The virtio spec says that a vdpa device should start off with one queue
pair. The driver is already compliant.
This patch moves the initialization to device add and reset times. This
is done in preparation for the pre-creation of hardware virtqueues at
device add time.
Reviewed-by: Cosmin Ratiu
Based on the filled flag, create VQs that are filled or blank.
Blank VQs will be filled in later through VQ modify.
Later patches will make use of this to pre-create blank VQs at
vdpa device creation.
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/
The virtqueue size is a pre-requisite for setting up any virtqueue
resources. For the upcoming optimization of creating virtqueues at
device add, the virtqueue size has to be configured.
The queue size check in setup_vq() will always be false. So remove it.
Signed-off-by: Dragos Tatulea
Reviewed
Currently rqt_size is initialized during device flag configuration.
That's because it is the earliest moment when device knows if MQ
(multi queue) is on or off.
Shift this configuration earlier to device creation time. This implies
that non-MQ devices will have a larger RQT size. But the configura
Otherwise, when virtqueues are moved from INIT to READY the latest mkey
will not be set appropriately.
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drive
Instead of blindly calling suspend/resume_vqs(), make then return error
codes.
To keep compatibility, keep suspending or resuming VQs on error and
return the last error code. The assumption here is that the error code
would be the same.
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-o
Until now resume_vq() was used only for the suspend/resume scenario.
This change also allows calling resume_vq() to bring it from Init to
Ready state (VQ initialization).
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 24
Currently, hardware VQs are created right when the vdpa device gets into
DRIVER_OK state. That is easier because most of the VQ state is known by
then.
This patch switches to creating all VQs and their associated resources
at device creation time. The motivation is to reduce the vdpa device
live m
There are a few more places modifying the VQ to Ready directly. Let's
consolidate them into resume_vq().
The redundant warnings for resume_vq() errors can also be dropped.
There is one special case that needs to be handled for virtio-vdpa:
the initialized flag must be set to true earlier in setup
There are a few conditions under which the hardware VQs need a full
teardown and setup:
- VQ size changed to something else than default value. Hardware VQ size
modification is not supported.
- User turns off certain device features: mergeable buffers, checksum
virtio 1.0 compliance. In these
Start using the suspend/resume_vq() error return codes previously added.
Reviewed-by: Cosmin Ratiu
Reviewed-by: Zhu Yanjun
Reviewed-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --
VQ indices in the range [cur_num_qps, max_vqs) represent queues that
have not yet been activated. .set_vq_ready should not activate these
VQs.
Reviewed-by: Cosmin Ratiu
Acked-by: Eugenio Pérez
Signed-off-by: Dragos Tatulea
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 3 +++
1 file changed, 3 insert
Resume a VQ if it is already created when the number of VQ pairs
increases. This is done in preparation for VQ pre-creation which is
coming in a later patch. It is necessary because calling setup_vq() on
an already created VQ will return early and will not enable the queue.
For symmetry, suspend a
The vdpa device can be reset many times in sequence without any
significant state changes in between. Previously this was not a problem:
VQs were torn down only on first reset. But after VQ pre-creation was
introduced, each reset will delete and re-create the hardware VQs and
their associated resou
On Wed, Jul 03, 2024 at 11:36:00PM +, Tim Merrifield wrote:
> Add a new prctl option to enable/disable user-level hypercalls when
> running in a confidential VM. Add support for checking this flag on
> VMCALL #VE for TDX and transfer control to a hypervisor
> vendor-specific handler.
>
> Signe
On Wed, Jul 03, 2024 at 11:36:01PM +, Tim Merrifield wrote:
> @@ -539,6 +547,24 @@ unsigned long vmware_tdx_hypercall(unsigned long cmd,
> return args.r12;
> }
> EXPORT_SYMBOL_GPL(vmware_tdx_hypercall);
> +
> +static bool vmware_tdx_user_hcall(struct pt_regs *regs)
> +{
> + struct t
Thanks!
Acked-by: Dan Carpenter
regards,
dan carpenter
On Fri, Jul 05, 2024 at 09:33:55AM +0200, Arnaud POULIQUEN wrote:
>
>
> On 7/4/24 17:32, Mathieu Poirier wrote:
> > On Thu, Jul 04, 2024 at 10:05:24AM +0200, Arnaud POULIQUEN wrote:
> >>
> >>
> >> On 7/3/24 17:14, Mathieu Poirier wrote:
> >>> On Wed, Jul 03, 2024 at 09:19:44AM +0200, Arnaud POULI
On Wed, Jul 03, 2024 at 11:05:59AM +0200, AngeloGioacchino Del Regno wrote:
> Il 03/07/24 05:44, Jason Chen ha scritto:
> > The current DRAM size is insufficient for the HEVC feature, which
> > requires more memory for proper functionality. This change ensures the
> > feature has the necessary reso
在 2024/6/17 17:07, Dragos Tatulea 写道:
Currently, hardware VQs are created right when the vdpa device gets into
DRIVER_OK state. That is easier because most of the VQ state is known by
then.
This patch switches to creating all VQs and their associated resources
at device creation time. The motiva
Hi Zhu Yanjun,
On Mon, 2024-07-08 at 18:22 +0200, Zhu Yanjun wrote:
> 在 2024/6/17 17:07, Dragos Tatulea 写道:
> > Currently, hardware VQs are created right when the vdpa device gets into
> > DRIVER_OK state. That is easier because most of the VQ state is known by
> > then.
> >
> > This patch switch
On Fri, 28 Jun 2024 19:40:55 +0200, Luca Weiss wrote:
> I'm slowly migrating my mail to a new domain, add an entry to map the
> mail address. Just for clarity, my work-related @fairphone.com email
> stays unchanged.
>
>
Applied, thanks!
[1/1] mailmap: Update Luca Weiss's email address
c
On Thu, Jul 4, 2024 at 8:44 AM Paul E. McKenney wrote:
>
> On Thu, Jul 04, 2024 at 11:15:59AM +0200, Peter Zijlstra wrote:
> > On Wed, Jul 03, 2024 at 02:33:06PM -0700, Andrii Nakryiko wrote:
> >
> > > 2. More tactically, RCU protection seems like the best way forward. We
> > > got hung up on SRCU
On Thu, Jul 4, 2024 at 2:16 AM Peter Zijlstra wrote:
>
> On Wed, Jul 03, 2024 at 02:33:06PM -0700, Andrii Nakryiko wrote:
>
> > 2. More tactically, RCU protection seems like the best way forward. We
> > got hung up on SRCU vs RCU Tasks Trace. Thanks to Paul, we also
> > clarified that RCU Tasks Tr
On Mon, Jul 08, 2024 at 02:55:49PM +0800, Cindy Lu wrote:
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vn
On Thu, Jul 04, 2024 at 11:02:18AM +0200, Petr Mladek wrote:
> On Wed 2024-07-03 08:30:33, Luis Chamberlain wrote:
> > On Tue, Jul 02, 2024 at 10:56:41PM -0700, Josh Poimboeuf wrote:
> > > On Mon, Jul 01, 2024 at 03:13:23PM +0200, Petr Mladek wrote:
> > > > So, you suggest to search the symbols by
On Fri, Jul 05, 2024 at 11:15:11AM +, Andreas Hindborg wrote:
> From: Andreas Hindborg
>
> This patch includes changes required for Rust kernel modules to utilize
> module parameters. This code implements read only support for integer
> types without `sysfs` support.
>
> This code is a reduc
When tracing user functions with uprobe functionality, it's common to
install the probe (e.g., a BPF program) at the first instruction of the
function. This is often going to be `push %rbp` instruction in function
preamble, which means that within that function frame pointer hasn't
been established
From: Masami Hiramatsu (Google)
Currently, kprobe event checks whether the target symbol name is unique
or not, so that it does not put a probe on an unexpected place. But this
skips the check if the target is on a module because the module may not
be loaded.
To fix this issue, this patch checks
On Mon, Jul 8, 2024 at 2:33 PM Luis Chamberlain wrote:
>
> Looking at this again its not to me why Masahiro Yamada's suggestion on
> that old patch series to just increase the length and put long symbols
> names into its own section [0] could not be embraced with a new kconfig
> option, so new ker
On 2024/7/8 下午5:47, Huacai Chen wrote:
On Mon, Jul 8, 2024 at 9:16 AM maobibo wrote:
On 2024/7/6 下午5:41, Huacai Chen wrote:
On Sat, Jul 6, 2024 at 2:59 PM maobibo wrote:
Huacai,
On 2024/7/6 上午11:00, Huacai Chen wrote:
Hi, Bibo,
On Fri, May 24, 2024 at 3:38 PM Bibo Mao wrote:
Ste
On Mon, Jul 8, 2024 at 4:15 PM Stefano Garzarella wrote:
>
> Hi Cindy, Jason,
>
> On Mon, Jul 08, 2024 at 03:59:34PM GMT, Jason Wang wrote:
> >On Mon, Jul 8, 2024 at 3:06 PM Cindy Lu wrote:
> >>
> >> On Fri, 5 Jul 2024 at 20:42, Stefano Garzarella
> >> wrote:
> >> >
> >> > On Fri, Jul 05, 2024
Hi Cindy,
> From: Cindy Lu
> Sent: Monday, July 8, 2024 12:17 PM
>
> Add support for setting the MAC address using the VDPA tool.
> This feature will allow setting the MAC address using the VDPA tool.
> For example, in vdpa_sim_net, the implementation sets the MAC address to
> the config space.
Hi Andrew,
> From: Andrew Lunn
> Sent: Tuesday, July 9, 2024 12:31 AM
> To: Cindy Lu
> Cc: Dragos Tatulea ; m...@redhat.com;
> jasow...@redhat.com; Parav Pandit ;
> sgarz...@redhat.com; net...@vger.kernel.org; virtualization@lists.linux-
> foundation.org; linux-kernel@vger.kernel.org; k...@vger.
On 2024-07-08 at 12:25:49, Cindy Lu (l...@redhat.com) wrote:
> +static int mlx5_vdpa_set_attr_mac(struct vdpa_mgmt_dev *v_mdev,
> + struct vdpa_device *dev,
> + const struct vdpa_dev_set_config *add_config)
> +{
> + struct mlx5_vdpa_de
Hi Luis,
On Monday, July 8th, 2024 at 23:42, Luis Chamberlain wrote:
> I'm starting to feel the same way about modules, but modules requires
> more work than the firmware loader. And since I also know Andreas has
> already a lot on his plate, I'm at a cross roads. My above request for
> the firm
On Tue, 9 Jul 2024 at 11:59, Parav Pandit wrote:
>
> Hi Cindy,
>
> > From: Cindy Lu
> > Sent: Monday, July 8, 2024 12:17 PM
> >
> > Add support for setting the MAC address using the VDPA tool.
> > This feature will allow setting the MAC address using the VDPA tool.
> > For example, in vdpa_sim_ne
On 6/26/2024 13:18, Borislav Petkov wrote:
> On Wed, Jun 26, 2024 at 12:24:20PM -0500, Naik, Avadhut wrote:
>>
>>
>> On 6/26/2024 06:10, Borislav Petkov wrote:
>>> On Tue, Jun 25, 2024 at 02:56:22PM -0500, Avadhut Naik wrote:
AMD's Scalable MCA systems viz. Genoa will include two new regist
On 6/26/2024 13:20, Borislav Petkov wrote:
> On Wed, Jun 26, 2024 at 01:00:30PM -0500, Naik, Avadhut wrote:
>>>
>>> Why are you clearing it if you're overwriting it immediately?
>>>
>> Since its a local variable, wanted to ensure that the memory is zeroed out
>> to prevent
>> any issues with th
Add modem support to SDX75 using the PAS remoteproc driver.
Also, add qlink_logging memory region and split MPSS DSM
region into 2 separate regions.
These patches were co-authored by Rohit Agarwal while at
Qualcomm.
Changes in v4:
- Updated commit message for reserved memory updation for mpss to
Document the MPSS Peripheral Authentication Service on SDX75 platform.
Signed-off-by: Naina Mehta
Reviewed-by: Krzysztof Kozlowski
---
.../devicetree/bindings/remoteproc/qcom,sm8550-pas.yaml| 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/remotepr
Add MPSS Peripheral Authentication Service support for SDX75 platform.
Signed-off-by: Naina Mehta
---
drivers/remoteproc/qcom_q6v5_pas.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/remoteproc/qcom_q6v5_pas.c
b/drivers/remoteproc/qcom_q6v5_pas.c
index 8458bcfe9e19..833e2f9c2c5e 1
Add MPSS remoteproc node for SDX75 SoC.
Signed-off-by: Naina Mehta
Reviewed-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdx75.dtsi | 47 +
1 file changed, 47 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdx75.dtsi
b/arch/arm64/boot/dts/qcom/sdx75.dtsi
Enable MPSS remoteproc node on sdx75-idp platform.
Signed-off-by: Naina Mehta
Reviewed-by: Dmitry Baryshkov
---
arch/arm64/boot/dts/qcom/sdx75-idp.dts | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdx75-idp.dts
b/arch/arm64/boot/dts/qcom/sdx75-idp.dts
index
Rename qdss@8880 memory region as qlink_logging memory region
and add qdss_mem memory region at address of 0x8850,
qlink_logging is being added at the memory region at the address
of 0x8880 as the region is being used by modem firmware.
Since different DSM region size is required for di
Hello,
On Sat, Jul 06, 2024 at 12:15:01AM -0300, Ágatha Isabelle Chris Moreira Guedes
wrote:
> Fix the absence of warning message and kernel tainting when initializing
> drivers from the `drivers/staging` subtree from initcalls (when
> configured as built-in).
>
> When such a driver is built as
78 matches
Mail list logo
