[RFC net-next 00/15] net: A socket API for LoRa

[RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

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

-- 
2.16.4

[RFC net-next 15/15] net: lora: Add Semtech SX1301

[Andreas Färber]

The Semtech SX1301 was the first multi-channel LoRa "concentrator".
It uses a SPI interface to the host as well as a dual SPI interface to
its radios. These two have been implemented as spi_controller, so that
the Device Tree can specify whether the respective module uses two
SX1257, two SX1255 or a combination of these or some unforeseen chipset.

This implementation is the most recent - initialization is not yet
complete, it will need to load firmware into the two on-chip MCUs.

Unfortunately there is no full datasheet with register descriptions,
only a BSD-licensed userspace HAL implementation using spidev devices.
Therefore some register names are unknown.

Cc: Ben Whitten <ben.whitten@lairdtech.com>
Cc: Steve deRosier <derosier@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Michael Röder <michael.roeder@avnet.eu>
Cc: Ken Yu (禹凯) <ken.yu@rakwireless.com>
Cc: linux-spi@vger.kernel.org
Signed-off-by: Andreas Färber <afaerber@suse.de>
---
 drivers/net/lora/Kconfig  |   7 +
 drivers/net/lora/Makefile |   3 +
 drivers/net/lora/sx1301.c | 446 ++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 456 insertions(+)
 create mode 100644 drivers/net/lora/sx1301.c

diff --git a/drivers/net/lora/Kconfig b/drivers/net/lora/Kconfig
index 68c7480d7812..950450e353b4 100644
--- a/drivers/net/lora/Kconfig
+++ b/drivers/net/lora/Kconfig
@@ -45,6 +45,13 @@ config LORA_SX1276
 	help
 	  Semtech SX1272/1276/1278
 
+config LORA_SX1301
+	tristate "Semtech SX1301 SPI driver"
+	default y
+	depends on SPI
+	help
+	  Semtech SX1301
+
 config LORA_USI
 	tristate "USI WM-SG-SM-42 driver"
 	default y
diff --git a/drivers/net/lora/Makefile b/drivers/net/lora/Makefile
index 44c578bde7d5..1cc1e3aa189b 100644
--- a/drivers/net/lora/Makefile
+++ b/drivers/net/lora/Makefile
@@ -22,6 +22,9 @@ lora-sx1257-y := sx1257.o
 obj-$(CONFIG_LORA_SX1276) += lora-sx1276.o
 lora-sx1276-y := sx1276.o
 
+obj-$(CONFIG_LORA_SX1301) += lora-sx1301.o
+lora-sx1301-y := sx1301.o
+
 obj-$(CONFIG_LORA_USI) += lora-usi.o
 lora-usi-y := usi.o
 
diff --git a/drivers/net/lora/sx1301.c b/drivers/net/lora/sx1301.c
new file mode 100644
index 000000000000..5c936c1116d1
--- /dev/null
+++ b/drivers/net/lora/sx1301.c
@@ -0,0 +1,446 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Semtech SX1301 LoRa concentrator
+ *
+ * Copyright (c) 2018 Andreas Färber
+ *
+ * Based on SX1301 HAL code:
+ * Copyright (c) 2013 Semtech-Cycleo
+ */
+
+#include <linux/bitops.h>
+#include <linux/delay.h>
+#include <linux/lora.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
+#include <linux/lora/dev.h>
+#include <linux/spi/spi.h>
+
+#define REG_PAGE_RESET			0
+#define REG_VERSION			1
+#define REG_2_SPI_RADIO_A_DATA		33
+#define REG_2_SPI_RADIO_A_DATA_READBACK	34
+#define REG_2_SPI_RADIO_A_ADDR		35
+#define REG_2_SPI_RADIO_A_CS		37
+#define REG_2_SPI_RADIO_B_DATA		38
+#define REG_2_SPI_RADIO_B_DATA_READBACK	39
+#define REG_2_SPI_RADIO_B_ADDR		40
+#define REG_2_SPI_RADIO_B_CS		42
+
+#define REG_PAGE_RESET_SOFT_RESET	BIT(7)
+
+#define REG_16_GLOBAL_EN		BIT(3)
+
+#define REG_17_CLK32M_EN		BIT(0)
+
+#define REG_2_43_RADIO_A_EN		BIT(0)
+#define REG_2_43_RADIO_B_EN		BIT(1)
+#define REG_2_43_RADIO_RST		BIT(2)
+
+struct spi_sx1301 {
+	struct spi_device *parent;
+	u8 page;
+	u8 regs;
+};
+
+struct sx1301_priv {
+	struct lora_priv lora;
+	struct gpio_desc *rst_gpio;
+	u8 cur_page;
+	struct spi_controller *radio_a_ctrl, *radio_b_ctrl;
+};
+
+static int sx1301_read(struct spi_device *spi, u8 reg, u8 *val)
+{
+	u8 addr = reg & 0x7f;
+	return spi_write_then_read(spi, &addr, 1, val, 1);
+}
+
+static int sx1301_write(struct spi_device *spi, u8 reg, u8 val)
+{
+	u8 buf[2];
+
+	buf[0] = reg | BIT(7);
+	buf[1] = val;
+	return spi_write(spi, buf, 2);
+}
+
+static int sx1301_page_switch(struct spi_device *spi, u8 page)
+{
+	struct sx1301_priv *priv = spi_get_drvdata(spi);
+	int ret;
+
+	if (priv->cur_page == page)
+		return 0;
+
+	dev_dbg(&spi->dev, "switching to page %u\n", (unsigned)page);
+	ret = sx1301_write(spi, REG_PAGE_RESET, page & 0x3);
+	if (ret) {
+		dev_err(&spi->dev, "switching to page %u failed\n", (unsigned)page);
+		return ret;
+	}
+
+	priv->cur_page = page;
+
+	return 0;
+}
+
+static int sx1301_soft_reset(struct spi_device *spi)
+{
+	return sx1301_write(spi, REG_PAGE_RESET, REG_PAGE_RESET_SOFT_RESET);
+}
+
+#define REG_RADIO_X_DATA		0
+#define REG_RADIO_X_DATA_READBACK	1
+#define REG_RADIO_X_ADDR		2
+#define REG_RADIO_X_CS			4
+
+static int sx1301_radio_set_cs(struct spi_controller *ctrl, bool enable)
+{
+	struct spi_sx1301 *ssx = spi_controller_get_devdata(ctrl);
+	u8 cs;
+	int ret;
+
+	dev_dbg(&ctrl->dev, "setting CS to %s\n", enable ? "1" : "0");
+
+	ret = sx1301_page_switch(ssx->parent, ssx->page);
+	if (ret) {
+		dev_warn(&ctrl->dev, "failed to switch page for CS (%d)\n", ret);
+		return ret;
+	}
+
+	ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_CS, &cs);
+	if (ret) {
+		dev_warn(&ctrl->dev, "failed to read CS (%d)\n", ret);
+		cs = 0;
+	}
+
+	if (enable)
+		cs |= BIT(0);
+	else
+		cs &= ~BIT(0);
+
+	ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_CS, cs);
+	if (ret)
+		dev_warn(&ctrl->dev, "failed to write CS (%d)\n", ret);
+
+	return 0;
+}
+
+static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
+{
+	int ret;
+
+	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
+
+	if (enable)
+		return;
+
+	ret = sx1301_radio_set_cs(spi->controller, enable);
+	if (ret)
+		dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
+}
+
+static int sx1301_radio_spi_transfer_one(struct spi_controller *ctrl,
+	struct spi_device *spi, struct spi_transfer *xfr)
+{
+	struct spi_sx1301 *ssx = spi_controller_get_devdata(ctrl);
+	const u8 *tx_buf = xfr->tx_buf;
+	u8 *rx_buf = xfr->rx_buf;
+	int ret;
+
+	if (xfr->len == 0 || xfr->len > 3)
+		return -EINVAL;
+
+	dev_dbg(&spi->dev, "transferring one (%u)\n", xfr->len);
+
+	ret = sx1301_page_switch(ssx->parent, ssx->page);
+	if (ret) {
+		dev_err(&spi->dev, "failed to switch page for transfer (%d)\n", ret);
+		return ret;
+	}
+
+	if (tx_buf) {
+		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
+		if (ret) {
+			dev_err(&spi->dev, "SPI radio address write failed\n");
+			return ret;
+		}
+
+		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
+		if (ret) {
+			dev_err(&spi->dev, "SPI radio data write failed\n");
+			return ret;
+		}
+
+		ret = sx1301_radio_set_cs(ctrl, true);
+		if (ret) {
+			dev_err(&spi->dev, "SPI radio CS set failed\n");
+			return ret;
+		}
+
+		ret = sx1301_radio_set_cs(ctrl, false);
+		if (ret) {
+			dev_err(&spi->dev, "SPI radio CS unset failed\n");
+			return ret;
+		}
+	}
+
+	if (rx_buf) {
+		ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
+		if (ret) {
+			dev_err(&spi->dev, "SPI radio data read failed\n");
+			return ret;
+		}
+	}
+
+	return 0;
+}
+
+static void sx1301_radio_setup(struct spi_controller *ctrl)
+{
+	ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
+	ctrl->bits_per_word_mask = SPI_BPW_MASK(8);
+	ctrl->num_chipselect = 1;
+	ctrl->set_cs = sx1301_radio_spi_set_cs;
+	ctrl->transfer_one = sx1301_radio_spi_transfer_one;
+}
+
+static int sx1301_probe(struct spi_device *spi)
+{
+	struct net_device *netdev;
+	struct sx1301_priv *priv;
+	struct spi_sx1301 *radio;
+	struct gpio_desc *rst;
+	int ret;
+	u8 val;
+
+	rst = devm_gpiod_get_optional(&spi->dev, "reset", GPIOD_OUT_LOW);
+	if (IS_ERR(rst))
+		return PTR_ERR(rst);
+
+	gpiod_set_value_cansleep(rst, 1);
+	msleep(100);
+	gpiod_set_value_cansleep(rst, 0);
+	msleep(100);
+
+	spi->bits_per_word = 8;
+	spi_setup(spi);
+
+	ret = sx1301_read(spi, REG_VERSION, &val);
+	if (ret) {
+		dev_err(&spi->dev, "version read failed\n");
+		goto err_version;
+	}
+
+	if (val != 103) {
+		dev_err(&spi->dev, "unexpected version: %u\n", val);
+		ret = -ENXIO;
+		goto err_version;
+	}
+
+	netdev = alloc_loradev(sizeof(*priv));
+	if (!netdev) {
+		ret = -ENOMEM;
+		goto err_alloc_loradev;
+	}
+
+	priv = netdev_priv(netdev);
+	priv->rst_gpio = rst;
+	priv->cur_page = 0xff;
+
+	spi_set_drvdata(spi, netdev);
+	SET_NETDEV_DEV(netdev, &spi->dev);
+
+	ret = sx1301_write(spi, REG_PAGE_RESET, 0);
+	if (ret) {
+		dev_err(&spi->dev, "page/reset write failed\n");
+		return ret;
+	}
+
+	ret = sx1301_soft_reset(spi);
+	if (ret) {
+		dev_err(&spi->dev, "soft reset failed\n");
+		return ret;
+	}
+
+	ret = sx1301_read(spi, 16, &val);
+	if (ret) {
+		dev_err(&spi->dev, "16 read failed\n");
+		return ret;
+	}
+
+	val &= ~REG_16_GLOBAL_EN;
+
+	ret = sx1301_write(spi, 16, val);
+	if (ret) {
+		dev_err(&spi->dev, "16 write failed\n");
+		return ret;
+	}
+
+	ret = sx1301_read(spi, 17, &val);
+	if (ret) {
+		dev_err(&spi->dev, "17 read failed\n");
+		return ret;
+	}
+
+	val &= ~REG_17_CLK32M_EN;
+
+	ret = sx1301_write(spi, 17, val);
+	if (ret) {
+		dev_err(&spi->dev, "17 write failed\n");
+		return ret;
+	}
+
+	ret = sx1301_page_switch(spi, 2);
+	if (ret) {
+		dev_err(&spi->dev, "page 2 switch failed\n");
+		return ret;
+	}
+
+	ret = sx1301_read(spi, 43, &val);
+	if (ret) {
+		dev_err(&spi->dev, "2|43 read failed\n");
+		return ret;
+	}
+
+	val |= REG_2_43_RADIO_B_EN | REG_2_43_RADIO_A_EN;
+
+	ret = sx1301_write(spi, 43, val);
+	if (ret) {
+		dev_err(&spi->dev, "2|43 write failed\n");
+		return ret;
+	}
+
+	msleep(500);
+
+	ret = sx1301_read(spi, 43, &val);
+	if (ret) {
+		dev_err(&spi->dev, "2|43 read failed\n");
+		return ret;
+	}
+
+	val |= REG_2_43_RADIO_RST;
+
+	ret = sx1301_write(spi, 43, val);
+	if (ret) {
+		dev_err(&spi->dev, "2|43 write failed\n");
+		return ret;
+	}
+
+	msleep(5);
+
+	ret = sx1301_read(spi, 43, &val);
+	if (ret) {
+		dev_err(&spi->dev, "2|43 read failed\n");
+		return ret;
+	}
+
+	val &= ~REG_2_43_RADIO_RST;
+
+	ret = sx1301_write(spi, 43, val);
+	if (ret) {
+		dev_err(&spi->dev, "2|43 write failed\n");
+		return ret;
+	}
+
+	/* radio A */
+
+	priv->radio_a_ctrl = spi_alloc_master(&spi->dev, sizeof(*radio));
+	if (!priv->radio_a_ctrl) {
+		ret = -ENOMEM;
+		goto err_radio_a_alloc;
+	}
+
+	sx1301_radio_setup(priv->radio_a_ctrl);
+	priv->radio_a_ctrl->dev.of_node = of_get_child_by_name(spi->dev.of_node, "radio-a");
+
+	radio = spi_controller_get_devdata(priv->radio_a_ctrl);
+	radio->page = 2;
+	radio->regs = REG_2_SPI_RADIO_A_DATA;
+	radio->parent = spi;
+
+	dev_info(&spi->dev, "registering radio A SPI\n");
+
+	ret = devm_spi_register_controller(&spi->dev, priv->radio_a_ctrl);
+	if (ret) {
+		dev_err(&spi->dev, "radio A SPI register failed\n");
+		goto err_radio_a_register;
+	}
+
+	/* radio B */
+
+	priv->radio_b_ctrl = spi_alloc_master(&spi->dev, sizeof(*radio));
+	if (!priv->radio_b_ctrl) {
+		ret = -ENOMEM;
+		goto err_radio_b_alloc;
+	}
+
+	sx1301_radio_setup(priv->radio_b_ctrl);
+	priv->radio_b_ctrl->dev.of_node = of_get_child_by_name(spi->dev.of_node, "radio-b");
+
+	radio = spi_controller_get_devdata(priv->radio_b_ctrl);
+	radio->page = 2;
+	radio->regs = REG_2_SPI_RADIO_B_DATA;
+	radio->parent = spi;
+
+	dev_info(&spi->dev, "registering radio B SPI\n");
+
+	ret = devm_spi_register_controller(&spi->dev, priv->radio_b_ctrl);
+	if (ret) {
+		dev_err(&spi->dev, "radio B SPI register failed\n");
+		goto err_radio_b_register;
+	}
+
+	dev_info(&spi->dev, "SX1301 module probed\n");
+
+	return 0;
+err_radio_b_register:
+	spi_controller_put(priv->radio_b_ctrl);
+err_radio_b_alloc:
+err_radio_a_register:
+	spi_controller_put(priv->radio_a_ctrl);
+err_radio_a_alloc:
+	free_loradev(netdev);
+err_alloc_loradev:
+err_version:
+	return ret;
+}
+
+static int sx1301_remove(struct spi_device *spi)
+{
+	struct net_device *netdev = spi_get_drvdata(spi);
+
+	//unregister_loradev(netdev);
+	free_loradev(netdev);
+
+	dev_info(&spi->dev, "SX1301 module removed\n");
+
+	return 0;
+}
+
+#ifdef CONFIG_OF
+static const struct of_device_id sx1301_dt_ids[] = {
+	{ .compatible = "semtech,sx1301" },
+	{}
+};
+MODULE_DEVICE_TABLE(of, sx1301_dt_ids);
+#endif
+
+static struct spi_driver sx1301_spi_driver = {
+	.driver = {
+		.name = "sx1301",
+		.of_match_table = of_match_ptr(sx1301_dt_ids),
+	},
+	.probe = sx1301_probe,
+	.remove = sx1301_remove,
+};
+
+module_spi_driver(sx1301_spi_driver);
+
+MODULE_DESCRIPTION("SX1301 SPI driver");
+MODULE_AUTHOR("Andreas Färber <afaerber@suse.de>");
+MODULE_LICENSE("GPL");
-- 
2.16.4

