From: Ben Whitten <Ben.Whitten@lairdtech.com>
To: "Andreas Färber" <afaerber@suse.de>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Jian-Hong Pan" <starnight@g.ncu.edu.tw>,
"Jiri Pirko" <jiri@resnulli.us>,
"Marcel Holtmann" <marcel@holtmann.org>,
"David S . Miller" <davem@davemloft.net>,
"Matthias Brugger" <mbrugger@suse.com>,
"Janus Piwek" <jpiwek@arroweurope.com>,
"Michael Röder" <michael.roeder@avnet.eu>,
"Dollar Chen" <dollar.chen@wtmec.com>,
"Ken Yu" <ken.yu@rakwireless.com>,
"Konstantin Böhm" <konstantin.boehm@ancud.de>,
"Jan Jongboom" <jan.jongboom@arm.com>,
"Jon Ortego" <Jon.Ortego@imst.de>,
"contact@snootlab.com" <contact@snootlab.com>,
"Brian Ray" <brian.ray@link-labs.com>,
"lora@globalsat.com.tw" <lora@globalsat.com.tw>,
"Alexander Graf" <agraf@suse.de>,
"Michal Kubeček" <mkubecek@suse.cz>,
"Rob Herring" <robh@kernel.org>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"Steve deRosier" <derosier@gmail.com>,
"Mark Brown" <broonie@kernel.org>,
"linux-spi@vger.kernel.org" <linux-spi@vger.kernel.org>,
"Hasnain Virk" <Hasnain.Virk@arm.com>,
"Stefan Schmidt" <stefan@datenfreihafen.org>,
"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
"seth.forshee@canonical.com" <seth.forshee@canonical.com>
Subject: RE: [RFC net-next 00/15] net: A socket API for LoRa
Date: Wed, 18 Jul 2018 11:28:41 +0000 [thread overview]
Message-ID: <BY1PR02MB11143134B9ABAC9C9929A9C4E7530@BY1PR02MB1114.namprd02.prod.outlook.com> (raw)
In-Reply-To: <e08cdcfb-207f-bd73-2afd-f775810b72b7@suse.de>
> 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)
next prev parent reply other threads:[~2018-07-18 11:28 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-01 11:07 [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber
2018-07-01 11:07 ` [RFC net-next 01/15] net: Reserve protocol numbers " Andreas Färber
2018-07-01 11:07 ` [RFC net-next 02/15] net: lora: Define sockaddr_lora Andreas Färber
2018-07-01 11:07 ` [RFC net-next 03/15] net: lora: Add protocol numbers Andreas Färber
2018-07-01 11:07 ` [RFC net-next 04/15] net: Add lora subsystem Andreas Färber
2018-07-01 11:07 ` [RFC net-next 05/15] HACK: net: lora: Deal with .poll_mask in 4.18-rc2 Andreas Färber
2018-07-02 16:22 ` Jiri Pirko
2018-07-02 16:59 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 06/15] net: lora: Prepare for device drivers Andreas Färber
2018-07-01 11:07 ` [RFC net-next 07/15] net: lora: Add Semtech SX1276 Andreas Färber
2018-07-01 12:02 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 08/15] net: lora: sx1276: Add debugfs Andreas Färber
2018-07-02 16:26 ` Jiri Pirko
2018-07-02 17:57 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 09/15] net: lora: Prepare EUI helpers Andreas Färber
2018-07-01 11:07 ` [RFC net-next 10/15] net: lora: Add Microchip RN2483 Andreas Färber
2018-07-01 11:08 ` [RFC net-next 11/15] net: lora: Add IMST WiMOD Andreas Färber
2019-01-06 14:57 ` Heinrich Schuchardt
2019-01-07 11:29 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 12/15] net: lora: Add USI WM-SG-SM-42 Andreas Färber
2018-07-01 11:08 ` [RFC net-next 13/15] net: lora: Prepare RAK RAK811 Andreas Färber
2018-07-01 11:08 ` [RFC net-next 14/15] net: lora: Prepare Semtech SX1257 Andreas Färber
2018-07-01 11:08 ` [RFC net-next 15/15] net: lora: Add Semtech SX1301 Andreas Färber
2018-07-02 11:51 ` Ben Whitten
2018-07-03 3:01 ` Andreas Färber
2018-07-05 8:59 ` Ben Whitten
2018-07-02 16:12 ` Mark Brown
2018-07-02 17:34 ` Andreas Färber
2018-07-02 20:43 ` Ben Whitten
2018-07-03 3:21 ` Andreas Färber
2018-07-05 8:43 ` Ben Whitten
2018-07-03 14:50 ` Mark Brown
2018-07-03 15:09 ` Andreas Färber
2018-07-03 15:31 ` Mark Brown
2018-07-03 16:40 ` Andreas Färber
2018-07-04 11:43 ` Mark Brown
2018-07-04 13:41 ` Ben Whitten
2018-07-04 14:32 ` Mark Brown
2018-07-03 15:11 ` [RFC net-next 00/15] net: A socket API for LoRa Jian-Hong Pan
2018-08-05 0:11 ` Andreas Färber
2018-08-08 20:36 ` Alan Cox
2018-08-08 22:42 ` Andreas Färber
2018-08-09 11:59 ` Alan Cox
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:21 ` Alexander Aring
2018-08-10 15:57 ` Alan Cox
2018-08-11 18:30 ` Stefan Schmidt
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:37 ` Jian-Hong Pan
2018-08-12 17:59 ` Andreas Färber
2018-08-13 12:36 ` Alan Cox
2018-08-09 15:12 ` Alexander Aring
2018-08-09 0:50 ` Andreas Färber
2018-07-04 18:26 ` Stefan Schmidt
2018-07-05 10:43 ` Helmut Tschemernjak
2018-07-11 2:07 ` Andreas Färber
2018-07-11 11:45 ` Helmut Tschemernjak
2018-07-11 15:21 ` Ben Whitten
2018-07-15 18:13 ` Andreas Färber
2018-07-18 11:28 ` Ben Whitten [this message]
2018-08-02 7:52 ` Jian-Hong Pan
2018-08-03 8:44 ` linux-lora.git and LoRaWAN (was: [RFC net-next 00/15] net: A socket API for LoRa) Andreas Färber
2018-08-05 12:49 ` Jian-Hong Pan
2018-08-05 13:49 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BY1PR02MB11143134B9ABAC9C9929A9C4E7530@BY1PR02MB1114.namprd02.prod.outlook.com \
--to=ben.whitten@lairdtech.com \
--cc=Hasnain.Virk@arm.com \
--cc=Jon.Ortego@imst.de \
--cc=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=brian.ray@link-labs.com \
--cc=broonie@kernel.org \
--cc=contact@snootlab.com \
--cc=davem@davemloft.net \
--cc=derosier@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=dollar.chen@wtmec.com \
--cc=jan.jongboom@arm.com \
--cc=jiri@resnulli.us \
--cc=jpiwek@arroweurope.com \
--cc=ken.yu@rakwireless.com \
--cc=konstantin.boehm@ancud.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-spi@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lora@globalsat.com.tw \
--cc=marcel@holtmann.org \
--cc=mbrugger@suse.com \
--cc=michael.roeder@avnet.eu \
--cc=mkubecek@suse.cz \
--cc=netdev@vger.kernel.org \
--cc=robh@kernel.org \
--cc=seth.forshee@canonical.com \
--cc=starnight@g.ncu.edu.tw \
--cc=stefan@datenfreihafen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).