<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="/rss.xsl.xml"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
    <title>Changes in qcom_glink_native.c</title>
    <description></description>
    <language>en</language>
    <copyright>Copyright 2015</copyright>
    <generator>Java</generator><item>
        <title>06c59d97 - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#06c59d97</link>
        <description>rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name lengthThe name len field of the CMD_OPEN packet is only 16-bits and the upper16-bits of &quot;param2&quot; are a different &quot;prio&quot; field, which can be nonzero incertain situations, and CMD_OPEN packets can be unexpectedly droppedbecause of this.Fix this by masking out the upper 16 bits of param2.Fixes: b4f8e52b89f6 (&quot;rpmsg: Introduce Qualcomm RPM glink driver&quot;)Signed-off-by: Jonathan Marek &lt;jonathan@marek.ca&gt;Reviewed-by: Dmitry Baryshkov &lt;dmitry.baryshkov@linaro.org&gt;Link: https://lore.kernel.org/r/20241007235935.6216-1-jonathan@marek.caSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 07 Oct 2024 23:59:35 +0000</pubDate>
        <dc:creator>Jonathan Marek &lt;jonathan@marek.ca&gt;</dc:creator>
    </item>
<item>
        <title>a387e73f - rpmsg: glink: Handle rejected intent request better</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#a387e73f</link>
        <description>rpmsg: glink: Handle rejected intent request betterGLINK operates using pre-allocated buffers, aka intents, where incomingmessages are aggregated before being passed up the stack. In the casethat no suitable intents have been announced by the receiver, the sendercan request an intent to be allocated.The initial implementation of the response to such request dealtwith two outcomes; granted allocations, and all other cases beingconsidered -ECANCELLED (likely from &quot;cancelling the operation as theremote is going down&quot;).But on some channels intent allocation is not supported, instead theremote will pre-allocate and announce a fixed number of intents for thesender to use. If for such channels an rpmsg_send() is being invokedbefore any channels have been announced, an intent request will beissued and as this comes back rejected the call fails with -ECANCELED.Given that this is reported in the same way as the remote being shutdown, there&apos;s no way for the client to differentiate the two cases.In line with the original GLINK design, change the return value to-EAGAIN for the case where the remote rejects an intent allocationrequest.It&apos;s tempting to handle this case in the GLINK core, as we expectintents to show up in this case. But there&apos;s no way to distinguishbetween this case and a rejection for a too big allocation, nor is itpossible to predict if a currently used (and seemingly suitable) intentwill be returned for reuse or not. As such, returning the error to theclient and allow it to react seems to be the only sensible solution.In addition to this, commit &apos;c05dfce0b89e (&quot;rpmsg: glink: Wait forintent, not just request ack&quot;)&apos; changed the logic such that the codealways wait for an intent request response and an intent. This works outin most cases, but in the event that an intent request is rejected and nofurther intent arrives (e.g. client asks for a too big intent), the codewill stall for 10 seconds and then return -ETIMEDOUT; instead of a moresuitable error.This change also resulted in intent requests racing with the shutdown ofthe remote would be exposed to this same problem, unless some intenthappens to arrive. A patch for this was developed and posted by SarannyaS [1], and has been incorporated here.To summarize, the intent request can end in 4 ways:- Timeout, no response arrived =&gt; return -ETIMEDOUT- Abort TX, the edge is going away =&gt; return -ECANCELLED- Intent request was rejected =&gt; return -EAGAIN- Intent request was accepted, and an intent arrived =&gt; return 0This patch was developed with input from Sarannya S, Deepak Kumar Singh,and Chris Lew.[1] https://lore.kernel.org/all/20240925072328.1163183-1-quic_deesin@quicinc.com/Fixes: c05dfce0b89e (&quot;rpmsg: glink: Wait for intent, not just request ack&quot;)Cc: stable@vger.kernel.orgTested-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;Signed-off-by: Bjorn Andersson &lt;bjorn.andersson@oss.qualcomm.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Link: https://lore.kernel.org/r/20241023-pmic-glink-ecancelled-v2-1-ebc268129407@oss.qualcomm.comSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Wed, 23 Oct 2024 17:24:32 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;bjorn.andersson@oss.qualcomm.com&gt;</dc:creator>
    </item>