RE: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Ben Whitten]

Hi Andreas,

Excellent work on doing this I have also been working on and off
this personally for some time.
Have a look at my repository [1] for sx1301 and sx1257 drivers,
I use regmaps capability of switching pages which should simplify
your driver considerably, I also have a full register map and bit field.

I have also been trying to use the clk framework to capture the various
routing that the cards have.

I will dig into this series this evening.

[1] https://github.com/BWhitten/linux-stable/tree/971aadc8fdfe842020d912449bdd71b33d576fe3/drivers/net/lora


> Subject: [RFC net-next 15/15] net: lora: Add Semtech SX1301
> 
> The Semtech SX1301 was the first multi-channel LoRa "concentrator".
> It uses a SPI interface to the host as well as a dual SPI interface to
> its radios. These two have been implemented as spi_controller, so that
> the Device Tree can specify whether the respective module uses two
> SX1257, two SX1255 or a combination of these or some unforeseen chipset.
> 
> This implementation is the most recent - initialization is not yet
> complete, it will need to load firmware into the two on-chip MCUs.
> 
> Unfortunately there is no full datasheet with register descriptions,
> only a BSD-licensed userspace HAL implementation using spidev devices.
> Therefore some register names are unknown.
> 
> Cc: Ben Whitten <ben.whitten@lairdtech.com>
> Cc: Steve deRosier <derosier@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Michael Röder <michael.roeder@avnet.eu>
> Cc: Ken Yu (禹凯) <ken.yu@rakwireless.com>
> Cc: linux-spi@vger.kernel.org
> Signed-off-by: Andreas Färber <afaerber@suse.de>
> ---
>  drivers/net/lora/Kconfig  |   7 +
>  drivers/net/lora/Makefile |   3 +
>  drivers/net/lora/sx1301.c | 446
> ++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 456 insertions(+)
>  create mode 100644 drivers/net/lora/sx1301.c
> 
> diff --git a/drivers/net/lora/Kconfig b/drivers/net/lora/Kconfig
> index 68c7480d7812..950450e353b4 100644
> --- a/drivers/net/lora/Kconfig
> +++ b/drivers/net/lora/Kconfig
> @@ -45,6 +45,13 @@ config LORA_SX1276
>  	help
>  	  Semtech SX1272/1276/1278
> 
> +config LORA_SX1301
> +	tristate "Semtech SX1301 SPI driver"
> +	default y
> +	depends on SPI
> +	help
> +	  Semtech SX1301
> +
>  config LORA_USI
>  	tristate "USI WM-SG-SM-42 driver"
>  	default y
> diff --git a/drivers/net/lora/Makefile b/drivers/net/lora/Makefile
> index 44c578bde7d5..1cc1e3aa189b 100644
> --- a/drivers/net/lora/Makefile
> +++ b/drivers/net/lora/Makefile
> @@ -22,6 +22,9 @@ lora-sx1257-y := sx1257.o
>  obj-$(CONFIG_LORA_SX1276) += lora-sx1276.o
>  lora-sx1276-y := sx1276.o
> 
> +obj-$(CONFIG_LORA_SX1301) += lora-sx1301.o
> +lora-sx1301-y := sx1301.o
> +
>  obj-$(CONFIG_LORA_USI) += lora-usi.o
>  lora-usi-y := usi.o
> 
> diff --git a/drivers/net/lora/sx1301.c b/drivers/net/lora/sx1301.c
> new file mode 100644
> index 000000000000..5c936c1116d1
> --- /dev/null
> +++ b/drivers/net/lora/sx1301.c
> @@ -0,0 +1,446 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Semtech SX1301 LoRa concentrator
> + *
> + * Copyright (c) 2018 Andreas Färber
> + *
> + * Based on SX1301 HAL code:
> + * Copyright (c) 2013 Semtech-Cycleo
> + */
> +
> +#include <linux/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/lora.h>
> +#include <linux/module.h>
> +#include <linux/netdevice.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/of_gpio.h>
> +#include <linux/lora/dev.h>
> +#include <linux/spi/spi.h>
> +
> +#define REG_PAGE_RESET			0
> +#define REG_VERSION			1
> +#define REG_2_SPI_RADIO_A_DATA		33
> +#define REG_2_SPI_RADIO_A_DATA_READBACK	34
> +#define REG_2_SPI_RADIO_A_ADDR		35
> +#define REG_2_SPI_RADIO_A_CS		37
> +#define REG_2_SPI_RADIO_B_DATA		38
> +#define REG_2_SPI_RADIO_B_DATA_READBACK	39
> +#define REG_2_SPI_RADIO_B_ADDR		40
> +#define REG_2_SPI_RADIO_B_CS		42
> +
> +#define REG_PAGE_RESET_SOFT_RESET	BIT(7)
> +
> +#define REG_16_GLOBAL_EN		BIT(3)
> +
> +#define REG_17_CLK32M_EN		BIT(0)
> +
> +#define REG_2_43_RADIO_A_EN		BIT(0)
> +#define REG_2_43_RADIO_B_EN		BIT(1)
> +#define REG_2_43_RADIO_RST		BIT(2)
> +
> +struct spi_sx1301 {
> +	struct spi_device *parent;
> +	u8 page;
> +	u8 regs;
> +};
> +
> +struct sx1301_priv {
> +	struct lora_priv lora;
> +	struct gpio_desc *rst_gpio;
> +	u8 cur_page;
> +	struct spi_controller *radio_a_ctrl, *radio_b_ctrl;
> +};
> +
> +static int sx1301_read(struct spi_device *spi, u8 reg, u8 *val)
> +{
> +	u8 addr = reg & 0x7f;
> +	return spi_write_then_read(spi, &addr, 1, val, 1);
> +}
> +
> +static int sx1301_write(struct spi_device *spi, u8 reg, u8 val)
> +{
> +	u8 buf[2];
> +
> +	buf[0] = reg | BIT(7);
> +	buf[1] = val;
> +	return spi_write(spi, buf, 2);
> +}
> +
> +static int sx1301_page_switch(struct spi_device *spi, u8 page)
> +{
> +	struct sx1301_priv *priv = spi_get_drvdata(spi);
> +	int ret;
> +
> +	if (priv->cur_page == page)
> +		return 0;
> +
> +	dev_dbg(&spi->dev, "switching to page %u\n", (unsigned)page);
> +	ret = sx1301_write(spi, REG_PAGE_RESET, page & 0x3);
> +	if (ret) {
> +		dev_err(&spi->dev, "switching to page %u failed\n",
> (unsigned)page);
> +		return ret;
> +	}
> +
> +	priv->cur_page = page;
> +
> +	return 0;
> +}
> +
> +static int sx1301_soft_reset(struct spi_device *spi)
> +{
> +	return sx1301_write(spi, REG_PAGE_RESET,
> REG_PAGE_RESET_SOFT_RESET);
> +}
> +
> +#define REG_RADIO_X_DATA		0
> +#define REG_RADIO_X_DATA_READBACK	1
> +#define REG_RADIO_X_ADDR		2
> +#define REG_RADIO_X_CS			4
> +
> +static int sx1301_radio_set_cs(struct spi_controller *ctrl, bool enable)
> +{
> +	struct spi_sx1301 *ssx = spi_controller_get_devdata(ctrl);
> +	u8 cs;
> +	int ret;
> +
> +	dev_dbg(&ctrl->dev, "setting CS to %s\n", enable ? "1" : "0");
> +
> +	ret = sx1301_page_switch(ssx->parent, ssx->page);
> +	if (ret) {
> +		dev_warn(&ctrl->dev, "failed to switch page for CS (%d)\n",
> ret);
> +		return ret;
> +	}
> +
> +	ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_CS, &cs);
> +	if (ret) {
> +		dev_warn(&ctrl->dev, "failed to read CS (%d)\n", ret);
> +		cs = 0;
> +	}
> +
> +	if (enable)
> +		cs |= BIT(0);
> +	else
> +		cs &= ~BIT(0);
> +
> +	ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_CS, cs);
> +	if (ret)
> +		dev_warn(&ctrl->dev, "failed to write CS (%d)\n", ret);
> +
> +	return 0;
> +}
> +
> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
> +{
> +	int ret;
> +
> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> +
> +	if (enable)
> +		return;
> +
> +	ret = sx1301_radio_set_cs(spi->controller, enable);
> +	if (ret)
> +		dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
> +}
> +
> +static int sx1301_radio_spi_transfer_one(struct spi_controller *ctrl,
> +	struct spi_device *spi, struct spi_transfer *xfr)
> +{
> +	struct spi_sx1301 *ssx = spi_controller_get_devdata(ctrl);
> +	const u8 *tx_buf = xfr->tx_buf;
> +	u8 *rx_buf = xfr->rx_buf;
> +	int ret;
> +
> +	if (xfr->len == 0 || xfr->len > 3)
> +		return -EINVAL;
> +
> +	dev_dbg(&spi->dev, "transferring one (%u)\n", xfr->len);
> +
> +	ret = sx1301_page_switch(ssx->parent, ssx->page);
> +	if (ret) {
> +		dev_err(&spi->dev, "failed to switch page for transfer
> (%d)\n", ret);
> +		return ret;
> +	}
> +
> +	if (tx_buf) {
> +		ret = sx1301_write(ssx->parent, ssx->regs +
> REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio address write
> failed\n");
> +			return ret;
> +		}
> +
> +		ret = sx1301_write(ssx->parent, ssx->regs +
> REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio data write failed\n");
> +			return ret;
> +		}
> +
> +		ret = sx1301_radio_set_cs(ctrl, true);
> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio CS set failed\n");
> +			return ret;
> +		}
> +
> +		ret = sx1301_radio_set_cs(ctrl, false);
> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio CS unset failed\n");
> +			return ret;
> +		}
> +	}
> +
> +	if (rx_buf) {
> +		ret = sx1301_read(ssx->parent, ssx->regs +
> REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio data read failed\n");
> +			return ret;
> +		}
> +	}
> +
> +	return 0;
> +}
> +
> +static void sx1301_radio_setup(struct spi_controller *ctrl)
> +{
> +	ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
> +	ctrl->bits_per_word_mask = SPI_BPW_MASK(8);
> +	ctrl->num_chipselect = 1;
> +	ctrl->set_cs = sx1301_radio_spi_set_cs;
> +	ctrl->transfer_one = sx1301_radio_spi_transfer_one;
> +}
> +
> +static int sx1301_probe(struct spi_device *spi)
> +{
> +	struct net_device *netdev;
> +	struct sx1301_priv *priv;
> +	struct spi_sx1301 *radio;
> +	struct gpio_desc *rst;
> +	int ret;
> +	u8 val;
> +
> +	rst = devm_gpiod_get_optional(&spi->dev, "reset",
> GPIOD_OUT_LOW);
> +	if (IS_ERR(rst))
> +		return PTR_ERR(rst);
> +
> +	gpiod_set_value_cansleep(rst, 1);
> +	msleep(100);
> +	gpiod_set_value_cansleep(rst, 0);
> +	msleep(100);
> +
> +	spi->bits_per_word = 8;
> +	spi_setup(spi);
> +
> +	ret = sx1301_read(spi, REG_VERSION, &val);
> +	if (ret) {
> +		dev_err(&spi->dev, "version read failed\n");
> +		goto err_version;
> +	}
> +
> +	if (val != 103) {
> +		dev_err(&spi->dev, "unexpected version: %u\n", val);
> +		ret = -ENXIO;
> +		goto err_version;
> +	}
> +
> +	netdev = alloc_loradev(sizeof(*priv));
> +	if (!netdev) {
> +		ret = -ENOMEM;
> +		goto err_alloc_loradev;
> +	}
> +
> +	priv = netdev_priv(netdev);
> +	priv->rst_gpio = rst;
> +	priv->cur_page = 0xff;
> +
> +	spi_set_drvdata(spi, netdev);
> +	SET_NETDEV_DEV(netdev, &spi->dev);
> +
> +	ret = sx1301_write(spi, REG_PAGE_RESET, 0);
> +	if (ret) {
> +		dev_err(&spi->dev, "page/reset write failed\n");
> +		return ret;
> +	}
> +
> +	ret = sx1301_soft_reset(spi);
> +	if (ret) {
> +		dev_err(&spi->dev, "soft reset failed\n");
> +		return ret;
> +	}
> +
> +	ret = sx1301_read(spi, 16, &val);
> +	if (ret) {
> +		dev_err(&spi->dev, "16 read failed\n");
> +		return ret;
> +	}
> +
> +	val &= ~REG_16_GLOBAL_EN;
> +
> +	ret = sx1301_write(spi, 16, val);
> +	if (ret) {
> +		dev_err(&spi->dev, "16 write failed\n");
> +		return ret;
> +	}
> +
> +	ret = sx1301_read(spi, 17, &val);
> +	if (ret) {
> +		dev_err(&spi->dev, "17 read failed\n");
> +		return ret;
> +	}
> +
> +	val &= ~REG_17_CLK32M_EN;
> +
> +	ret = sx1301_write(spi, 17, val);
> +	if (ret) {
> +		dev_err(&spi->dev, "17 write failed\n");
> +		return ret;
> +	}
> +
> +	ret = sx1301_page_switch(spi, 2);
> +	if (ret) {
> +		dev_err(&spi->dev, "page 2 switch failed\n");
> +		return ret;
> +	}
> +
> +	ret = sx1301_read(spi, 43, &val);
> +	if (ret) {
> +		dev_err(&spi->dev, "2|43 read failed\n");
> +		return ret;
> +	}
> +
> +	val |= REG_2_43_RADIO_B_EN | REG_2_43_RADIO_A_EN;
> +
> +	ret = sx1301_write(spi, 43, val);
> +	if (ret) {
> +		dev_err(&spi->dev, "2|43 write failed\n");
> +		return ret;
> +	}
> +
> +	msleep(500);
> +
> +	ret = sx1301_read(spi, 43, &val);
> +	if (ret) {
> +		dev_err(&spi->dev, "2|43 read failed\n");
> +		return ret;
> +	}
> +
> +	val |= REG_2_43_RADIO_RST;
> +
> +	ret = sx1301_write(spi, 43, val);
> +	if (ret) {
> +		dev_err(&spi->dev, "2|43 write failed\n");
> +		return ret;
> +	}
> +
> +	msleep(5);
> +
> +	ret = sx1301_read(spi, 43, &val);
> +	if (ret) {
> +		dev_err(&spi->dev, "2|43 read failed\n");
> +		return ret;
> +	}
> +
> +	val &= ~REG_2_43_RADIO_RST;
> +
> +	ret = sx1301_write(spi, 43, val);
> +	if (ret) {
> +		dev_err(&spi->dev, "2|43 write failed\n");
> +		return ret;
> +	}
> +
> +	/* radio A */
> +
> +	priv->radio_a_ctrl = spi_alloc_master(&spi->dev, sizeof(*radio));
> +	if (!priv->radio_a_ctrl) {
> +		ret = -ENOMEM;
> +		goto err_radio_a_alloc;
> +	}
> +
> +	sx1301_radio_setup(priv->radio_a_ctrl);
> +	priv->radio_a_ctrl->dev.of_node = of_get_child_by_name(spi-
> >dev.of_node, "radio-a");
> +
> +	radio = spi_controller_get_devdata(priv->radio_a_ctrl);
> +	radio->page = 2;
> +	radio->regs = REG_2_SPI_RADIO_A_DATA;
> +	radio->parent = spi;
> +
> +	dev_info(&spi->dev, "registering radio A SPI\n");
> +
> +	ret = devm_spi_register_controller(&spi->dev, priv->radio_a_ctrl);
> +	if (ret) {
> +		dev_err(&spi->dev, "radio A SPI register failed\n");
> +		goto err_radio_a_register;
> +	}
> +
> +	/* radio B */
> +
> +	priv->radio_b_ctrl = spi_alloc_master(&spi->dev, sizeof(*radio));
> +	if (!priv->radio_b_ctrl) {
> +		ret = -ENOMEM;
> +		goto err_radio_b_alloc;
> +	}
> +
> +	sx1301_radio_setup(priv->radio_b_ctrl);
> +	priv->radio_b_ctrl->dev.of_node = of_get_child_by_name(spi-
> >dev.of_node, "radio-b");
> +
> +	radio = spi_controller_get_devdata(priv->radio_b_ctrl);
> +	radio->page = 2;
> +	radio->regs = REG_2_SPI_RADIO_B_DATA;
> +	radio->parent = spi;
> +
> +	dev_info(&spi->dev, "registering radio B SPI\n");
> +
> +	ret = devm_spi_register_controller(&spi->dev, priv->radio_b_ctrl);
> +	if (ret) {
> +		dev_err(&spi->dev, "radio B SPI register failed\n");
> +		goto err_radio_b_register;
> +	}
> +
> +	dev_info(&spi->dev, "SX1301 module probed\n");
> +
> +	return 0;
> +err_radio_b_register:
> +	spi_controller_put(priv->radio_b_ctrl);
> +err_radio_b_alloc:
> +err_radio_a_register:
> +	spi_controller_put(priv->radio_a_ctrl);
> +err_radio_a_alloc:
> +	free_loradev(netdev);
> +err_alloc_loradev:
> +err_version:
> +	return ret;
> +}
> +
> +static int sx1301_remove(struct spi_device *spi)
> +{
> +	struct net_device *netdev = spi_get_drvdata(spi);
> +
> +	//unregister_loradev(netdev);
> +	free_loradev(netdev);
> +
> +	dev_info(&spi->dev, "SX1301 module removed\n");
> +
> +	return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static const struct of_device_id sx1301_dt_ids[] = {
> +	{ .compatible = "semtech,sx1301" },
> +	{}
> +};
> +MODULE_DEVICE_TABLE(of, sx1301_dt_ids);
> +#endif
> +
> +static struct spi_driver sx1301_spi_driver = {
> +	.driver = {
> +		.name = "sx1301",
> +		.of_match_table = of_match_ptr(sx1301_dt_ids),
> +	},
> +	.probe = sx1301_probe,
> +	.remove = sx1301_remove,
> +};
> +
> +module_spi_driver(sx1301_spi_driver);
> +
> +MODULE_DESCRIPTION("SX1301 SPI driver");
> +MODULE_AUTHOR("Andreas Färber <afaerber@suse.de>");
> +MODULE_LICENSE("GPL");
> --
> 2.16.4

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1719 bytes --]

