linux-stable.git/drivers/rpmsg, branch v6.5.4

rpmsg: glink: Add check for kstrdup

2023-09-13T07:53:46+00:00

[ Upstream commit b5c9ee8296a3760760c7b5d2e305f91412adc795 ]

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 
Signed-off-by: Sasha Levin

Merge tag 'driver-core-6.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2023-04-27T18:53:57+00:00

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.
  ...

rpmsg: glink: Consolidate TX_DATA and TX_DATA_CONT

2023-04-19T19:43:19+00:00

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

rpmsg: glink: Propagate TX failures in intentless mode as well

2023-04-19T19:43:19+00:00

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

rpmsg: glink: Wait for intent, not just request ack

2023-04-19T19:43:19+00:00

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

rpmsg: glink: Transition intent request signaling to wait queue

2023-04-19T19:43:17+00:00

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

rpmsg: qcom_smd: Convert to platform remove callback returning void

2023-04-06T03:58:32+00:00

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

rpmsg: qcom_glink_rpm: Convert to platform remove callback returning void

2023-04-06T03:58:32+00:00

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

rpmsg: qcom_smd: Make qcom_smd_unregister_edge() return void

2023-04-06T03:58:32+00:00

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

driver core: class: remove module * from class_create()

2023-03-17T14:16:33+00:00

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