Message ID | 20190129050130.10932-2-afaerber@suse.de |
---|---|
State | New |
Headers | show |
Series | net: EnOcean prototype driver | expand |
Hi Alex, Am 29.01.19 um 13:57 schrieb Alexander Aring: > On Tue, Jan 29, 2019 at 06:01:27AM +0100, Andreas Färber wrote: >> EnOcean wireless technology is based on ASK (ERP1) and FSK (ERP2) modulations >> for sub-GHz and on IEEE 802.15.4 for 2.4 GHz. >> > > I am not sure what you try to do here. If I see that correctly you > want to add for some special protocol vendor specific transceiver which > is underneath an 802.15.4 transceiver a new ARPHRD type and even more > for each modulation what it supports? No. EnOcean uses a 4-byte node ID across PHY layers, which I am using a single ARPHRD_ENOCEAN for (which you conveniently cut off above). As indicated above, the 868 MHz transceiver is _not_ using 802.15.4 PHY or MAC to my knowledge. It does sound like you spotted "IEEE 802.15.4" and literally blended out all the rest... > > If it's a 802.15.4 transceiver why not using the 802.15.4 subsystem? > > For me it sounds more like a HardMAC transceiver driver for doing the > vendor protocol. The different modulations is part of a 802.15.4 phy > device class. Similar like in wireless. I've tried to design this exactly so that one _could_ implement it based on 802.15.4 PHY framework for 2.4 GHz or based on an FSK PHY for sub-GHz as a soft-MAC, layered similarly to LoRaWAN vs. LoRa, alongside the ESP serdev driver in this series. In ESP3 the only 802.15.4 specific operations are getting/setting the channel (COMMAND_2_4 packet type), and there's a CO_GET_FREQUENCY_INFO command to discover frequency and protocol, with 802.15.4 having a different ID than ERP2 (and I spot a value 0x30 for "Long Range" :-)). So in theory it might be possible to instantiate an 802.15.4 PHY after discovering that ESP3 value, but neither is this a generic 802.15.4 PHY nor a generic FSK PHY, and none of that relates to above ARPHRD really. PF_PACKET with SOCK_DGRAM for ETH_P_ERP2 gives me the subtelegram contents to transmit via ESP, whereas SOCK_RAW would give the full frame to transmit via FSK PHY. By avoiding a custom PF_ENOCEAN we seem to lose the ability to prepend any protocol headers on the skb for SOCK_DGRAM. Did you actually read my P.S. in the cover letter? I was glad to avoid much PF_ socket boilerplate code here (as a playground for LoRa), and now you're complaining about a single ARPHRD constant! :-/ By that standard we could stop implementing anything new... If you're worried about number space, why has no one commented on the values added for LoRa and other previous wireless technologies? No one had any such comments on my LoRa RFC, nor on Jian-Hong's LoRaWAN patches, so I've been reserving new ARPHRD_ constants for each technology I work on. If ARPHRD_NONE would be a better value to use for PHY layers, no one bothered to point it out so far! Nor did anyone suggest to Jian-Hong to reuse ARPHRD_EUI64! And yet I spot nothing more suitable for EnOcean addresses than a custom value. Fact is, the net_device wants some value. Note that you have two ARPHRD constants assigned for 802.15.4 alone, so please be fair to others. An 802.15.4 PHY won't help me for 868 MHz FSK - by my reading 802.15.4 is PSK (BPSK/OQPSK), thus incompatible with ASK/OOK and FSK/MSK. As noted in the cover letter, Semtech chips have FSK and OOK support alongside LoRa modulation; so I am looking into FSK PHY support, both for those chips as well as for some pure FSK/OOK transceivers posted to linux-lpwan list (and potentially more, given time): https://lists.infradead.org/pipermail/linux-lpwan/2019-January/000116.html https://lists.infradead.org/pipermail/linux-lpwan/2019-January/000117.html https://en.opensuse.org/User:A_faerber/LoRa_interop Therefore an FSK PHY's netlink interface will need to be able to handle the requirements of upper-layer protocols, such as: * Wireless M-Bus (which I could not yet find a suitable 868MHz hard-MAC for to test against, only 169MHz; Si4432 has an Application Note AN451), * KNX RF (which I have not come across a hard-MAC for either), * Sigfox downstream (cf. mm002 LoRa driver as hard-MAC; no public docs), * Z-Wave (not enough docs to implement much more for now), and here * EnOcean Radio Protocol 2. In general I want to make sure my implementations can work with both soft- and hard-MAC hardware out there, as demonstrated for LoRaWAN. Pointing a user with hard-MAC device to a theoretical generic subsystem of your preference doesn't help them, nor does it help to split the community into separate hard-MAC vs. soft-MAC implementation camps that make it hard for users to switch. * For example, when looking for how to actually use the Pine64 Z-Wave adapter, back in the day I merely found an OpenHAB Raspbian(?) image that as an openSUSE contributor I would surely not block my board with; no explanations, no instructions, nothing. And when you have a pure Java application on the one hand and a C/Python/whatever application on the other, chances are that the kernel is the only common point of reuse. I surely mentioned that I hate any userspace applications that attempt to detect hardware on spidev/i2c-dev/tty without using the kernel-provided facilities such as DT; finally, serdev allows to move any such hardware-dependent tty code into the kernel - we just need to figure out how to best expose functionality there (and ideally grow some more helpers). Just note how patch 3/4 reuses the kernel's crc8 implementation instead of re-implementing it from scratch. Similarly I'd love for my AT based LoRa drivers to share more serdev code, despite line ending and response styles differing greatly (think serdev_device_readline w/args?); binary protocols like ESP here are luckily not affected as much. It could also use some more/better documentation, some of the return values are wrong. * As another example, we seem to be lacking a generic SDR subsystem: People with SDR hardware seem to use either downstream kernel modules, possibly application-generated, or closed-source userspace libraries? Neither seems able to currently reuse the net subsystem for protocols. And yet I've been asked repeatedly to design drivers in a way they could be used with SDR, too, but without any way to actually test that today. Has anyone talked to the SDR chipset/equipment vendors to remedy that? The one I was in contact with simply chose not to reply again to date... For ETH_P_ we seem to be far away from 0xffff, so I don't see a problem there? Not just was it the easiest thing to implement & test short-term, but as outlined in the cover letter I saw no way here to turn that into a non-net-subsystem because the data transmitted is not self-describing (mostly battery-less sensors/actuators with ca. 4 byte data payload). You must know that your device with id 0x12345678 conforms to profile X. Is describing remote devices in DT an option? (CC'ing Rob and Jonathan) /.../uart@foo { enocean { compatible = "enocean,esp3"; #address-cells = <1>; #size-cells = <0>; window-handle@41424344 { compatible = "manufacturer1,handle"; reg = <0x41424344>; enocean,equipment-profile = <1 2 3>; #io-channel-cells = <1>; }; light-switch@41424348 { compatible = "manufacturer2,rocker"; reg = <0x41424348>; enocean,equipment-profile = <4 5 6>; #io-channel-cells = <2>; }; }; }; Pro: This would allow to abstract sensors (iio?) and actuators (gpio?). Cf. https://patchwork.ozlabs.org/patch/1028209/ for comparison. Con: How to deal with it on ACPI or on DT platforms without Overlays? How would the kernel preserve remote device state across reboots? So no, I don't think we can or should shoehorn non-802.15.4 PHYs into your ieee802154 PHY layer. If you see ways to share code between the various wireless PHYs, that would be great, but at present it seems like mostly boilerplate code with nothing in your phy struct applying to FSK or LoRa. Compare my cfglora series pointed to and Xue Liu's recent sysfs patch under discussion. If no more comments turn up on my cfglora series I'll copy it into a cfgfsk, so that I can integrate both into sx127x as a base for further discussions at Netdevconf. Thanks. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Hi, On Wed, Jan 30, 2019 at 02:42:29AM +0100, Andreas Färber wrote: > Hi Alex, > > Am 29.01.19 um 13:57 schrieb Alexander Aring: > > On Tue, Jan 29, 2019 at 06:01:27AM +0100, Andreas Färber wrote: > >> EnOcean wireless technology is based on ASK (ERP1) and FSK (ERP2) modulations > >> for sub-GHz and on IEEE 802.15.4 for 2.4 GHz. > >> > > > > I am not sure what you try to do here. If I see that correctly you > > want to add for some special protocol vendor specific transceiver which > > is underneath an 802.15.4 transceiver a new ARPHRD type and even more > > for each modulation what it supports? > > No. EnOcean uses a 4-byte node ID across PHY layers, which I am using a > single ARPHRD_ENOCEAN for (which you conveniently cut off above). > > As indicated above, the 868 MHz transceiver is _not_ using 802.15.4 PHY > or MAC to my knowledge. It does sound like you spotted "IEEE 802.15.4" > and literally blended out all the rest... > Ah okay, I am curious about that. As far I undetstood now this has nothing to do with LoRa? I was not getting that point. Is the PHY layer open? Do they actually refer to 802.15.4 in their specs, but the PHY layer is changed by... preamble, phy header, MTU? > > > > If it's a 802.15.4 transceiver why not using the 802.15.4 subsystem? > > > > For me it sounds more like a HardMAC transceiver driver for doing the > > vendor protocol. The different modulations is part of a 802.15.4 phy > > device class. Similar like in wireless. > > I've tried to design this exactly so that one _could_ implement it based > on 802.15.4 PHY framework for 2.4 GHz or based on an FSK PHY for sub-GHz > as a soft-MAC, layered similarly to LoRaWAN vs. LoRa, alongside the ESP > serdev driver in this series. > > In ESP3 the only 802.15.4 specific operations are getting/setting the > channel (COMMAND_2_4 packet type), and there's a CO_GET_FREQUENCY_INFO > command to discover frequency and protocol, with 802.15.4 having a > different ID than ERP2 (and I spot a value 0x30 for "Long Range" :-)). > So in theory it might be possible to instantiate an 802.15.4 PHY after > discovering that ESP3 value, but neither is this a generic 802.15.4 PHY > nor a generic FSK PHY, and none of that relates to above ARPHRD really. > I keep it in mind, thanks. > PF_PACKET with SOCK_DGRAM for ETH_P_ERP2 gives me the subtelegram > contents to transmit via ESP, whereas SOCK_RAW would give the full frame > to transmit via FSK PHY. By avoiding a custom PF_ENOCEAN we seem to lose > the ability to prepend any protocol headers on the skb for SOCK_DGRAM. > I am not quite following here. SOCK_RAW full frame and SOCK_DGRAM payload sounds like what I suppose it should work. A switch of protocol will do a switch from ESP to FSK which is a phy layer behaviour? > Did you actually read my P.S. in the cover letter? I was glad to avoid > much PF_ socket boilerplate code here (as a playground for LoRa), and > now you're complaining about a single ARPHRD constant! :-/ > By that standard we could stop implementing anything new... If you're > worried about number space, why has no one commented on the values added > for LoRa and other previous wireless technologies? No one had any such > comments on my LoRa RFC, nor on Jian-Hong's LoRaWAN patches, so I've > been reserving new ARPHRD_ constants for each technology I work on. If > ARPHRD_NONE would be a better value to use for PHY layers, no one > bothered to point it out so far! Nor did anyone suggest to Jian-Hong to > reuse ARPHRD_EUI64! And yet I spot nothing more suitable for EnOcean > addresses than a custom value. Fact is, the net_device wants some value. > Note that you have two ARPHRD constants assigned for 802.15.4 alone, so > please be fair to others. > Indeed we only need one. :-) > An 802.15.4 PHY won't help me for 868 MHz FSK - by my reading 802.15.4 > is PSK (BPSK/OQPSK), thus incompatible with ASK/OOK and FSK/MSK. > > As noted in the cover letter, Semtech chips have FSK and OOK support > alongside LoRa modulation; so I am looking into FSK PHY support, both > for those chips as well as for some pure FSK/OOK transceivers posted to > linux-lpwan list (and potentially more, given time): > https://lists.infradead.org/pipermail/linux-lpwan/2019-January/000116.html > https://lists.infradead.org/pipermail/linux-lpwan/2019-January/000117.html > https://en.opensuse.org/User:A_faerber/LoRa_interop > > Therefore an FSK PHY's netlink interface will need to be able to handle > the requirements of upper-layer protocols, such as: > * Wireless M-Bus (which I could not yet find a suitable 868MHz hard-MAC > for to test against, only 169MHz; Si4432 has an Application Note AN451), > * KNX RF (which I have not come across a hard-MAC for either), > * Sigfox downstream (cf. mm002 LoRa driver as hard-MAC; no public docs), > * Z-Wave (not enough docs to implement much more for now), and here > * EnOcean Radio Protocol 2. > > In general I want to make sure my implementations can work with both > soft- and hard-MAC hardware out there, as demonstrated for LoRaWAN. > Pointing a user with hard-MAC device to a theoretical generic subsystem > of your preference doesn't help them, nor does it help to split the > community into separate hard-MAC vs. soft-MAC implementation camps that > make it hard for users to switch. agree. > * For example, when looking for how to actually use the Pine64 Z-Wave > adapter, back in the day I merely found an OpenHAB Raspbian(?) image > that as an openSUSE contributor I would surely not block my board with; > no explanations, no instructions, nothing. And when you have a pure Java > application on the one hand and a C/Python/whatever application on the > other, chances are that the kernel is the only common point of reuse. I > surely mentioned that I hate any userspace applications that attempt to > detect hardware on spidev/i2c-dev/tty without using the kernel-provided > facilities such as DT; finally, serdev allows to move any such > hardware-dependent tty code into the kernel - we just need to figure out > how to best expose functionality there (and ideally grow some more > helpers). Just note how patch 3/4 reuses the kernel's crc8 > implementation instead of re-implementing it from scratch. Similarly I'd > love for my AT based LoRa drivers to share more serdev code, despite > line ending and response styles differing greatly (think > serdev_device_readline w/args?); binary protocols like ESP here are > luckily not affected as much. It could also use some more/better > documentation, some of the return values are wrong. > * As another example, we seem to be lacking a generic SDR subsystem: > People with SDR hardware seem to use either downstream kernel modules, > possibly application-generated, or closed-source userspace libraries? > Neither seems able to currently reuse the net subsystem for protocols. > And yet I've been asked repeatedly to design drivers in a way they could > be used with SDR, too, but without any way to actually test that today. > Has anyone talked to the SDR chipset/equipment vendors to remedy that? > The one I was in contact with simply chose not to reply again to date... > > For ETH_P_ we seem to be far away from 0xffff, so I don't see a problem > there? Not just was it the easiest thing to implement & test short-term, > but as outlined in the cover letter I saw no way here to turn that into > a non-net-subsystem because the data transmitted is not self-describing > (mostly battery-less sensors/actuators with ca. 4 byte data payload). > You must know that your device with id 0x12345678 conforms to profile X. > > Is describing remote devices in DT an option? (CC'ing Rob and Jonathan) > > /.../uart@foo { > enocean { > compatible = "enocean,esp3"; > #address-cells = <1>; > #size-cells = <0>; > > window-handle@41424344 { > compatible = "manufacturer1,handle"; > reg = <0x41424344>; > enocean,equipment-profile = <1 2 3>; What are these profiles? For declaring you actually can support some "window-handle"? Can this be changed during runtime? Is this some kind of device class specification by EnOcean which need to be set into their transceiver that a management layer handle it which is running by firmware? > #io-channel-cells = <1>; > }; > > light-switch@41424348 { > compatible = "manufacturer2,rocker"; > reg = <0x41424348>; > enocean,equipment-profile = <4 5 6>; > #io-channel-cells = <2>; > }; > }; > }; > > Pro: This would allow to abstract sensors (iio?) and actuators (gpio?). > Cf. https://patchwork.ozlabs.org/patch/1028209/ for comparison. > Con: How to deal with it on ACPI or on DT platforms without Overlays? > How would the kernel preserve remote device state across reboots? > > So no, I don't think we can or should shoehorn non-802.15.4 PHYs into > your ieee802154 PHY layer. If you see ways to share code between the > various wireless PHYs, that would be great, but at present it seems like > mostly boilerplate code with nothing in your phy struct applying to FSK > or LoRa. Compare my cfglora series pointed to and Xue Liu's recent sysfs > patch under discussion. If no more comments turn up on my cfglora series > I'll copy it into a cfgfsk, so that I can integrate both into sx127x as > a base for further discussions at Netdevconf. Thanks. > Share code always sounds like a good idea. Thanks. - Alex
diff --git a/include/uapi/linux/if_arp.h b/include/uapi/linux/if_arp.h index dd7992a441c9..327ef052329f 100644 --- a/include/uapi/linux/if_arp.h +++ b/include/uapi/linux/if_arp.h @@ -102,6 +102,7 @@ #define ARPHRD_LORAWAN 828 /* LoRaWAN */ #define ARPHRD_OOK 829 /* On/Off Keying modulation */ #define ARPHRD_FSK 830 /* Frequency Shift Keying modulation */ +#define ARPHRD_ENOCEAN 832 /* EnOcean */ #define ARPHRD_VOID 0xFFFF /* Void type, nothing is known */ #define ARPHRD_NONE 0xFFFE /* zero header length */ diff --git a/include/uapi/linux/if_ether.h b/include/uapi/linux/if_ether.h index 0b5c30f78261..3e22948cc329 100644 --- a/include/uapi/linux/if_ether.h +++ b/include/uapi/linux/if_ether.h @@ -152,6 +152,8 @@ #define ETH_P_OOK 0x00FC /* On/Off Keying modulation */ #define ETH_P_FSK 0x00FD /* Frequency Shift Keying mod. */ #define ETH_P_FLRC 0x00FE /* Fast Long Range Communication */ +#define ETH_P_ERP1 0x00FF /* EnOcean Radio Protocol 1 */ +#define ETH_P_ERP2 0x0100 /* EnOcean Radio Protocol 2 */ /* * This is an Ethernet frame header.
EnOcean wireless technology is based on ASK (ERP1) and FSK (ERP2) modulations for sub-GHz and on IEEE 802.15.4 for 2.4 GHz. ARPHRD_ENOCEAN ETH_P_ERP{1,2} Signed-off-by: Andreas Färber <afaerber@suse.de> --- include/uapi/linux/if_arp.h | 1 + include/uapi/linux/if_ether.h | 2 ++ 2 files changed, 3 insertions(+) -- 2.16.4