On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:

> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
> +{
> +	int ret;
> +
> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> +
> +	if (enable)
> +		return;
> +
> +	ret = sx1301_radio_set_cs(spi->controller, enable);
> +	if (ret)
> +		dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
> +}

So we never disable chip select?

> +	if (tx_buf) {
> +		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);

This looks confused.  We're in an if (tx_buf) block but there's a use of
the ternery operator that appears to be checking if we have a tx_buf?

> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio address write failed\n");
> +			return ret;
> +		}
> +
> +		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio data write failed\n");
> +			return ret;
> +		}

This looks awfully like you're coming in at the wrong abstraction layer
and the hardware actually implements a register abstraction rather than
a SPI one so you should be using regmap as the abstraction.

> +	if (rx_buf) {
> +		ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
> +		if (ret) {
> +			dev_err(&spi->dev, "SPI radio data read failed\n");
> +			return ret;
> +		}
> +	}

For a read we never set an address?

> +static void sx1301_radio_setup(struct spi_controller *ctrl)
> +{
> +	ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;

This controller has no chip select but we provided a set_cs operation?

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Andreas Färber]

[-- Attachment #1.1: Type: text/plain, Size: 5074 bytes --]

Hi Mark,

This driver is still evolving, there's newer code on my lora-next branch
already: https://github.com/afaerber/linux/commits/lora-next

The reason you're in CC on this RFC is two-fold:

1) You applied Ben's patch to associate "semtech,sx1301" with spidev,
whereas I am now preparing a new driver for the same compatible.

