| Message ID | 20180701110804.32415-1-afaerber@suse.de |
|---|---|
| Headers | show |
| Series | net: A socket API for LoRa | expand |
Hi Andreas, First, thanks for your great jobs. LoRaWAN module needs the compatible devices drivers. I will reply the message under the LoRaWAN specification. 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>: > Hello, > > LoRa is a long-range, low-power wireless technology by Semtech. > Unlike other LPWAN technologies, users don't need to rely on infrastructure > providers and SIM cards and expensive subscription plans, they can set up > their own gateways. Modules, adapters and evaluation boards are available > from a large number of vendors. > > Many vendors also make available Open Source software examples on GitHub. > But when taking a closer look, many of them combine licenses in ways that are > not redistributable. My reports have remained without response or solution. > > https://github.com/ernstdevreede/lmic_pi/issues/2 > https://github.com/Snootlab/lmic_chisterapi/issues/2 > https://github.com/Snootlab/lora_chisterapi/issues/2 > > Another issue was that most such projects around the Raspberry Pi make use of > spidev to communicate with the Semtech chipsets from userspace. The Linux spi > maintainers have chosen to greet any such users of spidev with a friendly > WARN_ON(), preferring in-kernel spi drivers and white-listing individual > devices only. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c?h=v4.17#n722 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c?h=v4.17#n667 > > Also I don't quite see the point in having userspace probe what SPI devices > are connected to a generic spidev driver when we have an easy Device Tree > hardware description on arm/arm64 that could give us that info. > > I raised the topic during Q&A of a FOSDEM 2017 talk (cut off at the end > of the video) but unfortunately found no one to collaborate on this. > > https://archive.fosdem.org/2017/schedule/event/lorawan/ > > Instead of porting from wiringPi to a differently licensed GPIO library > and dealing with seemingly unmaintained LoRaWAN code dumps, I started a > spi kernel driver for SX1276 back in 2016. But obviously a kernel driver > isn't too helpful without a userspace API to send and receive packets. > > This patchset, updated from 2017 and extended, is implementing kernel drivers > for various LoRa chipsets and modules. As API I'm proposing a PF_LORA socket > implementation. Why? LoRa uses data packets with headers and checksums > and differing MTUs and multiple protocols layered on top of it. Apart from > simple headers for addressing used by RadioHead library and IMST's LoRa P2P > protocol, the main use case (not implemented in this patchset) is expected > to be LoRaWAN. And LoRaWAN has competing proprietary protocols, such as > Link Labs' Symphony Link or GlobalSat M.O.S.T. or RadioShuttle, that might > at some point want to adopt a standard API for their implementations, too. > > Ready-made LoRa hardware modules come in three flavors, > a) with SPI access to the underlying Semtech chipsets, needing a software > implementation of e.g. LoRaWAN protocol stack (i.e., a soft MAC), > b) with a custom, often UART based interface and a pre-certified LoRaWAN > protocol stack already integrated (i.e., hard/full MAC), and > c) with a microcontroller that serves not only for the protocol stack but > also as application processor, not offering a ready-made interface. > > This patchset focuses on option a). An SX1276 based LoRaWAN stack appeared > to be the project of Jian-Hong Pan and is not included here. Thanks, LoRaWAN module needs the compatible device drivers. > This patchset also includes drivers for b), from text based AT commands to > a binary SLIP based HCI protocol. > Hardware examples for c) are Murata CMWX1ZZABZ-078 and RAK813. > > This patchset is clearly not ready for merging, but is being submitted for > discussion, as requested by Jiri, in particular of the design choices: > > 1) PF_LORA/AF_LORA and associated identifiers are proposed to represent > this technology. While for an SX1276 - case a) above - it might work to > layer LoRaWAN as a protocol option for PF_LORA and add LoRaWAN address > fields to the union in my sockaddr_lora, how would that work for devices > that only support LoRaWAN but not pure LoRa? Do we need both AF_LORA and > AF_LORAWAN, or just a separate ETH_P_LORAWAN or ARPHRD_LORAWAN? The LoRaWAN module also register the LoRa device as a network device. Will use the macros AF_LORAWAN, PF_LORAWAN, ARPHRD_LORAWAN and ETH_P_LORAWAN. > 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode > would be DGRAM plus preamble plus optional checksum. Is the preamble added by the hardware itself here or software here? > 3) Only the transmit path is partially implemented already. The assumption > is that the devices should go into receive mode by default and only > interrupt that when asked to transmit. If it goes with LoRaWAN spec., end devices should be in idle (or called standby mode) by default. Unless the device is asked to be in transmitting or receiving timing slot. > 4) Some hardware settings need to be supplied externally, such as the radio > frequency for some modules, but many others can be runtime-configured, > such as Spreading Factor, Bandwidth, Sync Word, or which antenna to use. > What settings should be implemented as socket option vs. netlink layer > vs. ioctl vs. sysfs? What are the criteria to apply? - We can have a pre-defined table according to LoRaWAN Regional Parameters. - Device driver declares the hardware's capability, for example frequency, TX power. And then registers as a LoRaWAN compatible device. - LoRaWAN module handle the requests from upper layer or MAC commands from a gateway (netlink layer), than uses the pre-defined interface functions to set the parameters. LoRaWAN module will export the operation functions interface. > 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK. > Lacking a LoRaWAN implementation, I am currently switching them into LoRa > mode at probe time wherever possible. How do we deal with that properly? - There are data rate tables defined in LoRaWAN Regional Parameters. Those contain which data rate uses LoRa mode or FSK mode. - LoRaWAN should handle the data rate changing requests and then calls the corresponding operation functions. Of course, the hardware's capability registered before should also be under consideration at the same time. > a) Is there any precedence from the Wifi world for dynamically selecting > between our own trusted Open Source implementation vs. hardware/firmware > accelerated and/or certified implementations? > > b) Would a proof of concept for FSK (non-LoRa) modes be required for > merging any LoRa driver for chipsets that support both? Or is there any > facility or design guidelines that would allow us to focus on LoRa and > LoRaWAN and leave non-LoRa radio modes to later contributors? > > As evident by the many questions, this is my first deep dive into the Linux > net subsystem. It's also my first experiments with the new serdev subsystem, > so in particular the receive paths will need some review and optimizations. > > This patchset was developed and tested mainly as KMP, originally at > https://github.com/afaerber/lora-modules. It was recently transformed into a > linux-next based tree, still mostly tested on our openSUSE Tumbleweed kernel > with a differing AF_LORA value below current AF_MAX limit. > > Some corresponding Device Tree Overlays have been collected here: > https://github.com/afaerber/dt-overlays > > Only European models for 868 MHz and 433 MHz could be tested when available. I can test 922-928 MHz in Taiwan. But I need a workable LoRaWAN gateway first! XD Cheers, Jian-Hong Pan > Thanks to all companies and people that have supported this project so far. > > Have a lot of fun! > > Cheers, > Andreas > > Cc: Jian-Hong Pan <starnight@g.ncu.edu.tw> > Cc: Jiri Pirko <jiri@resnulli.us> > Cc: Marcel Holtmann <marcel@holtmann.org> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Matthias Brugger <mbrugger@suse.com> > Cc: Konstantin Böhm <konstantin.boehm@ancud.de> > Cc: Jan Jongboom <jan.jongboom@arm.com> > Cc: Janus Piwek <jpiwek@arroweurope.com> > Cc: Michael Röder <michael.roeder@avnet.eu> > Cc: Dollar Chen (陳義元) <dollar.chen@wtmec.com> > Cc: Ken Yu (禹凯) <ken.yu@rakwireless.com> > Cc: Jon Ortego <Jon.Ortego@imst.de> > Cc: contact@snootlab.com > Cc: Ben Whitten <ben.whitten@lairdtech.com> > Cc: Brian Ray <brian.ray@link-labs.com> > Cc: lora@globalsat.com.tw > Cc: lora@radioshuttle.de > Cc: Alexander Graf <agraf@suse.de> > Cc: Michal Kubeček <mkubecek@suse.cz> > Cc: Rob Herring <robh@kernel.org> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: Steve deRosier <derosier@gmail.com> > Cc: Mark Brown <broonie@kernel.org> > Cc: linux-spi@vger.kernel.org > > Andreas Färber (15): > net: Reserve protocol numbers for LoRa > net: lora: Define sockaddr_lora > net: lora: Add protocol numbers > net: Add lora subsystem > HACK: net: lora: Deal with .poll_mask in 4.18-rc2 > net: lora: Prepare for device drivers > net: lora: Add Semtech SX1276 > net: lora: sx1276: Add debugfs > net: lora: Prepare EUI helpers > net: lora: Add Microchip RN2483 > net: lora: Add IMST WiMOD > net: lora: Add USI WM-SG-SM-42 > net: lora: Prepare RAK RAK811 > net: lora: Prepare Semtech SX1257 > net: lora: Add Semtech SX1301 > > drivers/net/Makefile | 1 + > drivers/net/lora/Kconfig | 72 ++++ > drivers/net/lora/Makefile | 32 ++ > drivers/net/lora/dev.c | 125 ++++++ > drivers/net/lora/rak811.c | 219 +++++++++++ > drivers/net/lora/rn2483.c | 344 +++++++++++++++++ > drivers/net/lora/rn2483.h | 40 ++ > drivers/net/lora/rn2483_cmd.c | 130 +++++++ > drivers/net/lora/sx1257.c | 96 +++++ > drivers/net/lora/sx1276.c | 740 ++++++++++++++++++++++++++++++++++++ > drivers/net/lora/sx1301.c | 446 ++++++++++++++++++++++ > drivers/net/lora/usi.c | 411 ++++++++++++++++++++ > drivers/net/lora/wimod.c | 597 +++++++++++++++++++++++++++++ > include/linux/lora/dev.h | 44 +++ > include/linux/lora/skb.h | 29 ++ > include/linux/socket.h | 4 +- > include/uapi/linux/if_arp.h | 1 + > include/uapi/linux/if_ether.h | 1 + > include/uapi/linux/lora.h | 24 ++ > net/Kconfig | 1 + > net/Makefile | 1 + > net/lora/Kconfig | 15 + > net/lora/Makefile | 8 + > net/lora/af_lora.c | 152 ++++++++ > net/lora/af_lora.h | 13 + > net/lora/dgram.c | 297 +++++++++++++++ > security/selinux/hooks.c | 4 +- > security/selinux/include/classmap.h | 4 +- > 28 files changed, 3848 insertions(+), 3 deletions(-) > create mode 100644 drivers/net/lora/Kconfig > create mode 100644 drivers/net/lora/Makefile > create mode 100644 drivers/net/lora/dev.c > create mode 100644 drivers/net/lora/rak811.c > create mode 100644 drivers/net/lora/rn2483.c > create mode 100644 drivers/net/lora/rn2483.h > create mode 100644 drivers/net/lora/rn2483_cmd.c > create mode 100644 drivers/net/lora/sx1257.c > create mode 100644 drivers/net/lora/sx1276.c > create mode 100644 drivers/net/lora/sx1301.c > create mode 100644 drivers/net/lora/usi.c > create mode 100644 drivers/net/lora/wimod.c > create mode 100644 include/linux/lora/dev.h > create mode 100644 include/linux/lora/skb.h > create mode 100644 include/uapi/linux/lora.h > create mode 100644 net/lora/Kconfig > create mode 100644 net/lora/Makefile > create mode 100644 net/lora/af_lora.c > create mode 100644 net/lora/af_lora.h > create mode 100644 net/lora/dgram.c > > -- > 2.16.4 >
Hello. On 01.07.2018 13:07, Andreas Färber wrote: > > This patchset, updated from 2017 and extended, is implementing kernel drivers > for various LoRa chipsets and modules. I am very happy to see that we now have three people (you, Jian-Hong and Ben) working towards a lora subsystem for protocol stack and drivers. Will allocate some time to look over this and provide some review and feedback how we handled things in the ieee802154 and 6lowpan subsystems. We are also having a IoT protocols workshop during NetDev Conf next week in Montreal (short notice if you are not already planning to attend). If you (or Ben) has soem topics wanted to bring up their please let me know by pm. Jian-Hong will be there presenting on his lora work and I would love to get more input from you and Ben on your views on this. https://netdevconf.org/0x12/session.html?workshop-on-iot-related-mac-layers-header-compression-and-routing-protocols regards Stefan Schmidt
Dear Andreas, I put the kernel support for the SX1276 LoRa chip in question. I don’t think that this kind of device should be in the Linux kernel. Here are a few facts to consider: - A LoRa transaction is very slow (e.g. SF7 needs about 210 ms, for SF12 6280 ms) for 12 bytes user data with acknowledge. - There are many different implementations for the antenna switch, switching between receiving/sending, PA-BOOST, 433, 868/915 MHz. (I know SX1276 Heltec ESP32, SX1276 Murata, RFM95-(1276), SX1276 Heltec STM32-L4) they are all different regarding this. - The LoRa chip device ID is only 8-bit which is not sufficient for larger networks, e.g. our RadioShuttle protocol uses compressed 32-bit device IDs. - The chip can do MTU sizes up to 2048 bytes, most protocols use less than 250 bytes. - Applications do on-the-fly channel and spreading factor switching which makes it more difficult for the configuration. - The chip supports Lora modulation as well as FSK, GFSK, MSK, GMSK, and OOK modulation, for some use cases the other modulations are of interest, e.g. to communicated with other devices. - Power saving modes, like sleep, suspend may be required for battery operation. - Cad detection is very flexible and can be differently used. - LoRa preamble may be different depending on the protocol used. - The new Lora chip SX1262 / 68 (successor of the SX1276) has different hardware and all different registers, it is driver incompatible with the SX1276. It needs an entire new driver. - The device is not multi-process capable (only a single process can communicate with it). - There are SX1276 LoRa modules with a build-in protocol (LoRaWAN and RAW) via a serial connection only, again complete different API compared the SX1276 chip. Software updates for this devices are difficult. - I am even convinced that the LoRaWAN protocol with the concentrator concept is not good, the peer to peer communication and a standard MQTT gateway (what we do) is way more flexible. For all this reasons, I feel a user level driver task implementation is way more flexible. I did a lot of work/enhancements on the SX1276 link level driver from Semtech, it is available and maintained on mbed.org and supports mbed-os, Arduino and is prepared for Linux. https://os.mbed.com/users/Helmut64/code/SX1276GenericLib/ Protocols e.g. our RadioShuttle LoRa peer to peer protocol or the LoRaWAN protocol can run on top of the SX1276GenericLib. We may should focus on such a driver library getting supported for multiple OS's (Win, Linux, mbed, Ardino, etc.) Again I feel a Linux kernel device driver for the SX1276 chip make little sense for me. Regards Helmut Tschemernjak (www.radioshuttle.de, www.helios.de)
Dear Helmut, Am 05.07.2018 um 12:43 schrieb Helmut Tschemernjak: > I put the kernel support for the SX1276 LoRa chip in question. I don’t > think that this kind of device should be in the Linux kernel. Thanks for sharing your opinion. > Here are a few facts to consider: > - A LoRa transaction is very slow (e.g. SF7 needs about 210 ms, for > SF12 6280 ms) for 12 bytes user data with acknowledge. Where do you see a problem? If you look at my SX1276 patch, you will find that it queues a work item for the transmission (asynchronously) and has an interrupt handler to get notified of the TX interrupt. It surely won't get quicker in userspace - and as you point out, we're not speaking about DPDK performance here, so no need for polling. > - There are many different implementations for the antenna switch, > switching between receiving/sending, PA-BOOST, 433, 868/915 MHz. (I know > SX1276 Heltec ESP32, SX1276 Murata, RFM95-(1276), SX1276 Heltec > STM32-L4) they are all different regarding this. Yes, and as demonstrated with this patch series, the kernel is well able to handle this variety of interfaces. I would say better than userspace! As noted, I've tested both 868 MHz and 433 MHz modules. My SX1276 driver uses the Device Tree (radio-frequency) to configure the driver when this was a property of the module. RN2483 by contrast supports two, so a netlink interface was suggested to configure this at runtime. > - The LoRa chip device ID is only 8-bit which is not sufficient for > larger networks, e.g. our RadioShuttle protocol uses compressed 32-bit > device IDs. What does that have to do with anything? The whole reason that you're CC'ed on this patchset is to make sure that you or someone else can implement your custom protocol on top of the APIs being proposed. So my-protocol-is-better-than-theirs is no argument against this project. The way I understand LoRa and thus designed the struct sockaddr_lora is that there is no ID involved for LoRa at all - it is essentially a broadcast. The 8-byte (not 8-bit) EUIs only come into play for LoRaWAN AFAIU. Am I missing anything? LoRaWAN, RadioShuttle, RadioHead and LR Base all have their own ways of addressing - the question here is how to model that in Linux, whether as one PF_LORA with different protocol options and a growing union lora_addr inside sockaddr_lora covering all of them, or a protocol family (requiring global number allocation) for each one of them. > - The chip can do MTU sizes up to 2048 bytes, most protocols use less > than 250 bytes. How would 2048 bytes work? The FIFO buffer fits a maximum of 256 bytes. IIRC the recommended MTU is also restricted by the airtime, i.e. SF, bandwidth, preamble and other factors... Some UART based modules allow a maximum of 64 bytes. > - Applications do on-the-fly channel and spreading factor switching > which makes it more difficult for the configuration. That's exactly the question of how to implement individual options - Device Tree would be fixed for the system's hardware, netlink would be user-configurable for the whole network device, whereas socket options would be per socket/application, and ioctls might be yet another implementation layer. > - The chip supports Lora modulation as well as FSK, GFSK, MSK, GMSK, > and OOK modulation, for some use cases the other modulations are of > interest, e.g. to communicated with other devices. Yes, therefore I raised it in the cover letter as open point 5). > - Power saving modes, like sleep, suspend may be required for battery > operation. The Linux kernel can deal with that much better than userspace. There's pm hooks that one could implement. And SX1276 returns to standby mode whenever an operation such as TX is completed. In sleep mode not all settings get preserved, so they would need to be saved in the private struct and restored on resume. > - Cad detection is very flexible and can be differently used. > > - LoRa preamble may be different depending on the protocol used. > > - The new Lora chip SX1262 / 68 (successor of the SX1276) has different > hardware and all different registers, it is driver incompatible with the > SX1276. It needs an entire new driver. Not unexpected, same as SX1301 being different. As this series shows, multiple drivers can easily be implemented as necessary. > - The device is not multi-process capable (only a single process can > communicate with it). How is that different from other half-duplex network interfaces? The driver needs to take care of appropriate locking of its operations, and the socket subsystem should make sure packets get queued accordingly. > - There are SX1276 LoRa modules with a build-in protocol (LoRaWAN and > RAW) via a serial connection only, again complete different API compared > the SX1276 chip. Software updates for this devices are difficult. Drivers for such modules are already demonstrated in this series. > - I am even convinced that the LoRaWAN protocol with the concentrator > concept is not good, the peer to peer communication and a standard MQTT > gateway (what we do) is way more flexible. Your opinion in all honors, LoRaWAN is an open specification, whereas yours is closed. So whatever benefits yours may have, that way you're unlikely to make LoRaWAN go away. People are rolling out LoRaWAN gateways, and therefore the question is not which protocol is more flexible but rather how all of them can be enabled equally for those that want to use them. > For all this reasons, I feel a user level driver task implementation is > way more flexible. I did a lot of work/enhancements on the SX1276 link > level driver from Semtech, it is available and maintained on mbed.org > and supports mbed-os, Arduino and is prepared for Linux. > https://os.mbed.com/users/Helmut64/code/SX1276GenericLib/ > > Protocols e.g. our RadioShuttle LoRa peer to peer protocol or the > LoRaWAN protocol can run on top of the SX1276GenericLib. We may should > focus on such a driver library getting supported for multiple OS's (Win, > Linux, mbed, Ardino, etc.) > > Again I feel a Linux kernel device driver for the SX1276 chip make > little sense for me. Well, feel free to use spidev if you prefer. As I pointed out, the Linux spi maintainers don't seem to share your view - instead of white-listing chipsets for concrete kernel drivers (as you appear to suggest here) they rather black-list chipsets to be "allowed" to use spidev if all else fails. Having already done part of the implementation work, for me the question is not whether to do a kernel driver but how to do it properly, keeping all corner cases in mind, such as non-standard protocols like yours. It's great that you're writing an Open Source library for mbed, but its name indicates that it offers no abstraction like proposed here. I'll drop you from v2 then, to not bother you about this Linux kernel implementation anymore. Regards, Andreas
Dear Andreas, here are a few comments in response to your answer. The SX1276 can do MTU sizes up to 2048 bytes, there is a FIFO and corresponding interrupts to handle this, details are in datasheet. Regarding the LoRaWAN concept, when companies like Semtech and IBM designing such a thing, and other companies (Stackforce) implementing the code for it. This does not mean automatically that it is good for most use cases. Specifically the idea of the concentrator has major limits. Check out our article and picture: "Protocols: LoRaWANTM vs RadioShuttle" at http://www.radioshuttle.de/en/radioshuttle-2/protocol/ Again my opinion is that that such a specific driver is not needed in the kernel. I am happy to provide further feedback, when you have questions about the SX1276Generic driver which I maintain, I am available to discuss this. And again the open source driver works on mbed, arduino and can be easily adopted to Linux user space and other environments. Regards Helmut On 11/07/18 04:07, Andreas Färber wrote: > Dear Helmut, > > Am 05.07.2018 um 12:43 schrieb Helmut Tschemernjak: >> I put the kernel support for the SX1276 LoRa chip in question. I don’t >> think that this kind of device should be in the Linux kernel. > Thanks for sharing your opinion. > >> Here are a few facts to consider: >> - A LoRa transaction is very slow (e.g. SF7 needs about 210 ms, for >> SF12 6280 ms) for 12 bytes user data with acknowledge. > Where do you see a problem? If you look at my SX1276 patch, you will > find that it queues a work item for the transmission (asynchronously) > and has an interrupt handler to get notified of the TX interrupt. It > surely won't get quicker in userspace - and as you point out, we're not > speaking about DPDK performance here, so no need for polling. > >> - There are many different implementations for the antenna switch, >> switching between receiving/sending, PA-BOOST, 433, 868/915 MHz. (I know >> SX1276 Heltec ESP32, SX1276 Murata, RFM95-(1276), SX1276 Heltec >> STM32-L4) they are all different regarding this. > Yes, and as demonstrated with this patch series, the kernel is well able > to handle this variety of interfaces. I would say better than userspace! > > As noted, I've tested both 868 MHz and 433 MHz modules. My SX1276 driver > uses the Device Tree (radio-frequency) to configure the driver when this > was a property of the module. RN2483 by contrast supports two, so a > netlink interface was suggested to configure this at runtime. > >> - The LoRa chip device ID is only 8-bit which is not sufficient for >> larger networks, e.g. our RadioShuttle protocol uses compressed 32-bit >> device IDs. > What does that have to do with anything? The whole reason that you're > CC'ed on this patchset is to make sure that you or someone else can > implement your custom protocol on top of the APIs being proposed. So > my-protocol-is-better-than-theirs is no argument against this project. > > The way I understand LoRa and thus designed the struct sockaddr_lora is > that there is no ID involved for LoRa at all - it is essentially a > broadcast. The 8-byte (not 8-bit) EUIs only come into play for LoRaWAN > AFAIU. Am I missing anything? > > LoRaWAN, RadioShuttle, RadioHead and LR Base all have their own ways of > addressing - the question here is how to model that in Linux, whether as > one PF_LORA with different protocol options and a growing union > lora_addr inside sockaddr_lora covering all of them, or a protocol > family (requiring global number allocation) for each one of them. > >> - The chip can do MTU sizes up to 2048 bytes, most protocols use less >> than 250 bytes. > How would 2048 bytes work? The FIFO buffer fits a maximum of 256 bytes. > > IIRC the recommended MTU is also restricted by the airtime, i.e. SF, > bandwidth, preamble and other factors... > > Some UART based modules allow a maximum of 64 bytes. > >> - Applications do on-the-fly channel and spreading factor switching >> which makes it more difficult for the configuration. > That's exactly the question of how to implement individual options - > Device Tree would be fixed for the system's hardware, netlink would be > user-configurable for the whole network device, whereas socket options > would be per socket/application, and ioctls might be yet another > implementation layer. > >> - The chip supports Lora modulation as well as FSK, GFSK, MSK, GMSK, >> and OOK modulation, for some use cases the other modulations are of >> interest, e.g. to communicated with other devices. > Yes, therefore I raised it in the cover letter as open point 5). > >> - Power saving modes, like sleep, suspend may be required for battery >> operation. > The Linux kernel can deal with that much better than userspace. There's > pm hooks that one could implement. And SX1276 returns to standby mode > whenever an operation such as TX is completed. In sleep mode not all > settings get preserved, so they would need to be saved in the private > struct and restored on resume. > >> - Cad detection is very flexible and can be differently used. >> >> - LoRa preamble may be different depending on the protocol used. >> >> - The new Lora chip SX1262 / 68 (successor of the SX1276) has different >> hardware and all different registers, it is driver incompatible with the >> SX1276. It needs an entire new driver. > Not unexpected, same as SX1301 being different. As this series shows, > multiple drivers can easily be implemented as necessary. > >> - The device is not multi-process capable (only a single process can >> communicate with it). > How is that different from other half-duplex network interfaces? The > driver needs to take care of appropriate locking of its operations, and > the socket subsystem should make sure packets get queued accordingly. > >> - There are SX1276 LoRa modules with a build-in protocol (LoRaWAN and >> RAW) via a serial connection only, again complete different API compared >> the SX1276 chip. Software updates for this devices are difficult. > Drivers for such modules are already demonstrated in this series. > >> - I am even convinced that the LoRaWAN protocol with the concentrator >> concept is not good, the peer to peer communication and a standard MQTT >> gateway (what we do) is way more flexible. > Your opinion in all honors, LoRaWAN is an open specification, whereas > yours is closed. So whatever benefits yours may have, that way you're > unlikely to make LoRaWAN go away. People are rolling out LoRaWAN > gateways, and therefore the question is not which protocol is more > flexible but rather how all of them can be enabled equally for those > that want to use them. > >> For all this reasons, I feel a user level driver task implementation is >> way more flexible. I did a lot of work/enhancements on the SX1276 link >> level driver from Semtech, it is available and maintained on mbed.org >> and supports mbed-os, Arduino and is prepared for Linux. >> https://os.mbed.com/users/Helmut64/code/SX1276GenericLib/ >> >> Protocols e.g. our RadioShuttle LoRa peer to peer protocol or the >> LoRaWAN protocol can run on top of the SX1276GenericLib. We may should >> focus on such a driver library getting supported for multiple OS's (Win, >> Linux, mbed, Ardino, etc.) >> >> Again I feel a Linux kernel device driver for the SX1276 chip make >> little sense for me. > Well, feel free to use spidev if you prefer. As I pointed out, the Linux > spi maintainers don't seem to share your view - instead of white-listing > chipsets for concrete kernel drivers (as you appear to suggest here) > they rather black-list chipsets to be "allowed" to use spidev if all > else fails. > > Having already done part of the implementation work, for me the question > is not whether to do a kernel driver but how to do it properly, keeping > all corner cases in mind, such as non-standard protocols like yours. > It's great that you're writing an Open Source library for mbed, but its > name indicates that it offers no abstraction like proposed here. > > I'll drop you from v2 then, to not bother you about this Linux kernel > implementation anymore. > > Regards, > Andreas >
> Subject: [RFC net-next 00/15] net: A socket API for LoRa > > Hello, > > LoRa is a long-range, low-power wireless technology by > Semtech. > Unlike other LPWAN technologies, users don't need to rely > on infrastructure > providers and SIM cards and expensive subscription plans, > they can set up > their own gateways. Modules, adapters and evaluation > boards are available > from a large number of vendors. > > Many vendors also make available Open Source software > examples on GitHub. > But when taking a closer look, many of them combine > licenses in ways that are > not redistributable. My reports have remained without > response or solution. > > https://github.com/ernstdevreede/lmic_pi/issues/2 > https://github.com/Snootlab/lmic_chisterapi/issues/2 > https://github.com/Snootlab/lora_chisterapi/issues/2 > > Another issue was that most such projects around the > Raspberry Pi make use of > spidev to communicate with the Semtech chipsets from > userspace. The Linux spi > maintainers have chosen to greet any such users of spidev > with a friendly > WARN_ON(), preferring in-kernel spi drivers and white- > listing individual > devices only. > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin > ux.git/tree/drivers/spi/spidev.c?h=v4.17#n722 > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin > ux.git/tree/drivers/spi/spidev.c?h=v4.17#n667 > > Also I don't quite see the point in having userspace probe > what SPI devices > are connected to a generic spidev driver when we have an > easy Device Tree > hardware description on arm/arm64 that could give us that > info. > > I raised the topic during Q&A of a FOSDEM 2017 talk (cut off > at the end > of the video) but unfortunately found no one to collaborate > on this. > > https://archive.fosdem.org/2017/schedule/event/lorawan/ > > Instead of porting from wiringPi to a differently licensed > GPIO library > and dealing with seemingly unmaintained LoRaWAN code > dumps, I started a > spi kernel driver for SX1276 back in 2016. But obviously a > kernel driver > isn't too helpful without a userspace API to send and receive > packets. > > This patchset, updated from 2017 and extended, is > implementing kernel drivers > for various LoRa chipsets and modules. As API I'm proposing > a PF_LORA socket > implementation. Why? LoRa uses data packets with headers > and checksums > and differing MTUs and multiple protocols layered on top of > it. Apart from > simple headers for addressing used by RadioHead library > and IMST's LoRa P2P > protocol, the main use case (not implemented in this > patchset) is expected > to be LoRaWAN. And LoRaWAN has competing proprietary > protocols, such as > Link Labs' Symphony Link or GlobalSat M.O.S.T. or > RadioShuttle, that might > at some point want to adopt a standard API for their > implementations, too. > > Ready-made LoRa hardware modules come in three flavors, > a) with SPI access to the underlying Semtech chipsets, > needing a software > implementation of e.g. LoRaWAN protocol stack (i.e., a > soft MAC), > b) with a custom, often UART based interface and a pre- > certified LoRaWAN > protocol stack already integrated (i.e., hard/full MAC), and > c) with a microcontroller that serves not only for the > protocol stack but > also as application processor, not offering a ready-made > interface. > > This patchset focuses on option a). An SX1276 based > LoRaWAN stack appeared > to be the project of Jian-Hong Pan and is not included here. > This patchset also includes drivers for b), from text based AT > commands to > a binary SLIP based HCI protocol. > Hardware examples for c) are Murata CMWX1ZZABZ-078 > and RAK813. > > This patchset is clearly not ready for merging, but is being > submitted for > discussion, as requested by Jiri, in particular of the design > choices: > > 1) PF_LORA/AF_LORA and associated identifiers are > proposed to represent > this technology. While for an SX1276 - case a) above - it > might work to > layer LoRaWAN as a protocol option for PF_LORA and add > LoRaWAN address > fields to the union in my sockaddr_lora, how would that > work for devices > that only support LoRaWAN but not pure LoRa? Do we > need both AF_LORA and > AF_LORAWAN, or just a separate ETH_P_LORAWAN or > ARPHRD_LORAWAN? > > 2) PF_LORA is used with SOCK_DGRAM here. The > assumption is that RAW mode > would be DGRAM plus preamble plus optional checksum. > > 3) Only the transmit path is partially implemented already. > The assumption > is that the devices should go into receive mode by default > and only > interrupt that when asked to transmit. > > 4) Some hardware settings need to be supplied externally, > such as the radio > frequency for some modules, but many others can be > runtime-configured, > such as Spreading Factor, Bandwidth, Sync Word, or which > antenna to use. > What settings should be implemented as socket option vs. > netlink layer > vs. ioctl vs. sysfs? What are the criteria to apply? > > 5) Many of the modules support multiple modes, such as > LoRa, LoRaWAN and FSK. > Lacking a LoRaWAN implementation, I am currently > switching them into LoRa > mode at probe time wherever possible. How do we deal > with that properly? > > a) Is there any precedence from the Wifi world for > dynamically selecting > between our own trusted Open Source implementation > vs. hardware/firmware > accelerated and/or certified implementations? > > b) Would a proof of concept for FSK (non-LoRa) modes be > required for > merging any LoRa driver for chipsets that support both? > Or is there any > facility or design guidelines that would allow us to focus > on LoRa and > LoRaWAN and leave non-LoRa radio modes to later > contributors? Down the line I think we should also plan for a CRDA style regdb somewhere in the path for raw LoRa transceivers operating as softMAC, much like with WiFi. LoRa radios used in Gateway devices are typically relatively high power (capable of 27dBm) and operate in bands with certain restrictions, eg the EU has keep out areas within 868MHz for alarms and SRD devices must abide by certain duty cycle restrictions, there are also maximum powers to consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K, L, M, N, P, Q) The certified AT style modules will (should) already have this regulatory data baked in so it only applied to situations where we drive the transceivers directly, but it wouldn't hurt to check that the frequency being asked to transmit on doesn't spill into a restricted band. > As evident by the many questions, this is my first deep dive > into the Linux > net subsystem. It's also my first experiments with the new > serdev subsystem, > so in particular the receive paths will need some review and > optimizations. > > This patchset was developed and tested mainly as KMP, > originally at > https://github.com/afaerber/lora-modules. It was recently > transformed into a > linux-next based tree, still mostly tested on our openSUSE > Tumbleweed kernel > with a differing AF_LORA value below current AF_MAX limit. > > Some corresponding Device Tree Overlays have been > collected here: > https://github.com/afaerber/dt-overlays > > Only European models for 868 MHz and 433 MHz could be > tested when available. > Thanks to all companies and people that have supported > this project so far. > > Have a lot of fun! > > Cheers, > Andreas > > Cc: Jian-Hong Pan <starnight@g.ncu.edu.tw> > Cc: Jiri Pirko <jiri@resnulli.us> > Cc: Marcel Holtmann <marcel@holtmann.org> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Matthias Brugger <mbrugger@suse.com> > Cc: Konstantin Böhm <konstantin.boehm@ancud.de> > Cc: Jan Jongboom <jan.jongboom@arm.com> > Cc: Janus Piwek <jpiwek@arroweurope.com> > Cc: Michael Röder <michael.roeder@avnet.eu> > Cc: Dollar Chen (陳義元) <dollar.chen@wtmec.com> > Cc: Ken Yu (禹凯) <ken.yu@rakwireless.com> > Cc: Jon Ortego <Jon.Ortego@imst.de> > Cc: contact@snootlab.com > Cc: Ben Whitten <ben.whitten@lairdtech.com> > Cc: Brian Ray <brian.ray@link-labs.com> > Cc: lora@globalsat.com.tw > Cc: lora@radioshuttle.de > Cc: Alexander Graf <agraf@suse.de> > Cc: Michal Kubeček <mkubecek@suse.cz> > Cc: Rob Herring <robh@kernel.org> > Cc: devicetree@vger.kernel.org > Cc: linux-arm-kernel@lists.infradead.org > Cc: Steve deRosier <derosier@gmail.com> > Cc: Mark Brown <broonie@kernel.org> > Cc: linux-spi@vger.kernel.org > > Andreas Färber (15): > net: Reserve protocol numbers for LoRa > net: lora: Define sockaddr_lora > net: lora: Add protocol numbers > net: Add lora subsystem > HACK: net: lora: Deal with .poll_mask in 4.18-rc2 > net: lora: Prepare for device drivers > net: lora: Add Semtech SX1276 > net: lora: sx1276: Add debugfs > net: lora: Prepare EUI helpers > net: lora: Add Microchip RN2483 > net: lora: Add IMST WiMOD > net: lora: Add USI WM-SG-SM-42 > net: lora: Prepare RAK RAK811 > net: lora: Prepare Semtech SX1257 > net: lora: Add Semtech SX1301 > > drivers/net/Makefile | 1 + > drivers/net/lora/Kconfig | 72 ++++ > drivers/net/lora/Makefile | 32 ++ > drivers/net/lora/dev.c | 125 ++++++ > drivers/net/lora/rak811.c | 219 +++++++++++ > drivers/net/lora/rn2483.c | 344 +++++++++++++++++ > drivers/net/lora/rn2483.h | 40 ++ > drivers/net/lora/rn2483_cmd.c | 130 +++++++ > drivers/net/lora/sx1257.c | 96 +++++ > drivers/net/lora/sx1276.c | 740 > ++++++++++++++++++++++++++++++++++++ > drivers/net/lora/sx1301.c | 446 > ++++++++++++++++++++++ > drivers/net/lora/usi.c | 411 > ++++++++++++++++++++ > drivers/net/lora/wimod.c | 597 > +++++++++++++++++++++++++++++ > include/linux/lora/dev.h | 44 +++ > include/linux/lora/skb.h | 29 ++ > include/linux/socket.h | 4 +- > include/uapi/linux/if_arp.h | 1 + > include/uapi/linux/if_ether.h | 1 + > include/uapi/linux/lora.h | 24 ++ > net/Kconfig | 1 + > net/Makefile | 1 + > net/lora/Kconfig | 15 + > net/lora/Makefile | 8 + > net/lora/af_lora.c | 152 ++++++++ > net/lora/af_lora.h | 13 + > net/lora/dgram.c | 297 +++++++++++++++ > security/selinux/hooks.c | 4 +- > security/selinux/include/classmap.h | 4 +- > 28 files changed, 3848 insertions(+), 3 deletions(-) > create mode 100644 drivers/net/lora/Kconfig > create mode 100644 drivers/net/lora/Makefile > create mode 100644 drivers/net/lora/dev.c > create mode 100644 drivers/net/lora/rak811.c > create mode 100644 drivers/net/lora/rn2483.c > create mode 100644 drivers/net/lora/rn2483.h > create mode 100644 drivers/net/lora/rn2483_cmd.c > create mode 100644 drivers/net/lora/sx1257.c > create mode 100644 drivers/net/lora/sx1276.c > create mode 100644 drivers/net/lora/sx1301.c > create mode 100644 drivers/net/lora/usi.c > create mode 100644 drivers/net/lora/wimod.c > create mode 100644 include/linux/lora/dev.h > create mode 100644 include/linux/lora/skb.h > create mode 100644 include/uapi/linux/lora.h > create mode 100644 net/lora/Kconfig > create mode 100644 net/lora/Makefile > create mode 100644 net/lora/af_lora.c > create mode 100644 net/lora/af_lora.h > create mode 100644 net/lora/dgram.c > > -- > 2.16.4
+ linux-wireless + Stefan + Seth Am 11.07.2018 um 17:21 schrieb Ben Whitten: >> This patchset is clearly not ready for merging, but is being >> submitted for >> discussion, as requested by Jiri, in particular of the design >> choices: >> >> 1) PF_LORA/AF_LORA and associated identifiers are >> proposed to represent >> this technology. While for an SX1276 - case a) above - it >> might work to >> layer LoRaWAN as a protocol option for PF_LORA and add >> LoRaWAN address >> fields to the union in my sockaddr_lora, how would that >> work for devices >> that only support LoRaWAN but not pure LoRa? Do we >> need both AF_LORA and >> AF_LORAWAN, or just a separate ETH_P_LORAWAN or >> ARPHRD_LORAWAN? >> >> 2) PF_LORA is used with SOCK_DGRAM here. The >> assumption is that RAW mode >> would be DGRAM plus preamble plus optional checksum. >> >> 3) Only the transmit path is partially implemented already. >> The assumption >> is that the devices should go into receive mode by default >> and only >> interrupt that when asked to transmit. >> >> 4) Some hardware settings need to be supplied externally, >> such as the radio >> frequency for some modules, but many others can be >> runtime-configured, >> such as Spreading Factor, Bandwidth, Sync Word, or which >> antenna to use. >> What settings should be implemented as socket option vs. >> netlink layer >> vs. ioctl vs. sysfs? What are the criteria to apply? >> >> 5) Many of the modules support multiple modes, such as >> LoRa, LoRaWAN and FSK. >> Lacking a LoRaWAN implementation, I am currently >> switching them into LoRa >> mode at probe time wherever possible. How do we deal >> with that properly? >> >> a) Is there any precedence from the Wifi world for >> dynamically selecting >> between our own trusted Open Source implementation >> vs. hardware/firmware >> accelerated and/or certified implementations? >> >> b) Would a proof of concept for FSK (non-LoRa) modes be >> required for >> merging any LoRa driver for chipsets that support both? >> Or is there any >> facility or design guidelines that would allow us to focus >> on LoRa and >> LoRaWAN and leave non-LoRa radio modes to later >> contributors? > > Down the line I think we should also plan for a CRDA style regdb somewhere in the path for raw LoRa transceivers operating as softMAC, much like with WiFi. Yes, I had raised the topic of wireless-regdb for Stefan's conference - currently it seems to only cover 2.4 GHz, 5 GHz and 60 GHz. Not sure if we can easily extend that to cover 433 MHz, 868 MHz, 915 MHz and 923 MHz bands or whether we'd just need something similar... Is 802.15.4 able to share this database with Wifi? An argument to share with Wifi might be that Semtech's SX1280 and SX1281 2.4 GHz transceivers claim to support LoRa modulation, too. Having two different regulatory DBs interact with LoRa drivers seems a bad idea, and duplicating 2.4 GHz into a new DB doesn't sound appealing either. https://www.semtech.com/products/wireless-rf/24-ghz-transceivers Meanwhile my attempt to play with netlink during SUSE Hackweek has been going slow and I could use some guidance or a volunteer to contribute: I have a bare skeleton of registration, commands, attributes and multicast groups, but no plan yet how to connect that to the actual drivers to query or apply the settings... https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/net/lora/netlink.c?h=lora-next > LoRa radios used in Gateway devices are typically relatively high power (capable of 27dBm) and operate in bands with certain restrictions, eg the EU has keep out areas within 868MHz for alarms and SRD devices must abide by certain duty cycle restrictions, there are also maximum powers to consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K, L, M, N, P, Q) > The certified AT style modules will (should) already have this regulatory data baked in so it only applied to situations where we drive the transceivers directly, but it wouldn't hurt to check that the frequency being asked to transmit on doesn't spill into a restricted band. Some do have configuration options that will need to be set or checked. Regards, Andreas
> Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa > > + linux-wireless + Stefan + Seth > > Am 11.07.2018 um 17:21 schrieb Ben Whitten: > >> This patchset is clearly not ready for merging, but is being > >> submitted for > >> discussion, as requested by Jiri, in particular of the design > >> choices: > >> > >> 1) PF_LORA/AF_LORA and associated identifiers are > >> proposed to represent > >> this technology. While for an SX1276 - case a) above - it > >> might work to > >> layer LoRaWAN as a protocol option for PF_LORA and > add > >> LoRaWAN address > >> fields to the union in my sockaddr_lora, how would that > >> work for devices > >> that only support LoRaWAN but not pure LoRa? Do we > >> need both AF_LORA and > >> AF_LORAWAN, or just a separate ETH_P_LORAWAN or > >> ARPHRD_LORAWAN? > >> > >> 2) PF_LORA is used with SOCK_DGRAM here. The > >> assumption is that RAW mode > >> would be DGRAM plus preamble plus optional > checksum. > >> > >> 3) Only the transmit path is partially implemented > already. > >> The assumption > >> is that the devices should go into receive mode by > default > >> and only > >> interrupt that when asked to transmit. > >> > >> 4) Some hardware settings need to be supplied > externally, > >> such as the radio > >> frequency for some modules, but many others can be > >> runtime-configured, > >> such as Spreading Factor, Bandwidth, Sync Word, or > which > >> antenna to use. > >> What settings should be implemented as socket option > vs. > >> netlink layer > >> vs. ioctl vs. sysfs? What are the criteria to apply? > >> > >> 5) Many of the modules support multiple modes, such as > >> LoRa, LoRaWAN and FSK. > >> Lacking a LoRaWAN implementation, I am currently > >> switching them into LoRa > >> mode at probe time wherever possible. How do we > deal > >> with that properly? > >> > >> a) Is there any precedence from the Wifi world for > >> dynamically selecting > >> between our own trusted Open Source > implementation > >> vs. hardware/firmware > >> accelerated and/or certified implementations? > >> > >> b) Would a proof of concept for FSK (non-LoRa) modes > be > >> required for > >> merging any LoRa driver for chipsets that support > both? > >> Or is there any > >> facility or design guidelines that would allow us to > focus > >> on LoRa and > >> LoRaWAN and leave non-LoRa radio modes to later > >> contributors? > > > > Down the line I think we should also plan for a CRDA style > regdb somewhere in the path for raw LoRa transceivers > operating as softMAC, much like with WiFi. > > Yes, I had raised the topic of wireless-regdb for Stefan's > conference - > currently it seems to only cover 2.4 GHz, 5 GHz and 60 GHz. > Not sure if > we can easily extend that to cover 433 MHz, 868 MHz, 915 > MHz and 923 MHz > bands or whether we'd just need something similar... Is > 802.15.4 able to > share this database with Wifi? Well the README in the wireless-regdb doesn't bind itself to 80211, there are references to the other ETSI EN specs so this would be the place rather than duplicating. There would need a bit of additional information to capture duty-cycle requirements, however the SRD spec states the maximum bandwidths can be 'The whole band', so with a flag set we could hijack this band information for duty-cycle. I am unsure if 802.15.4 uses this database, most of the naming seems geared towards 80211, nl80211, cfg80211 so perhaps we need our own versions of these with a common component, I hope the maintainers can give some guidance here. > An argument to share with Wifi might be that Semtech's > SX1280 and SX1281 > 2.4 GHz transceivers claim to support LoRa modulation, too. > Having two > different regulatory DBs interact with LoRa drivers seems a > bad idea, > and duplicating 2.4 GHz into a new DB doesn't sound > appealing either. Well I'm not sure if the modulation affects regulatory information, just bands, power, and techniques like DFS. As these chips are 2.4GHz only I expect they are bound by the existing regulatory information we would just need a path to access it. > https://www.semtech.com/products/wireless-rf/24-ghz- > transceivers > > Meanwhile my attempt to play with netlink during SUSE > Hackweek has been > going slow and I could use some guidance or a volunteer to > contribute: I > have a bare skeleton of registration, commands, attributes > and multicast > groups, but no plan yet how to connect that to the actual > drivers to > query or apply the settings... Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal. > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li > nux-lora.git/tree/net/lora/netlink.c?h=lora-next > > > LoRa radios used in Gateway devices are typically relatively > high power (capable of 27dBm) and operate in bands with > certain restrictions, eg the EU has keep out areas within > 868MHz for alarms and SRD devices must abide by certain > duty cycle restrictions, there are also maximum powers to > consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K, > L, M, N, P, Q) > > > The certified AT style modules will (should) already have > this regulatory data baked in so it only applied to situations > where we drive the transceivers directly, but it wouldn't > hurt to check that the frequency being asked to transmit on > doesn't spill into a restricted band. > > Some do have configuration options that will need to be set > or checked. > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg)
2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten@lairdtech.com>: >> Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa >> >> + linux-wireless + Stefan + Seth >> >> Am 11.07.2018 um 17:21 schrieb Ben Whitten: >> >> This patchset is clearly not ready for merging, but is being >> >> submitted for >> >> discussion, as requested by Jiri, in particular of the design >> >> choices: >> >> >> >> 1) PF_LORA/AF_LORA and associated identifiers are >> >> proposed to represent >> >> this technology. While for an SX1276 - case a) above - it >> >> might work to >> >> layer LoRaWAN as a protocol option for PF_LORA and >> add >> >> LoRaWAN address >> >> fields to the union in my sockaddr_lora, how would that >> >> work for devices >> >> that only support LoRaWAN but not pure LoRa? Do we >> >> need both AF_LORA and >> >> AF_LORAWAN, or just a separate ETH_P_LORAWAN or >> >> ARPHRD_LORAWAN? >> >> >> >> 2) PF_LORA is used with SOCK_DGRAM here. The >> >> assumption is that RAW mode >> >> would be DGRAM plus preamble plus optional >> checksum. >> >> >> >> 3) Only the transmit path is partially implemented >> already. >> >> The assumption >> >> is that the devices should go into receive mode by >> default >> >> and only >> >> interrupt that when asked to transmit. >> >> >> >> 4) Some hardware settings need to be supplied >> externally, >> >> such as the radio >> >> frequency for some modules, but many others can be >> >> runtime-configured, >> >> such as Spreading Factor, Bandwidth, Sync Word, or >> which >> >> antenna to use. >> >> What settings should be implemented as socket option >> vs. >> >> netlink layer >> >> vs. ioctl vs. sysfs? What are the criteria to apply? >> >> >> >> 5) Many of the modules support multiple modes, such as >> >> LoRa, LoRaWAN and FSK. >> >> Lacking a LoRaWAN implementation, I am currently >> >> switching them into LoRa >> >> mode at probe time wherever possible. How do we >> deal >> >> with that properly? >> >> >> >> a) Is there any precedence from the Wifi world for >> >> dynamically selecting >> >> between our own trusted Open Source >> implementation >> >> vs. hardware/firmware >> >> accelerated and/or certified implementations? >> >> >> >> b) Would a proof of concept for FSK (non-LoRa) modes >> be >> >> required for >> >> merging any LoRa driver for chipsets that support >> both? >> >> Or is there any >> >> facility or design guidelines that would allow us to >> focus >> >> on LoRa and >> >> LoRaWAN and leave non-LoRa radio modes to later >> >> contributors? >> > >> > Down the line I think we should also plan for a CRDA style >> regdb somewhere in the path for raw LoRa transceivers >> operating as softMAC, much like with WiFi. >> >> Yes, I had raised the topic of wireless-regdb for Stefan's >> conference - >> currently it seems to only cover 2.4 GHz, 5 GHz and 60 GHz. >> Not sure if >> we can easily extend that to cover 433 MHz, 868 MHz, 915 >> MHz and 923 MHz >> bands or whether we'd just need something similar... Is >> 802.15.4 able to >> share this database with Wifi? > > Well the README in the wireless-regdb doesn't bind itself to 80211, there are references to the other ETSI EN specs so this would be the place rather than duplicating. > There would need a bit of additional information to capture duty-cycle requirements, however the SRD spec states the maximum bandwidths can be 'The whole band', so with a flag set we could hijack this band information for duty-cycle. > I am unsure if 802.15.4 uses this database, most of the naming seems geared towards 80211, nl80211, cfg80211 so perhaps we need our own versions of these with a common component, I hope the maintainers can give some guidance here. > >> An argument to share with Wifi might be that Semtech's >> SX1280 and SX1281 >> 2.4 GHz transceivers claim to support LoRa modulation, too. >> Having two >> different regulatory DBs interact with LoRa drivers seems a >> bad idea, >> and duplicating 2.4 GHz into a new DB doesn't sound >> appealing either. > > Well I'm not sure if the modulation affects regulatory information, just bands, power, and techniques like DFS. > As these chips are 2.4GHz only I expect they are bound by the existing regulatory information we would just need a path to access it. > >> https://www.semtech.com/products/wireless-rf/24-ghz- >> transceivers >> >> Meanwhile my attempt to play with netlink during SUSE >> Hackweek has been >> going slow and I could use some guidance or a volunteer to >> contribute: I >> have a bare skeleton of registration, commands, attributes >> and multicast >> groups, but no plan yet how to connect that to the actual >> drivers to >> query or apply the settings... > > Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal. > >> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li >> nux-lora.git/tree/net/lora/netlink.c?h=lora-next Is this the repository used for the LoRa subsystem now?!!! If it is, than great! As the previous mails, I am trying to implement the LoRaWAN specification as the soft MAC as the MAC layer over LoRa PHY. This is the the talk about LoRaWAN class module I gave in Netdev Conf https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsystem The expectation is: socket APIs: send and receive the data ------------------------------------------------------------ LoRaWAN class module implements MAC: append the header/footer, encryption/decryption, timing slot and MAC commands ------------------------------------------------------------ LoRa device drivers: send and receive the messages for MAC layer ------------------------------------------------------------ LoRa devices Is it possible that combine the LoRaWAN class module I implemented? I start from the simplest class A end device's behavior, especially the timing slot. Also the encryption/decryption for uplink/downlink data messages. I can send it as patches. However, I have 2 problems right now. 1. Which Address and Protocol Family should we use? PF_LORA or PF_LORAWAN? 2. To test the LoRaWAN class module, adding more procedures in LoRa device drivers to register as a LoRaWAN device is needed. Regards, Jian-Hong Pan >> > LoRa radios used in Gateway devices are typically relatively >> high power (capable of 27dBm) and operate in bands with >> certain restrictions, eg the EU has keep out areas within >> 868MHz for alarms and SRD devices must abide by certain >> duty cycle restrictions, there are also maximum powers to >> consider for sub-bands. (ETSI EN 300 220-2 V3.2.1, Bands K, >> L, M, N, P, Q) >> >> > The certified AT style modules will (should) already have >> this regulatory data baked in so it only applied to situations >> where we drive the transceivers directly, but it wouldn't >> hurt to check that the frequency being asked to transmit on >> doesn't spill into a restricted band. >> >> Some do have configuration options that will need to be set >> or checked. >> >> Regards, >> Andreas >> >> -- >> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany >> GF: Felix Imendörffer, Jane Smithard, Graham Norton >> HRB 21284 (AG Nürnberg)
Hi Jian-Hong, Am 02.08.2018 um 09:52 schrieb Jian-Hong Pan: > 2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten@lairdtech.com>: >>> 1) PF_LORA/AF_LORA and associated identifiers are >>> proposed to represent >>> this technology. While for an SX1276 [...] it >>> might work to >>> layer LoRaWAN as a protocol option for PF_LORA and > add >>> LoRaWAN address >>> fields to the union in my sockaddr_lora, how would that >>> work for devices >>> that only support LoRaWAN but not pure LoRa? Do we >>> need both AF_LORA and >>> AF_LORAWAN, or just a separate ETH_P_LORAWAN or >>> ARPHRD_LORAWAN? [...] >>> Meanwhile my attempt to play with netlink during SUSE >>> Hackweek has been >>> going slow and I could use some guidance or a volunteer to >>> contribute: I >>> have a bare skeleton of registration, commands, attributes >>> and multicast >>> groups, but no plan yet how to connect that to the actual >>> drivers to >>> query or apply the settings... >> >> Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal. >> >>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li >>> nux-lora.git/tree/net/lora/netlink.c?h=lora-next > > Is this the repository used for the LoRa subsystem now?!!! > If it is, than great! Yes, my linux-lora.git contains this RFC patchset (modulo SX1276 fixes spotted by kbuild bot) plus a new serdev driver for another module and ongoing work by Ben and me for refactoring SX1301. It's monitored by the 0-day test service (kbuild bot). As this patchset was an RFC and does not have any Acked-bys from maintainers, the tree does not have a for-next branch integrated into linux-next on basis of 4.18-rc1, but instead (like my personal GitHub tree before) has a lora-next branch that rebases as patch queue on top of linux-next for now. The intent is to allow collaboration on getting things into a state that I can later submit a clean (squashed) RFC v2 for review, with all issues raised for this v1 addressed. For contributing patches to my linux-lora.git I suggest to use --subject-prefix="PATCH lora-next" to distinguish from net-next. And I just realize I should add a MAINTAINERS entry in my tree to make sure patches CC me, too. (I do monitor netdev for patches with subject "lora", but chances are someone might omit that.) > As the previous mails, I am trying to implement the LoRaWAN > specification as the soft MAC as the MAC layer over LoRa PHY. > This is the the talk about LoRaWAN class module I gave in Netdev Conf > https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsystem > > The expectation is: > > socket APIs: > send and receive the data > ------------------------------------------------------------ > LoRaWAN class module implements MAC: > append the header/footer, encryption/decryption, timing slot and MAC commands > ------------------------------------------------------------ > LoRa device drivers: > send and receive the messages for MAC layer > ------------------------------------------------------------ > LoRa devices Thanks for sharing your slides. We seem to be in alignment for the abstract concept above. The devil is in the implementation details. ^.- > Is it possible that combine the LoRaWAN class module I implemented? Yes, as stated in this cover letter, I would love if you could help merge your LoRaWAN implementation with my driver framework. Comparing 802.15.4 and 802.11, I think MAC code should go into net/maclorawan/ and then is a fairly independent module, with you as maintainer. > I start from the simplest class A end device's behavior, especially > the timing slot. > Also the encryption/decryption for uplink/downlink data messages. > I can send it as patches. > > However, I have 2 problems right now. > 1. Which Address and Protocol Family should we use? PF_LORA or PF_LORAWAN? That was one of the questions I raised above. I now think we need both. I'm not yet too deep into LoRaWAN, but from the AT command interfaces I've seen there's confirmed and unconfirmed transmission modes that with PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see a way of doing both on a single PF_LORA SOCK_LORAWAN socket? > 2. To test the LoRaWAN class module, adding more procedures in LoRa > device drivers to register as a LoRaWAN device is needed. No, I don't think so. There are (at least) two types of devices, LoRaWAN and LoRa devices. The SX1276 is a pure LoRa device and thus should only expose a LoRa network device. It'll be the task of the maclorawan module to translate between the two layers, not the business of the device driver; SX1276 should receive a ready-to-send LoRa skb. For Ethernet, PF_INET and PF_INET6 don't need separate devices either, both use eth0. What I do think we need is your struct lora_hw, maybe renamed to lora_phy. That could be the missing piece for registration of the device drivers with nllora module? Note that similarly we'll also need an nllorawan module that needs to work both with your maclorawan and with some of my device drivers that implement the MAC in an MCU. Additionally I've been looking into socket options at PF_LORA dgram layer for some radio options, but discarded that again for lack of precedence. Basically I wondered whether we could allow to choose SF, bandwidth, etc. on socket level and then apply those settings before sending one packet rather than expecting a global netlink operation that affects all sockets for that interface. Regards, Andreas
Hi Jian-Hong, Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: > 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>: >> 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode >> would be DGRAM plus preamble plus optional checksum. > > Is the preamble added by the hardware itself here or software here? That depends on the driver. For SX127x and any SX127x based modules it is added by hardware and a SOCK_RAW seems impossible. If you were to use some SDR hardware, it would need to be done by software and might either be done in the device driver for SOCK_DGRAM or by user with a SOCK_RAW. Right now I don't see a practical use case for the latter. (CC Pieter) >> 3) Only the transmit path is partially implemented already. The assumption >> is that the devices should go into receive mode by default and only >> interrupt that when asked to transmit. > > If it goes with LoRaWAN spec., end devices should be in idle (or > called standby mode) by default. Unless the device is asked to be in > transmitting or receiving timing slot. Whatever the LoRaWAN spec says, in practice struct net_device_ops has an ndo_start_xmit hook but no ndo_start_recv. All drivers that I've checked start receiving via interrupts after ndo_open has set things up. LoRa radio channels being half-duplex, we'd need to stop receiving in ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU. Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet. Are you suggesting to have dgram's recvmsg trigger the RX state somehow? It gets access to the net_device and could access dev.h struct lora_priv that we might extend to contain a LoRa-specific start_recv callback. And probably rename it more uniquely to lora_dev_priv while at it. The only other alternative I can think of would be to require the user to perform some netlink operation, possibly wrapped in some lora_ API, to actively put the device into receive mode. Doesn't sound desirable. >> 4) Some hardware settings need to be supplied externally, such as the radio >> frequency for some modules, but many others can be runtime-configured, >> such as Spreading Factor, Bandwidth, Sync Word, or which antenna to use. >> What settings should be implemented as socket option vs. netlink layer >> vs. ioctl vs. sysfs? What are the criteria to apply? > > - We can have a pre-defined table according to LoRaWAN Regional Parameters. > - Device driver declares the hardware's capability, for example > frequency, TX power. And then registers as a LoRaWAN compatible > device. That sounds like a layering violation. We rather need to expose all these tunable parameters individually at the LoRa layer, allowing the LoRaWAN layer to configure them as it pleases. Not the other direction. That still leaves my above question 4) open of how to implement each. The use case I have in mind is this: User A opens a LoRaWAN socket and using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters and LoRaWAN Sync Word need to be applied. User B then opens a pure LoRa socket and transmits a packet P1' with different Sync Word, SF, BW, CR, etc. Afterwards user A wants to send another packet P2 via LoRaWAN - this needs to use the same LoRaWAN settings as before, not those used for LoRa in between. Therefore I was thinking about socket-level options, as netlink operations would be device-wide, with undesired side-effects. Obviously in that scenario not both users can receive at the same time. If there was a way to start receiving only when a user performs such a socket operations, even this could be implemented - if incompatible reception can get detected and if the packet gets delivered to both, LoRa being broadcast. > - LoRaWAN module handle the requests from upper layer or MAC commands > from a gateway (netlink layer), than uses the pre-defined interface > functions to set the parameters. > > LoRaWAN module will export the operation functions interface. > >> 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK. >> Lacking a LoRaWAN implementation, I am currently switching them into LoRa >> mode at probe time wherever possible. How do we deal with that properly? > > - There are data rate tables defined in LoRaWAN Regional Parameters. > Those contain which data rate uses LoRa mode or FSK mode. That's missing my point, I fear. Independently of what LoRaWAN does, the user needs to be able to send on the physical layer from a selection of LoRa, GFSK, FSK, OOK, GMSK and MSK. Supposedly Wireless M-Bus and IEEE 802.15.4 can be implemented via those according to the SX1276 datasheet. This opens a can of worms... SX127x has a single channel, so I don't think there should be six network interfaces lora0, gfsk0, fsk0, ook0, gmsk0 and msk0 exposed to the user. Having a lora0 interface speak non-LoRa modulations may be confusing, but since the chip is sold as LoRa transceiver it might be acceptable. SX130x has 8+2 channels, with IF9 dedicated to GFSK/FSK. It appears to use one FIFO for receiving (up to 16 packets) and can only transmit one packet at a time. So I think this should be one lora0 interface, too. With a view to supporting non-LoRa RF chipsets such as Si4xxx (GFSK, FSK, OOK) or nRF905 and nRF24L01+ (both GFSK) at a later date, I don't think those modulations should be some netlink option on a PF_LORA interface but cleanly distinguished as ETH_P_GFSK or something. For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. The next question arising is how the user would create such an skb. Just like I was hesitant about PF_LORAWAN originally, I'd like to avoid polluting the PF_ number space for each of these. Maybe have one PF_FSK as equivalent to PF_LORA and then have either a socket option or sockaddr field to select the modulation variants? Not sure how exactly those others differ from each other, that's why I tried to postpone the FSK topic and to focus on LoRa first - b) below. At this point we could also argue whether we need a PF_LORA at all or rather just some generic PF_RADIO with lots of options stored in its sockaddr. One criteria will be whether we need multiple protocol options per modulation type or just one. For LoRa that was the dgram vs. raw discussion; for FSK/OOK I read packet mode vs. continuous mode in SX127x but not obvious if that affects the protocol or just the device driver. Getting back to your point, the data rate selection at LoRaWAN layer needs to determine how an skb gets passed between device driver and MAC. Another aspect FSK touches on is interactions with other subsystems. For example, how an sx1276 802.15.4 implementation for FSK/OOK (or LoRa, as you mentioned in your slides) would best interact with ieee802154 and mac802154 code when not done as standalone implementation. Or how to deal with SigFox on the same module as LoRaWAN - not aware of any kernel subsystem for SigFox. By comparison, on-module BLE sounds slightly easier, since it uses a separate antenna. (Haven't seen LoRa plus NB-IoT yet, to name the other LPWAN technology.) > - LoRaWAN should handle the data rate changing requests and then calls > the corresponding operation functions. Of course, the hardware's > capability registered before should also be under consideration at the > same time. > >> a) Is there any precedence from the Wifi world for dynamically selecting >> between our own trusted Open Source implementation vs. hardware/firmware >> accelerated and/or certified implementations? >> >> b) Would a proof of concept for FSK (non-LoRa) modes be required for >> merging any LoRa driver for chipsets that support both? Or is there any >> facility or design guidelines that would allow us to focus on LoRa and >> LoRaWAN and leave non-LoRa radio modes to later contributors? Regards, Andreas
Hi Andreas, 2018-08-03 16:44 GMT+08:00 Andreas Färber <afaerber@suse.de>: > Hi Jian-Hong, > > Am 02.08.2018 um 09:52 schrieb Jian-Hong Pan: >> 2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten@lairdtech.com>: >>>> 1) PF_LORA/AF_LORA and associated identifiers are >>>> proposed to represent >>>> this technology. While for an SX1276 [...] it >>>> might work to >>>> layer LoRaWAN as a protocol option for PF_LORA and >> add >>>> LoRaWAN address >>>> fields to the union in my sockaddr_lora, how would that >>>> work for devices >>>> that only support LoRaWAN but not pure LoRa? Do we >>>> need both AF_LORA and >>>> AF_LORAWAN, or just a separate ETH_P_LORAWAN or >>>> ARPHRD_LORAWAN? > [...] >>>> Meanwhile my attempt to play with netlink during SUSE >>>> Hackweek has been >>>> going slow and I could use some guidance or a volunteer to >>>> contribute: I >>>> have a bare skeleton of registration, commands, attributes >>>> and multicast >>>> groups, but no plan yet how to connect that to the actual >>>> drivers to >>>> query or apply the settings... >>> >>> Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal. >>> >>>> https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/li >>>> nux-lora.git/tree/net/lora/netlink.c?h=lora-next >> >> Is this the repository used for the LoRa subsystem now?!!! >> If it is, than great! > > Yes, my linux-lora.git contains this RFC patchset (modulo SX1276 fixes > spotted by kbuild bot) plus a new serdev driver for another module and > ongoing work by Ben and me for refactoring SX1301. It's monitored by the > 0-day test service (kbuild bot). > > As this patchset was an RFC and does not have any Acked-bys from > maintainers, the tree does not have a for-next branch integrated into > linux-next on basis of 4.18-rc1, but instead (like my personal GitHub > tree before) has a lora-next branch that rebases as patch queue on top > of linux-next for now. > > The intent is to allow collaboration on getting things into a state that > I can later submit a clean (squashed) RFC v2 for review, with all issues > raised for this v1 addressed. > > For contributing patches to my linux-lora.git I suggest to use > --subject-prefix="PATCH lora-next" to distinguish from net-next. > And I just realize I should add a MAINTAINERS entry in my tree to make > sure patches CC me, too. (I do monitor netdev for patches with subject > "lora", but chances are someone might omit that.) > >> As the previous mails, I am trying to implement the LoRaWAN >> specification as the soft MAC as the MAC layer over LoRa PHY. >> This is the the talk about LoRaWAN class module I gave in Netdev Conf >> https://www.slideshare.net/chienhungpan/lorawan-class-module-and-subsystem >> >> The expectation is: >> >> socket APIs: >> send and receive the data >> ------------------------------------------------------------ >> LoRaWAN class module implements MAC: >> append the header/footer, encryption/decryption, timing slot and MAC commands >> ------------------------------------------------------------ >> LoRa device drivers: >> send and receive the messages for MAC layer >> ------------------------------------------------------------ >> LoRa devices > > Thanks for sharing your slides. We seem to be in alignment for the > abstract concept above. The devil is in the implementation details. ^.- > >> Is it possible that combine the LoRaWAN class module I implemented? > > Yes, as stated in this cover letter, I would love if you could help > merge your LoRaWAN implementation with my driver framework. Comparing > 802.15.4 and 802.11, I think MAC code should go into net/maclorawan/ and > then is a fairly independent module, with you as maintainer. > >> I start from the simplest class A end device's behavior, especially >> the timing slot. >> Also the encryption/decryption for uplink/downlink data messages. >> I can send it as patches. >> >> However, I have 2 problems right now. >> 1. Which Address and Protocol Family should we use? PF_LORA or PF_LORAWAN? > > That was one of the questions I raised above. I now think we need both. > I'm not yet too deep into LoRaWAN, but from the AT command interfaces > I've seen there's confirmed and unconfirmed transmission modes that with > PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see > a way of doing both on a single PF_LORA SOCK_LORAWAN socket? > >> 2. To test the LoRaWAN class module, adding more procedures in LoRa >> device drivers to register as a LoRaWAN device is needed. > > No, I don't think so. There are (at least) two types of devices, LoRaWAN > and LoRa devices. The SX1276 is a pure LoRa device and thus should only > expose a LoRa network device. It'll be the task of the maclorawan module > to translate between the two layers, not the business of the device > driver; SX1276 should receive a ready-to-send LoRa skb. For Ethernet, > PF_INET and PF_INET6 don't need separate devices either, both use eth0. > > What I do think we need is your struct lora_hw, maybe renamed to > lora_phy. That could be the missing piece for registration of the device > drivers with nllora module? > Note that similarly we'll also need an nllorawan module that needs to > work both with your maclorawan and with some of my device drivers that > implement the MAC in an MCU. Let me think these twice. > Additionally I've been looking into socket options at PF_LORA dgram > layer for some radio options, but discarded that again for lack of > precedence. Basically I wondered whether we could allow to choose SF, > bandwidth, etc. on socket level and then apply those settings before > sending one packet rather than expecting a global netlink operation that > affects all sockets for that interface. According to the LoRaWAN Regional Parameters, we should have the APIs to set the SF, frequency, bandwidth ... The idea is: LoRaWAN class module gets the region of this device and the device's abilities. Then LoRaWAN class module calls the callback functions to set the related parameters: SF, frequency, bandwidth ... And of course, the setting actions only happen in the idle, standby or stop status. 1. Interface is being startup. 2. Requested by MAC command. But let start from simple case and add more features and complexity in the future. By the way, I am rearranging the module's code and try to make it could be patches. Regards, Jian-Hong Pan
Hi Ben and Jian-Hong, [- SPI - devicetree] Am 18.07.2018 um 13:28 schrieb Ben Whitten: >> Meanwhile my attempt to play with netlink during SUSE >> Hackweek has been >> going slow and I could use some guidance or a volunteer to >> contribute: I >> have a bare skeleton of registration, commands, attributes >> and multicast >> groups, but no plan yet how to connect that to the actual >> drivers to >> query or apply the settings... > > Happy to help, I will be starting from zero on netlink but I can contribute my existing work incorporating Marks comments for sx1301 etal. I've figured out a way to retrieve a frequency value via netlink: By passing the lora0 ifindex in as attribute, nllora can look up the net_device by index, and then via struct lora_dev_priv call into hooks that the device drivers can optionally implement. :) https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/net/lora/netlink.c?h=lora-next Tested with HIMO-01M module. The command might need an additional channel attribute for SX130x. The corresponding nltest program (using libnl-genl) is here: https://github.com/afaerber/lora-modules/blob/master/nltest.c Cheers, Andreas
Hi Alan, 2018-08-03 22:02 GMT+08:00 Alan Cox <gnomes@lxorguk.ukuu.org.uk>: >> I'm not yet too deep into LoRaWAN, but from the AT command interfaces >> I've seen there's confirmed and unconfirmed transmission modes that with >> PF_LORAWAN might be mapped to SOCK_STREAM and SOCK_DGRAM. Or do you see >> a way of doing both on a single PF_LORA SOCK_LORAWAN socket? > > SOCK_STREAM is not a confirmed message, but a reliable data stream where > packet boundaries have no meaning. > > SOCK_SEQPACKET is a reliable ordered stream where message boundaries have > meaning. > > SOCK_RDM is reliable messaging where there is no ordering. > > The standard socket API has no concept of a single connection doing both > reliable and unreliable messages. Thanks for the useful information. LoRaWAN has 4 kinds of data messages: Unconfirmed data up/down, Confirmed data up/down. Unconfirmed data up/down can be mapped to SOCK_DGRAM. Confirmed data up/down can be mapped to SOCK_SEQPACKET. Because, there is the FCnt (frame counter) field in frame header for the order. Regards, Jian-Hong Pan >> Additionally I've been looking into socket options at PF_LORA dgram >> layer for some radio options, but discarded that again for lack of >> precedence. Basically I wondered whether we could allow to choose SF, > > I don't know if it'll stretch that far in the right directions but to the > extent you can re-use bits of the wifi API and it makes sense it would be > good to do so. > > For stuff bound to a specific socket you need to use the generic SOCK_ > stuff or you may indeed need some socket options at the PF_LORA level - > which is fine, and the whole point of setsockopt passing layers around. > > Some of the existing general stuff like priority is probably quite > useable. > >> bandwidth, etc. on socket level and then apply those settings before >> sending one packet rather than expecting a global netlink operation that >> affects all sockets for that interface. > > Alan
On Sun, 5 Aug 2018 02:11:25 +0200 Andreas Färber <afaerber@suse.de> wrote: > Hi Jian-Hong, > > Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: > > 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>: > >> 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode > >> would be DGRAM plus preamble plus optional checksum. > > > > Is the preamble added by the hardware itself here or software here? > > That depends on the driver. For SX127x and any SX127x based modules it > is added by hardware and a SOCK_RAW seems impossible. If you were to use > some SDR hardware, it would need to be done by software and might either > be done in the device driver for SOCK_DGRAM or by user with a SOCK_RAW. > Right now I don't see a practical use case for the latter. (CC Pieter) For TCP/IP a SOCK_RAW is a socket with raw IP level access. It doesn't deal in IP headers and unless you ask it also does chunks of IP header stuff for you. SOCK_PACKET is the truely raw interface and even then it's rawness is bounded. You can't for example talk truely raw wifi bit streams, and for ethernet you get to generate MAC headers but not preambles etc. > LoRa radio channels being half-duplex, we'd need to stop receiving in > ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU. > Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet. Why - the signal is still floating around in the air, you can't unhear it at the antenna. If a given piece of hardware needs to flip between RX and TX mode then it should be handled by that driver. (Some ancient ethernet cards do this btw.. they can't listen and transmit at the same time) > > - We can have a pre-defined table according to LoRaWAN Regional Parameters. > > - Device driver declares the hardware's capability, for example > > frequency, TX power. And then registers as a LoRaWAN compatible > > device. > > That sounds like a layering violation. We rather need to expose all > these tunable parameters individually at the LoRa layer, allowing the > LoRaWAN layer to configure them as it pleases. Not the other direction. > That still leaves my above question 4) open of how to implement each. Wifi already has the general policy database for the various existing protocols. Please take a look at the CRDA agent and how it hooks into wireless.It might need to some tweaking but it would be odd to have different configuration schemes for different wifi protocols. > The use case I have in mind is this: User A opens a LoRaWAN socket and > using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters > and LoRaWAN Sync Word need to be applied. > User B then opens a pure LoRa socket and transmits a packet P1' with > different Sync Word, SF, BW, CR, etc. > Afterwards user A wants to send another packet P2 via LoRaWAN - this > needs to use the same LoRaWAN settings as before, not those used for > LoRa in between. Therefore I was thinking about socket-level options, as > netlink operations would be device-wide, with undesired side-effects. Agreed > Obviously in that scenario not both users can receive at the same time. That's a hardware question. Imagine a software defined radio. If your limitation wouldn't exist in a pure software defined radio then it's almost certainly a device level detal. > interface but cleanly distinguished as ETH_P_GFSK or something. > For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. Agreed if you can flip per packet. > The next question arising is how the user would create such an skb. Just > like I was hesitant about PF_LORAWAN originally, I'd like to avoid > polluting the PF_ number space for each of these. Maybe have one PF_FSK > as equivalent to PF_LORA and then have either a socket option or > sockaddr field to select the modulation variants? Not sure how exactly > those others differ from each other, that's why I tried to postpone the > FSK topic and to focus on LoRa first - b) below. > > At this point we could also argue whether we need a PF_LORA at all or > rather just some generic PF_RADIO with lots of options stored in its > sockaddr. What matters most is mux/demux. If you've got something listening to data but without the structure needed to identify multiple listeners and split out the data meaningfully to those listeners according to parts of the packet then you've got no reason to make it a protocol just use SOCK_PACKET and if need be BPF. The reason we have a socket layer not /dev/ethernet0 is that it's meaningful to divide messages up into flows, and to partition those flows securely amongst multiple consumers/generators. Alan
Am 08.08.2018 um 22:36 schrieb Alan Cox: > On Sun, 5 Aug 2018 02:11:25 +0200 > Andreas Färber <afaerber@suse.de> wrote: >> Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: >>> 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>: >> LoRa radio channels being half-duplex, we'd need to stop receiving in >> ndo_start_xmit and re-start receiving in the TX interrupt handler AFAIU. >> Yes, it's ugly - one reason I haven't implemented RX in sx1276 yet. > > Why - the signal is still floating around in the air, you can't unhear it > at the antenna. Why what? :) > If a given piece of hardware needs to flip between RX > and TX mode then it should be handled by that driver. Yes, and we are talking about that concrete sx1276 driver here, whose chipset has a state machine that only allows either rx or tx and also has standby and sleep modes with differing levels of data retention. The sx1301 is a different beast (and driver) and may allow both. In any case, the ndo_start_xmit hook is in each device driver. But the recvmsg hook I mentioned is at protocol layer, which exactly is the layering problem I see. > (Some ancient ethernet cards do this btw.. they can't listen and transmit > at the same time) So when do they start receiving? The issue here was that my original description, which you appear to have cut, suggested a continuous listen mode, interrupted by transmit. Jian-Hong didn't like that, with reference to the LoRaWAN spec that supposedly asks for only being in receive mode when expecting a message, likely to save on battery. So the question is, could we cleanly implement receiving only when the user asks us to, or is that a no-go? >>> - We can have a pre-defined table according to LoRaWAN Regional Parameters. >>> - Device driver declares the hardware's capability, for example >>> frequency, TX power. And then registers as a LoRaWAN compatible >>> device. >> >> That sounds like a layering violation. We rather need to expose all >> these tunable parameters individually at the LoRa layer, allowing the >> LoRaWAN layer to configure them as it pleases. Not the other direction. >> That still leaves my above question 4) open of how to implement each. > > Wifi already has the general policy database for the various existing > protocols. Please take a look at the CRDA agent and how it hooks into > wireless.It might need to some tweaking but it would be odd to have > different configuration schemes for different wifi protocols. CRDA/wireless-regdb had been brought up and I've been pointed to nl80211 and nl802154, which I've tried to make sense of for my initial nllora. Admittedly with limited success, as that code is slightly complex. We also seemed to have consensus here that we _should_ be reusing wireless-regdb but would need to extend it 1.) with sub-GHz frequency bands and 2.) duty-cycle limits for some of those bands. No maintainer commented on that so far. Thus I am working in tiny steps on providing netlink-layer commands in nllora that can dispatch the individual radio settings to drivers, which then upper layers can instrument as needed. And making my very first steps with netlink here, it appeared as if each technology has its own enums of commands and attributes, so I don't see how to reuse anything from Wifi here apart from some design inspiration. >> The use case I have in mind is this: User A opens a LoRaWAN socket and >> using maclorawan sends a packet P1. Here the LoRaWAN Regional Parameters >> and LoRaWAN Sync Word need to be applied. >> User B then opens a pure LoRa socket and transmits a packet P1' with >> different Sync Word, SF, BW, CR, etc. >> Afterwards user A wants to send another packet P2 via LoRaWAN - this >> needs to use the same LoRaWAN settings as before, not those used for >> LoRa in between. Therefore I was thinking about socket-level options, as >> netlink operations would be device-wide, with undesired side-effects. > > Agreed > >> Obviously in that scenario not both users can receive at the same time. > > That's a hardware question. Imagine a software defined radio. If your > limitation wouldn't exist in a pure software defined radio then it's > almost certainly a device level detal. An SDR would not be using this sx1276 device driver, I imagine. In fact I would expect an SDR device not to be in drivers/net/lora/ at all but to live in drivers/net/sdr/ and to consume ETH_P_LORA etc. skbs and just do the right thing for them depending on their type... >> interface but cleanly distinguished as ETH_P_GFSK or something. >> For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. > > Agreed if you can flip per packet. The SX127x can - it might involve delays of course. The SX130x doesn't even need to flip for sending AFAICT, it's just metadata after the payload in the FIFO. >> The next question arising is how the user would create such an skb. Just >> like I was hesitant about PF_LORAWAN originally, I'd like to avoid >> polluting the PF_ number space for each of these. Maybe have one PF_FSK >> as equivalent to PF_LORA and then have either a socket option or >> sockaddr field to select the modulation variants? Not sure how exactly >> those others differ from each other, that's why I tried to postpone the >> FSK topic and to focus on LoRa first - b) below. >> >> At this point we could also argue whether we need a PF_LORA at all or >> rather just some generic PF_RADIO with lots of options stored in its >> sockaddr. > > What matters most is mux/demux. > > If you've got something listening to data but without the structure > needed to identify multiple listeners and split out the data meaningfully > to those listeners according to parts of the packet then you've got no > reason to make it a protocol just use SOCK_PACKET and if need be BPF. Sorry, that doesn't parse for me. SOCK_PACKET must be a protocol on some PF_ protocol family, no? Are you suggesting I use SOCK_PACKET instead of SOCK_DGRAM in what is now net/lora/dgram.c? Or are you saying there's some generic implementation that we can reuse and scratch mine? > The reason we have a socket layer not /dev/ethernet0 is that it's > meaningful to divide messages up into flows, and to partition those flows > securely amongst multiple consumers/generators. For me the distinction is that a /dev/whatever0 would seem more suited for a stream of data to read/write, whereas sockets give us a bounded skb for packets at device driver level. These PHYs all broadcast something over the antenna when sending, with any addressing of listeners or senders being optional and MAC-specific, apart from the LoRa/FSK SyncWord as well as the various frequency etc. settings that determine what the receiver listens for. None of these PHYs define any mechanism like EtherType through which to identify upper-layer protocols. So in a way, listening is always in a promiscuous mode, and I guess we would need to try to parse each incoming packet as e.g. a LoRaWAN packet and just give up if it's too short or checksums don't match. Only at the layer of LoRaWAN and competing proprietary or custom protocols can we split received packets out to individual listeners. Does that give us any further clues for the design discussion here? Regards, Andreas
Am 05.08.2018 um 02:11 schrieb Andreas Färber: > Am 03.07.2018 um 17:11 schrieb Jian-Hong Pan: >> 2018-07-01 19:07 GMT+08:00 Andreas Färber <afaerber@suse.de>: >>> 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK. >>> Lacking a LoRaWAN implementation, I am currently switching them into LoRa >>> mode at probe time wherever possible. How do we deal with that properly? [...] > Independently of what LoRaWAN does, the > user needs to be able to send on the physical layer from a selection of > LoRa, GFSK, FSK, OOK, GMSK and MSK. > Supposedly Wireless M-Bus and IEEE 802.15.4 can be implemented via those > according to the SX1276 datasheet. > > This opens a can of worms... > > SX127x has a single channel, so I don't think there should be six > network interfaces lora0, gfsk0, fsk0, ook0, gmsk0 and msk0 exposed to > the user. > Having a lora0 interface speak non-LoRa modulations may be confusing, > but since the chip is sold as LoRa transceiver it might be acceptable. > > SX130x has 8+2 channels, with IF9 dedicated to GFSK/FSK. It appears to > use one FIFO for receiving (up to 16 packets) and can only transmit one > packet at a time. So I think this should be one lora0 interface, too. > > With a view to supporting non-LoRa RF chipsets such as Si4xxx (GFSK, > FSK, OOK) or nRF905 and nRF24L01+ (both GFSK) at a later date, I don't > think those modulations should be some netlink option on a PF_LORA > interface but cleanly distinguished as ETH_P_GFSK or something. > For example, the Chistera Pi HAT has both an RFM95W and an RFM22 module. Answering myself here: MSK is a special case of FSK, and GMSK a special case of GFSK. SX1276 allows to switch between LoRa and FSK/OOK modes, and in FSK/OOK mode between FSK and OOK modulation types and for FSK modulation allows to set Gaussian filter values. I assume (G)MSK is selected indirectly through BitRate and Fdev settings or something. So we would just need ETH_P_FSK and ETH_P_OOK plus some skb fields for ETH_P_FSK. Regards, Andreas
> Yes, and we are talking about that concrete sx1276 driver here, whose > chipset has a state machine that only allows either rx or tx and also > has standby and sleep modes with differing levels of data retention. It's a hardware limit, it should never influence the protocol stack itself just the driver. Linux always tries to design to optimize the non-crappy case. In the long term that works out best because hardware improves and you don't want to be tied to an old limit. > > (Some ancient ethernet cards do this btw.. they can't listen and transmit > > at the same time) > > So when do they start receiving? When they are not transmitting. The transmit path switches modes and when the frame send is done it goes back to receiving. As old ethernet was also half duplex that worked. > The issue here was that my original description, which you appear to > have cut, suggested a continuous listen mode, interrupted by transmit. I don't think I cut it but if so I didn't mean to and your approach is the one I agree with. > Jian-Hong didn't like that, with reference to the LoRaWAN spec that > supposedly asks for only being in receive mode when expecting a message, > likely to save on battery. So the question is, could we cleanly > implement receiving only when the user asks us to, or is that a no-go? Why would you do so ? You can't run Linux on a tiny little micro-controller where that would matter. Sure it makes sense for some tiny spec of embedded silicon buried in a sensor - but not a Linux box. Now you might power it down when the interface is down, or when there is nobody using that interface but that's really more about long term idle power. > bands and 2.) duty-cycle limits for some of those bands. No maintainer > commented on that so far. Thus I am working in tiny steps on providing > netlink-layer commands in nllora that can dispatch the individual radio > settings to drivers, which then upper layers can instrument as needed. Sounds right to me. > > And making my very first steps with netlink here, it appeared as if each > technology has its own enums of commands and attributes, so I don't see > how to reuse anything from Wifi here apart from some design inspiration. That seems reasonable - you aren't likely to want to manage them with the same tool. > > That's a hardware question. Imagine a software defined radio. If your > > limitation wouldn't exist in a pure software defined radio then it's > > almost certainly a device level detal. > > An SDR would not be using this sx1276 device driver, I imagine. > > In fact I would expect an SDR device not to be in drivers/net/lora/ at > all but to live in drivers/net/sdr/ and to consume ETH_P_LORA etc. skbs > and just do the right thing for them depending on their type... The point I was trying to make was that if you want to decide whether something is driver level or protocol level ask 'is this something you can't do even with an SDR'. Some things are protocol properties that no fancy hardware will change. Others are hardware limits, in which case you want them driver level - because at some point the hardware will get better. > > If you've got something listening to data but without the structure > > needed to identify multiple listeners and split out the data meaningfully > > to those listeners according to parts of the packet then you've got no > > reason to make it a protocol just use SOCK_PACKET and if need be BPF. > > Sorry, that doesn't parse for me. SOCK_PACKET must be a protocol on some > PF_ protocol family, no? Are you suggesting I use SOCK_PACKET instead of > SOCK_DGRAM in what is now net/lora/dgram.c? Or are you saying there's > some generic implementation that we can reuse and scratch mine? There is a heirarchy. Let me us IP for an example (historically it was SOCK_PACKET nowdays PF_PACKET - the layering got sorted better) PF_PACKET SOCK_RAW ETH_P_ALL Everything on that device minus some things like hardware pre-ambles PF_PACKET SOCK_RAW ETH_P_SOMETHING Everything on that device that has the underlying protocol (and the protocol might not be in the packet but a property of the interface because it only does that format - simple example SLIP is IP packets over a serial link a SLIP interface is IP, not because there is anything saying it is but because that is *all* it can be) You get the two above for free. PF_PACKET is built into the stack so providing you label packets with the ETH_P_xxx you have for Lora, you can use PF_PACKET interfaces to dump them and write raw packets at the kernel layer. PF_INET SOCK_RAW Split the messages by protocol number in IP between multiple listeners/writers PF_INET SOCK_UDP / TCP etc Split the messages by port numbers in the higher level protocol For PF_LORA these would map to whatever goes on at the LORA protocol level and divide LORA messages up between multiple processes on the Linux system that are interested in some of the messages. > > The reason we have a socket layer not /dev/ethernet0 is that it's > > meaningful to divide messages up into flows, and to partition those flows > > securely amongst multiple consumers/generators. > > For me the distinction is that a /dev/whatever0 would seem more suited > for a stream of data to read/write, whereas sockets give us a bounded > skb for packets at device driver level. You could equally do that in a simple character device *if* you didn't need to split messages up and share between users. Some protocol stacks actually do that and then sort it out in user space, either because they are really obscure or they are incredibly complicated and broken so want to be out of kernel 8) > These PHYs all broadcast something over the antenna when sending, with > any addressing of listeners or senders being optional and MAC-specific, > apart from the LoRa/FSK SyncWord as well as the various frequency etc. > settings that determine what the receiver listens for. > > None of these PHYs define any mechanism like EtherType through which to > identify upper-layer protocols. > > So in a way, listening is always in a promiscuous mode, and I guess we > would need to try to parse each incoming packet as e.g. a LoRaWAN packet > and just give up if it's too short or checksums don't match. Only at the > layer of LoRaWAN and competing proprietary or custom protocols can we > split received packets out to individual listeners. My vote would be in that case that you either 1. Set the protocol type on the interface assuming you don't mix and match (and if it's relying on random bits not looking like other packets then it sounds a complete mess at the moment - but yeah its new tech) 2. You pass everything up to some magical agent which somehow splits them up and labels them ETH_P_LORA / ETH_P_FOO etc 3. You do what ethernet does (which admittedly is *way* simpler for ethernet) and you have a library routine you can pass an skbuff in the driver itself which figures out wtf to label the packet. Look how eth_type_trans() is used. Drivers then just do skb->protocol = xxx_type_trans(skb, dev); and the basic labelling gets done and any header pulls (you probably won't have any given you don't have anything wrapping LORA), and multicast/broadcast labelling - again meaningless I suspect. #3 Is probably the nicest because you update it all in one place as standards change and the market hopefully conslidates and develops some kind of sane packet formats. It's also effectively covering #1 and it's easy to start with because an initial implementation can just do 'return htons(ETH_P_LORA)'. > > Does that give us any further clues for the design discussion here? > I think so yes How do you plan to deal with routing if you've got multiple devices ? Alan
Alan Cox <gnomes@lxorguk.ukuu.org.uk> 於 2018年8月9日 週四 下午7:59寫道： > > > Yes, and we are talking about that concrete sx1276 driver here, whose > > chipset has a state machine that only allows either rx or tx and also > > has standby and sleep modes with differing levels of data retention. > > It's a hardware limit, it should never influence the protocol stack > itself just the driver. Linux always tries to design to optimize the > non-crappy case. In the long term that works out best because hardware > improves and you don't want to be tied to an old limit. > > > > (Some ancient ethernet cards do this btw.. they can't listen and transmit > > > at the same time) > > > > So when do they start receiving? > > When they are not transmitting. The transmit path switches modes and when > the frame send is done it goes back to receiving. As old ethernet was > also half duplex that worked. > > > The issue here was that my original description, which you appear to > > have cut, suggested a continuous listen mode, interrupted by transmit. > > I don't think I cut it but if so I didn't mean to and your approach is > the one I agree with. > > > Jian-Hong didn't like that, with reference to the LoRaWAN spec that > > supposedly asks for only being in receive mode when expecting a message, > > likely to save on battery. So the question is, could we cleanly > > implement receiving only when the user asks us to, or is that a no-go? > > Why would you do so ? You can't run Linux on a tiny little > micro-controller where that would matter. Sure it makes sense for some > tiny spec of embedded silicon buried in a sensor - but not a Linux box. > > Now you might power it down when the interface is down, or when there is > nobody using that interface but that's really more about long term idle > power. Except saving power, mitigating the wireless signal conflict on the air is one of the reasons. According to the LoRaWAN spec. defined by LoRa Alliance, all LoRaWAN end devices must implement class A features, which is also the most general and simplest. 1. The transmission slot scheduled by the end-device is based on its own communication needs with a small variation based on a random time basis (ALOHA-type of protocol). 2. Only require downlink communication from the server shortly after the end-device has sent an uplink transmission. Downlink communications from the server at any other time will have to wait until the next scheduled uplink. 3. Each end-device‘s uplink transmission is followed by two short downlink receive windows. End device transmits an uplink message finished -> End device goes to sleep/idle/stop -> End device opens RX1 window. This is the time for the downlink message. -> End device goes to sleep/idle/stop -> End device opens RX2 window. This is another time for the downlink message. -> End device goes to sleep/idle/stop The time between end device transmit an uplink message finished and end device opens RX1 window is RX delay #1. The time between end device transmit an uplink message finished and end device opens RX2 window is RX delay #2. If end device gets the meaningful downlink message in RX1 window, it will not open RX2 window. The time of RX delay #1 and 2 are defined in LoRaWAN Regional Parameters. The sleep/idle/stop mitigate the unconcerned RF signals or messages. > > bands and 2.) duty-cycle limits for some of those bands. No maintainer > > commented on that so far. Thus I am working in tiny steps on providing > > netlink-layer commands in nllora that can dispatch the individual radio > > settings to drivers, which then upper layers can instrument as needed. > > Sounds right to me. > > > > And making my very first steps with netlink here, it appeared as if each > > technology has its own enums of commands and attributes, so I don't see > > how to reuse anything from Wifi here apart from some design inspiration. > > That seems reasonable - you aren't likely to want to manage them with the > same tool. > > > > That's a hardware question. Imagine a software defined radio. If your > > > limitation wouldn't exist in a pure software defined radio then it's > > > almost certainly a device level detal. > > > > An SDR would not be using this sx1276 device driver, I imagine. > > > > In fact I would expect an SDR device not to be in drivers/net/lora/ at > > all but to live in drivers/net/sdr/ and to consume ETH_P_LORA etc. skbs > > and just do the right thing for them depending on their type... > > The point I was trying to make was that if you want to decide whether > something is driver level or protocol level ask 'is this something you > can't do even with an SDR'. Some things are protocol properties that no > fancy hardware will change. Others are hardware limits, in which case you > want them driver level - because at some point the hardware will get > better. > > > > If you've got something listening to data but without the structure > > > needed to identify multiple listeners and split out the data meaningfully > > > to those listeners according to parts of the packet then you've got no > > > reason to make it a protocol just use SOCK_PACKET and if need be BPF. > > > > Sorry, that doesn't parse for me. SOCK_PACKET must be a protocol on some > > PF_ protocol family, no? Are you suggesting I use SOCK_PACKET instead of > > SOCK_DGRAM in what is now net/lora/dgram.c? Or are you saying there's > > some generic implementation that we can reuse and scratch mine? > > There is a heirarchy. Let me us IP for an example > > (historically it was SOCK_PACKET nowdays PF_PACKET - the layering got > sorted better) > > PF_PACKET SOCK_RAW ETH_P_ALL > > Everything on that device minus some things like hardware pre-ambles > > PF_PACKET SOCK_RAW ETH_P_SOMETHING > > Everything on that device that has the underlying protocol (and the > protocol might not be in the packet but a property of the interface > because it only does that format - simple example SLIP is IP packets over > a serial link a SLIP interface is IP, not because there is anything > saying it is but because that is *all* it can be) > > You get the two above for free. PF_PACKET is built into the stack so > providing you label packets with the ETH_P_xxx you have for Lora, you can > use PF_PACKET interfaces to dump them and write raw packets at the kernel > layer. > > PF_INET SOCK_RAW > > Split the messages by protocol number in IP between multiple > listeners/writers > > PF_INET SOCK_UDP / TCP etc > > Split the messages by port numbers in the higher level protocol > > > For PF_LORA these would map to whatever goes on at the LORA protocol > level and divide LORA messages up between multiple processes on the > Linux system that are interested in some of the messages. > > > > > The reason we have a socket layer not /dev/ethernet0 is that it's > > > meaningful to divide messages up into flows, and to partition those flows > > > securely amongst multiple consumers/generators. > > > > For me the distinction is that a /dev/whatever0 would seem more suited > > for a stream of data to read/write, whereas sockets give us a bounded > > skb for packets at device driver level. > > You could equally do that in a simple character device *if* you didn't > need to split messages up and share between users. Some protocol stacks > actually do that and then sort it out in user space, either because they > are really obscure or they are incredibly complicated and broken so want > to be out of kernel 8) > > > These PHYs all broadcast something over the antenna when sending, with > > any addressing of listeners or senders being optional and MAC-specific, > > apart from the LoRa/FSK SyncWord as well as the various frequency etc. > > settings that determine what the receiver listens for. > > > > None of these PHYs define any mechanism like EtherType through which to > > identify upper-layer protocols. > > > > So in a way, listening is always in a promiscuous mode, and I guess we > > would need to try to parse each incoming packet as e.g. a LoRaWAN packet > > and just give up if it's too short or checksums don't match. Only at the > > layer of LoRaWAN and competing proprietary or custom protocols can we > > split received packets out to individual listeners. > > My vote would be in that case that you either > > 1. Set the protocol type on the interface assuming you don't mix and > match (and if it's relying on random bits not looking like other packets > then it sounds a complete mess at the moment - but yeah its new tech) > > 2. You pass everything up to some magical agent which somehow splits them > up and labels them ETH_P_LORA / ETH_P_FOO etc > > 3. You do what ethernet does (which admittedly is *way* simpler for > ethernet) and you have a library routine you can pass an skbuff in the > driver itself which figures out wtf to label the packet. Look how > eth_type_trans() is used. Drivers then just do > > skb->protocol = xxx_type_trans(skb, dev); > > and the basic labelling gets done and any header pulls (you probably won't > have any given you don't have anything wrapping LORA), and > multicast/broadcast labelling - again meaningless I suspect. > > #3 Is probably the nicest because you update it all in one place as > standards change and the market hopefully conslidates and develops some > kind of sane packet formats. It's also effectively covering #1 and it's > easy to start with because an initial implementation can just do 'return > htons(ETH_P_LORA)'. > > > > > Does that give us any further clues for the design discussion here? > > > I think so yes > > How do you plan to deal with routing if you've got multiple devices ? For LoRaWAN, it is a star topology. One end device and one LoRaWAN gateway: An end device sends a uplink message to the LoRaWAN gateway directly. A LoRaWAN gateway receives the uplink message, then transfers to the LoRaWAN network server. The network server sends a downlink message to the end device via the transfer of the LoRaWAN gateway. Multiple end devices and multiple LoRaWAN gateway: Multiple end devices can send uplink messages to multiple LoRaWAN gateways directly. Gateways receive the the uplink messages, then transfer to the LoRaWAN network server. The LoRaWAN network server compares the uplink messages' content to filter out the duplicated messages. The LoRaWAN network server sends a downlink message to the end device via the transfer of only one chosen LoRaWAN gateway. So, an end device does not talk to other end devices directly. And, of course, the links between LoRaWAN gateway and the network server could be any network technology, only if they can communicate with each other fast enough. Regards, Jian-Hong Pan
Hi, On Thu, Aug 09, 2018 at 12:59:39PM +0100, Alan Cox wrote: > > Yes, and we are talking about that concrete sx1276 driver here, whose > > chipset has a state machine that only allows either rx or tx and also > > has standby and sleep modes with differing levels of data retention. > > It's a hardware limit, it should never influence the protocol stack > itself just the driver. Linux always tries to design to optimize the > non-crappy case. In the long term that works out best because hardware > improves and you don't want to be tied to an old limit. > > > > (Some ancient ethernet cards do this btw.. they can't listen and transmit > > > at the same time) > > > > So when do they start receiving? > > When they are not transmitting. The transmit path switches modes and when > the frame send is done it goes back to receiving. As old ethernet was > also half duplex that worked. > We do the same at some IEEE 802.15.4 transceivers. A transceiver has _one_ framebuffer only for tx and rx. Another one has two framebuffer separated tx and rx, but is half duplex. There is a little performance tweak in separated framebuffers that you can fill up the tx framebuffer while the transceiver receives the frame (completely independet from any bus communicaten/linux handling). > > The issue here was that my original description, which you appear to > > have cut, suggested a continuous listen mode, interrupted by transmit. > > I don't think I cut it but if so I didn't mean to and your approach is > the one I agree with. > ... > > There is a heirarchy. Let me us IP for an example > > (historically it was SOCK_PACKET nowdays PF_PACKET - the layering got > sorted better) > > PF_PACKET SOCK_RAW ETH_P_ALL > > Everything on that device minus some things like hardware pre-ambles > > PF_PACKET SOCK_RAW ETH_P_SOMETHING > > Everything on that device that has the underlying protocol (and the > protocol might not be in the packet but a property of the interface > because it only does that format - simple example SLIP is IP packets over > a serial link a SLIP interface is IP, not because there is anything > saying it is but because that is *all* it can be) > > You get the two above for free. PF_PACKET is built into the stack so > providing you label packets with the ETH_P_xxx you have for Lora, you can > use PF_PACKET interfaces to dump them and write raw packets at the kernel > layer. > In 802.15.4: We recommend nowadays to use PF_PACKET raw sockets for construct L2 frames in userspace. We use that mostly to connect some user space stacks to make some interop testing without hardware being involved. For DGRAM sockets, due lack of UAPI limitations of sockaddr_t we have our own implementation. DGRAM in PF_PACKET use some limitated feature to "just send something" to an unique address scheme... but some users need more access because 802.15.4 address scheme is complex. > PF_INET SOCK_RAW I think LoRa should look into the 6lowpan subsystem of the Linux kernel for that. 6lowpan is known as some "IPv6-over-foo" adaptations. Mostly you just need to implement some mapping from L2 address to SLAAC IPv6 address pattern only. I see there is a draft at 6lo wg [0] for that which is expired 2016 (But I would not care about that). At the end you have a master IP capable interface and your slave is your L2 interface. The 6lowpan interface is a RAW IP interface and do a protocol translation in the background. On L2 interface you will see L2 + 6LoWPAN + $IP_UPPER_LAYER. Current benefits are more compression, but there exists also some ndisc optimizations for low power networks which we don't support right now. - Alex [0] https://www.ietf.org/archive/id/draft-vilajosana-6lpwa-lora-hc-01.txt
Hi, On Thu, Aug 09, 2018 at 11:02:45PM +0800, Jian-Hong Pan wrote: ... > > For LoRaWAN, it is a star topology. > In sense of 6LoWPAN that means "border router" in the middle which runs radvd on it and sending RA messages. Then doing a route (or even allow nd proxy) between capable $IPv6 (ethernet?) and LoRa 6LoWPAN interface. All others listen for RA messages with PIO and doing autoconfiguration. (In 6LoWPAN you would also pass a 6CO option to compress the PIO prefix, which would make sense to fully elide all IP addresses in the header). - Alex
> Except saving power, mitigating the wireless signal conflict on the > air is one of the reasons. If the device level is always receiving when not transmitting it has no effect on this. The act of listening does not harm other traffic. > The sleep/idle/stop mitigate the unconcerned RF signals or messages. At the physical level it's irrelevant. If we are receiving then we might hear more things we later discard. It's not running on a tiny microcontroller so the extra CPU cycles are not going to kill us. > > How do you plan to deal with routing if you've got multiple devices ? > > For LoRaWAN, it is a star topology. No the question was much more how you plan to deal with it in the OS. If for example I want to open a LORA connection to something, then there needs to be a proper process to figure out where the target is and how to get traffic to them. I guess it's best phrased as - What does a struct sockaddr_lora look like - How does the kernel decide which interface it goes out of (if any), and if it loops back remembering we might only be talking to a hub, or we might even be a virtualized LORA interface where we are pretending to be some kind of sensor and feeding it back. Long term yes I think Alexander is right the inevitable fate of all networks is to become a link layer in order to transmit IP frames 8) Alan
Hello. On 08/10/2018 05:57 PM, Alan Cox wrote: > > Long term yes I think Alexander is right the inevitable fate of all > networks is to become a link layer in order to transmit IP frames 8) There should be a niche for both at the same time. LoRaWAN is relevant right now and we should aim for making it possible to run a native Linux gateway for it. As for IP for long range low power there is the static context header compression draft to adapt IPv6 to the characteristics for some use cases of such networks. Implementing it within the existing 6lwopan subsystem should be possible. https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16 regards Stefan Schmidt
Alan Cox <gnomes@lxorguk.ukuu.org.uk> 於 2018年8月10日 週五 下午11:57寫道： > > > Except saving power, mitigating the wireless signal conflict on the > > air is one of the reasons. > > If the device level is always receiving when not transmitting it has no > effect on this. The act of listening does not harm other traffic. My friend had tested practically: If he changes the LoRa interface to RX mode after TX completes immediately, he will receive the signals like reflection echo some times. That is interesting! There is a paper "Exploring LoRa and LoRaWAN A suitable protocol for IoT weather stations?" by Kristoffer Olsson & Sveinn Finnsson http://publications.lib.chalmers.se/records/fulltext/252610/252610.pdf In chapter 3.2 Chirp Spread Spectrum, it describes the reflection echo phenomenon. I think that is why LoRaWAN places the RX delay time which avoids receiving the reflection noise. > > The sleep/idle/stop mitigate the unconcerned RF signals or messages. > > At the physical level it's irrelevant. If we are receiving then we might > hear more things we later discard. It's not running on a tiny > microcontroller so the extra CPU cycles are not going to kill us. According different power resource, LoRaWAN defines Class A, B and C. Class A is the basic and both Class B and C devices must also implement the feature of Class A. If the end device has sufficient power available, it can also implement the Class C: Continuously listening end-device. Here are the descriptions in LoRaWAN spec. for Class C: - The Class C end-device will listen with RX2 windows parameters as often as possible. - The end-device listens on RX2 when it is not either (a) sending or (b) receiving on RX1, according to Class A definition. - 1. It will open a short window on RX2 parameters between the end of the uplink transmission and the beginning of the RX1 reception window. (*) 2. It will switch to RX2 reception parameters as soon as the RX1 reception window is closed; the RX2 reception window will remain open until the end-device has to send another message. According to the LoRaWAN Regional Parameters, the DataRate (including spreading factor and bandwidth) and frequency channel of RX1 and RX2 windows may be different.(*) So, yes! Class C opens the RX windows almost all the time, except the TX time. And uses different channel to avoid the reflection noise (*). However, Class C must also implements Class A and C is more complex than A. I think starting from the simpler one and adding more features and complexity in the future will be a better practice. > > > How do you plan to deal with routing if you've got multiple devices ? > > > > For LoRaWAN, it is a star topology. > > No the question was much more how you plan to deal with it in the OS. If > for example I want to open a LORA connection to something, then there > needs to be a proper process to figure out where the target is and how to > get traffic to them. > > I guess it's best phrased as > > - What does a struct sockaddr_lora look like According to LoRaWAN spec, the Data Message only has the device's DevAddr (the device's address in 4 bytes) field related to "address". The device just sends the uplink Data Message through the interface and does not know the destination. Then, a LoRaWAN gateway receives the uplink Data Message and forwards to the designated network server. So, end device does not care about the destination. It only knows there is a gateway will forward its message to some where. Therefore, only the DevAddr as the source address will be meaningful for uplink Data Message. > - How does the kernel decide which interface it goes out of (if any), and > if it loops back There is the MAC Header in the Data Message which is one byte. Bits 5 to 7 indicate which kind of type the message is. 000: Join Request 001: Join Accept 010: Unconfirmed Data Up 011: Unconfirmed Data Down 100: Confirmed Data Up 101: Confirmed Data Down 110: RFU 111: Proprietary So, end device only accepts the types of downlink and the matched DevAddr (the device's address) in downlink Data Message for RX. > remembering we might only be talking to a hub, or we might even be a > virtualized LORA interface where we are pretending to be some kind of > sensor and feeding it back. > > Long term yes I think Alexander is right the inevitable fate of all > networks is to become a link layer in order to transmit IP frames 8) Yeah, maybe. It will be easier for life. But I have not seen the formal standard for that yet or I missed it. If the standard appears, we can try to implement it. Jian-Hong Pan
Hi, Am 11.08.2018 um 20:30 schrieb Stefan Schmidt: > On 08/10/2018 05:57 PM, Alan Cox wrote: >> >> Long term yes I think Alexander is right the inevitable fate of all >> networks is to become a link layer in order to transmit IP frames 8) > > There should be a niche for both at the same time. LoRaWAN is relevant > right now and we should aim for making it possible to run a native Linux > gateway for it. +1 > As for IP for long range low power there is the static context header > compression draft to adapt IPv6 to the characteristics for some use > cases of such networks. Implementing it within the existing 6lwopan > subsystem should be possible. > > https://tools.ietf.org/html/draft-ietf-lpwan-ipv6-static-context-hc-16 I'm open to supporting by appropriate design all kinds of upper layers people want to experiment with. Review feedback for that is welcome. However I don't intend to implement each of those myself, and hardcoding them is not really an option so they must be in appropriate modules. Do keep in mind that depending on vendor implementation we have between 26 and 2048 bytes MTU available, less based on regulatory requirements, often below 256 bytes. The more space we take away for frame headers just because they're somehow standardized will make it less useful. Regards, Andreas
Am 12.08.2018 um 18:37 schrieb Jian-Hong Pan: > Alan Cox <gnomes@lxorguk.ukuu.org.uk> 於 2018年8月10日 週五 下午11:57寫道： >> >>> The sleep/idle/stop mitigate the unconcerned RF signals or messages. >> >> At the physical level it's irrelevant. If we are receiving then we might >> hear more things we later discard. It's not running on a tiny >> microcontroller so the extra CPU cycles are not going to kill us. > > According different power resource, LoRaWAN defines Class A, B and C. > Class A is the basic and both Class B and C devices must also > implement the feature of Class A. [...] > So, yes! Class C opens the RX windows almost all the time, except the TX time. > And uses different channel to avoid the reflection noise (*). > > However, Class C must also implements Class A and C is more complex than A. > I think starting from the simpler one and adding more features and > complexity in the future will be a better practice. Jian-Hong, you've failed to come up with any practical proposal or patch how to implement what you are saying LoRaWAN requires. Doing the impossible is never simpler! Implementing a simple back-off timer sounds doable by comparison. May I remind you, LoRa is the simpler step before LoRaWAN - if our layering is done right, someone else might choose to implement LoRaWAN in userspace based on PF_LORA. There is absolutely no reason to hardcode any LoRaWAN settings at device driver level for e.g. SX1276. >>>> How do you plan to deal with routing if you've got multiple devices ? >>> >>> For LoRaWAN, it is a star topology. >> >> No the question was much more how you plan to deal with it in the OS. If >> for example I want to open a LORA connection to something, then there >> needs to be a proper process to figure out where the target is and how to >> get traffic to them. >> >> I guess it's best phrased as >> >> - What does a struct sockaddr_lora look like > > According to LoRaWAN spec, the Data Message only has the device's > DevAddr (the device's address in 4 bytes) field related to "address". > The device just sends the uplink Data Message through the interface > and does not know the destination. Then, a LoRaWAN gateway receives > the uplink Data Message and forwards to the designated network server. > So, end device does not care about the destination. It only knows > there is a gateway will forward its message to some where. > Therefore, only the DevAddr as the source address will be meaningful > for uplink Data Message. Note that he was asking about sockaddr_lora, not LoRaWAN. The simple answer is that, inspired by CAN, it uses an ifindex to select the interface the user asked to use. That then also answers Alan's next question: This ifindex determines which interface it goes out to. sockaddr_lora was in patch 02/15, latest code here: https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/include/uapi/linux/lora.h?h=lora-next >> - How does the kernel decide which interface it goes out of (if any), and >> if it loops back > > There is the MAC Header in the Data Message which is one byte. > Bits 5 to 7 indicate which kind of type the message is. > 000: Join Request > 001: Join Accept > 010: Unconfirmed Data Up > 011: Unconfirmed Data Down > 100: Confirmed Data Up > 101: Confirmed Data Down > 110: RFU > 111: Proprietary > > So, end device only accepts the types of downlink and the matched > DevAddr (the device's address) in downlink Data Message for RX. LoRaWAN is an entirely different story, therefore my agreement that we need a separate PF_LORAWAN and sockaddr_lorawan for EUI addressing. I still think the user will need to explicitly say which interface they want to bind their socket to. AFAIU the device EUI is more comparable to an Ethernet MAC address than to an IP address that the user would configure routes for. If you have e.g. four SX1301 devices then they may be configured for different frequencies, bandwidths, etc. but unlikely for certain destination/source addresses. So either all that data comes via sockaddr (which I was discussing in the FSK/OOK part of this thread) or the user needs to make the interface choice for us. Loopback mode would require a separate virtual device driver such as fakelr or vlora. Regards, Andreas
> The simple answer is that, inspired by CAN, it uses an ifindex to select > the interface the user asked to use. That then also answers Alan's next > question: This ifindex determines which interface it goes out to. > > sockaddr_lora was in patch 02/15, latest code here: > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/include/uapi/linux/lora.h?h=lora-next And any loopback just becomes an ifindex, likewise any virtual lorawan device (eg when testing in a cloud or simulating radio properties). > I still think the user will need to explicitly say which interface they > want to bind their socket to. AFAIU the device EUI is more comparable to It does make it very hard for any vaguely complex environment because if for example you have two interfaces enumerated via USB they will appear in random order each boot. CANbus is a bit of a mess in this sense but it's so statically configured and embedded into industrial devices it's less of a problem. I just wonder if the name would be a better binding (so you can sort the order out), or a local physical identifier of some kind so that your enumeration is consistent. > Loopback mode would require a separate virtual device driver such as > fakelr or vlora. And a tunnel device, which is easy enough if you've got tap support or similar. Alan
Hello, LoRa is a long-range, low-power wireless technology by Semtech. Unlike other LPWAN technologies, users don't need to rely on infrastructure providers and SIM cards and expensive subscription plans, they can set up their own gateways. Modules, adapters and evaluation boards are available from a large number of vendors. Many vendors also make available Open Source software examples on GitHub. But when taking a closer look, many of them combine licenses in ways that are not redistributable. My reports have remained without response or solution. https://github.com/ernstdevreede/lmic_pi/issues/2 https://github.com/Snootlab/lmic_chisterapi/issues/2 https://github.com/Snootlab/lora_chisterapi/issues/2 Another issue was that most such projects around the Raspberry Pi make use of spidev to communicate with the Semtech chipsets from userspace. The Linux spi maintainers have chosen to greet any such users of spidev with a friendly WARN_ON(), preferring in-kernel spi drivers and white-listing individual devices only. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c?h=v4.17#n722 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/spi/spidev.c?h=v4.17#n667 Also I don't quite see the point in having userspace probe what SPI devices are connected to a generic spidev driver when we have an easy Device Tree hardware description on arm/arm64 that could give us that info. I raised the topic during Q&A of a FOSDEM 2017 talk (cut off at the end of the video) but unfortunately found no one to collaborate on this. https://archive.fosdem.org/2017/schedule/event/lorawan/ Instead of porting from wiringPi to a differently licensed GPIO library and dealing with seemingly unmaintained LoRaWAN code dumps, I started a spi kernel driver for SX1276 back in 2016. But obviously a kernel driver isn't too helpful without a userspace API to send and receive packets. This patchset, updated from 2017 and extended, is implementing kernel drivers for various LoRa chipsets and modules. As API I'm proposing a PF_LORA socket implementation. Why? LoRa uses data packets with headers and checksums and differing MTUs and multiple protocols layered on top of it. Apart from simple headers for addressing used by RadioHead library and IMST's LoRa P2P protocol, the main use case (not implemented in this patchset) is expected to be LoRaWAN. And LoRaWAN has competing proprietary protocols, such as Link Labs' Symphony Link or GlobalSat M.O.S.T. or RadioShuttle, that might at some point want to adopt a standard API for their implementations, too. Ready-made LoRa hardware modules come in three flavors, a) with SPI access to the underlying Semtech chipsets, needing a software implementation of e.g. LoRaWAN protocol stack (i.e., a soft MAC), b) with a custom, often UART based interface and a pre-certified LoRaWAN protocol stack already integrated (i.e., hard/full MAC), and c) with a microcontroller that serves not only for the protocol stack but also as application processor, not offering a ready-made interface. This patchset focuses on option a). An SX1276 based LoRaWAN stack appeared to be the project of Jian-Hong Pan and is not included here. This patchset also includes drivers for b), from text based AT commands to a binary SLIP based HCI protocol. Hardware examples for c) are Murata CMWX1ZZABZ-078 and RAK813. This patchset is clearly not ready for merging, but is being submitted for discussion, as requested by Jiri, in particular of the design choices: 1) PF_LORA/AF_LORA and associated identifiers are proposed to represent this technology. While for an SX1276 - case a) above - it might work to layer LoRaWAN as a protocol option for PF_LORA and add LoRaWAN address fields to the union in my sockaddr_lora, how would that work for devices that only support LoRaWAN but not pure LoRa? Do we need both AF_LORA and AF_LORAWAN, or just a separate ETH_P_LORAWAN or ARPHRD_LORAWAN? 2) PF_LORA is used with SOCK_DGRAM here. The assumption is that RAW mode would be DGRAM plus preamble plus optional checksum. 3) Only the transmit path is partially implemented already. The assumption is that the devices should go into receive mode by default and only interrupt that when asked to transmit. 4) Some hardware settings need to be supplied externally, such as the radio frequency for some modules, but many others can be runtime-configured, such as Spreading Factor, Bandwidth, Sync Word, or which antenna to use. What settings should be implemented as socket option vs. netlink layer vs. ioctl vs. sysfs? What are the criteria to apply? 5) Many of the modules support multiple modes, such as LoRa, LoRaWAN and FSK. Lacking a LoRaWAN implementation, I am currently switching them into LoRa mode at probe time wherever possible. How do we deal with that properly? a) Is there any precedence from the Wifi world for dynamically selecting between our own trusted Open Source implementation vs. hardware/firmware accelerated and/or certified implementations? b) Would a proof of concept for FSK (non-LoRa) modes be required for merging any LoRa driver for chipsets that support both? Or is there any facility or design guidelines that would allow us to focus on LoRa and LoRaWAN and leave non-LoRa radio modes to later contributors? As evident by the many questions, this is my first deep dive into the Linux net subsystem. It's also my first experiments with the new serdev subsystem, so in particular the receive paths will need some review and optimizations. This patchset was developed and tested mainly as KMP, originally at https://github.com/afaerber/lora-modules. It was recently transformed into a linux-next based tree, still mostly tested on our openSUSE Tumbleweed kernel with a differing AF_LORA value below current AF_MAX limit. Some corresponding Device Tree Overlays have been collected here: https://github.com/afaerber/dt-overlays Only European models for 868 MHz and 433 MHz could be tested when available. Thanks to all companies and people that have supported this project so far. Have a lot of fun! Cheers, Andreas Cc: Jian-Hong Pan <starnight@g.ncu.edu.tw> Cc: Jiri Pirko <jiri@resnulli.us> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Matthias Brugger <mbrugger@suse.com> Cc: Konstantin Böhm <konstantin.boehm@ancud.de> Cc: Jan Jongboom <jan.jongboom@arm.com> Cc: Janus Piwek <jpiwek@arroweurope.com> Cc: Michael Röder <michael.roeder@avnet.eu> Cc: Dollar Chen (陳義元) <dollar.chen@wtmec.com> Cc: Ken Yu (禹凯) <ken.yu@rakwireless.com> Cc: Jon Ortego <Jon.Ortego@imst.de> Cc: contact@snootlab.com Cc: Ben Whitten <ben.whitten@lairdtech.com> Cc: Brian Ray <brian.ray@link-labs.com> Cc: lora@globalsat.com.tw Cc: lora@radioshuttle.de Cc: Alexander Graf <agraf@suse.de> Cc: Michal Kubeček <mkubecek@suse.cz> Cc: Rob Herring <robh@kernel.org> Cc: devicetree@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: Steve deRosier <derosier@gmail.com> Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org Andreas Färber (15): net: Reserve protocol numbers for LoRa net: lora: Define sockaddr_lora net: lora: Add protocol numbers net: Add lora subsystem HACK: net: lora: Deal with .poll_mask in 4.18-rc2 net: lora: Prepare for device drivers net: lora: Add Semtech SX1276 net: lora: sx1276: Add debugfs net: lora: Prepare EUI helpers net: lora: Add Microchip RN2483 net: lora: Add IMST WiMOD net: lora: Add USI WM-SG-SM-42 net: lora: Prepare RAK RAK811 net: lora: Prepare Semtech SX1257 net: lora: Add Semtech SX1301 drivers/net/Makefile | 1 + drivers/net/lora/Kconfig | 72 ++++ drivers/net/lora/Makefile | 32 ++ drivers/net/lora/dev.c | 125 ++++++ drivers/net/lora/rak811.c | 219 +++++++++++ drivers/net/lora/rn2483.c | 344 +++++++++++++++++ drivers/net/lora/rn2483.h | 40 ++ drivers/net/lora/rn2483_cmd.c | 130 +++++++ drivers/net/lora/sx1257.c | 96 +++++ drivers/net/lora/sx1276.c | 740 ++++++++++++++++++++++++++++++++++++ drivers/net/lora/sx1301.c | 446 ++++++++++++++++++++++ drivers/net/lora/usi.c | 411 ++++++++++++++++++++ drivers/net/lora/wimod.c | 597 +++++++++++++++++++++++++++++ include/linux/lora/dev.h | 44 +++ include/linux/lora/skb.h | 29 ++ include/linux/socket.h | 4 +- include/uapi/linux/if_arp.h | 1 + include/uapi/linux/if_ether.h | 1 + include/uapi/linux/lora.h | 24 ++ net/Kconfig | 1 + net/Makefile | 1 + net/lora/Kconfig | 15 + net/lora/Makefile | 8 + net/lora/af_lora.c | 152 ++++++++ net/lora/af_lora.h | 13 + net/lora/dgram.c | 297 +++++++++++++++ security/selinux/hooks.c | 4 +- security/selinux/include/classmap.h | 4 +- 28 files changed, 3848 insertions(+), 3 deletions(-) create mode 100644 drivers/net/lora/Kconfig create mode 100644 drivers/net/lora/Makefile create mode 100644 drivers/net/lora/dev.c create mode 100644 drivers/net/lora/rak811.c create mode 100644 drivers/net/lora/rn2483.c create mode 100644 drivers/net/lora/rn2483.h create mode 100644 drivers/net/lora/rn2483_cmd.c create mode 100644 drivers/net/lora/sx1257.c create mode 100644 drivers/net/lora/sx1276.c create mode 100644 drivers/net/lora/sx1301.c create mode 100644 drivers/net/lora/usi.c create mode 100644 drivers/net/lora/wimod.c create mode 100644 include/linux/lora/dev.h create mode 100644 include/linux/lora/skb.h create mode 100644 include/uapi/linux/lora.h create mode 100644 net/lora/Kconfig create mode 100644 net/lora/Makefile create mode 100644 net/lora/af_lora.c create mode 100644 net/lora/af_lora.h create mode 100644 net/lora/dgram.c