> > > Am 18.12.18 um 15:27 schrieb Jian-Hong Pan: > > > >> Sun, Dec 16, 2018 at 11:18:59AM CET, starnight@xxxxxxxxxxxx wrote: > > > >>> LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa > > > devices. > > > >>> > > > >>> This patch implements part of Class A end-devices SoftMAC defined in > > > >>> LoRaWAN(TM) Specification Ver. 1.0.2: > > > >>> 1. End-device receive slot timing > > > >>> 2. Only single channel and single data rate for now > > > >>> 3. Unconfirmed data up/down message types > > > >>> > > > >>> On the other side, it defines the basic interface and operation > > > >>> functions for compatible LoRa device drivers. > > > >>> > > > >>> Signed-off-by: Jian-Hong Pan <starnight@xxxxxxxxxxxx> > > > [...] > > > >>> net/maclorawan/Kconfig | 14 + > > > >>> net/maclorawan/Makefile | 2 + > > > >>> net/maclorawan/mac.c | 555 > > > ++++++++++++++++++++++++++++++++++++ > > > >>> net/maclorawan/main.c | 606 > > > ++++++++++++++++++++++++++++++++++++++++ > > > >>> 4 files changed, 1177 insertions(+) > > > >>> create mode 100644 net/maclorawan/Kconfig > > > >>> create mode 100644 net/maclorawan/Makefile > > > >>> create mode 100644 net/maclorawan/mac.c > > > >>> create mode 100644 net/maclorawan/main.c > > > >> > > > >> I don't get it. In patch "Add LoRaWAN API declaration for LoRa devices" > > > >> you add headers for "API" and here you implement functions. That is > just > > > >> weird. Does it mean you can have other implementations? > > > > > > > > LoRaWAN defined by LoRa Alliance(TM) is the MAC layer over LoRa PHY. > > > > This part is soft-MAC as Andreas mentioned > > > > http://lists.infradead.org/pipermail/linux-lpwan/2018- > > > December/000010.html > > > > > > > >> Also, you don't really have any user of this API in the set. Please > > > >> introduce at least 1 driver, preferably more (I see that Andreas has > > > >> multiple ones in his patchset). You cannot push kernel infrastructure > > > >> without kernel user. > > > > > > > > The soft-MAC is suitable for the LoRa chips' device drivers, like > > > > sx1276/77/78/79, RFM95/96/97/98W ... > > > > Still waiting for Andreas' sx1276 version 2 patch and more discussion. > > > > > > sx1276 regmap conversion was pushed to my staging tree together with > > > Ben's sx1301 final conversion last night, lightly tested. > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux- > > > lora.git/log/?h=lora-next > > > > > > TBD: rename to sx127x, implement regmap fields, only auto-detect reset > > > when no OF node available (all low priority atm, patches welcome) > > > > > > (and for sx1301 I still need to update my DT overlays with the new clk) > > > > > > > For example, how to make PF_LORA and PF_LORAWAN like Ethernet, > > > PF_INET > > > > and PF_INET6 don't need separate devices either, both use eth0. > > > > https://lkml.org/lkml/2018/8/3/266 > > > > > > Jiri, I am expecting the maclorawan driver to lower packets from > > > ETH_P_LORAWAN to ETH_P_LORA in a generic way, so that any of the LoRa > > > device drivers can benefit of it, with maclorawan using the LoRa netlink > > > commands that the individual drivers implement. > > > Not sure what if anything is missing for that in the current revision? > > > Still dealing with the lower-level infrastructure and my test setup ... > > > progressing slowly. > > > > > > I'll probably need to queue the remaining generic LoRaWAN part 1/6 in my > > > tree to resolve this circular dependency between Jian-Hong and me, so > > > that only the soft-MAC implementation remains a separate patch series. > > > The hard-MAC implementations will be on my plate mostly, as both SX1276 > > > and SX1301 need the soft-MAC. > > > > On the SX1301 side of things, the ability to send messages as a LoRaWAN > > node device is a niche use case, the majority if not all people will use the > > concentrator card as the pass through gateway to the node. > > > > In this mode of operation the parameters for transmission such as; > frequency, > > spreading factor / data rate, power, are given by a remote server and passed > > in from the userspace application which received it. > > Eventually in the kernel these need to be checked locally to ensure > regulatory > > compliance. > > To that end I have experimented with framing, as CAN does, so that this > > metadata can be provided on a write from userspace to the SX1301 driver. > > > > Sounds like we need different protocols for framing within the protocol > family. > > Raw in the case of nodes and framed with metadata in the case of > concentrator > > cards, thoughts? > > Yes, I have thought the roles of node and gateway. They may have > different skb passing paths. > As you mentioned, many things of the gateway is controlled by the > remote server. So, I only implement the path for nodes right now. > Maybe, we can have a role flag: node, gateway which can be assigned by > some way. Then, the skb can be decode, checked and passed according > to the role flag. And module also checks the integrity (MIC, length > ...) and filter out the bad skb before sends to next stop. As IP have IPPROTO_TCP, IPPROTO_UDP, etc maybe we can have LORA_PROTO_MODULE, LORA_PROTO_GATEWAY which dictates the pathway and skb format. > > I will send my experiment RFC to the lpwan mailing list. > > Or you can send the RFC first. Then we can have the skb passing path > for gateway and figure out how to put them together. > > Does this sound reasonable? Sent, it's being held at mailing list for moderator approval but should be in your inboxes currently. Regards, Ben