2) This SPI device is in turn exposing the two SPI masters that you
already found below, and I didn't see a sane way to split that code out
into drivers/spi/, so it's in drivers/net/lora/ here - has there been
any precedence either way?

More inline ...

Am 02.07.2018 um 18:12 schrieb Mark Brown:
> On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
> 
>> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
>> +{
>> +	int ret;
>> +
>> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
>> +
>> +	if (enable)
>> +		return;
>> +
>> +	ret = sx1301_radio_set_cs(spi->controller, enable);
>> +	if (ret)
>> +		dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
>> +}
> 
> So we never disable chip select?

Not here, I instead did that in transfer_one below.

Unfortunately there seems to be no documentation, only reference code:

https://github.com/Lora-net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L121
https://github.com/Lora-net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L165

It sets CS to 0 before writing to address and data registers, then
immediately sets CS to 1 and back to 0 before reading or ending the
write transaction. I've tried to force the same behavior in this driver.
My guess was that CS is high-active during the short 1-0 cycle, because
if it's low-active during the register writes then why the heck is it
set to 0 again in the end instead of keeping at 1... confusing.

Maybe the Semtech folks CC'ed can comment how these registers work?

>> +	if (tx_buf) {
>> +		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
> 
> This looks confused.  We're in an if (tx_buf) block but there's a use of
> the ternery operator that appears to be checking if we have a tx_buf?

Yeah, as mentioned this RFC is not ready for merging - checkpatch.pl
will complain about lines too long, and TODOs are sprinkled all over or
not even mentioned. It's a Proof of Concept that a net_device could work
for a wide range of spi and serdev based drivers, and on top this device
has more than one channel, which may influence network-level design
discussions.

That said, I'll happily drop the second check. Thanks for spotting!

>> +		if (ret) {
>> +			dev_err(&spi->dev, "SPI radio address write failed\n");
>> +			return ret;
>> +		}
>> +
>> +		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
>> +		if (ret) {
>> +			dev_err(&spi->dev, "SPI radio data write failed\n");
>> +			return ret;
>> +		}
> 
> This looks awfully like you're coming in at the wrong abstraction layer
> and the hardware actually implements a register abstraction rather than
> a SPI one so you should be using regmap as the abstraction.

I don't understand. Ben has suggested using regmap for the SPI _device_
that we're talking to, which may be a good idea. But this SX1301 device
in turn has two SPI _masters_ talking to an SX125x slave each. I don't
see how using regmap instead of my wrappers avoids this spi_controller?
The whole point of this spi_controller is to abstract and separate the
SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
instead of mixing it into the SX1301 driver - to me that looks cleaner
and more extensible. It also has the side-effect that we could configure
the two radios via DT (frequencies, clk output, etc.).

You will find a datasheet with some diagrams mentioning "SPI" at:
https://www.semtech.com/products/wireless-rf/lora-gateways/SX1301

>> +	if (rx_buf) {
>> +		ret = sx1301_read(ssx->parent, ssx->regs + REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
>> +		if (ret) {
>> +			dev_err(&spi->dev, "SPI radio data read failed\n");
>> +			return ret;
>> +		}
>> +	}
> 
> For a read we never set an address?

To read, you first write the address via tx_buf, then either in the same
transfer in the third byte or in a subsequent one-byte transfer as first
byte you get the data.

If you have better ideas how to structure this, do let me know.

>> +static void sx1301_radio_setup(struct spi_controller *ctrl)
>> +{
>> +	ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
> 
> This controller has no chip select but we provided a set_cs operation?

Oops, I played around with those two options and was hoping SPI_NO_CS
would avoid the undesired set_cs invocations, but it didn't work as
expected and so I added the "if (enabled)" check above.

Thanks for your review,

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

RE: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Ben Whitten]

> Subject: Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
> 
> Hi Mark,
> 
> This driver is still evolving, there's newer code on my lora-next branch
> already: https://github.com/afaerber/linux/commits/lora-next
> 
> The reason you're in CC on this RFC is two-fold:
> 
> 1) You applied Ben's patch to associate "semtech,sx1301" with spidev,
> whereas I am now preparing a new driver for the same compatible.
> 
> 2) This SPI device is in turn exposing the two SPI masters that you
> already found below, and I didn't see a sane way to split that code out
> into drivers/spi/, so it's in drivers/net/lora/ here - has there been
> any precedence either way?

