Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp459558imm; Wed, 11 Jul 2018 05:39:12 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeHBmkhd9sfGNSgHJbSl4NCh98eIsA5ehNaDlHlq2XoSOpfdph1QQSlqMJsC74lLhMtlsMw X-Received: by 2002:a17:902:1127:: with SMTP id d36-v6mr28930983pla.267.1531312752207; Wed, 11 Jul 2018 05:39:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531312752; cv=none; d=google.com; s=arc-20160816; b=y5LcyAaxGkx/UJTyeYw14wdVF3wxlCARNXzdabRwc75Ta4plyr2nNBXEiy/C4kfq3u YFaMLsMj3muIDGMQiC3SIkQUFzcWRC6i8Z7TXmXjSRE8vuk0d50SbMgK+oAmnHQFR66i kwuPmPGiaiU9Eru4MUeVcFE8D8VhXi4ZI5Qf7A7lS0MfGra8Ke2qaI6flX3vYhlJhHmy 1mGD1vzFRca2kHxzJQJriaabXfwF0WOxbsBXiBo34dJcercZseP9QcbhXfI0a4CLJ3yc mX88GeeAILoP/yIJBXCt1FCq+Bqy7N95rDEhPCuKafhlgsWjQ1geBku3aOcgiFejUgEE /+Ag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=SstrlbmWGV8QjTngCe3TtCpF8K+yhoOc0RXgYxBd1HQ=; b=YnAbU6vz4xmhMKTCwlsrD0Qt0JzGLM9x9f9mNQ2tlg4Qmw922jzw/yg0f3z+dNZf2O oU/M76ovDotI+q7E7Y0aqRP/6iEj4Hd6U7MjKK+v4nhWdxVd/5GzbG2iGaZp23ecHu3s b3UbhqGdJ0WdmJOh4+S0/4KXIwWMDqYNUQmjjjtcUZjj9c6a2Psn5i4c7CY2fQksoIjt cUgu11hUQO5Y1xSPJbc2YF888ySMlHzldKLNjAdIrD292Ih0hlNtDCu1D6fq5T+S5HzE PSWaM5TIi3PKQzV74UReU1+d2uUgOmyrfXihwpv5EQ6so7y0ZiRizTZPetE2MuAqSnPV Lh3Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 20-v6si16839465pgl.358.2018.07.11.05.38.57; Wed, 11 Jul 2018 05:39:12 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732481AbeGKLtW (ORCPT + 99 others); Wed, 11 Jul 2018 07:49:22 -0400 Received: from proxy.helios.de ([193.141.98.37]:53151 "EHLO proxy.helios.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726388AbeGKLtV (ORCPT ); Wed, 11 Jul 2018 07:49:21 -0400 Received: from hpx.helios.de (hpx.helios.de [172.16.0.106]) by proxy.helios.de (Postfix) with ESMTP id C4CD01F71F; Wed, 11 Jul 2018 13:45:21 +0200 (CEST) Received: from macht.dyn.helios.de (proxy.helios.de [172.16.0.2]) by hpx.helios.de (Postfix) with ESMTP id A8D4C1F60C; Wed, 11 Jul 2018 13:45:21 +0200 (CEST) Subject: Re: [RFC net-next 00/15] net: A socket API for LoRa To: =?UTF-8?Q?Andreas_F=c3=a4rber?= Cc: Stefan Schmidt , netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Jian-Hong Pan , Jiri Pirko , Marcel Holtmann , "David S . Miller" , Matthias Brugger , Janus Piwek , =?UTF-8?Q?Michael_R=c3=b6der?= , Dollar Chen , Ken Yu , =?UTF-8?Q?Konstantin_B=c3=b6hm?= , Jan Jongboom , Jon Ortego , contact@snootlab.com, Ben Whitten , Brian Ray , lora@globalsat.com.tw, lora@radioshuttle.de, Alexander Graf , =?UTF-8?Q?Michal_Kube=c4=8dek?= , Rob Herring , devicetree@vger.kernel.org, Steve deRosier , Mark Brown , linux-spi@vger.kernel.org, Hasnain Virk References: <20180701110804.32415-1-afaerber@suse.de> <487df785-ddf5-ed81-a253-6afb7f2de811@datenfreihafen.org> <5aac9ea5-484c-1b3b-8058-50e11e8d7a9a@helios.de> <23213cab-dc87-118c-1750-cd30d60ce9f8@suse.de> From: Helmut Tschemernjak Organization: HELIOS Software GmbH Message-ID: <5fed8b9a-20a3-4677-0213-ac2814c4aaa9@helios.de> Date: Wed, 11 Jul 2018 13:45:22 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <23213cab-dc87-118c-1750-cd30d60ce9f8@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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