On Tue, Dec 12, 2017 at 10:59 AM, Will Newton <will.newton@xxxxxxxxx> wrote: > On Mon, Dec 11, 2017 at 6:11 AM, Bjorn Andersson > <bjorn.andersson@xxxxxxxxxx> wrote: >> or >> 2) take a more active role in driving the channel to opening, >> based on the knowledge that Linux do have someone to interested in >> communicating over this link. > > Do you have an idea of what this approach might look like? After a bit more poking at the code I think I understand what you mean more now. It looks like if we put our side of the channel into the OPENING state instead of the CLOSED state in qcom_smd_channel_reset then the remote state machine flips back into OPENED state and everything seems to be pretty much working. The current code we seem to get stuck with our end in CLOSED and the remote end in CLOSING and nobody making the first move to open the channel. Does making that simple change in qcom_smd_channel_reset seem OK to you or do we need to change the driver more drastically than that? (I am seeing an "external abort on non-linefetch" after making this change, however it doesn't appear to be in the smd driver so may not be directly related) -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
