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>
PiBTdWJqZWN0OiBSZTogW1JGQyBuZXQtbmV4dCAwMC8xNV0gbmV0OiBBIHNvY2tldCBBUEkgZm9y
IExvUmENCj4gDQo+ICsgbGludXgtd2lyZWxlc3MgKyBTdGVmYW4gKyBTZXRoDQo+IA0KPiBBbSAx
MS4wNy4yMDE4IHVtIDE3OjIxIHNjaHJpZWIgQmVuIFdoaXR0ZW46DQo+ID4+IFRoaXMgcGF0Y2hz
ZXQgaXMgY2xlYXJseSBub3QgcmVhZHkgZm9yIG1lcmdpbmcsIGJ1dCBpcyBiZWluZw0KPiA+PiBz
dWJtaXR0ZWQgZm9yDQo+ID4+IGRpc2N1c3Npb24sIGFzIHJlcXVlc3RlZCBieSBKaXJpLCBpbiBw
YXJ0aWN1bGFyIG9mIHRoZSBkZXNpZ24NCj4gPj4gY2hvaWNlczoNCj4gPj4NCj4gPj4gMSkgUEZf
TE9SQS9BRl9MT1JBIGFuZCBhc3NvY2lhdGVkIGlkZW50aWZpZXJzIGFyZQ0KPiA+PiBwcm9wb3Nl
ZCB0byByZXByZXNlbnQNCj4gPj4gICAgdGhpcyB0ZWNobm9sb2d5LiBXaGlsZSBmb3IgYW4gU1gx
Mjc2IC0gY2FzZSBhKSBhYm92ZSAtIGl0DQo+ID4+IG1pZ2h0IHdvcmsgdG8NCj4gPj4gICAgbGF5
ZXIgTG9SYVdBTiBhcyBhIHByb3RvY29sIG9wdGlvbiBmb3IgUEZfTE9SQSBhbmQNCj4gYWRkDQo+
ID4+IExvUmFXQU4gYWRkcmVzcw0KPiA+PiAgICBmaWVsZHMgdG8gdGhlIHVuaW9uIGluIG15IHNv
Y2thZGRyX2xvcmEsIGhvdyB3b3VsZCB0aGF0DQo+ID4+IHdvcmsgZm9yIGRldmljZXMNCj4gPj4g
ICAgdGhhdCBvbmx5IHN1cHBvcnQgTG9SYVdBTiBidXQgbm90IHB1cmUgTG9SYT8gRG8gd2UNCj4g
Pj4gbmVlZCBib3RoIEFGX0xPUkEgYW5kDQo+ID4+ICAgIEFGX0xPUkFXQU4sIG9yIGp1c3QgYSBz
ZXBhcmF0ZSBFVEhfUF9MT1JBV0FOIG9yDQo+ID4+IEFSUEhSRF9MT1JBV0FOPw0KPiA+Pg0KPiA+
PiAyKSBQRl9MT1JBIGlzIHVzZWQgd2l0aCBTT0NLX0RHUkFNIGhlcmUuIFRoZQ0KPiA+PiBhc3N1
bXB0aW9uIGlzIHRoYXQgUkFXIG1vZGUNCj4gPj4gICAgd291bGQgYmUgREdSQU0gcGx1cyBwcmVh
bWJsZSBwbHVzIG9wdGlvbmFsDQo+IGNoZWNrc3VtLg0KPiA+Pg0KPiA+PiAzKSBPbmx5IHRoZSB0
cmFuc21pdCBwYXRoIGlzIHBhcnRpYWxseSBpbXBsZW1lbnRlZA0KPiBhbHJlYWR5Lg0KPiA+PiBU
aGUgYXNzdW1wdGlvbg0KPiA+PiAgICBpcyB0aGF0IHRoZSBkZXZpY2VzIHNob3VsZCBnbyBpbnRv
IHJlY2VpdmUgbW9kZSBieQ0KPiBkZWZhdWx0DQo+ID4+IGFuZCBvbmx5DQo+ID4+ICAgIGludGVy
cnVwdCB0aGF0IHdoZW4gYXNrZWQgdG8gdHJhbnNtaXQuDQo+ID4+DQo+ID4+IDQpIFNvbWUgaGFy
ZHdhcmUgc2V0dGluZ3MgbmVlZCB0byBiZSBzdXBwbGllZA0KPiBleHRlcm5hbGx5LA0KPiA+PiBz
dWNoIGFzIHRoZSByYWRpbw0KPiA+PiAgICBmcmVxdWVuY3kgZm9yIHNvbWUgbW9kdWxlcywgYnV0
IG1hbnkgb3RoZXJzIGNhbiBiZQ0KPiA+PiBydW50aW1lLWNvbmZpZ3VyZWQsDQo+ID4+ICAgIHN1
Y2ggYXMgU3ByZWFkaW5nIEZhY3RvciwgQmFuZHdpZHRoLCBTeW5jIFdvcmQsIG9yDQo+IHdoaWNo
DQo+ID4+IGFudGVubmEgdG8gdXNlLg0KPiA+PiAgICBXaGF0IHNldHRpbmdzIHNob3VsZCBiZSBp
bXBsZW1lbnRlZCBhcyBzb2NrZXQgb3B0aW9uDQo+IHZzLg0KPiA+PiBuZXRsaW5rIGxheWVyDQo+
ID4+ICAgIHZzLiBpb2N0bCB2cy4gc3lzZnM/IFdoYXQgYXJlIHRoZSBjcml0ZXJpYSB0byBhcHBs
eT8NCj4gPj4NCj4gPj4gNSkgTWFueSBvZiB0aGUgbW9kdWxlcyBzdXBwb3J0IG11bHRpcGxlIG1v
ZGVzLCBzdWNoIGFzDQo+ID4+IExvUmEsIExvUmFXQU4gYW5kIEZTSy4NCj4gPj4gICAgTGFja2lu
ZyBhIExvUmFXQU4gaW1wbGVtZW50YXRpb24sIEkgYW0gY3VycmVudGx5DQo+ID4+IHN3aXRjaGlu
ZyB0aGVtIGludG8gTG9SYQ0KPiA+PiAgICBtb2RlIGF0IHByb2JlIHRpbWUgd2hlcmV2ZXIgcG9z
c2libGUuIEhvdyBkbyB3ZQ0KPiBkZWFsDQo+ID4+IHdpdGggdGhhdCBwcm9wZXJseT8NCj4gPj4N
Cj4gPj4gICBhKSBJcyB0aGVyZSBhbnkgcHJlY2VkZW5jZSBmcm9tIHRoZSBXaWZpIHdvcmxkIGZv
cg0KPiA+PiBkeW5hbWljYWxseSBzZWxlY3RpbmcNCj4gPj4gICAgICBiZXR3ZWVuIG91ciBvd24g
dHJ1c3RlZCBPcGVuIFNvdXJjZQ0KPiBpbXBsZW1lbnRhdGlvbg0KPiA+PiB2cy4gaGFyZHdhcmUv
ZmlybXdhcmUNCj4gPj4gICAgICBhY2NlbGVyYXRlZCBhbmQvb3IgY2VydGlmaWVkIGltcGxlbWVu
dGF0aW9ucz8NCj4gPj4NCj4gPj4gICBiKSBXb3VsZCBhIHByb29mIG9mIGNvbmNlcHQgZm9yIEZT
SyAobm9uLUxvUmEpIG1vZGVzDQo+IGJlDQo+ID4+IHJlcXVpcmVkIGZvcg0KPiA+PiAgICAgIG1l
cmdpbmcgYW55IExvUmEgZHJpdmVyIGZvciBjaGlwc2V0cyB0aGF0IHN1cHBvcnQNCj4gYm90aD8N
Cj4gPj4gT3IgaXMgdGhlcmUgYW55DQo+ID4+ICAgICAgZmFjaWxpdHkgb3IgZGVzaWduIGd1aWRl
bGluZXMgdGhhdCB3b3VsZCBhbGxvdyB1cyB0bw0KPiBmb2N1cw0KPiA+PiBvbiBMb1JhIGFuZA0K
PiA+PiAgICAgIExvUmFXQU4gYW5kIGxlYXZlIG5vbi1Mb1JhIHJhZGlvIG1vZGVzIHRvIGxhdGVy
DQo+ID4+IGNvbnRyaWJ1dG9ycz8NCj4gPg0KPiA+IERvd24gdGhlIGxpbmUgSSB0aGluayB3ZSBz
aG91bGQgYWxzbyBwbGFuIGZvciBhIENSREEgc3R5bGUNCj4gcmVnZGIgc29tZXdoZXJlIGluIHRo
ZSBwYXRoIGZvciByYXcgTG9SYSB0cmFuc2NlaXZlcnMNCj4gb3BlcmF0aW5nIGFzIHNvZnRNQUMs
IG11Y2ggbGlrZSB3aXRoIFdpRmkuDQo+IA0KPiBZZXMsIEkgaGFkIHJhaXNlZCB0aGUgdG9waWMg
b2Ygd2lyZWxlc3MtcmVnZGIgZm9yIFN0ZWZhbidzDQo+IGNvbmZlcmVuY2UgLQ0KPiBjdXJyZW50
bHkgaXQgc2VlbXMgdG8gb25seSBjb3ZlciAyLjQgR0h6LCA1IEdIeiBhbmQgNjAgR0h6Lg0KPiBO
b3Qgc3VyZSBpZg0KPiB3ZSBjYW4gZWFzaWx5IGV4dGVuZCB0aGF0IHRvIGNvdmVyIDQzMyBNSHos
IDg2OCBNSHosIDkxNQ0KPiBNSHogYW5kIDkyMyBNSHoNCj4gYmFuZHMgb3Igd2hldGhlciB3ZSdk
IGp1c3QgbmVlZCBzb21ldGhpbmcgc2ltaWxhci4uLiBJcw0KPiA4MDIuMTUuNCBhYmxlIHRvDQo+
IHNoYXJlIHRoaXMgZGF0YWJhc2Ugd2l0aCBXaWZpPw0KDQpXZWxsIHRoZSBSRUFETUUgaW4gdGhl
IHdpcmVsZXNzLXJlZ2RiIGRvZXNuJ3QgYmluZCBpdHNlbGYgdG8gODAyMTEsIHRoZXJlIGFyZSBy
ZWZlcmVuY2VzIHRvIHRoZSBvdGhlciBFVFNJIEVOIHNwZWNzIHNvIHRoaXMgd291bGQgYmUgdGhl
IHBsYWNlIHJhdGhlciB0aGFuIGR1cGxpY2F0aW5nLg0KVGhlcmUgd291bGQgbmVlZCBhIGJpdCBv
ZiBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIHRvIGNhcHR1cmUgZHV0eS1jeWNsZSByZXF1aXJlbWVu
dHMsIGhvd2V2ZXIgdGhlIFNSRCBzcGVjIHN0YXRlcyB0aGUgbWF4aW11bSBiYW5kd2lkdGhzIGNh
biBiZSAnVGhlIHdob2xlIGJhbmQnLCBzbyB3aXRoIGEgZmxhZyBzZXQgd2UgY291bGQgaGlqYWNr
IHRoaXMgYmFuZCBpbmZvcm1hdGlvbiBmb3IgZHV0eS1jeWNsZS4NCkkgYW0gdW5zdXJlIGlmIDgw
Mi4xNS40IHVzZXMgdGhpcyBkYXRhYmFzZSwgbW9zdCBvZiB0aGUgbmFtaW5nIHNlZW1zIGdlYXJl
ZCB0b3dhcmRzIDgwMjExLCBubDgwMjExLCBjZmc4MDIxMSBzbyBwZXJoYXBzIHdlIG5lZWQgb3Vy
IG93biB2ZXJzaW9ucyBvZiB0aGVzZSB3aXRoIGEgY29tbW9uIGNvbXBvbmVudCwgSSBob3BlIHRo
ZSBtYWludGFpbmVycyBjYW4gZ2l2ZSBzb21lIGd1aWRhbmNlIGhlcmUuDQoNCj4gQW4gYXJndW1l
bnQgdG8gc2hhcmUgd2l0aCBXaWZpIG1pZ2h0IGJlIHRoYXQgU2VtdGVjaCdzDQo+IFNYMTI4MCBh
bmQgU1gxMjgxDQo+IDIuNCBHSHogdHJhbnNjZWl2ZXJzIGNsYWltIHRvIHN1cHBvcnQgTG9SYSBt
b2R1bGF0aW9uLCB0b28uDQo+IEhhdmluZyB0d28NCj4gZGlmZmVyZW50IHJlZ3VsYXRvcnkgREJz
IGludGVyYWN0IHdpdGggTG9SYSBkcml2ZXJzIHNlZW1zIGENCj4gYmFkIGlkZWEsDQo+IGFuZCBk
dXBsaWNhdGluZyAyLjQgR0h6IGludG8gYSBuZXcgREIgZG9lc24ndCBzb3VuZA0KPiBhcHBlYWxp
bmcgZWl0aGVyLg0KDQpXZWxsIEknbSBub3Qgc3VyZSBpZiB0aGUgbW9kdWxhdGlvbiBhZmZlY3Rz
IHJlZ3VsYXRvcnkgaW5mb3JtYXRpb24sIGp1c3QgYmFuZHMsIHBvd2VyLCBhbmQgdGVjaG5pcXVl
cyBsaWtlIERGUy4NCkFzIHRoZXNlIGNoaXBzIGFyZSAyLjRHSHogb25seSBJIGV4cGVjdCB0aGV5
IGFyZSBib3VuZCBieSB0aGUgZXhpc3RpbmcgcmVndWxhdG9yeSBpbmZvcm1hdGlvbiB3ZSB3b3Vs
ZCBqdXN0IG5lZWQgYSBwYXRoIHRvIGFjY2VzcyBpdC4NCiANCj4gaHR0cHM6Ly93d3cuc2VtdGVj
aC5jb20vcHJvZHVjdHMvd2lyZWxlc3MtcmYvMjQtZ2h6LQ0KPiB0cmFuc2NlaXZlcnMNCj4gDQo+
IE1lYW53aGlsZSBteSBhdHRlbXB0IHRvIHBsYXkgd2l0aCBuZXRsaW5rIGR1cmluZyBTVVNFDQo+
IEhhY2t3ZWVrIGhhcyBiZWVuDQo+IGdvaW5nIHNsb3cgYW5kIEkgY291bGQgdXNlIHNvbWUgZ3Vp
ZGFuY2Ugb3IgYSB2b2x1bnRlZXIgdG8NCj4gY29udHJpYnV0ZTogSQ0KPiBoYXZlIGEgYmFyZSBz
a2VsZXRvbiBvZiByZWdpc3RyYXRpb24sIGNvbW1hbmRzLCBhdHRyaWJ1dGVzDQo+IGFuZCBtdWx0
aWNhc3QNCj4gZ3JvdXBzLCBidXQgbm8gcGxhbiB5ZXQgaG93IHRvIGNvbm5lY3QgdGhhdCB0byB0
aGUgYWN0dWFsDQo+IGRyaXZlcnMgdG8NCj4gcXVlcnkgb3IgYXBwbHkgdGhlIHNldHRpbmdzLi4u
DQoNCkhhcHB5IHRvIGhlbHAsIEkgd2lsbCBiZSBzdGFydGluZyBmcm9tIHplcm8gb24gbmV0bGlu
ayBidXQgSSBjYW4gY29udHJpYnV0ZSBteSBleGlzdGluZyB3b3JrIGluY29ycG9yYXRpbmcgTWFy
a3MgY29tbWVudHMgZm9yIHN4MTMwMSBldGFsLg0KDQo+IGh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcv
cHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L2FmYWVyYmVyL2xpDQo+IG51eC1sb3JhLmdpdC90cmVl
L25ldC9sb3JhL25ldGxpbmsuYz9oPWxvcmEtbmV4dA0KPiANCj4gPiBMb1JhIHJhZGlvcyB1c2Vk
IGluIEdhdGV3YXkgZGV2aWNlcyBhcmUgdHlwaWNhbGx5IHJlbGF0aXZlbHkNCj4gaGlnaCBwb3dl
ciAoY2FwYWJsZSBvZiAyN2RCbSkgYW5kIG9wZXJhdGUgaW4gYmFuZHMgd2l0aA0KPiBjZXJ0YWlu
IHJlc3RyaWN0aW9ucywgZWcgdGhlIEVVIGhhcyBrZWVwIG91dCBhcmVhcyB3aXRoaW4NCj4gODY4
TUh6IGZvciBhbGFybXMgYW5kIFNSRCBkZXZpY2VzIG11c3QgYWJpZGUgYnkgY2VydGFpbg0KPiBk
dXR5IGN5Y2xlIHJlc3RyaWN0aW9ucywgdGhlcmUgYXJlIGFsc28gbWF4aW11bSBwb3dlcnMgdG8N
Cj4gY29uc2lkZXIgZm9yIHN1Yi1iYW5kcy4gKEVUU0kgRU4gMzAwIDIyMC0yIFYzLjIuMSwgQmFu
ZHMgSywNCj4gTCwgTSwgTiwgUCwgUSkNCj4gDQo+ID4gVGhlIGNlcnRpZmllZCBBVCBzdHlsZSBt
b2R1bGVzIHdpbGwgKHNob3VsZCkgYWxyZWFkeSBoYXZlDQo+IHRoaXMgcmVndWxhdG9yeSBkYXRh
IGJha2VkIGluIHNvIGl0IG9ubHkgYXBwbGllZCB0byBzaXR1YXRpb25zDQo+IHdoZXJlIHdlIGRy
aXZlIHRoZSB0cmFuc2NlaXZlcnMgZGlyZWN0bHksIGJ1dCBpdCB3b3VsZG4ndA0KPiBodXJ0IHRv
IGNoZWNrIHRoYXQgdGhlIGZyZXF1ZW5jeSBiZWluZyBhc2tlZCB0byB0cmFuc21pdCBvbg0KPiBk
b2Vzbid0IHNwaWxsIGludG8gYSByZXN0cmljdGVkIGJhbmQuDQo+IA0KPiBTb21lIGRvIGhhdmUg
Y29uZmlndXJhdGlvbiBvcHRpb25zIHRoYXQgd2lsbCBuZWVkIHRvIGJlIHNldA0KPiBvciBjaGVj
a2VkLg0KPiANCj4gUmVnYXJkcywNCj4gQW5kcmVhcw0KPiANCj4gLS0NCj4gU1VTRSBMaW51eCBH
bWJILCBNYXhmZWxkc3RyLiA1LCA5MDQwOSBOw7xybmJlcmcsIEdlcm1hbnkNCj4gR0Y6IEZlbGl4
IEltZW5kw7ZyZmZlciwgSmFuZSBTbWl0aGFyZCwgR3JhaGFtIE5vcnRvbg0KPiBIUkIgMjEyODQg
KEFHIE7DvHJuYmVyZykNCg==
WARNING: multiple messages have this Message-ID (diff)
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)
WARNING: multiple messages have this Message-ID (diff)
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>
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)
WARNING: multiple messages have this Message-ID (diff)
From: Ben.Whitten@lairdtech.com (Ben Whitten)
To: linux-arm-kernel@lists.infradead.org
Subject: [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 12:06 UTC|newest]
Thread overview: 173+ 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 ` Andreas Färber
2018-07-01 11:07 ` 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 ` Andreas Färber
2018-07-01 11:07 ` 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 ` Andreas Färber
2018-07-01 11:07 ` 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 ` 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 ` Andreas Färber
2018-07-01 11:07 ` 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-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-02 16:22 ` Jiri Pirko
2018-07-02 16:22 ` Jiri Pirko
2018-07-02 16:59 ` Andreas Färber
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 ` Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 11:07 ` [RFC net-next 07/15] net: lora: Add Semtech SX1276 Andreas Färber
2018-07-01 11:07 ` Andreas Färber
2018-07-01 12:02 ` 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-01 11:07 ` Andreas Färber
2018-07-02 16:26 ` Jiri Pirko
2018-07-02 16:26 ` Jiri Pirko
2018-07-02 17:57 ` Andreas Färber
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 ` 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:07 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 11/15] net: lora: Add IMST WiMOD Andreas Färber
2018-07-01 11:08 ` Andreas Färber
2019-01-06 14:57 ` Heinrich Schuchardt
2019-01-06 14:57 ` Heinrich Schuchardt
2019-01-07 11:29 ` Andreas Färber
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 ` 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 ` 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 ` Andreas Färber
2018-07-01 11:08 ` [RFC net-next 15/15] net: lora: Add Semtech SX1301 Andreas Färber
2018-07-01 11:08 ` Andreas Färber
2018-07-02 11:51 ` Ben Whitten
2018-07-02 11:51 ` Ben Whitten
2018-07-03 3:01 ` Andreas Färber
2018-07-03 3:01 ` Andreas Färber
2018-07-05 8:59 ` Ben Whitten
2018-07-05 8:59 ` Ben Whitten
2018-07-05 8:59 ` Ben Whitten
2018-07-02 16:12 ` Mark Brown
2018-07-02 16:12 ` Mark Brown
2018-07-02 16:12 ` Mark Brown
2018-07-02 17:34 ` Andreas Färber
2018-07-02 17:34 ` Andreas Färber
2018-07-02 20:43 ` Ben Whitten
2018-07-02 20:43 ` Ben Whitten
2018-07-03 3:21 ` Andreas Färber
2018-07-03 3:21 ` Andreas Färber
2018-07-03 3:21 ` Andreas Färber
2018-07-05 8:43 ` Ben Whitten
2018-07-05 8:43 ` Ben Whitten
2018-07-05 8:43 ` Ben Whitten
2018-07-03 14:50 ` Mark Brown
2018-07-03 14:50 ` Mark Brown
2018-07-03 15:09 ` Andreas Färber
2018-07-03 15:09 ` Andreas Färber
2018-07-03 15:09 ` Andreas Färber
2018-07-03 15:31 ` Mark Brown
2018-07-03 15:31 ` Mark Brown
2018-07-03 15:31 ` Mark Brown
2018-07-03 16:40 ` Andreas Färber
2018-07-03 16:40 ` Andreas Färber
2018-07-04 11:43 ` Mark Brown
2018-07-04 11:43 ` Mark Brown
2018-07-04 13:41 ` Ben Whitten
2018-07-04 13:41 ` Ben Whitten
2018-07-04 13:41 ` Ben Whitten
2018-07-04 14:32 ` Mark Brown
2018-07-04 14:32 ` Mark Brown
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-07-03 15:11 ` Jian-Hong Pan
2018-07-03 15:11 ` Jian-Hong Pan
2018-08-05 0:11 ` Andreas Färber
2018-08-05 0:11 ` Andreas Färber
2018-08-05 0:11 ` Andreas Färber
2018-08-08 20:36 ` Alan Cox
2018-08-08 20:36 ` Alan Cox
2018-08-08 20:36 ` Alan Cox
2018-08-08 22:42 ` Andreas Färber
2018-08-08 22:42 ` Andreas Färber
2018-08-08 22:42 ` Andreas Färber
2018-08-09 11:59 ` Alan Cox
2018-08-09 11:59 ` Alan Cox
2018-08-09 11:59 ` Alan Cox
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:02 ` Jian-Hong Pan
2018-08-09 15:21 ` Alexander Aring
2018-08-09 15:21 ` Alexander Aring
2018-08-09 15:21 ` Alexander Aring
2018-08-10 15:57 ` Alan Cox
2018-08-10 15:57 ` Alan Cox
2018-08-10 15:57 ` Alan Cox
2018-08-11 18:30 ` Stefan Schmidt
2018-08-11 18:30 ` Stefan Schmidt
2018-08-11 18:30 ` Stefan Schmidt
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:49 ` Andreas Färber
2018-08-12 16:37 ` Jian-Hong Pan
2018-08-12 16:37 ` Jian-Hong Pan
2018-08-12 16:37 ` Jian-Hong Pan
2018-08-12 17:59 ` Andreas Färber
2018-08-12 17:59 ` Andreas Färber
2018-08-12 17:59 ` Andreas Färber
2018-08-13 12:36 ` Alan Cox
2018-08-13 12:36 ` Alan Cox
2018-08-13 12:36 ` Alan Cox
2018-08-09 15:12 ` Alexander Aring
2018-08-09 15:12 ` Alexander Aring
2018-08-09 15:12 ` Alexander Aring
2018-08-09 15:12 ` Alexander Aring
2018-08-09 0:50 ` Andreas Färber
2018-08-09 0:50 ` Andreas Färber
2018-08-09 0:50 ` Andreas Färber
2018-07-04 18:26 ` Stefan Schmidt
2018-07-04 18:26 ` Stefan Schmidt
2018-07-04 18:26 ` Stefan Schmidt
2018-07-05 10:43 ` Helmut Tschemernjak
2018-07-05 10:43 ` Helmut Tschemernjak
2018-07-05 10:43 ` Helmut Tschemernjak
2018-07-11 2:07 ` Andreas Färber
2018-07-11 2:07 ` Andreas Färber
2018-07-11 2:07 ` Andreas Färber
2018-07-11 11:45 ` Helmut Tschemernjak
2018-07-11 11:45 ` Helmut Tschemernjak
2018-07-11 11:45 ` Helmut Tschemernjak
2018-07-11 15:21 ` Ben Whitten
2018-07-11 15:21 ` Ben Whitten
2018-07-11 15:21 ` Ben Whitten
2018-07-15 18:13 ` Andreas Färber
2018-07-15 18:13 ` Andreas Färber
2018-07-15 18:13 ` Andreas Färber
2018-07-18 11:28 ` Ben Whitten [this message]
2018-07-18 11:28 ` Ben Whitten
2018-07-18 11:28 ` Ben Whitten
2018-07-18 11:28 ` Ben Whitten
2018-08-02 7:52 ` Jian-Hong Pan
2018-08-02 7:52 ` Jian-Hong Pan
2018-08-02 7:52 ` Jian-Hong Pan
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-03 8:44 ` Andreas Färber
2018-08-05 12:49 ` Jian-Hong Pan
2018-08-05 12:49 ` Jian-Hong Pan
2018-08-05 12:49 ` Jian-Hong Pan
2018-08-05 12:49 ` Jian-Hong Pan
[not found] ` <20180803150258.791b9942@alans-desktop>
2018-08-05 14:08 ` Jian-Hong Pan
2018-08-05 14:08 ` Jian-Hong Pan
2018-08-05 13:49 ` [RFC net-next 00/15] net: A socket API for LoRa Andreas Färber
2018-08-05 13:49 ` Andreas Färber
2018-08-05 13:49 ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.