In my work in progress driver I just register one controller for the sx1301 with two chip selects and use the chip select information to choose the correct radio to send to, this is based on the DT reg information. No need to register two separate masters.

> More inline ...
> 
> Am 02.07.2018 um 18:12 schrieb Mark Brown:
> > On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
> >
> >> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
> >> +{
> >> +	int ret;
> >> +
> >> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> >> +
> >> +	if (enable)
> >> +		return;
> >> +
> >> +	ret = sx1301_radio_set_cs(spi->controller, enable);
> >> +	if (ret)
> >> +		dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
> >> +}
> >
> > So we never disable chip select?
> 
> Not here, I instead did that in transfer_one below.
> 
> Unfortunately there seems to be no documentation, only reference code:
> 
> https://github.com/Lora-
> net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L121
> https://github.com/Lora-
> net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L165
> 
> It sets CS to 0 before writing to address and data registers, then
> immediately sets CS to 1 and back to 0 before reading or ending the
> write transaction. I've tried to force the same behavior in this driver.
> My guess was that CS is high-active during the short 1-0 cycle, because
> if it's low-active during the register writes then why the heck is it
> set to 0 again in the end instead of keeping at 1... confusing.
> 
> Maybe the Semtech folks CC'ed can comment how these registers work?
> 
> >> +	if (tx_buf) {
> >> +		ret = sx1301_write(ssx->parent, ssx->regs +
> REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
> >
> > This looks confused.  We're in an if (tx_buf) block but there's a use of
> > the ternery operator that appears to be checking if we have a tx_buf?
> 
> Yeah, as mentioned this RFC is not ready for merging - checkpatch.pl
> will complain about lines too long, and TODOs are sprinkled all over or
> not even mentioned. It's a Proof of Concept that a net_device could work
> for a wide range of spi and serdev based drivers, and on top this device
> has more than one channel, which may influence network-level design
> discussions.
> 
> That said, I'll happily drop the second check. Thanks for spotting!
> 
> >> +		if (ret) {
> >> +			dev_err(&spi->dev, "SPI radio address write
> failed\n");
> >> +			return ret;
> >> +		}
> >> +
> >> +		ret = sx1301_write(ssx->parent, ssx->regs +
> REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> >> +		if (ret) {
> >> +			dev_err(&spi->dev, "SPI radio data write failed\n");
> >> +			return ret;
> >> +		}
> >
> > This looks awfully like you're coming in at the wrong abstraction layer
> > and the hardware actually implements a register abstraction rather than
> > a SPI one so you should be using regmap as the abstraction.
> 
> I don't understand. Ben has suggested using regmap for the SPI _device_
> that we're talking to, which may be a good idea. But this SX1301 device
> in turn has two SPI _masters_ talking to an SX125x slave each. I don't
> see how using regmap instead of my wrappers avoids this spi_controller?
> The whole point of this spi_controller is to abstract and separate the
> SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
> instead of mixing it into the SX1301 driver - to me that looks cleaner
> and more extensible. It also has the side-effect that we could configure
> the two radios via DT (frequencies, clk output, etc.).

You want an SPI controller in the SX1301 as the down stream radios are SPI and could be attached directly to a host SPI bus, makes sense to have one radio driver and talk through the SX1301.
But you should use the regmap to access the SX1301 master controller registers.
Example I use with one SPI master and some clock info:
eg:
	sx1301: sx1301@0 {
		compatible = "semtech,sx1301";
		reg = <0>;
		#address-cells = <1>;
		#size-cells = <0>;
		spi-max-frequency = <8000000>;
		gpios-reset = <&pioA 26 GPIO_ACTIVE_HIGH>;
		clocks = <&radio1 0>, <&clkhs 0>;
		clock-names = "clk32m", "clkhs";

		radio0: sx1257@0 {
			compatible = "semtech,sx125x";
			reg = <0>;
			spi-max-frequency = <8000000>;
			tx;
			clocks = <&tcxo 0>;
			clock-names = "tcxo";
		};

		radio1: sx1257@1 {
			compatible = "semtech,sx125x";
			reg = <1>;
			spi-max-frequency = <8000000>;
			#clock-cells = <0>;
			clocks = <&tcxo 0>;
			clock-names = "tcxo";
			clock-output-names = "clk32m";
		};
};


> You will find a datasheet with some diagrams mentioning "SPI" at:
> https://www.semtech.com/products/wireless-rf/lora-gateways/SX1301
> 
> >> +	if (rx_buf) {
> >> +		ret = sx1301_read(ssx->parent, ssx->regs +
> REG_RADIO_X_DATA_READBACK, &rx_buf[xfr->len - 1]);
> >> +		if (ret) {
> >> +			dev_err(&spi->dev, "SPI radio data read failed\n");
> >> +			return ret;
> >> +		}
> >> +	}
> >
> > For a read we never set an address?
> 
> To read, you first write the address via tx_buf, then either in the same
> transfer in the third byte or in a subsequent one-byte transfer as first
> byte you get the data.
> 
> If you have better ideas how to structure this, do let me know.
> 
> >> +static void sx1301_radio_setup(struct spi_controller *ctrl)
> >> +{
> >> +	ctrl->mode_bits = SPI_CS_HIGH | SPI_NO_CS;
> >
> > This controller has no chip select but we provided a set_cs operation?
> 
> Oops, I played around with those two options and was hoping SPI_NO_CS
> would avoid the undesired set_cs invocations, but it didn't work as
> expected and so I added the "if (enabled)" check above.
> 
> Thanks for your review,
> 
> Andreas
> 
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Andreas Färber]

Hi Ben,

Am 02.07.2018 um 13:51 schrieb Ben Whitten:
> Excellent work on doing this I have also been working on and off
> this personally for some time.

Thanks. Colliding work is always unfortunate, I can relate...

> Have a look at my repository [1] for sx1301 and sx1257 drivers,
> I use regmaps capability of switching pages which should simplify
> your driver considerably, I also have a full register map and bit field.

Please note that my lora-next branch already has bug fixes and cleanups
over this patch. The probe error handling was broken, and I implemented
wrappers for paged reads and writes as well as burst modes, plus the
firmware loading.

https://github.com/afaerber/linux/commits/lora-next

I took a quick look at your sx1257 and noticed you licensed it as GPLv2.
Is there any particular reason for that? Since I wrote my driver without
copying from GPLv2 code, I prefer the less restrictive GPLv2+.

So far a work day has passed with no maintainer objecting to or
commenting on the underlying PF_LORA network layer design. Meanwhile
there's already three of us with code and more people have inquired
about testing and contributing, so I'm thinking about setting up a
staging tree on kernel.org to collaborate on...

Would you be willing to contribute your regmap ideas to my driver as a
patch to squash? Needs a Signed-off-by of course, which your GitHub
commits are lacking, so I can't merge them on my own.

> I have also been trying to use the clk framework to capture the various
> routing that the cards have.

I thought about clk too, but won't that cause name conflicts when
probing multiple concentrators? Would be nice to use that for
configuring the SX1257 clock output instead of my current hack.

Another thought I haven't investigated yet is whether we could use
remoteproc for ARB and AGC. I would at least prefer to have the firmware
as a binary loaded via the usual request_firmware(), not as byte array.
But then again the AGC gets firmware loaded twice, so maybe too complex
for remoteproc.

BTW do you have any insights on what MCU is in there? Would be nice to
understand in form of source code what the firmware is doing, to avoid
the hard dependency on a specific firmware version (imagine user
updating kernel-firmware - containing versions X,Y,Z - and kernel and
booting two different kernel versions, the older one stops working).

https://www.thethingsnetwork.org/forum/t/secret-price-of-a-lora-gateway/5730/74

Regards,
Andreas

> I will dig into this series this evening.
> 
> [1] https://github.com/BWhitten/linux-stable/tree/971aadc8fdfe842020d912449bdd71b33d576fe3/drivers/net/lora
[...]
>> diff --git a/drivers/net/lora/sx1301.c b/drivers/net/lora/sx1301.c
>> new file mode 100644
>> index 000000000000..5c936c1116d1
>> --- /dev/null
>> +++ b/drivers/net/lora/sx1301.c
>> @@ -0,0 +1,446 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
[snip]

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Andreas Färber]

Hi Ben,

Am 02.07.2018 um 22:43 schrieb Ben Whitten:
>> 2) This SPI device is in turn exposing the two SPI masters that you
>> already found below, and I didn't see a sane way to split that code out
>> into drivers/spi/, so it's in drivers/net/lora/ here - has there been
>> any precedence either way?
> 
> In my work in progress driver I just register one controller for the sx1301 with two chip selects and use the chip select information to choose the correct radio to send to, this is based on the DT reg information. No need to register two separate masters.

I had considered that and discarded it. The SX1301 has not just two CS
registers though but also two pairs of addr, data registers. That speaks
for two masters with a single chip-select each, unless I'm
misunderstanding the meaning of the registers.

>> Am 02.07.2018 um 18:12 schrieb Mark Brown:
>>> On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
>>>
>>>> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
>>>> +{
>>>> +	int ret;
>>>> +
>>>> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
>>>> +
>>>> +	if (enable)
>>>> +		return;
>>>> +
>>>> +	ret = sx1301_radio_set_cs(spi->controller, enable);
>>>> +	if (ret)
>>>> +		dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
>>>> +}
>>>
>>> So we never disable chip select?
>>
>> Not here, I instead did that in transfer_one below.
>>
>> Unfortunately there seems to be no documentation, only reference code:
>>
>> https://github.com/Lora-
>> net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L121
>> https://github.com/Lora-
>> net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L165
>>
>> It sets CS to 0 before writing to address and data registers, then
>> immediately sets CS to 1 and back to 0 before reading or ending the
>> write transaction. I've tried to force the same behavior in this driver.
>> My guess was that CS is high-active during the short 1-0 cycle, because
>> if it's low-active during the register writes then why the heck is it
>> set to 0 again in the end instead of keeping at 1... confusing.
>>
>> Maybe the Semtech folks CC'ed can comment how these registers work?
>>
>>>> +	if (tx_buf) {
>>>> +		ret = sx1301_write(ssx->parent, ssx->regs +
>> REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
>>>
>>> This looks confused.  We're in an if (tx_buf) block but there's a use of
>>> the ternery operator that appears to be checking if we have a tx_buf?
>>
>> Yeah, as mentioned this RFC is not ready for merging - checkpatch.pl
>> will complain about lines too long, and TODOs are sprinkled all over or
>> not even mentioned. It's a Proof of Concept that a net_device could work
>> for a wide range of spi and serdev based drivers, and on top this device
>> has more than one channel, which may influence network-level design
>> discussions.
>>
>> That said, I'll happily drop the second check. Thanks for spotting!
>>
>>>> +		if (ret) {
>>>> +			dev_err(&spi->dev, "SPI radio address write
>> failed\n");
>>>> +			return ret;
>>>> +		}
>>>> +
>>>> +		ret = sx1301_write(ssx->parent, ssx->regs +
>> REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
>>>> +		if (ret) {
>>>> +			dev_err(&spi->dev, "SPI radio data write failed\n");
>>>> +			return ret;
>>>> +		}
>>>
>>> This looks awfully like you're coming in at the wrong abstraction layer
>>> and the hardware actually implements a register abstraction rather than
>>> a SPI one so you should be using regmap as the abstraction.
>>
>> I don't understand. Ben has suggested using regmap for the SPI _device_
>> that we're talking to, which may be a good idea. But this SX1301 device
>> in turn has two SPI _masters_ talking to an SX125x slave each. I don't
>> see how using regmap instead of my wrappers avoids this spi_controller?
>> The whole point of this spi_controller is to abstract and separate the
>> SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
>> instead of mixing it into the SX1301 driver - to me that looks cleaner
>> and more extensible. It also has the side-effect that we could configure
>> the two radios via DT (frequencies, clk output, etc.).
> 
> You want an SPI controller in the SX1301 as the down stream radios are SPI and could be attached directly to a host SPI bus, makes sense to have one radio driver and talk through the SX1301.
> But you should use the regmap to access the SX1301 master controller registers.
> Example I use with one SPI master and some clock info:
> eg:
> 	sx1301: sx1301@0 {

Node names should not repeat the chipset, that goes into compatible.

lora-concentrator@0?

> 		compatible = "semtech,sx1301";
> 		reg = <0>;
> 		#address-cells = <1>;
> 		#size-cells = <0>;

I would still find it cleaner to have (a) sub-node(s) for the radios.

> 		spi-max-frequency = <8000000>;

Datasheet says 10 MHz, why 8 MHz?

> 		gpios-reset = <&pioA 26 GPIO_ACTIVE_HIGH>;

reset-gpios?

> 		clocks = <&radio1 0>, <&clkhs 0>;
> 		clock-names = "clk32m", "clkhs";
> 
> 		radio0: sx1257@0 {

lora@0?

> 			compatible = "semtech,sx125x";

No wildcards in bindings please, use concrete "semtech,sx1257".

> 			reg = <0>;
> 			spi-max-frequency = <8000000>;

Datasheet says 10 ns - I reported to Semtech that it should probably say
10 MHz, too.

> 			tx;

Might we configure that on the sx1301 instead?

> 			clocks = <&tcxo 0>;
> 			clock-names = "tcxo";
> 		};
> 
> 		radio1: sx1257@1 {
> 			compatible = "semtech,sx125x";
> 			reg = <1>;
> 			spi-max-frequency = <8000000>;
> 			#clock-cells = <0>;
> 			clocks = <&tcxo 0>;
> 			clock-names = "tcxo";
> 			clock-output-names = "clk32m";
> 		};
> };
[snip]

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 3135 bytes --]

On Mon, Jul 02, 2018 at 07:34:21PM +0200, Andreas Färber wrote:
> Hi Mark,
> 
> This driver is still evolving, there's newer code on my lora-next branch
> already: https://github.com/afaerber/linux/commits/lora-next

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> 2) This SPI device is in turn exposing the two SPI masters that you
> already found below, and I didn't see a sane way to split that code out
> into drivers/spi/, so it's in drivers/net/lora/ here - has there been
> any precedence either way?

A MFD?

> Am 02.07.2018 um 18:12 schrieb Mark Brown:
> > On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:

> >> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
> >> +{
> >> +	int ret;
> >> +
> >> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> >> +
> >> +	if (enable)
> >> +		return;

> > So we never disable chip select?

> Not here, I instead did that in transfer_one below.

That's obviously at best going to be fragile, you're implementing half
the operation here and half somewhere else which is most likely going to
break at some point when the framework changes.

> >> +		if (ret) {
> >> +			dev_err(&spi->dev, "SPI radio address write failed\n");
> >> +			return ret;
> >> +		}
> >> +
> >> +		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> >> +		if (ret) {
> >> +			dev_err(&spi->dev, "SPI radio data write failed\n");
> >> +			return ret;
> >> +		}

> > This looks awfully like you're coming in at the wrong abstraction layer
> > and the hardware actually implements a register abstraction rather than
> > a SPI one so you should be using regmap as the abstraction.

> I don't understand. Ben has suggested using regmap for the SPI _device_
> that we're talking to, which may be a good idea. But this SX1301 device
> in turn has two SPI _masters_ talking to an SX125x slave each. I don't
> see how using regmap instead of my wrappers avoids this spi_controller?

It seems obvious from the code that this isn't actually interacting with
a SPI controller, you're writing an address and a value to a register
map rather than dealing with a byte stream.  There may be a SPI bus
somewhere behind some other hardware but you don't seem to be
interacting with it as such.

> The whole point of this spi_controller is to abstract and separate the
> SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
> instead of mixing it into the SX1301 driver - to me that looks cleaner
> and more extensible. It also has the side-effect that we could configure
> the two radios via DT (frequencies, clk output, etc.).

A register map would work just as well here, we already have plenty of
devices that abstract at this level (most obviously the I2C/SPI devices
that use it to offer both interfaces with a single core driver).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Andreas Färber]

Am 03.07.2018 um 16:50 schrieb Mark Brown:
> On Mon, Jul 02, 2018 at 07:34:21PM +0200, Andreas Färber wrote:
>> Hi Mark,
>>
>> This driver is still evolving, there's newer code on my lora-next branch
>> already: https://github.com/afaerber/linux/commits/lora-next
> 
> Please don't top post, reply in line with needed context.  This allows
> readers to readily follow the flow of conversation and understand what
> you are talking about and also helps ensure that everything in the
> discussion is being addressed.

I did reply inline, if you cared to read on. ;)

>> 2) This SPI device is in turn exposing the two SPI masters that you
>> already found below, and I didn't see a sane way to split that code out
>> into drivers/spi/, so it's in drivers/net/lora/ here - has there been
>> any precedence either way?
> 
> A MFD?

I know of mfd, but how would the the the net vs. spi pieces interact
then? Some functions would need to be exported then or is there an
easier way without needing to set a cross-module API in stone?

>> Am 02.07.2018 um 18:12 schrieb Mark Brown:
>>> On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
>>>> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool enable)
>>>> +{
>>>> +	int ret;
>>>> +
>>>> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
>>>> +
>>>> +	if (enable)
>>>> +		return;
> 
>>> So we never disable chip select?
> 
>> Not here, I instead did that in transfer_one below.
> 
> That's obviously at best going to be fragile, you're implementing half
> the operation here and half somewhere else which is most likely going to
> break at some point when the framework changes.
> 
>>>> +		if (ret) {
>>>> +			dev_err(&spi->dev, "SPI radio address write failed\n");
>>>> +			return ret;
>>>> +		}
>>>> +
>>>> +		ret = sx1301_write(ssx->parent, ssx->regs + REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
>>>> +		if (ret) {
>>>> +			dev_err(&spi->dev, "SPI radio data write failed\n");
>>>> +			return ret;
>>>> +		}
> 
>>> This looks awfully like you're coming in at the wrong abstraction layer
>>> and the hardware actually implements a register abstraction rather than
>>> a SPI one so you should be using regmap as the abstraction.
> 
>> I don't understand. Ben has suggested using regmap for the SPI _device_
>> that we're talking to, which may be a good idea. But this SX1301 device
>> in turn has two SPI _masters_ talking to an SX125x slave each. I don't
>> see how using regmap instead of my wrappers avoids this spi_controller?
> 
> It seems obvious from the code that this isn't actually interacting with
> a SPI controller, you're writing an address and a value to a register
> map rather than dealing with a byte stream.  There may be a SPI bus
> somewhere behind some other hardware but you don't seem to be
> interacting with it as such.
> 
>> The whole point of this spi_controller is to abstract and separate the
>> SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
>> instead of mixing it into the SX1301 driver - to me that looks cleaner
>> and more extensible. It also has the side-effect that we could configure
>> the two radios via DT (frequencies, clk output, etc.).
> 
> A register map would work just as well here, we already have plenty of
> devices that abstract at this level (most obviously the I2C/SPI devices
> that use it to offer both interfaces with a single core driver).

The address and data registers together form a two-byte SPI message!

It is transmitted by writing to the CS register.

The received data is afterwards available in another register.

HTE,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Jian-Hong Pan]

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
>

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 2006 bytes --]

On Tue, Jul 03, 2018 at 05:09:38PM +0200, Andreas Färber wrote:
> Am 03.07.2018 um 16:50 schrieb Mark Brown:

> >> 2) This SPI device is in turn exposing the two SPI masters that you
> >> already found below, and I didn't see a sane way to split that code out
> >> into drivers/spi/, so it's in drivers/net/lora/ here - has there been
> >> any precedence either way?

