[RFC] Appropriate subsystem/UAPI for Semtech SX126x packet radio support

[RFC] Appropriate subsystem/UAPI for Semtech SX126x packet radio support

[i.n.a]

Hi,

I'm working on a general-purpose Linux driver for the Semtech SX126x family of sub-GHz radio transceivers, initially targeting the SX1262.

Semtech provides a portable C driver for the radio, with the platform-specific interface abstracted behind read, write, reset and wakeup operations:

https://github.com/Lora-net/sx126x_driver

I'm currently implementing the Linux side using SPI, GPIO and IRQ infrastructure.

The SX126x supports LoRa and (G)FSK packet modes, but isn't inherently tied to a particular higher-level protocol. My intention is therefore to keep protocols such as LoRaWAN, AX.25 and Reticulum outside the hardware driver and expose generic packet TX/RX, PHY configuration, radio state and receive metadata such as RSSI/SNR.

I was considering exposing the radio as a character device, for example `/dev/sx126x0`, with a small userspace API for configuration and packet I/O. However, before defining an out-of-tree UAPI that may turn out to be the wrong abstraction, I'd appreciate some guidance:

1.  Is there an existing Linux subsystem suitable for this class of packet radio?
2.  If not, would a character device be an appropriate interface, or is there another abstraction I should investigate?
3.  Would it make sense for the hardware driver to remain protocol-agnostic, with networking/protocol interfaces implemented above it?

The aim is for the driver to be generic across SX1261/SX1262/SX1268 hardware rather than tied to a particular board. I'm also interested in supporting different transports where practical; my initial hardware is SPI-connected.

I wanted to ask about the architecture early, before too much code or a userspace ABI becomes established.

Thanks,
Ina

Re: [RFC] Appropriate subsystem/UAPI for Semtech SX126x packet radio support

[Andrew Lunn]

On Sun, Sep 20, 2026 at 09:15:16PM +0000, i.n.a wrote:
> Hi,
> 
> I'm working on a general-purpose Linux driver for the Semtech SX126x family of sub-GHz radio transceivers, initially targeting the SX1262.
> 
> Semtech provides a portable C driver for the radio, with the platform-specific interface abstracted behind read, write, reset and wakeup operations:
> 
> https://github.com/Lora-net/sx126x_driver
> 
> I'm currently implementing the Linux side using SPI, GPIO and IRQ infrastructure.
> 
> The SX126x supports LoRa and (G)FSK packet modes, but isn't inherently tied to a particular higher-level protocol. My intention is therefore to keep protocols such as LoRaWAN, AX.25 and Reticulum outside the hardware driver and expose generic packet TX/RX, PHY configuration, radio state and receive metadata such as RSSI/SNR.
> 
> I was considering exposing the radio as a character device, for example `/dev/sx126x0`, with a small userspace API for configuration and packet I/O.

One thing to keep in mind is that there are other vendors producing similar devices, e.g:

https://www.microchip.com/en-us/products/wireless-connectivity/sub-ghz/lora
https://www.st.com/en/microcontrollers-microprocessors/stm32wl-series.html

You want to make whatever API you design vendor independent.

	Andrew

Re: [RFC] Appropriate subsystem/UAPI for Semtech SX126x packet radio support

[i.n.a]

> You want to make whatever API you design vendor independent.

Thanks, that's a good point. I'll keep the API vendor-independent. Is there an existing kernel abstraction you'd suggest as a starting point?

Thanks,
Ina

Re: [RFC] Appropriate subsystem/UAPI for Semtech SX126x packet radio support

[Andrew Lunn]

On Sun, Sep 20, 2026 at 09:50:17PM +0000, i.n.a wrote:
> > You want to make whatever API you design vendor independent.
> 

> Thanks, that's a good point. I'll keep the API
> vendor-independent. Is there an existing kernel abstraction you'd
> suggest as a starting point?

This is not really my area, but i would look at the ieee802154 code in
the kernel. They are different technologies, but is the MAC interface
that different? Both need to pass packets to send, both need to
receive packets. There needs to be some why to select frequency, etc.

Is stacking protocols on top of the MAC that different to IEEE
802.15.4?

	Andrew

Re: [RFC] Appropriate subsystem/UAPI for Semtech SX126x packet radio support

[i.n.a]

>Is stacking protocols on top of the MAC that different to IEEE
802.15.4?

Had a look through `mac802154` and `ieee802154_ops`, the hardware boundary does look quite similar, particularly packet TX/RX, start/stop, TX power and energy detection.

The main differences seem to be the 802.15.4-specific parts such as channel/page addressing, CSMA parameters and address filtering, versus PHY-specific configuration for LoRa/GFSK.

Would it make sense to investigate factoring out a small generic packet-radio layer beneath the MAC-specific interfaces?

Thanks,
Ina

Re: [RFC] Appropriate subsystem/UAPI for Semtech SX126x packet radio support

[Jakub Kicinski]

On Sun, 20 Sep 2026 23:06:39 +0000 i.n.a wrote:
> >Is stacking protocols on top of the MAC that different to IEEE  
> 802.15.4?
> 
> Had a look through `mac802154` and `ieee802154_ops`, the hardware boundary does look quite similar, particularly packet TX/RX, start/stop, TX power and energy detection.
> 
> The main differences seem to be the 802.15.4-specific parts such as channel/page addressing, CSMA parameters and address filtering, versus PHY-specific configuration for LoRa/GFSK.
> 
> Would it make sense to investigate factoring out a small generic packet-radio layer beneath the MAC-specific interfaces?

Not an expert, but IMO, you'll need to take it up with ieee802154
maintainers. If they are not interested in broadening the support
I'd say keeping the code in user space seems perfectly fine.