> + struct virtio_net_config *vio_config = vdpasim->config;
> +
> + mutex_lock(>mutex);
> +
> + if (config->mask & (1 << VDPA_ATTR_DEV_NET_CFG_MACADDR)) {
> + memcpy(vio_config->mac, config->net.mac, ETH_ALEN);
ether_addr_copy()
Andrew
t; + .doit = vdpa_nl_cmd_dev_attr_set_doit,
> + .flags = GENL_ADMIN_PERM,
> + },
> };
>
> static struct genl_family vdpa_nl_family __ro_after_init = {
> diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
> index 7977ca03ac7a..3511156c10db 100644
> --- a/include/linux/vdpa.h
> +++ b/include/linux/vdpa.h
> @@ -582,11 +582,20 @@ void vdpa_set_status(struct vdpa_device *vdev, u8
> status);
> *@dev: vdpa device to remove
> *Driver need to remove the specified device by calling
> *_vdpa_unregister_device().
> + * @dev_set_attr: change a vdpa device's attr after it was create
> + *@mdev: parent device to use for device
The indentation looks a bit odd here.
Andrew
---
pw-bot: cr
- Address the comments
This history is to help reviewers of previous versions know if there
comments have been addressed. Just saying 'Address the comments' is
not useful. Please give a one line summary of each of the comment
which has been addressed, maybe including how it was addressed.
Andrew
>net.mac)) {
Is the core happy to call into the driver without validating the MAC
address? Will the core pass the broadcast address? That is not
zero. Or a multicast address? Should every driver repeat the same
validation, and probably get it just as wrong?
Andrew
---
pw-bot: cr
On 6/26/24 2:14 PM, Garrett Giordano wrote:
Driver was logging information as errors. Changed dev_err to dev_dbg
where appropriate.
Signed-off-by: Garrett Giordano
---
Acked-by: Andrew Davis
-v2
- Change from dev_info to dev_dbg
- Drop k3-r5 PATCH
---
drivers/remoteproc
ks like this function is called in a polling loop, if
ti_sci_proc_get_status() fails once, it won't get better,
no need to keep checking, we should just error out of
the polling loop.
Andrew
+}
+
/**
* k3_r5_rproc_mbox_callback() - inbound mailbox message handler
* @client: mailbox client point
On 6/26/24 9:39 AM, Dominic Rath wrote:
On 13.06.2024 14:22, Andrew Davis wrote:
We looked into this some time ago, and noticed that the IRQ approach caused
problems in the virtio/rpmsg code. I'd like to understand if your change was
for the same reason, or something else we missed before
On Fri, 21 Jun 2024 13:34:44 +0200 Ilya Leoshkevich wrote:
> v6 -> v7: Drop the ptdump patch.
> All patches are reviewed.
I added v7 to mm.git (and hence linux-next).
On 6/21/24 6:14 AM, Beleswar Prasad Padhi wrote:
Hi Andrew,
On 04/06/24 22:40, Andrew Davis wrote:
On 6/4/24 12:17 AM, Beleswar Padhi wrote:
Acquire the mailbox handle during device probe and do not release handle
in stop/detach routine or error paths. This removes the redundant
requests
On 6/18/24 12:05 PM, Mathieu Poirier wrote:
Good morning,
On Mon, Jun 10, 2024 at 01:06:09PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand
On Thu, 13 Jun 2024 16:10:12 -0400 Steven Rostedt wrote:
> > And... I'm a bit surprised that forward declarations are allowed in C.
> > A billion years ago I used a C compiler which would use 16 bits for
> > an enum if the enumted values would fit in 16 bits. And it would use 32
> > bits
On Thu, 13 Jun 2024 15:34:02 -0400 Steven Rostedt wrote:
> On Thu, 13 Jun 2024 22:22:18 +0300
> Alexey Dobriyan wrote:
>
> > g++ doesn't like forward enum declarations:
> >
> > error: use of enum ‘E’ without previous declaration
> >64 | enum E;
>
> But we don't care about g++. Do
On 6/13/24 2:58 AM, Dominic Rath wrote:
Hello Andrew,
On 10.04.2024 15:59, Andrew Davis wrote:
Changes for v2:
- Use threaded irq as suggested by Hari and to
fix possible "scheduling while atomic" issue
sorry for beeing late, I noticed this already got merged.
I was wond
-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 760 +++
3 files changed, 774 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff
by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-sk.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-sk.dts
b/arch/arm64/boot/dts/ti/k3-am642-sk.dts
index
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am642-evm.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am642-evm.dts
b/arch/arm64/boot/dts/ti/k3-am642-evm.dts
index
as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am64-mcu.dtsi
b/arch
by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk
be found the
the AM62 TRM in the section on the same:
AM62x Technical Reference Manual (SPRUIV7A – MAY 2022)
https://www.ti.com/lit/pdf/SPRUIV7A
Thanks,
Andrew
[0]
https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/
Changes for v10:
- Rebased on v6.10-rc3
- Added
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Reviewed-by: Conor Dooley
---
.../bindings/remoteproc/ti,k3-m4f
as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 20
1 file changed, 8 insertions
Use the device lifecycle managed allocation function. This helps prevent
mistakes like freeing out of order in cleanup functions and forgetting to
free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 15 ++-
1 file changed, 6 insertions(+), 9
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/drivers/remoteproc
This helps prevent mistakes like freeing out of order in cleanup functions
and forgetting to free on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 29 +--
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/da8xx_remoteproc.c | 21 +
1 file changed, 1 insertion
Use the device lifecycle managed add function. This helps prevent mistakes
like deleting out of order in cleanup functions and forgetting to delete
on error paths.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions
ttach(struct rproc *rproc) { return 0; }
I wonder if rproc_validate() should be updated to allow not
having an attach/detach for cases like this. Then we could drop
this function completely.
Andrew
/*
* Detach from a running R5F remote processor (IPC-only mode)
*
- * The R5
roc = rproc;
core->rproc = rproc;
+ ret = k3_r5_rproc_request_mbox(rproc);
Now that we get the channel here in init you'll want to add a matching
mbox_free_channel() call to k3_r5_cluster_rproc_exit().
Andrew
+ if (ret)
+ return ret;
+
ret = k3_r5_rproc_configure_mode(kproc);
if (ret < 0)
goto err_config;
On 5/9/24 10:32 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 10:54, Andrew Davis wrote:
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core
On 5/9/24 10:22 AM, Mathieu Poirier wrote:
On Wed, 8 May 2024 at 09:36, Andrew Davis wrote:
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done
On 5/7/24 3:36 PM, Mathieu Poirier wrote:
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
The AM62x and AM64x SoCs of the TI K3 family has a Cortex M4F core in
the MCU domain. This core is typically used for safety applications in a
stand alone mode. However
On 5/6/24 3:46 PM, Mathieu Poirier wrote:
Good day,
I have started reviewing this patchset. Comments will be scattered over
multiple days and as such, I will explicitly inform you when am done with the
review.
On Fri, Apr 26, 2024 at 02:18:08PM -0500, Andrew Davis wrote:
From: Martyn Welch
-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff
be found the
the AM62 TRM in the section on the same:
AM62x Technical Reference Manual (SPRUIV7A – MAY 2022)
https://www.ti.com/lit/pdf/SPRUIV7A
Thanks,
Andrew
[0]
https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/
Changes for v9:
- Fixed reserved-memory.yaml text
as this node is not complete until mailbox data
is provided in the board level DT.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi
b/arch
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
Reviewed-by: Conor Dooley
---
.../bindings/remoteproc/ti,k3-m4f
by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi
b/arch/arm64/boot/dts/ti/k3-am62x-sk
On 4/25/24 12:15 PM, Conor Dooley wrote:
On Wed, Apr 24, 2024 at 03:36:39PM -0500, Rob Herring wrote:
On Wed, 24 Apr 2024 14:06:09 -0500, Andrew Davis wrote:
From: Hari Nagalla
K3 AM64x SoC has a Cortex M4F subsystem in the MCU voltage domain.
The remote processor's life cycle management
-off-by: Andrew Davis
---
drivers/remoteproc/Kconfig | 13 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/ti_k3_m4_remoteproc.c | 785 +++
3 files changed, 799 insertions(+)
create mode 100644 drivers/remoteproc/ti_k3_m4_remoteproc.c
diff
by the firmware to be set-aside.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/boot/dts/ti/k3-am62-mcu.dtsi| 12
arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 18 ++
2 files changed, 30 insertions(+)
diff --git a/arch/arm64/boot/dts/ti
be found the
the AM62 TRM in the section on the same:
AM62x Technical Reference Manual (SPRUIV7A – MAY 2022)
https://www.ti.com/lit/pdf/SPRUIV7A
Thanks,
Andrew
[0]
https://lore.kernel.org/linux-arm-kernel/20240202175538.1705-5-hnaga...@ti.com/T/
Hari Nagalla (3):
dt-bindings: remoteproc: k3-m4f
From: Hari Nagalla
Some K3 platform devices (AM64x, AM62x) have a Cortex M4 core. Build
the M4 remote proc driver as a module for these platforms.
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch
and starting the M4F subsystems.
The YAML binding document provides the various node properties to be
configured by the consumers of the M4F subsystem.
Signed-off-by: Martyn Welch
Signed-off-by: Hari Nagalla
Signed-off-by: Andrew Davis
---
.../bindings/remoteproc/ti,k3-m4f-rproc.yaml | 126
On Thu, 11 Apr 2024 17:40:02 +0200 Michal Koutný wrote:
> Hello.
>
> On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton
> wrote:
> > That seems like a large change.
>
> In what sense is it large?
A large increase in the maximum number of processes. Or did I misinterpret?
On Fri, 5 Apr 2024 07:58:11 -0400 Paolo Bonzini wrote:
> Please review! Also feel free to take the KVM patches through the mm
> tree, as I don't expect any conflicts.
It's mainly a KVM thing and the MM changes are small and simple.
I'd say that the KVM tree would be a better home?
The mbox_controller struct is only needed in the probe function. Make
it a local variable instead of storing a copy in omap_mbox_device
to simplify that struct.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 21 -
1 file changed, 12 insertions(+), 9
ply dereference con_priv directly and remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e42266cb31a5..8e2760d2c5
the last couple users of the same in this driver.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 167348fb1b33b..4c673cb732ed1 100644
. The current mailbox framework expects
mbox_chan_received_data() to be called with data immediately as it
arrives. Remove the FIFO and pass the messages to the mailbox
framework directly as part of a threaded IRQ handler.
Signed-off-by: Andrew Davis
---
drivers/mailbox/Kconfig| 9 ---
drivers
-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 +-
1 file changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 97f59d9f9f319..8e42266cb31a5 100644
--- a/drivers/mailbox/omap
This is only used internal to the driver, move it out of the
public header and into the driver file. While we are here,
this is not used as a bitwise, so drop that and make it a
simple enum type.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 5 +
include/linux/omap
-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e2760d2c5b0c..c5d4083125856 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b
in probe.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 119 +
1 file changed, 46 insertions(+), 73 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 4f956c7b4072c..17c9b9df78b1d 100644
--- a/drivers
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap
some point, but that is not the case anymore, nor does it matter
for the upstream tree.
Remove this device class and related functions and variables.
This also allows us to switch to module_platform_driver() as
there is nothing left to do in module_init().
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mail
The mbox_kfifo_size can be changed at runtime, the sanity
check on it's value should be done when it is used, not
only once at init time.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox
These function are not used, remove these here.
While here, remove the leading _ from the driver internal functions that
do the same thing as the functions removed.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 --
include/linux/omap
Hello all,
Core of this series is the last patch removing the message FIFO
from OMAP mailbox. This hurts our real-time performance. It was a
legacy leftover from before the common mailbox framework anyway.
The rest of the patches are cleanups found along the way.
Thanks,
Andrew
Changes for v2
This function is not used, remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 36 --
include/linux/omap-mailbox.h | 6 --
2 files changed, 42 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox
On Tue, 9 Apr 2024 12:00:06 -0700 "Ho-Ren (Jack) Chuang"
wrote:
> Hi Jonathan,
>
> On Fri, Apr 5, 2024 at 6:56 AM Jonathan Cameron
> wrote:
> >
> > On Fri, 5 Apr 2024 00:07:05 +
> > "Ho-Ren (Jack) Chuang" wrote:
> >
> > > Since different memory devices require finding, allocating, and
On Mon, 8 Apr 2024 16:58:18 +0200 Michal Koutný wrote:
> The kernel provides mechanisms, while it should not imply policies --
> default pid_max seems to be an example of the policy that does not fit
> all. At the same time pid_max must have some value assigned, so use the
> end of the allowed
On Tue, 02 Apr 2024 00:24:28 -0600 Vishal Verma
wrote:
> In [1], Dan points out that all of the WARN_ON_ONCE() usage in the
> referenced patch should be replaced with lockdep_assert_held(_write)().
>
> Replace those, and additionally, replace a couple of other
> WARN_ON_ONCE() introduced in
On 4/1/24 6:39 PM, Hari Nagalla wrote:
On 3/25/24 12:20, Andrew Davis wrote:
The kernel FIFO queue has a couple issues. The biggest issue is that
it causes extra latency in a path that can be used in real-time tasks,
such as communication with real-time remote processors.
The whole FIFO idea
On 4/1/24 6:31 PM, Hari Nagalla wrote:
On 3/25/24 12:20, Andrew Davis wrote:
static int omap_mbox_chan_send_noirq(struct omap_mbox *mbox, u32 msg)
{
- int ret = -EBUSY;
+ if (mbox_fifo_full(mbox))
+ return -EBUSY;
- if (!mbox_fifo_full(mbox)) {
- omap_mbox_enable_irq
On 3/28/24 10:28 AM, Mathieu Poirier wrote:
Hi Andrew,
On Mon, Mar 25, 2024 at 11:58:06AM -0500, Andrew Davis wrote:
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs
Thanks, I'll look into it.
On Thu, Mar 28, 2024 at 6:03 AM Jason Wang wrote:
>
> On Thu, Mar 28, 2024 at 7:44 AM 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
res() with
VHOST_NET_F_VIRTIO_NET_HDR, also it's set to zero at device open()
and reset() routine.
So, currently, to trigger the issue, we need to set up qemu with
vhost=on,vnet_hdr=off, or do not configure vhost in the custom program.
Signed-off-by: Andrew Melnychenko
---
drivers/vhost/net.c | 3 +++
1 file changed
the last couple users of the same in this driver.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 167348fb1b33b..4c673cb732ed1 100644
This is only used internal to the driver, move it out of the
public header and into the driver file. While we are here,
this is not used as a bitwise, so drop that and make it a
simple enum type.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 5 +
include/linux/omap
The mbox_controller struct is only needed in the probe function. Make
it a local variable instead of storing a copy in omap_mbox_device
to simplify that struct.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 21 -
1 file changed, 12 insertions(+), 9
-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 +-
1 file changed, 11 insertions(+), 31 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 97f59d9f9f319..8e42266cb31a5 100644
--- a/drivers/mailbox/omap
-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 33 -
1 file changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e2760d2c5b0c..c5d4083125856 100644
--- a/drivers/mailbox/omap-mailbox.c
+++ b
Hello all,
Core of this series is the last patch removing the message FIFO
from OMAP mailbox. This hurts our real-time performance. It was a
legacy leftover from before the common mailbox framework anyway.
The rest of the patches are cleanups found along the way.
Thanks,
Andrew
Andrew Davis
. The current mailbox framework expects
mbox_chan_received_data() to be called with data immediately as it
arrives. Remove the FIFO and pass the messages to the mailbox
framework directly.
Signed-off-by: Andrew Davis
---
drivers/mailbox/Kconfig| 9 ---
drivers/mailbox/omap-mailbox.c | 103
ply dereference con_priv directly and remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 8e42266cb31a5..8e2760d2c5
These function are not used, remove these here.
While here, remove the leading _ from the driver internal functions that
do the same thing as the functions removed.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 42 --
include/linux/omap
in probe.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 119 +
1 file changed, 46 insertions(+), 73 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap-mailbox.c
index 4f956c7b4072c..17c9b9df78b1d 100644
--- a/drivers
some point, but that is not the case anymore, nor does it matter
for the upstream tree.
Remove this device class and related functions and variables.
This also allows us to switch to module_platform_driver() as
there is nothing left to do in module_init().
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mail
Use device life-cycle managed runtime enable function to simplify probe
and exit paths.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox/omap
The mbox_kfifo_size can be changed at runtime, the sanity
check on it's value should be done when it is used, not
only once at init time.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mailbox
This function is not used, remove this function.
Signed-off-by: Andrew Davis
---
drivers/mailbox/omap-mailbox.c | 36 --
include/linux/omap-mailbox.h | 6 --
2 files changed, 42 deletions(-)
diff --git a/drivers/mailbox/omap-mailbox.c b/drivers/mailbox
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Use u32 unconditionally and remove
the now unneeded omap-mailbox.h include.
Signed-off-by: Andrew Davis
This header no longer used, remove this include.
Signed-off-by: Andrew Davis
---
drivers/remoteproc/omap_remoteproc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/remoteproc/omap_remoteproc.c
b/drivers/remoteproc/omap_remoteproc.c
index 8f50ab80e56f4..bde04e3e6d966 100644
The type of message sent using omap-mailbox is always u32. The definition
of mbox_msg_t is uintptr_t which is wrong as that type changes based on
the architecture (32bit vs 64bit). Use u32 unconditionally and remove
the now unneeded omap-mailbox.h include.
Signed-off-by: Andrew Davis
> subsystem.
Maybe deliberately throw away all the sub-second accuracy when
accessing the time via the RTC API? That helps to make it look like an
RTC. And when doing the rounding, add a constant offset of 10ms to
emulate the virtual i2c bus it is hanging off, like most RTCs?
Andrew
On Tue, 12 Mar 2024 20:20:17 + "Verma, Vishal L"
wrote:
> > All of these WARN_ON_ONCE() usages should be replaced with
> > lockdep_assert_held() and lockdep_assert_held_write() where appropriate.
>
> Makes sense - I can send a patch post -rc1 to change th
8: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 unpredict
On Mon, 19 Feb 2024 02:35:20 -0500 "Michael S. Tsirkin" wrote:
> On Sun, Feb 18, 2024 at 09:06:18PM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:d37e1e4c52bc Add linux-next specific files for 20240216
> > git tree: linux-next
> >
On Sat, 17 Feb 2024 16:18:10 +0800 Changbin Du wrote:
> The synchronization here is just to ensure the module init's been freed
> before doing W+X checking. But the commit 1a7b7d922081 ("modules: Use
> vmalloc special flag") moves do_free_init() into a global workqueue
> instead of call_rcu().
symbol names at build time to completely remove
symbol_get() from module.h? Correct me if I'm wrong since using of a
fuction which is not declared anywhere sounds confusing.
--
Andrew Kanner
now return right after registering our hwspinlock,
simply return directly and remove the extra debug message.
Signed-off-by: Andrew Davis
---
Changes for v2:
- Return directly from register as suggested on v1
- Clarify commit message
drivers/hwspinlock/omap_hwspinlock.c | 33
This will unregister the HW spinlock on module exit automatically for us,
currently we manually unregister which can be error-prone if not done in
the right order. This also allows us to remove the remove callback.
Do that here.
Signed-off-by: Andrew Davis
---
Changes for v2:
- Clarify commit
We do not use the OF node anymore, nor does it matter how
we got to probe, so remove the check for of_node.
Signed-off-by: Andrew Davis
---
drivers/hwspinlock/omap_hwspinlock.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock
For loops with multiple initializers and increments are hard to read
and reason about, simplify this by using the looping index to index
into the hwspinlock array.
Signed-off-by: Andrew Davis
---
drivers/hwspinlock/omap_hwspinlock.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions
On 2/6/24 1:06 PM, Bjorn Andersson wrote:
On Tue, Jan 23, 2024 at 10:04:03AM -0600, Andrew Davis wrote:
This disables runtime PM on module exit, allowing us to simplify
the probe exit path and remove callbacks. Do that here.
As with the later patch, unless I'm misreading the code, you already
sp_remoteproc.c when you only factored out
a couple functions to a different file.
Build up the new ti_k3_common.c one function per patch if it helps.
And factor the functions out of ti_k3_r5 also as it seems many
of these are common to that driver too.
Andrew
link to v6:
https:/
subject.. Maybe
no one will notice this is all still dead code since you didn't say the
word 'split' anymore..
Andrew
link to v6:
https://lore.kernel.org/all/20230913111644.29889-3-hnaga...@ti.com/
drivers/remoteproc/ti_k3_common.h | 107 ++
1 file changed, 107
1 - 100 of 40842 matches
Mail list logo