<item>
        <title>c1ddb297 - rpmsg: glink: Avoid -Wflex-array-member-not-at-end warnings</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#c1ddb297</link>
        <description>rpmsg: glink: Avoid -Wflex-array-member-not-at-end warnings-Wflex-array-member-not-at-end was introduced in GCC-14, and we aregetting ready to enable it, globally.So, in order to avoid ending up with a flexible-array member in themiddle of multiple other structs, we use the `__struct_group()`helper to create a new tagged `struct glink_msg_hdr`. This structuregroups together all the members of the flexible `struct glink_msg`except the flexible array.As a result, the array is effectively separated from the rest of themembers without modifying the memory layout of the flexible structure.We then change the type of the middle struct members currently causingtrouble from `struct glink_msg` to `struct glink_msg_hdr`.We also want to ensure that when new members need to be added to theflexible structure, they are always included within the newly createdtagged struct. For this, we use `static_assert()`. This ensures that thememory layout for both the flexible structure and the new tagged structis the same after any changes.This approach avoids having to implement `struct glink_msg_hdr` as acompletely separate structure, thus preventing having to maintain twoindependent but basically identical structures, closing the door topotential bugs in the future.We also use `container_of()` whenever we need to retrieve a pointer tothe flexible structure, through which we can access the flexible-arraymember, if necessary.Additionally, we use the `DEFINE_RAW_FLEX()` helper for an on-stackdefinition of a flexible structure where the size for the flexible-arraymember is known at compile-time.So, with these changes, fix the following warnings:drivers/rpmsg/qcom_glink_native.c:51:26: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]drivers/rpmsg/qcom_glink_native.c:459:34: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]drivers/rpmsg/qcom_glink_native.c:846:34: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]drivers/rpmsg/qcom_glink_native.c:968:34: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]drivers/rpmsg/qcom_glink_native.c:1380:34: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]Signed-off-by: Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;Reviewed-by: Kees Cook &lt;kees@kernel.org&gt;Link: https://lore.kernel.org/r/ZrOQa2gew5yadyt3@cuteSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Wed, 07 Aug 2024 15:19:07 +0000</pubDate>
        <dc:creator>Gustavo A. R. Silva &lt;gustavoars@kernel.org&gt;</dc:creator>
    </item>
<item>
        <title>34f79c11 - rpmsg: glink: Introduce packet tracepoints</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#34f79c11</link>
        <description>rpmsg: glink: Introduce packet tracepointsIntroduce tracepoints to allow tracing the GLINK packets being exchangedwith other subsystems. This is useful for debugging both interactionwith remote processors and client driver issues, as well as trackinglatency through the communication stack.Channel events are traced with both local and remote channel ids, aswell as the textual representation when possible. The channel ids areuseful when matching traces with traces from the firmware side logs,while the textual representation is necessary to identify channels whenwe&apos;re starting to trace an already running system.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Link: https://lore.kernel.org/r/20240805-glink-tracepoints-v1-3-a5f3293fb09e@quicinc.comSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 06 Aug 2024 03:56:27 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>91adb340 - rpmsg: glink: Pass channel to qcom_glink_send_close_ack()</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#91adb340</link>
        <description>rpmsg: glink: Pass channel to qcom_glink_send_close_ack()Align the qcom_glink_send_close_ack() arguments with other functions totake the struct glink_channel, so that the upcoming tracepoint patch canaccess the channel attributes.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Link: https://lore.kernel.org/r/20240805-glink-tracepoints-v1-2-a5f3293fb09e@quicinc.comSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 06 Aug 2024 03:56:26 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>159c7976 - rpmsg: glink: Tidy up RX advance handling</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#159c7976</link>
        <description>rpmsg: glink: Tidy up RX advance handlingThe operation of advancing the FIFO receive pointer is sprinkled betweenthe interrupt handler itself, and functions being called from this.Push all the RX advancement operations to the individual handlers, tounify the style across the handling of the various messages.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Link: https://lore.kernel.org/r/20240805-glink-tracepoints-v1-1-a5f3293fb09e@quicinc.comSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 06 Aug 2024 03:56:25 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>d629e5bc - rpmsg: glink: Avoid dereferencing NULL channel</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#d629e5bc</link>
        <description>rpmsg: glink: Avoid dereferencing NULL channelThe newly introduced signal command handler checks for non-existingchannel and print an error message, but then continues on to dereferencethat same channel.Instead abort the handler when no channel is found.Fixes: a2b73aa512a4 (&quot;rpmsg: glink: Add support to handle signals command&quot;)Reported-by: kernel test robot &lt;lkp@intel.com&gt;Reported-by: Dan Carpenter &lt;dan.carpenter@linaro.org&gt;Closes: https://lore.kernel.org/r/202307160800.sb7gMnL6-lkp@intel.com/Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Link: https://lore.kernel.org/r/20230717165538.1542034-1-quic_bjorande@quicinc.comSigned-off-by: Mathieu Poirier &lt;mathieu.poirier@linaro.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 17 Jul 2023 16:55:38 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>b5c9ee82 - rpmsg: glink: Add check for kstrdup</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#b5c9ee82</link>
        <description>rpmsg: glink: Add check for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.Fixes: b4f8e52b89f6 (&quot;rpmsg: Introduce Qualcomm RPM glink driver&quot;)Signed-off-by: Jiasheng Jiang &lt;jiasheng@iscas.ac.cn&gt;Link: https://lore.kernel.org/r/20230619030631.12361-1-jiasheng@iscas.ac.cnSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 19 Jun 2023 03:06:31 +0000</pubDate>
        <dc:creator>Jiasheng Jiang &lt;jiasheng@iscas.ac.cn&gt;</dc:creator>
    </item>