> > A MFD?

> I know of mfd, but how would the the the net vs. spi pieces interact
> then? Some functions would need to be exported then or is there an
> easier way without needing to set a cross-module API in stone?

It's an in-kernel ABI it's not exactly set in stone but yeah, you'll
need some interface.  A lot of devices work by having the children know
that they're part of a MFD and fish things out of the parent device,
either the pdata or (in the common case where the MFD bit mostly just
instantiates subdevices and holds a regmap) with dev_get_regmap().

> > A register map would work just as well here, we already have plenty of
> > devices that abstract at this level (most obviously the I2C/SPI devices
> > that use it to offer both interfaces with a single core driver).

> The address and data registers together form a two-byte SPI message!

> It is transmitted by writing to the CS register.

> The received data is afterwards available in another register.

Right, but it seems from the code that the hardware understands that
it's formatting register I/O and not just shifting in and out a byte
stream which is what a SPI controller does.  I'd not be surprised to
learn that the register you're calling a chip select register is a
strobe that initiates the transfer (and that this may be some of the
difficulty you're having with handling it in the way the framework
expects), the pattern with writing 1 followed immediately by 0 is a bit
of a flag here.

I've seen such before hardware where I know it was intentionally
designed that way so it wouldn't be totally surprising.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Andreas Färber]

