BMC/Intel-BMC/linux.git/drivers/rpmsg/qcom_smd.c, branch dev-4.17

rpmsg: smd: do not use mananged resources for endpoints and channels

2018-07-03T09:27:03+00:00

commit 4a2e84c6ed85434ce7843e4844b4d3263f7e233b upstream. All the managed resources would be freed by the time release function is invoked. Handling such memory in qcom_smd_edge_release() would do bad things. Found this issue while testing Audio usecase where the dsp is started up and shutdown in a loop. This patch fixes this issue by using simple kzalloc for allocating channel->name and channel which is then freed in qcom_smd_edge_release(). Without this patch restarting a remoteproc would crash the system. Fixes: 53e2822e56c7 ("rpmsg: Introduce Qualcomm SMD backend") Cc: Signed-off-by: Srinivas Kandagatla Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

rpmsg: smd: Use announce_create to process any receive work

2018-03-28T04:54:37+00:00

It is possible that incoming data arrives before the client driver has reached a point in the probe method where adequate context for handling the incoming message has been established. In the event that the client's callback function returns an error the message will be left on the FIFO and by invoking the receive handler after the device has been probed the message will be picked off the FIFO and the callback invoked again. Signed-off-by: Bjorn Andersson

rpmsg: smd: Fix container_of macros

2018-03-28T04:54:35+00:00

The container_of macros should not use the same name for the parameter as the member to use for lookup, as this will result in a compilation error unless the passed parameter has the same name as the member. Signed-off-by: Bjorn Andersson

Revert "rpmsg: smd: Create device for all channels"

2018-03-27T19:58:16+00:00

In an effort to pick up channels that are in a funky state we optimistically tried to open all channels that we found, with the addition that we failed if the other side did not handshake the opening. But as we're starting the modem a second time all channels are found - in a "funky" state - and we try to open them. But the modem firmware requires the IPCRTR to be up in order to initialize. So any channels we try to open before that will fail and will not be opened again. This takes care of the regression, at the cost of reintroducing the previous behavior of handling of channels with "funky" states. Reverts commit c12fc4519f60 ("rpmsg: smd: Create device for all channels") Reported-by: Srinivas Kandagatla Signed-off-by: Bjorn Andersson

rpmsg: smd: Use spinlock in tx path

2018-03-20T02:52:17+00:00

By switching the tx_lock to a spinlock we allow clients to use rpmsg_trysend() from atomic context. The mutex was interruptable as it was previously held for the duration of some client waiting for available space in the FIFO, but this was recently changed to only be held temporarily - allowing us to replace it with a spinlock. Tested-by: Srinivas Kandagatla Signed-off-by: Bjorn Andersson

rpmsg: smd: use put_device() if device_register fail

2018-03-18T04:46:19+00:00

if device_register() returned an error! Always use put_device() to give up the reference initialized. unregister device for other return error. Signed-off-by: Arvind Yadav Signed-off-by: Bjorn Andersson

vfs: do bulk POLL* -> EPOLL* replacement

2018-02-11T22:34:03+00:00

This is the mindless scripted replacement of kernel use of POLL* variables as described by Al, done by this script: for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'` for f in $L; do sed -i "-es/^$[^\"]*$$\$/\\1E\\2/" $f; done done with de-mangling cleanups yet to come. NOTE! On almost all architectures, the EPOLL* constants have the same values as the POLL* constants do. But they keyword here is "almost". For various bad reasons they aren't the same, and epoll() doesn't actually work quite correctly in some cases due to this on Sparc et al. The next patch from Al will sort out the final differences, and we should be all done. Scripted-by: Al Viro Signed-off-by: Linus Torvalds

Merge tag 'rpmsg-v4.16' of git://github.com/andersson/remoteproc

2018-02-05T18:05:40+00:00

Pull rpmsg updates from Bjorn Andersson: "This fixes a few issues found in the SMD and GLINK drivers and corrects the handling of SMD channels that are found in an (previously) unexpected state" * tag 'rpmsg-v4.16' of git://github.com/andersson/remoteproc: rpmsg: smd: Fix double unlock in __qcom_smd_send() rpmsg: glink: Fix missing mutex_init() in qcom_glink_alloc_channel() rpmsg: smd: Don't hold the tx lock during wait rpmsg: smd: Fail send on a closed channel rpmsg: smd: Wake up all waiters rpmsg: smd: Create device for all channels rpmsg: smd: Perform handshake during open rpmsg: glink: smem: Ensure ordering during tx drivers: rpmsg: remove duplicate includes remoteproc: qcom: Use PTR_ERR_OR_ZERO() in glink prob

rpmsg: smd: Fix double unlock in __qcom_smd_send()

2018-01-19T15:04:33+00:00

We're not holding the lock here, so we shouldn't unlock. Fixes: 178f3f75bb4e ("rpmsg: smd: Don't hold the tx lock during wait") Signed-off-by: Dan Carpenter [bjorn: renamed "out" label to further distinguish the two exit paths] Signed-off-by: Bjorn Andersson

rpmsg: smd: Don't hold the tx lock during wait

2017-12-19T05:50:11+00:00

Holding the tx lock while waiting for tx-drain events from the remote side blocks try_send requests from failing quickly, so temporarily drop the tx lock while waiting. While this allows try_send to fail quickly it also could allow a subsequent send to succeed putting a smaller packet in the FIFO while we're waiting for room for our large packet. But as this lock is per channel we expect that clients with ordering concerns implements their own ordering mechanism. Signed-off-by: Bjorn Andersson