<item>
        <title>a2b73aa5 - rpmsg: glink: Add support to handle signals command</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#a2b73aa5</link>
        <description>rpmsg: glink: Add support to handle signals commandRemote peripherals send signal notifications over glink with commandID 15.Add support to send and receive the signal command and based signalsenable or disable flow control with remote host.Signed-off-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Deepak Kumar Singh &lt;quic_deesin@quicinc.com&gt;Signed-off-by: Sarannya S &lt;quic_sarannya@quicinc.com&gt;Acked-by: Arnaud Pouliquen &lt;arnaud.pouliquen@foss.st.com&gt;Link: https://lore.kernel.org/r/1688679698-31274-3-git-send-email-quic_sarannya@quicinc.comSigned-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Thu, 06 Jul 2023 21:41:37 +0000</pubDate>
        <dc:creator>Chris Lew &lt;quic_clew@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>ba7a4754 - rpmsg: glink: Consolidate TX_DATA and TX_DATA_CONT</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#ba7a4754</link>
        <description>rpmsg: glink: Consolidate TX_DATA and TX_DATA_CONTRather than duplicating most of the code for constructing the initialTX_DATA and subsequent TX_DATA_CONT packets, roll them into a singleloop.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230418163018.785524-3-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 18 Apr 2023 16:30:18 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>7a68f9fa - rpmsg: glink: Propagate TX failures in intentless mode as well</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#7a68f9fa</link>
        <description>rpmsg: glink: Propagate TX failures in intentless mode as wellAs support for splitting transmission over several messages usingTX_DATA_CONT was introduced it does not immediately return the returnvalue of qcom_glink_tx().The result is that in the intentless case (i.e. intent == NULL), thecode will continue to send all additional chunks. This is wasteful, andit&apos;s possible that the send operation could incorrectly indicatesuccess, if the last chunk fits in the TX fifo.Fix the condition.Fixes: 8956927faed3 (&quot;rpmsg: glink: Add TX_DATA_CONT command while sending&quot;)Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230418163018.785524-2-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 18 Apr 2023 16:30:17 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>c05dfce0 - rpmsg: glink: Wait for intent, not just request ack</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#c05dfce0</link>
        <description>rpmsg: glink: Wait for intent, not just request ackIn some implementations of the remote firmware, an intent requestacknowledgment is sent when it&apos;s determined if the intent allocationwill be fulfilled, but then the intent is queued after theacknowledgment.The result is that upon receiving a granted allocation request, thesearch for the newly allocated intent will fail and an additionalrequest will be made. This will at best waste memory, but if the secondrequest is rejected the transaction will be incorrectly rejected.Take the incoming intent into account in the wait to mitigate thisproblem.The above scenario can still happen, in the case that, on that samechannel, an unrelated intent is delivered prior to the requestacknowledgment and a separate process enters the send path and picks upthe intent. Given that there&apos;s no relationship between theacknowledgment and the delivered (or to be delivered intent), theredoesn&apos;t seem to be a solution to this problem.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;[bjorn: Fixed spelling issues pointed out by checkpatch in commit message]Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230327144617.3134175-3-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 27 Mar 2023 14:46:17 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>0a7eee89 - rpmsg: glink: Transition intent request signaling to wait queue</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#0a7eee89</link>
        <description>rpmsg: glink: Transition intent request signaling to wait queueTransition the intent request acknowledgement to use a wait queue sothat it&apos;s possible, in the next commit, to extend the wait to also waitfor an incoming intent.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230327144617.3134175-2-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 27 Mar 2023 14:46:16 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>fb80ef67 - rpmsg: glink: Release driver_override</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#fb80ef67</link>
        <description>rpmsg: glink: Release driver_overrideUpon termination of the rpmsg_device, driver_override needs to be freedto avoid leaking the potentially assigned string.Fixes: 42cd402b8fd4 (&quot;rpmsg: Fix kfree() of static memory on setting driver_override&quot;)Fixes: 39e47767ec9b (&quot;rpmsg: Add driver_override device attribute for rpmsg_device&quot;)Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230109223931.1706429-1-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 09 Jan 2023 22:39:31 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>3e74ec2f - rpmsg: glink: Avoid infinite loop on intent for missing channel</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#3e74ec2f</link>
        <description>rpmsg: glink: Avoid infinite loop on intent for missing channelIn the event that an intent advertisement arrives on an unknown channelthe fifo is not advanced, resulting in the same message being handledover and over.Fixes: dacbb35e930f (&quot;rpmsg: glink: Receive and store the remote intent buffers&quot;)Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230214234231.2069751-1-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 14 Feb 2023 23:42:31 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>4e816d03 - rpmsg: glink: Fix GLINK command prefix</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#4e816d03</link>
        <description>rpmsg: glink: Fix GLINK command prefixThe upstream GLINK driver was first introduced to communicate with theRPM on MSM8996, presumably as an artifact from that era the commanddefines was prefixed RPM_CMD, while they actually are GLINK_CMDs.Let&apos;s rename these, to keep things tidy. No functional change.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230214225933.2025595-1-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 14 Feb 2023 22:59:33 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>a8f500c6 - rpmsg: glink: Fix spelling of peek</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#a8f500c6</link>
        <description>rpmsg: glink: Fix spelling of peekThe code is peeking into the buffers, not peaking. Fix this throughoutthe glink drivers.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230214224746.1996130-1-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Tue, 14 Feb 2023 22:47:46 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>fb23b973 - rpmsg: glink: Cancel pending intent requests at removal</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#fb23b973</link>
        <description>rpmsg: glink: Cancel pending intent requests at removalDuring removal of the glink edge interrupts are disabled and no moreincoming messages are being serviced. In addition to the remote endpointbeing defunct that means that any outstanding requests for intents willnot be serviced, and qcom_glink_request_intent() will blindly wait forup to 10 seconds.Mark the intent request as not granted and complete the intent requestcompletion to fail the waiting client immediately.Once the current intent request is failed, any potential clients waitingfor the intent request mutex will not enter the same wait, as theqcom_glink_tx() call will fail fast.Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230213155215.1237059-7-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 13 Feb 2023 15:52:15 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>9c96bacf - rpmsg: glink: Fail qcom_glink_tx() once remove has been initiated</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#9c96bacf</link>
        <description>rpmsg: glink: Fail qcom_glink_tx() once remove has been initiatedUpon removing the glink edge, communication is at best one-way. Thismeans that the very common scenario of glink requesting intents will notbe possible to serve.Typically a successful transmission results in the client waiting for aresponse, with some timeout and a mechanism for aborting that timeout.Because of this, once the glink edge is defunct once removal iscommenced it&apos;s better to fail transmissions fast.Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230213155215.1237059-6-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 13 Feb 2023 15:52:14 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
<item>
        <title>f424d1cb - rpmsg: glink: Move irq and mbox handling to transports</title>
        <link>http://172.16.0.5:8080/history/linux-6.15/drivers/rpmsg/qcom_glink_native.c#f424d1cb</link>
        <description>rpmsg: glink: Move irq and mbox handling to transportsNot all GLINK transports uses an interrupt and a mailbox instance. Theinterrupt for RPM needs to be IRQF_NOSUSPEND, while it seems reasonablefor the SMEM interrupt to use irq_set_wake. The glink struct device isconstructed in the SMEM and RPM drivers but torn down in the coredriver.Move the interrupt and kick handling into the SMEM and RPM driver, toimprove this and facilitate further improvements.Signed-off-by: Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;Reviewed-by: Chris Lew &lt;quic_clew@quicinc.com&gt;Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;Link: https://lore.kernel.org/r/20230213155215.1237059-5-quic_bjorande@quicinc.com

            List of files:
            /linux-6.15/drivers/rpmsg/qcom_glink_native.c</description>
        <pubDate>Mon, 13 Feb 2023 15:52:13 +0000</pubDate>
        <dc:creator>Bjorn Andersson &lt;quic_bjorande@quicinc.com&gt;</dc:creator>
    </item>
</channel>
</rss>
