11 Mar, 2024
1 commit
-
This is the 6.6.20 stable release
* tag 'v6.6.20': (3154 commits)
Linux 6.6.20
fs/ntfs3: fix build without CONFIG_NTFS3_LZX_XPRESS
Linux 6.6.19
...Signed-off-by: Jason Liu
Conflicts:
arch/arm64/boot/dts/freescale/imx8mm.dtsi
arch/arm64/boot/dts/freescale/imx8mq.dtsi
drivers/clk/imx/clk-imx8qxp.c
drivers/dma/fsl-edma.c
drivers/firmware/arm_scmi/perf.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-switch.c
drivers/net/ethernet/freescale/fec_main.c
drivers/scsi/scsi_error.c
drivers/spi/spi-imx.c
sound/soc/fsl/fsl_sai.c
01 Feb, 2024
1 commit
-
commit d5362c37e1f8a40096452fc201c30e705750e687 upstream.
Free driver_override when rpmsg_remove(), otherwise
the following memory leak will occur:unreferenced object 0xffff0000d55d7080 (size 128):
comm "kworker/u8:2", pid 56, jiffies 4294893188 (age 214.272s)
hex dump (first 32 bytes):
72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00 rpmsg_ns........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[] __kmem_cache_alloc_node+0x1f8/0x320
[] __kmalloc_node_track_caller+0x44/0x70
[] kstrndup+0x4c/0x90
[] driver_set_override+0xd0/0x164
[] rpmsg_register_device_override+0x98/0x170
[] rpmsg_ns_register_device+0x24/0x30
[] rpmsg_probe+0x2e0/0x3ec
[] virtio_dev_probe+0x1c0/0x280
[] really_probe+0xbc/0x2dc
[] __driver_probe_device+0x78/0xe0
[] driver_probe_device+0xd8/0x160
[] __device_attach_driver+0xb8/0x140
[] bus_for_each_drv+0x7c/0xd4
[] __device_attach+0x9c/0x19c
[] device_initial_probe+0x14/0x20
[] bus_probe_device+0xa0/0xacSigned-off-by: Xiaolei Wang
Fixes: b0b03b811963 ("rpmsg: Release rpmsg devices in backends")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20231215020049.78750-1-xiaolei.wang@windriver.com
Signed-off-by: Mathieu Poirier
Signed-off-by: Greg Kroah-Hartman
30 Oct, 2023
5 commits
-
Currently, after the rpmsg link up it will use mailbox
channel in blocking mode to send the notifications. So
it will be stuck in the notification when the remote side
unable to respond for some reason, such as crashed.To avoid interlock, this patch changes the notifying to
timeout mode, and treats the virtqueue as broken when
the remote side doesn't respond within 1 second.Signed-off-by: Hou Zhiqiang
-
Add the rpmsg tty demo for iMX AMP platforms.
Use the "echo > /dev/*RPMSG*", after insmod the module.Signed-off-by: Richard Zhu
Acked-by: Fugang Duan
Signed-off-by: Li Yang
Signed-off-by: Sherry Sun
[ Aisheng: cope with tty_operations::write() change ]
Signed-off-by: Dong Aisheng -
- Enable the tx_block mechanism to make sure that every transmission is
complete when mailbox is used.
- Refine the data exchange in the rpmsg_rx_callback and some info
messages and codes comments.Signed-off-by: Robin Gong
Signed-off-by: Richard Zhu -
Add partition reset notify if m4 reset so that rpmsg channel
could re-create again while m4 come back.Signed-off-by: Robin Gong
-
Based on "virtio_rpmsg_bus" driver, This patch-set is used to set up
the communication mechanism between A core and M core on i.MX AMP SOCs.Add the initial imx rpmsg support glue driver and one pingpong demo,
demonstrated the data transactions between A core and remote M core.
Distributed framework is used in IMX RPMSG implementation, refer to the
following requirements:
- The CAN functions contained in M core and RTOS should be ready and
complete functional in 50ms after AMP system is turned on.
- Partition reset. System wouldn't be stalled by the exceptions (e.x
the reset triggered by the system hang) occurred at the other side.
And the RPMSG mechanism should be recovered automactilly after the
partition reset is completed.
In this scenario, the M core and RTOS would be kicked off by bootloader
firstly, then A core and Linux would be loaded later. Both M core/RTOS
and A core/Linux are running independly.One physical memory region used to store the vring is mandatory required
to pre-reserved and well-knowned by both A core and M coreSigned-off-by: Richard Zhu
05 Sep, 2023
1 commit
-
Pull rpmsg updates from Bjorn Andersson:
"Add support for the GLINK flow control signals, and expose this to the
user through the rpmsg_char interface. Add missing kstrdup() failure
handling during allocation of GLINK channel objects"* tag 'rpmsg-v6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux:
rpmsg: glink: Avoid dereferencing NULL channel
rpmsg: glink: Add check for kstrdup
rpmsg: char: Add RPMSG GET/SET FLOWCONTROL IOCTL support
rpmsg: glink: Add support to handle signals command
rpmsg: core: Add signal API support
19 Jul, 2023
1 commit
-
The newly introduced signal command handler checks for non-existing
channel and print an error message, but then continues on to dereference
that same channel.Instead abort the handler when no channel is found.
Fixes: a2b73aa512a4 ("rpmsg: glink: Add support to handle signals command")
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Closes: https://lore.kernel.org/r/202307160800.sb7gMnL6-lkp@intel.com/
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230717165538.1542034-1-quic_bjorande@quicinc.com
Signed-off-by: Mathieu Poirier
16 Jul, 2023
4 commits
-
Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.Fixes: b4f8e52b89f6 ("rpmsg: Introduce Qualcomm RPM glink driver")
Signed-off-by: Jiasheng Jiang
Link: https://lore.kernel.org/r/20230619030631.12361-1-jiasheng@iscas.ac.cn
Signed-off-by: Bjorn Andersson -
Add RPMSG_GET_OUTGOING_FLOWCONTROL and RPMSG_SET_INCOMING_FLOWCONTROL
IOCTL support for rpmsg char device nodes to get/set the low level
transport signals.Signed-off-by: Chris Lew
Signed-off-by: Deepak Kumar Singh
Signed-off-by: Sarannya S
Acked-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/1688679698-31274-4-git-send-email-quic_sarannya@quicinc.com
Signed-off-by: Bjorn Andersson -
Remote peripherals send signal notifications over glink with commandID 15.
Add support to send and receive the signal command and based signals
enable or disable flow control with remote host.Signed-off-by: Chris Lew
Signed-off-by: Deepak Kumar Singh
Signed-off-by: Sarannya S
Acked-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/1688679698-31274-3-git-send-email-quic_sarannya@quicinc.com
Signed-off-by: Bjorn Andersson -
Some transports like Glink support the state notifications between
clients using flow control signals similar to serial protocol signals.
Local glink client drivers can send and receive flow control status
to glink clients running on remote processors.Add APIs to support sending and receiving of flow control status by
rpmsg clients.Signed-off-by: Deepak Kumar Singh
Signed-off-by: Sarannya S
Acked-by: Arnaud Pouliquen
Link: https://lore.kernel.org/r/1688679698-31274-2-git-send-email-quic_sarannya@quicinc.com
Signed-off-by: Bjorn Andersson
14 Jul, 2023
1 commit
-
Rather than looking up a dummy item from SMEM, use the new
qcom_smem_is_available() function to make the code more clear
(and reduce the overhead slightly).Add the same check to qcom_smd_register_edge() as well to ensure that
it only succeeds if SMEM is already available - if a driver calls the
function and SMEM is not available yet then the initial state will be
read incorrectly and the RPMSG devices might never become available.Reviewed-by: Konrad Dybcio
Signed-off-by: Stephan Gerhold
Link: https://lore.kernel.org/r/20230531-rpm-rproc-v3-8-a07dcdefd918@gerhold.net
Signed-off-by: Bjorn Andersson
28 Apr, 2023
1 commit
-
Pull driver core updates from Greg KH:
"Here is the large set of driver core changes for 6.4-rc1.Once again, a busy development cycle, with lots of changes happening
in the driver core in the quest to be able to move "struct bus" and
"struct class" into read-only memory, a task now complete with these
changes.This will make the future rust interactions with the driver core more
"provably correct" as well as providing more obvious lifetime rules
for all busses and classes in the kernel.The changes required for this did touch many individual classes and
busses as many callbacks were changed to take const * parameters
instead. All of these changes have been submitted to the various
subsystem maintainers, giving them plenty of time to review, and most
of them actually did so.Other than those changes, included in here are a small set of other
things:- kobject logging improvements
- cacheinfo improvements and updates
- obligatory fw_devlink updates and fixes
- documentation updates
- device property cleanups and const * changes
- firwmare loader dependency fixes.
All of these have been in linux-next for a while with no reported
problems"* tag 'driver-core-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (120 commits)
device property: make device_property functions take const device *
driver core: update comments in device_rename()
driver core: Don't require dynamic_debug for initcall_debug probe timing
firmware_loader: rework crypto dependencies
firmware_loader: Strip off \n from customized path
zram: fix up permission for the hot_add sysfs file
cacheinfo: Add use_arch[|_cache]_info field/function
arch_topology: Remove early cacheinfo error message if -ENOENT
cacheinfo: Check cache properties are present in DT
cacheinfo: Check sib_leaf in cache_leaves_are_shared()
cacheinfo: Allow early level detection when DT/ACPI info is missing/broken
cacheinfo: Add arm64 early level initializer implementation
cacheinfo: Add arch specific early level initializer
tty: make tty_class a static const structure
driver core: class: remove struct class_interface * from callbacks
driver core: class: mark the struct class in struct class_interface constant
driver core: class: make class_register() take a const *
driver core: class: mark class_release() as taking a const *
driver core: remove incorrect comment for device_create*
MIPS: vpe-cmp: remove module owner pointer from struct class usage.
...
20 Apr, 2023
4 commits
-
Rather than duplicating most of the code for constructing the initial
TX_DATA and subsequent TX_DATA_CONT packets, roll them into a single
loop.Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230418163018.785524-3-quic_bjorande@quicinc.com -
As support for splitting transmission over several messages using
TX_DATA_CONT was introduced it does not immediately return the return
value of qcom_glink_tx().The result is that in the intentless case (i.e. intent == NULL), the
code will continue to send all additional chunks. This is wasteful, and
it's possible that the send operation could incorrectly indicate
success, if the last chunk fits in the TX fifo.Fix the condition.
Fixes: 8956927faed3 ("rpmsg: glink: Add TX_DATA_CONT command while sending")
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230418163018.785524-2-quic_bjorande@quicinc.com -
In some implementations of the remote firmware, an intent request
acknowledgment is sent when it's determined if the intent allocation
will be fulfilled, but then the intent is queued after the
acknowledgment.The result is that upon receiving a granted allocation request, the
search for the newly allocated intent will fail and an additional
request will be made. This will at best waste memory, but if the second
request is rejected the transaction will be incorrectly rejected.Take the incoming intent into account in the wait to mitigate this
problem.The above scenario can still happen, in the case that, on that same
channel, an unrelated intent is delivered prior to the request
acknowledgment and a separate process enters the send path and picks up
the intent. Given that there's no relationship between the
acknowledgment and the delivered (or to be delivered intent), there
doesn't seem to be a solution to this problem.Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
[bjorn: Fixed spelling issues pointed out by checkpatch in commit message]
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230327144617.3134175-3-quic_bjorande@quicinc.com -
Transition the intent request acknowledgement to use a wait queue so
that it's possible, in the next commit, to extend the wait to also wait
for an incoming intent.Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230327144617.3134175-2-quic_bjorande@quicinc.com
06 Apr, 2023
3 commits
-
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.qcom_smd_remove() always returned zero, though that isn't completely
trivial to see. So explain that in a comment and convert to
.remove_new().Signed-off-by: Uwe Kleine-König
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230321154039.355098-4-u.kleine-koenig@pengutronix.de -
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is (mostly) ignored
and this typically results in resource leaks. To improve here there is a
quest to make the remove callback return void. In the first step of this
quest all drivers are converted to .remove_new() which already returns
void.Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.Signed-off-by: Uwe Kleine-König
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230321154039.355098-3-u.kleine-koenig@pengutronix.de -
This function returned zero unconditionally. Convert it to return no
value instead. This makes it more obvious what happens in the callers.One caller is converted to return zero explicitly. The only other caller
(smd_subdev_stop() in drivers/remoteproc/qcom_common.c) already ignored
the return value before.Signed-off-by: Uwe Kleine-König
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230321154039.355098-2-u.kleine-koenig@pengutronix.de
17 Mar, 2023
1 commit
-
The module pointer in class_create() never actually did anything, and it
shouldn't have been requred to be set as a parameter even if it did
something. So just remove it and fix up all callers of the function in
the kernel tree at the same time.Cc: "Rafael J. Wysocki"
Acked-by: Benjamin Tissoires
Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
27 Feb, 2023
1 commit
-
Pull rpmsg updates from Bjorn Andersson:
- rpmsg ctrl and char driver locking is ensure ordering in cases where
the communication link is being torn down in parallel with calls to
open(2) or poll(2)- The glink driver is refactored, to move rpm/smem-specifics out of the
common logic and better suite further improvements, such as
transports without a mailbox controller. The handling of remoteproc
shutdown is improved, to fail clients immediately instead of having
them to wait for timeouts. A driver_override memory leak is corrected
and a few spelling improvements are introduced- glink_ssr is transitioned off strlcpy() and "gpr" is added as a valid
child node of the glink-edge DT binding* tag 'rpmsg-v6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/remoteproc/linux:
rpmsg: glink: Release driver_override
rpmsg: glink: Avoid infinite loop on intent for missing channel
rpmsg: glink: Fix GLINK command prefix
rpmsg: glink: Fix spelling of peek
rpmsg: glink: Cancel pending intent requests at removal
rpmsg: glink: Fail qcom_glink_tx() once remove has been initiated
rpmsg: glink: Move irq and mbox handling to transports
rpmsg: glink: rpm: Wrap driver context
rpmsg: glink: smem: Wrap driver context
rpmsg: glink: Extract tx kick operation
rpmsg: glink: Include types in qcom_glink_native.h
rpmsg: ctrl: Add lock to rpmsg_ctrldev_remove
rpmsg: char: Add lock to avoid race when rpmsg device is released
rpmsg: move from strlcpy with unused retval to strscpy
dt-bindings: remoteproc: qcom,glink-edge: add GPR node
15 Feb, 2023
10 commits
-
Upon termination of the rpmsg_device, driver_override needs to be freed
to avoid leaking the potentially assigned string.Fixes: 42cd402b8fd4 ("rpmsg: Fix kfree() of static memory on setting driver_override")
Fixes: 39e47767ec9b ("rpmsg: Add driver_override device attribute for rpmsg_device")
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230109223931.1706429-1-quic_bjorande@quicinc.com -
In the event that an intent advertisement arrives on an unknown channel
the fifo is not advanced, resulting in the same message being handled
over and over.Fixes: dacbb35e930f ("rpmsg: glink: Receive and store the remote intent buffers")
Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230214234231.2069751-1-quic_bjorande@quicinc.com -
The upstream GLINK driver was first introduced to communicate with the
RPM on MSM8996, presumably as an artifact from that era the command
defines was prefixed RPM_CMD, while they actually are GLINK_CMDs.Let's rename these, to keep things tidy. No functional change.
Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230214225933.2025595-1-quic_bjorande@quicinc.com -
The code is peeking into the buffers, not peaking. Fix this throughout
the glink drivers.Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230214224746.1996130-1-quic_bjorande@quicinc.com -
During removal of the glink edge interrupts are disabled and no more
incoming messages are being serviced. In addition to the remote endpoint
being defunct that means that any outstanding requests for intents will
not be serviced, and qcom_glink_request_intent() will blindly wait for
up to 10 seconds.Mark the intent request as not granted and complete the intent request
completion to fail the waiting client immediately.Once the current intent request is failed, any potential clients waiting
for the intent request mutex will not enter the same wait, as the
qcom_glink_tx() call will fail fast.Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230213155215.1237059-7-quic_bjorande@quicinc.com -
Upon removing the glink edge, communication is at best one-way. This
means that the very common scenario of glink requesting intents will not
be possible to serve.Typically a successful transmission results in the client waiting for a
response, with some timeout and a mechanism for aborting that timeout.Because of this, once the glink edge is defunct once removal is
commenced it's better to fail transmissions fast.Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230213155215.1237059-6-quic_bjorande@quicinc.com -
Not all GLINK transports uses an interrupt and a mailbox instance. The
interrupt for RPM needs to be IRQF_NOSUSPEND, while it seems reasonable
for the SMEM interrupt to use irq_set_wake. The glink struct device is
constructed in the SMEM and RPM drivers but torn down in the core
driver.Move the interrupt and kick handling into the SMEM and RPM driver, to
improve this and facilitate further improvements.Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230213155215.1237059-5-quic_bjorande@quicinc.com -
As with the SMEM driver update, wrap the RPM context in a struct to
facilitate the upcoming changes of moving IRQ and mailbox registration
to the driver.Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230213155215.1237059-4-quic_bjorande@quicinc.com -
The Glink SMEM driver allocates a struct device and hangs two
devres-allocated pipe objects thereon. To facilitate the move of
interrupt and mailbox handling to the driver, introduce a wrapper object
capturing the device, glink reference and remote processor id.The type of the remoteproc reference is updated, as these are
specifically targeting the SMEM implementation.Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230213155215.1237059-3-quic_bjorande@quicinc.com -
Refactor out the tx kick operations to its own function, in preparation
for pushing the details to the individual transports.Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230213155215.1237059-2-quic_bjorande@quicinc.com
27 Jan, 2023
1 commit
-
The uevent() callback in struct bus_type should not be modifying the
device that is passed into it, so mark it as a const * and propagate the
function signature changes out into all relevant subsystems that use
this callback.Acked-by: Rafael J. Wysocki
Acked-by: Hans de Goede
Link: https://lore.kernel.org/r/20230111113018.459199-16-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman
19 Jan, 2023
1 commit
-
Ensure that the used data types are available in qcom_glink_native.h, to
silence LSP warnings.Signed-off-by: Bjorn Andersson
Reviewed-by: Chris Lew
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20230109223745.1706152-1-quic_bjorande@quicinc.com
28 Dec, 2022
3 commits
-
Call to rpmsg_ctrldev_ioctl() and rpmsg_ctrldev_remove() must be synchronized.
In present code rpmsg_ctrldev_remove() is not protected with lock, therefore
new char device creation can succeed through rpmsg_ctrldev_ioctl() call. At the
same time call to rpmsg_ctrldev_remove() function for ctrl device removal will
free associated rpdev device. As char device creation already succeeded, user
space is free to issue open() call which maps to rpmsg_create_ept() in kernel.
rpmsg_create_ept() function tries to reference rpdev which has already been
freed through rpmsg_ctrldev_remove(). Issue is predominantly seen in aggressive
reboot tests where rpmsg_ctrldev_ioctl() and rpmsg_ctrldev_remove() can race with
each other.Adding lock in rpmsg_ctrldev_remove() avoids any new char device creation
through rpmsg_ctrldev_ioctl() while remove call is already in progress.Signed-off-by: Deepak Kumar Singh
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/1663584840-15762-3-git-send-email-quic_deesin@quicinc.com -
When remote host goes down glink char device channel is freed and
associated rpdev is destroyed through rpmsg_chrdev_eptdev_destroy(),
At the same time user space apps can still try to open/poll rpmsg
char device which will result in calling rpmsg_create_ept()/rpmsg_poll().
These functions will try to reference rpdev which has already been freed
through rpmsg_chrdev_eptdev_destroy().File operation functions and device removal function must be protected
with lock. This patch adds existing ept lock in remove function as well.Signed-off-by: Deepak Kumar Singh
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/1663584840-15762-2-git-send-email-quic_deesin@quicinc.com -
Follow the advice of the below link and prefer 'strscpy' in this
subsystem. Conversion is 1:1 because the return value is not used.
Generated by a coccinelle script.Link: https://lore.kernel.org/r/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Wolfram Sang
Signed-off-by: Bjorn Andersson
Link: https://lore.kernel.org/r/20220818210100.7277-1-wsa+renesas@sang-engineering.com
22 Sep, 2022
1 commit
-
The rpmsg_dev_remove() in rpmsg_core is the place for releasing
this default endpoint.So need to avoid destroying the default endpoint in
rpmsg_chrdev_eptdev_destroy(), this should be the same as
rpmsg_eptdev_release(). Otherwise there will be double destroy
issue that ept->refcount report warning:refcount_t: underflow; use-after-free.
Call trace:
refcount_warn_saturate+0xf8/0x150
virtio_rpmsg_destroy_ept+0xd4/0xec
rpmsg_dev_remove+0x60/0x70The issue can be reproduced by stopping remoteproc before
closing the /dev/rpmsgX.Fixes: bea9b79c2d10 ("rpmsg: char: Add possibility to use default endpoint of the rpmsg device")
Signed-off-by: Shengjiu Wang
Reviewed-by: Arnaud Pouliquen
Reviewed-by: Peng Fan
Cc: stable
Link: https://lore.kernel.org/r/1663725523-6514-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mathieu Poirier