Am 03.07.2018 um 17:31 schrieb Mark Brown:
> On Tue, Jul 03, 2018 at 05:09:38PM +0200, Andreas Färber wrote:
>> Am 03.07.2018 um 16:50 schrieb Mark Brown:
>>> A register map would work just as well here, we already have plenty of
>>> devices that abstract at this level (most obviously the I2C/SPI devices
>>> that use it to offer both interfaces with a single core driver).
> 
>> The address and data registers together form a two-byte SPI message!
> 
>> It is transmitted by writing to the CS register.
> 
>> The received data is afterwards available in another register.
> 
> Right, but it seems from the code that the hardware understands that
> it's formatting register I/O and not just shifting in and out a byte
> stream which is what a SPI controller does.  I'd not be surprised to
> learn that the register you're calling a chip select register is a
> strobe that initiates the transfer (and that this may be some of the
> difficulty you're having with handling it in the way the framework
> expects), the pattern with writing 1 followed immediately by 0 is a bit
> of a flag here.

Yeah, the current implementation assumes exactly that. :)

> I've seen such before hardware where I know it was intentionally
> designed that way so it wouldn't be totally surprising.

If we don't implement a spi_controller here, then IIUC we can't have
multiple spi_device implementations for the devices on the receiving
end, as they rely on a spi_controller for their APIs.

Do you have an alternative solution for abstraction? A regmap would seem
to require putting everything into a monolithic SX1301 driver despite
those connected chipsets actually being regular, external SPI chips that
could also be attached to non-SX1301 SPI masters.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On Tue, Jul 03, 2018 at 06:40:41PM +0200, Andreas Färber wrote:

> Do you have an alternative solution for abstraction? A regmap would seem
> to require putting everything into a monolithic SX1301 driver despite
> those connected chipsets actually being regular, external SPI chips that
> could also be attached to non-SX1301 SPI masters.

I'm suggesting a regmap for those external SPI chips.  It doesn't matter
what the host uses.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Ben Whitten]

> Subject: Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
> 
> On Tue, Jul 03, 2018 at 06:40:41PM +0200, Andreas Färber wrote:
> 
> > Do you have an alternative solution for abstraction? A regmap would seem
> > to require putting everything into a monolithic SX1301 driver despite
> > those connected chipsets actually being regular, external SPI chips that
> > could also be attached to non-SX1301 SPI masters.
> 
> I'm suggesting a regmap for those external SPI chips.  It doesn't matter
> what the host uses.

Currently in my testing drivers I have used regmap for both the SX1301 and the downstream SX1257.
In my SX1257 driver currently the regmap is backed via SPI with devm_regmap_init_spi, please correct me if I am wrong but if I understand correctly this could be split out to regmap backed by SPI in the case of a direct host connection, and a regmap backed by the SX1301's regmapped strobing register interface, regmap_bus?
Is there a precedent to this I can examine?

Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 819 bytes --]

On Wed, Jul 04, 2018 at 01:41:42PM +0000, Ben Whitten wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> In my SX1257 driver currently the regmap is backed via SPI with
> devm_regmap_init_spi, please correct me if I am wrong but if I
> understand correctly this could be split out to regmap backed by SPI
> in the case of a direct host connection, and a regmap backed by the
> SX1301's regmapped strobing register interface, regmap_bus?

Yes.

> Is there a precedent to this I can examine?

There's lots of devices that provide both SPI and I2C, you'd just be
using a regmap_bus instead of the I2C one.  I can't recall an example of
the specific combination you're looking for though.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Stefan Schmidt]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Ben Whitten]

> Subject: Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
> 
> Hi Ben,
> 
> Am 02.07.2018 um 22:43 schrieb Ben Whitten:
> >> 2) This SPI device is in turn exposing the two SPI masters that you
> >> already found below, and I didn't see a sane way to split that code out
> >> into drivers/spi/, so it's in drivers/net/lora/ here - has there been
> >> any precedence either way?
> >
> > In my work in progress driver I just register one controller for the sx1301
> with two chip selects and use the chip select information to choose the
> correct radio to send to, this is based on the DT reg information. No need to
> register two separate masters.
> 
> I had considered that and discarded it. The SX1301 has not just two CS
> registers though but also two pairs of addr, data registers. That speaks
> for two masters with a single chip-select each, unless I'm
> misunderstanding the meaning of the registers.

Based on Marks suggestion I am experimenting with using the SX1301 to expose a regmap_bus that the underlying SX1257 can attach to, so the radio has a core component, a SPI component for direct connection and this concentrator connection component. 

