Skip to content

qcom-rtss-can: add recipe for RTSS CAN userspace deamon#2644

Draft
q-AnupKulkarni wants to merge 1 commit into
qualcomm-linux:masterfrom
q-AnupKulkarni:rtss-can-linux
Draft

qcom-rtss-can: add recipe for RTSS CAN userspace deamon#2644
q-AnupKulkarni wants to merge 1 commit into
qualcomm-linux:masterfrom
q-AnupKulkarni:rtss-can-linux

Conversation

@q-AnupKulkarni

Copy link
Copy Markdown

Add a BitBake recipe for the RTSS CAN userspace daemon. This daemon acts
as a gateway between SocketCAN applications and the RTSS subsystem using
the RTSS mailbox UMD libraries (qcom-rtss-mailbox-umd).

Depends on qcom-rtss-mailbox-umd for librtss_mailbox.so and on
linux-libc-headers for linux/can.h and linux/can/raw.h.

Tested on: iq-9075-evk

daemon

The RTSS subsystem on Qualcomm SoCs includes a dedicated CAN controller
that is not directly accessible from the Linux CAN stack. This recipe
builds rtss_can, a userspace daemon that bridges that gap by routing
traffic between Linux SocketCAN virtual interfaces and RTSS mailbox
channels, allowing standard SocketCAN applications to communicate with
CAN hardware managed by RTSS.

The daemon depends on qcom-rtss-mailbox-umd for the librtss_mailbox
interface and on linux-libc-headers for the SocketCAN kernel UAPI
headers (linux/can.h, linux/can/raw.h).

Active CAN controller count is configured per MACHINE at build time
and injected into rtss_can.conf during install.

Tested on: iq-9075-evk

Signed-off-by: q-AnupKulkarni <anupkulk@qti.qualcomm.com>
@q-AnupKulkarni

q-AnupKulkarni commented Jun 28, 2026

Copy link
Copy Markdown
Author

Depends on #2528

lumag

This comment was marked as duplicate.

@lumag Dmitry Baryshkov (lumag) left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what we talked about earlier, uAPI. Don't invent extra API. Provide the standard uAPI. Linux has AF_CAN. As such, if you want to provide CAN support, hook into the existing subsytem instead of providing something new.

This is NAK from my side.

@lumag

Copy link
Copy Markdown
Contributor

To point out, provide AF_CAN by the kernel, there should be no need for the extra userspace bridges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants