Hey Stephan,
> +static const struct rpmsg_device_id rpmsg_wwan_ctrl_id_table[] = {
> + /* RPMSG channels for Qualcomm SoCs with integrated modem */
> + { .name = "DATA5_CNTL", .driver_data = WWAN_PORT_QMI },
> + { .name = "DATA4", .driver_data = WWAN_PORT_AT },
> + {},
> +};
If I understand this properly, now these rpmsg backed control ports
would be automatically exposed without the need of a userspace CLI
tool to do that (rpmsgexport).
And if I recall correctly, DATA5_CNTL and DATA4 were the only channels
actively exported with udev actions using rpmsgexport in postmarketos,
but that didn't mean someone could add additional rules to export
other channels (i.e. as per the ModemManager port type hint rules,
DATA[0-9]*_CNTL as QMI and DATA[0-9]* as AT, except for DATA40_CNTL
and DATA_40 which are the USB tethering related ones).
So, does this mean we're limiting the amount of channels exported to
only one QMI control port and one AT control port? Not saying that's
wrong, but maybe it makes sense to add a comment somewhere specifying
that explicitly.
Also, would it make sense to have some way to trigger the export of
additional channels somehow via userspace? e.g. something like
rpmsgexport but using the wwan subsystem. I'm not sure if that's a
true need anywhere or just over-engineering the solution, truth be
told.
--
Aleksander
https://aleksander.es
