Re: [PATCH] rpmsg: glink: Split protocol start out of native_probe

Chunkai Deng <[email protected]>
Newsgroups org.kernel.vger.linux-remoteproc,org.kernel.vger.linux-arm-msm,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
On 6/29/2026 8:47 PM, Konrad Dybcio wrote:

> On 6/19/26 7:01 AM, Chunkai Deng wrote:
>> The SMEM and RPM transports request their receive interrupt with
>> IRQF_NO_AUTOEN and enable it only after qcom_glink_native_probe()
>> returns. Since native_probe() sends the initial version command, the
>> remote may ACK before the local IRQ is enabled, stalling the version
>> handshake on a fast remote.
>>
>> Split the protocol start (qcom_glink_send_version() and
>> qcom_glink_create_chrdev()) into a new qcom_glink_native_start().
>> Transports now enable their IRQ first, then call native_start(), so the
>> version ACK is guaranteed to be serviced.
>>
>> Signed-off-by: Chunkai Deng <[email protected]>
>> ---
> Would it not be simpler to just move the devm_request_irq a bit down
> and remove the NO_AUTOEN flag then?

Thanks for the suggestion.
I analyzed and verified it locally,but I'd personally still lean towards
keeping the current change as-is. My reasoning:

(1) The IRQ must be live before the version handshake — that's the core
point that can't change. The version command is sent from native_start(),
so we need to request/enable the IRQ first and only then call
native_start(). That ordering is only possible with the version send
kept out of native_probe(), so the split needs to stay.

(2) Dropping IRQF_NO_AUTOEN does make the structure a little simpler,
and functionally it's equivalent, but I'd lean towards keeping the
request-disabled + explicit enable_irq() form. It makes the ordering
constraint visible at the call site: the IRQ is requested up front,
and enable_irq() marks the exact point where the handler becomes safe
to run(glink assigned) and where we want RX servicing to begin. Folding
that into an implicit auto-enable hides that intent, and I think the
explicit form is easier to maintain.

That said, if you'd prefer the simpler form, I'm happy to do the IRQ
cleanup as a separate follow-up patch on top of this fix rather than
mixing the refactor into the race fix.

Best regards,
Chunkai Deng
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.