> >> Am 02.07.2018 um 18:12 schrieb Mark Brown:
> >>> On Sun, Jul 01, 2018 at 01:08:04PM +0200, Andreas Färber wrote:
> >>>
> >>>> +static void sx1301_radio_spi_set_cs(struct spi_device *spi, bool
> enable)
> >>>> +{
> >>>> +	int ret;
> >>>> +
> >>>> +	dev_dbg(&spi->dev, "setting SPI CS to %s\n", enable ? "1" : "0");
> >>>> +
> >>>> +	if (enable)
> >>>> +		return;
> >>>> +
> >>>> +	ret = sx1301_radio_set_cs(spi->controller, enable);
> >>>> +	if (ret)
> >>>> +		dev_warn(&spi->dev, "failed to write CS (%d)\n", ret);
> >>>> +}
> >>>
> >>> So we never disable chip select?
> >>
> >> Not here, I instead did that in transfer_one below.
> >>
> >> Unfortunately there seems to be no documentation, only reference
> code:
> >>
> >> https://github.com/Lora-
> >> net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L121
> >> https://github.com/Lora-
> >> net/lora_gateway/blob/master/libloragw/src/loragw_radio.c#L165
> >>
> >> It sets CS to 0 before writing to address and data registers, then
> >> immediately sets CS to 1 and back to 0 before reading or ending the
> >> write transaction. I've tried to force the same behavior in this driver.
> >> My guess was that CS is high-active during the short 1-0 cycle, because
> >> if it's low-active during the register writes then why the heck is it
> >> set to 0 again in the end instead of keeping at 1... confusing.
> >>
> >> Maybe the Semtech folks CC'ed can comment how these registers work?
> >>
> >>>> +	if (tx_buf) {
> >>>> +		ret = sx1301_write(ssx->parent, ssx->regs +
> >> REG_RADIO_X_ADDR, tx_buf ? tx_buf[0] : 0);
> >>>
> >>> This looks confused.  We're in an if (tx_buf) block but there's a use of
> >>> the ternery operator that appears to be checking if we have a tx_buf?
> >>
> >> Yeah, as mentioned this RFC is not ready for merging - checkpatch.pl
> >> will complain about lines too long, and TODOs are sprinkled all over or
> >> not even mentioned. It's a Proof of Concept that a net_device could work
> >> for a wide range of spi and serdev based drivers, and on top this device
> >> has more than one channel, which may influence network-level design
> >> discussions.
> >>
> >> That said, I'll happily drop the second check. Thanks for spotting!
> >>
> >>>> +		if (ret) {
> >>>> +			dev_err(&spi->dev, "SPI radio address write
> >> failed\n");
> >>>> +			return ret;
> >>>> +		}
> >>>> +
> >>>> +		ret = sx1301_write(ssx->parent, ssx->regs +
> >> REG_RADIO_X_DATA, (tx_buf && xfr->len >= 2) ? tx_buf[1] : 0);
> >>>> +		if (ret) {
> >>>> +			dev_err(&spi->dev, "SPI radio data write failed\n");
> >>>> +			return ret;
> >>>> +		}
> >>>
> >>> This looks awfully like you're coming in at the wrong abstraction layer
> >>> and the hardware actually implements a register abstraction rather than
> >>> a SPI one so you should be using regmap as the abstraction.
> >>
> >> I don't understand. Ben has suggested using regmap for the SPI _device_
> >> that we're talking to, which may be a good idea. But this SX1301 device
> >> in turn has two SPI _masters_ talking to an SX125x slave each. I don't
> >> see how using regmap instead of my wrappers avoids this spi_controller?
> >> The whole point of this spi_controller is to abstract and separate the
> >> SX1255 vs. SX1257 vs. whatever-radio-attached into a separate driver,
> >> instead of mixing it into the SX1301 driver - to me that looks cleaner
> >> and more extensible. It also has the side-effect that we could configure
> >> the two radios via DT (frequencies, clk output, etc.).
> >
> > You want an SPI controller in the SX1301 as the down stream radios are SPI
> and could be attached directly to a host SPI bus, makes sense to have one
> radio driver and talk through the SX1301.
> > But you should use the regmap to access the SX1301 master controller
> registers.
> > Example I use with one SPI master and some clock info:
> > eg:
> > 	sx1301: sx1301@0 {
> 
> Node names should not repeat the chipset, that goes into compatible.
> 
> lora-concentrator@0?
> 
Sure

> > 		compatible = "semtech,sx1301";
> > 		reg = <0>;
> > 		#address-cells = <1>;
> > 		#size-cells = <0>;
> 
> I would still find it cleaner to have (a) sub-node(s) for the radios.
How do you mean?

> > 		spi-max-frequency = <8000000>;
> 
> Datasheet says 10 MHz, why 8 MHz?
> 
> > 		gpios-reset = <&pioA 26 GPIO_ACTIVE_HIGH>;
> 
> reset-gpios?
Agreed, this seems more common.

> > 		clocks = <&radio1 0>, <&clkhs 0>;
> > 		clock-names = "clk32m", "clkhs";
> >
> > 		radio0: sx1257@0 {
> 
> lora@0?
> 
> > 			compatible = "semtech,sx125x";
> 
> No wildcards in bindings please, use concrete "semtech,sx1257".
Sure

> > 			reg = <0>;
> > 			spi-max-frequency = <8000000>;
> 
> Datasheet says 10 ns - I reported to Semtech that it should probably say
> 10 MHz, too.
> 
> > 			tx;
> 
> Might we configure that on the sx1301 instead?

Well the ability for a radio to TX is a radio property really. It depends on the board which chain has the PAs on. I don’t think that its appropriate to configure this at the concentrator, it can instead discover this from the radios.

> > 			clocks = <&tcxo 0>;
> > 			clock-names = "tcxo";
> > 		};
> >
> > 		radio1: sx1257@1 {
> > 			compatible = "semtech,sx125x";
> > 			reg = <1>;
> > 			spi-max-frequency = <8000000>;
> > 			#clock-cells = <0>;
> > 			clocks = <&tcxo 0>;
> > 			clock-names = "tcxo";
> > 			clock-output-names = "clk32m";
> > 		};
> > };
> [snip]
> 
> Regards,
> Andreas
> 
> --
> SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Graham Norton
> HRB 21284 (AG Nürnberg)

RE: [RFC net-next 15/15] net: lora: Add Semtech SX1301

[Ben Whitten]

> Subject: Re: [RFC net-next 15/15] net: lora: Add Semtech SX1301
> 
> Hi Ben,
> 
> Am 02.07.2018 um 13:51 schrieb Ben Whitten:
> > Excellent work on doing this I have also been working on and off
> > this personally for some time.
> 
> Thanks. Colliding work is always unfortunate, I can relate...
> 
> > Have a look at my repository [1] for sx1301 and sx1257 drivers,
> > I use regmaps capability of switching pages which should simplify
> > your driver considerably, I also have a full register map and bit field.
> 
> Please note that my lora-next branch already has bug fixes and cleanups
> over this patch. The probe error handling was broken, and I implemented
> wrappers for paged reads and writes as well as burst modes, plus the
> firmware loading.
> 
> https://github.com/afaerber/linux/commits/lora-next
> 
> I took a quick look at your sx1257 and noticed you licensed it as GPLv2.
> Is there any particular reason for that? Since I wrote my driver without
> copying from GPLv2 code, I prefer the less restrictive GPLv2+.

As I was learning about regmap usage and how SPI devices connect to the bus I adopted the most common licence employed in these kernel files, seemed appropriate.
Ultimately I don’t want a licence choice to hamper inclusion to mainline, not a lawyer I don’t find that fun.

> 
> So far a work day has passed with no maintainer objecting to or
> commenting on the underlying PF_LORA network layer design. Meanwhile
> there's already three of us with code and more people have inquired
> about testing and contributing, so I'm thinking about setting up a
> staging tree on kernel.org to collaborate on...
> 
> Would you be willing to contribute your regmap ideas to my driver as a
> patch to squash? Needs a Signed-off-by of course, which your GitHub
> commits are lacking, so I can't merge them on my own.

I'm sure whichever way we merge it, yours to mine / mine to yours, we can work together on it.
As I already have regmap running and mostly split out SX1257 drivers to Marks suggestions avoiding the extra SPI layer it may by easier to port the various functions you have to mine and share authorship.

> > I have also been trying to use the clk framework to capture the various
> > routing that the cards have.
> 
> I thought about clk too, but won't that cause name conflicts when
> probing multiple concentrators? Would be nice to use that for
> configuring the SX1257 clock output instead of my current hack.

Potentially, it maybe that we need to augment the names of the clk with the CS of the concentrator in use.
Or maybe the radio only searches the clk's of its parent device...
I've not explored this area to far yet but there will be a solution I'm sure.

> Another thought I haven't investigated yet is whether we could use
> remoteproc for ARB and AGC. I would at least prefer to have the firmware
> as a binary loaded via the usual request_firmware(), not as byte array.
> But then again the AGC gets firmware loaded twice, so maybe too complex
> for remoteproc.
> 
> BTW do you have any insights on what MCU is in there? Would be nice to
> understand in form of source code what the firmware is doing, to avoid
> the hard dependency on a specific firmware version (imagine user
> updating kernel-firmware - containing versions X,Y,Z - and kernel and
> booting two different kernel versions, the older one stops working).

I'm afraid no insight into the internals of this chip, some good guesswork but I think a firmware blob is something we are going to have to live with for the time being.

> https://www.thethingsnetwork.org/forum/t/secret-price-of-a-lora-
> gateway/5730/74
> 
> Regards,
> Andreas
> 
> > I will dig into this series this evening.
> >
> > [1] https://github.com/BWhitten/linux-
> stable/tree/971aadc8fdfe842020d912449bdd71b33d576fe3/drivers/net/lora
> [...]
> >> diff --git a/drivers/net/lora/sx1301.c b/drivers/net/lora/sx1301.c
> >> new file mode 100644
> >> index 000000000000..5c936c1116d1
> >> --- /dev/null
> >> +++ b/drivers/net/lora/sx1301.c
> >> @@ -0,0 +1,446 @@
> >> +// SPDX-License-Identifier: GPL-2.0-or-later
> [snip]

Ben

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Helmut Tschemernjak]

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)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Helmut Tschemernjak]

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
>

-- 
best regards / mit freundlichen Gruessen,

Helmut Tschemernjak


HELIOS Software GmbH
Steinriede 3
30827 Garbsen (Hannover)
Phone:    +49-5131-709320
Fax:      +49-5131-709325
Internet    Mail: helmut@helios.de
             Web: http://www.helios.de
             Google+: http://helios.de/helmut

RE: [RFC net-next 00/15] net: A socket API for LoRa

[Ben Whitten]

> 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-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

+ 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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

RE: [RFC net-next 00/15] net: A socket API for LoRa

[Ben Whitten]

> 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)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Jian-Hong Pan]

2018-07-18 19:28 GMT+08:00 Ben Whitten <Ben.Whitten-xJ1y+ldTOs21Z/+hSey0Gg@public.gmane.org>:
>> 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)

linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa)

[Jian-Hong Pan]

Hi Andreas,

2018-08-03 16:44 GMT+08:00 Andreas Färber <afaerber-l3A5Bk7waGM@public.gmane.org>:
> 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-xJ1y+ldTOs21Z/+hSey0Gg@public.gmane.org>:
>>>> 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

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Alan Cox]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Alan Cox]

> 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

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Jian-Hong Pan]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Alexander Aring]

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

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Alexander Aring]

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

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Alan Cox]

> 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

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Stefan Schmidt]

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

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Jian-Hong Pan]

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

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Andreas Färber]

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

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

Re: [RFC net-next 00/15] net: A socket API for LoRa

[Alan Cox]

> 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