Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Am 28.12.18 um 16:43 schrieb Alexander Aring: > On Fri, Dec 28, 2018 at 05:57:53AM +0100, Andreas Färber wrote: >> Am 24.12.18 um 16:32 schrieb Alexander Aring: >>> On Tue, Dec 18, 2018 at 02:50:58PM +0100, Xue Liu wrote: On Mon, 17 Dec 2018 at 15:19, Andreas Färber wrote: > Am 17.12.18 um 09:50 schrieb Xue Liu: >> I have a question about the architecture of your module. AFAIK LoRaWAN >> is already the MAC Layer above the LoRa technology. Why do you want to >> make a new layer called "maclorawan" ? > > I had asked Jian-Hong to separate between his soft-MAC implementation > and the common bits needed to drive hard-MAC implementations found on > several of the hardware modules made available to me. > As a reference Linux 802.11 uses cfg80211 to talk with hard-MAC devices. We may also use the name “cfglora” for hard-MAC implementation. >>> >>> There exists also a cfg802154. :-) >>> >>> Note that cfg80211 is also for providing a backwardscompatibility to the >>> wireless ioctl() interface. >>> >>> In theory it's simple: >>> >>> netlink API -> SoftMAC (macFOOBAR layer) -> cfgFOOBAR implementation -> >>> driver layer >>> \-> HardMAC (driver layer) -> cfgFOOBAR implementation >> >> So how does cfgFOOBAR relate to nlFOOBAR now? Given that we were told to >> use netlink and pointed to some nl802whatever, I am confused about two >> people now calling for cfg. We have an nllora stubbed in linux-lora.git, >> and I was expecting to see an nllorawan¹ either in this series or on > > Why there is a different between two lora technologies? This sounds you > driving into two lora subsystems without one userspace api to access them, > this getting worse. This had just been explained to Jiri: LoRa PHY vs. LoRaWAN MAC. Similar splits exist for other technologies; and how the LoRaWAN soft-MAC can reuse underlying LoRa facilities is the very subject of this sub-thread! It entirely depends on what the user wants to do - connect to a LoRaWAN network as client, forward LoRaWAN packets as a gateway, communicate peer-to-peer, implement alternative MACs in userspace, ... So if a user is working on LoRaWAN MAC layer I expect him to deal with PF_LORAWAN and nllorawan and not need direct access to nllora, as that would be an implementation detail specific to the soft-MAC; a hard-MAC should not need to implement nllora, as it may not have that control. >> top. If you're suggesting to rename them technology-neutral, then please > > I am sorry, I actually meant that... People tell me that I can't explain > things all the time. > >> say so clearly - otherwise it sounds to me like you didn't actually look >> at the staged code yet or didn't read our previous discussions and lead >> our contributors to reinvent things we already have... > > As example for 802.15.4: > > nl802154 (which is one netlink interface for doesn't matter what > kind 802.15.4 device is behind) -> callback structure of cfg802154 which > goes to a somehow 802.15.4 device as SoftMAC layer or HardMAC driver. Okay, I took a shortcut there for LoRa and assume we always have a LoRa netdev (i.e., no theoretical SDR netdev), so that I could postpone figuring out how to register extra per-netdev cfg structs for quicker PoC of the netlink interface. :) My get_freq callback will need to be moved out from struct lora_dev_priv (lora/netdev.h) into its own struct. >> We really need to complete the layers from the ground up before we get >> lost in more nice-to-have upper layers: For LoRaWAN that means we need >> to have TX and RX working for LoRa _and_ FSK. sx1276 still has lots of >> hardcoded stuff from my own testing that needs to hook into nllora, and >> FSK exists only as ETH_P_FSK constant so far, with no concept for >> switching modes yet (which as mentioned in my presentation¹ needs to go >> via sleep mode, losing most register settings) nor any netlink support. >> Not all drivers need to be at the same implementation level, of course, >> but we need at least one that's far enough to validate such patches. > > Your register behaviour sounds for me like a feature for regmap. Or > either a feature to handle in your subsystem. We don't have regmap caching enabled. sx1276 has no paging implemented, as it's slightly more complicated than sx1301 (and the "youngest" of 3). I assume instead of just writing from netlink/cfg callbacks to regmap we'll need to also save the values in the driver for writing them back after a mode switch or suspend. However it's also a question of who initiates the mode switch and how, presumably via netlink. >> And seeing that I just found a major bug in sx1276 driver's TX path, >> apparently no one apart from me is testing that driver - sx128x and >> sx1301 were not yet complete enough to transmit, and due to the open >> socket address/protocol discussions none can receive yet, so as Jiri >> hinted, this LoRaWAN soft-MAC patch series can't have been >> runtime-tested against a
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
On Fri, Dec 28, 2018 at 05:57:53AM +0100, Andreas Färber wrote: > Hi Alexander and Xue Liu, > > Am 24.12.18 um 16:32 schrieb Alexander Aring: > > On Tue, Dec 18, 2018 at 02:50:58PM +0100, Xue Liu wrote: > >> On Mon, 17 Dec 2018 at 15:19, Andreas Färber wrote: > >>> Am 17.12.18 um 09:50 schrieb Xue Liu: > I have a question about the architecture of your module. AFAIK LoRaWAN > is already the MAC Layer above the LoRa technology. Why do you want to > make a new layer called "maclorawan" ? > >>> > >>> I had asked Jian-Hong to separate between his soft-MAC implementation > >>> and the common bits needed to drive hard-MAC implementations found on > >>> several of the hardware modules made available to me. > >>> > >> As a reference Linux 802.11 uses cfg80211 to talk with hard-MAC devices. > >> We may also use the name “cfglora” for hard-MAC implementation. > > > > There exists also a cfg802154. :-) > > > > Note that cfg80211 is also for providing a backwardscompatibility to the > > wireless ioctl() interface. > > > > In theory it's simple: > > > > netlink API -> SoftMAC (macFOOBAR layer) -> cfgFOOBAR implementation -> > > driver layer > > \-> HardMAC (driver layer) -> cfgFOOBAR implementation > > So how does cfgFOOBAR relate to nlFOOBAR now? Given that we were told to > use netlink and pointed to some nl802whatever, I am confused about two > people now calling for cfg. We have an nllora stubbed in linux-lora.git, > and I was expecting to see an nllorawan¹ either in this series or on Why there is a different between two lora technologies? This sounds you driving into two lora subsystems without one userspace api to access them, this getting worse. > top. If you're suggesting to rename them technology-neutral, then please I am sorry, I actually meant that... People tell me that I can't explain things all the time. > say so clearly - otherwise it sounds to me like you didn't actually look > at the staged code yet or didn't read our previous discussions and lead > our contributors to reinvent things we already have... > As example for 802.15.4: nl802154 (which is one netlink interface for doesn't matter what kind 802.15.4 device is behind) -> callback structure of cfg802154 which goes to a somehow 802.15.4 device as SoftMAC layer or HardMAC driver. > We really need to complete the layers from the ground up before we get > lost in more nice-to-have upper layers: For LoRaWAN that means we need > to have TX and RX working for LoRa _and_ FSK. sx1276 still has lots of > hardcoded stuff from my own testing that needs to hook into nllora, and > FSK exists only as ETH_P_FSK constant so far, with no concept for > switching modes yet (which as mentioned in my presentation¹ needs to go > via sleep mode, losing most register settings) nor any netlink support. > Not all drivers need to be at the same implementation level, of course, > but we need at least one that's far enough to validate such patches. > Your register behaviour sounds for me like a feature for regmap. Or either a feature to handle in your subsystem. > And seeing that I just found a major bug in sx1276 driver's TX path, > apparently no one apart from me is testing that driver - sx128x and > sx1301 were not yet complete enough to transmit, and due to the open > socket address/protocol discussions none can receive yet, so as Jiri > hinted, this LoRaWAN soft-MAC patch series can't have been > runtime-tested against any staged driver at all! => [RFC lora-next v5 6/6] > aha. When I started working on ieee802154 many times I thought nobody had really tested it. That's somehow the process of upstream programming, it's growing over the time. The first implementation is always somehow crappy, but people working on it and get experience over the time, you cannot have perfect code. > Therefore I thought in our case some hard-MAC may be easier to validate > LoRaWAN sockets (patch 1/6), to avoid a dependency on completing the MAC > implementation first. For example, iM880, RF1276TS and 32001353 are pure > LoRaWAN modules without raw LoRa support. (Whereas many others support > both and I'm still looking for input on how to best deal with that - > currently exposing them as LoRa devices for maximal flexibility.) > So that means you ignore SoftMAC because HardMAC is easier? We actually go the opposite way to say SoftMAC introduce the most infrastructure and then say that we will bind HardMAC to it. Of course binding a socket interface to a datapath is easy. - Alex
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Hi Alexander and Xue Liu, Am 24.12.18 um 16:32 schrieb Alexander Aring: > On Tue, Dec 18, 2018 at 02:50:58PM +0100, Xue Liu wrote: >> On Mon, 17 Dec 2018 at 15:19, Andreas Färber wrote: >>> Am 17.12.18 um 09:50 schrieb Xue Liu: I have a question about the architecture of your module. AFAIK LoRaWAN is already the MAC Layer above the LoRa technology. Why do you want to make a new layer called "maclorawan" ? >>> >>> I had asked Jian-Hong to separate between his soft-MAC implementation >>> and the common bits needed to drive hard-MAC implementations found on >>> several of the hardware modules made available to me. >>> >> As a reference Linux 802.11 uses cfg80211 to talk with hard-MAC devices. >> We may also use the name “cfglora” for hard-MAC implementation. > > There exists also a cfg802154. :-) > > Note that cfg80211 is also for providing a backwardscompatibility to the > wireless ioctl() interface. > > In theory it's simple: > > netlink API -> SoftMAC (macFOOBAR layer) -> cfgFOOBAR implementation -> > driver layer > \-> HardMAC (driver layer) -> cfgFOOBAR implementation So how does cfgFOOBAR relate to nlFOOBAR now? Given that we were told to use netlink and pointed to some nl802whatever, I am confused about two people now calling for cfg. We have an nllora stubbed in linux-lora.git, and I was expecting to see an nllorawan¹ either in this series or on top. If you're suggesting to rename them technology-neutral, then please say so clearly - otherwise it sounds to me like you didn't actually look at the staged code yet or didn't read our previous discussions and lead our contributors to reinvent things we already have... We really need to complete the layers from the ground up before we get lost in more nice-to-have upper layers: For LoRaWAN that means we need to have TX and RX working for LoRa _and_ FSK. sx1276 still has lots of hardcoded stuff from my own testing that needs to hook into nllora, and FSK exists only as ETH_P_FSK constant so far, with no concept for switching modes yet (which as mentioned in my presentation¹ needs to go via sleep mode, losing most register settings) nor any netlink support. Not all drivers need to be at the same implementation level, of course, but we need at least one that's far enough to validate such patches. And seeing that I just found a major bug in sx1276 driver's TX path, apparently no one apart from me is testing that driver - sx128x and sx1301 were not yet complete enough to transmit, and due to the open socket address/protocol discussions none can receive yet, so as Jiri hinted, this LoRaWAN soft-MAC patch series can't have been runtime-tested against any staged driver at all! => [RFC lora-next v5 6/6] Therefore I thought in our case some hard-MAC may be easier to validate LoRaWAN sockets (patch 1/6), to avoid a dependency on completing the MAC implementation first. For example, iM880, RF1276TS and 32001353 are pure LoRaWAN modules without raw LoRa support. (Whereas many others support both and I'm still looking for input on how to best deal with that - currently exposing them as LoRa devices for maximal flexibility.) Regards, Andreas ¹ https://events.linuxfoundation.org/wp-content/uploads/2017/12/ELCE2018_LoRa_final_Andreas-Farber.pdf https://www.youtube.com/watch?v=Jjel65sZO9M -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Hi, On Tue, Dec 18, 2018 at 02:50:58PM +0100, Xue Liu wrote: > Hello Andreas, > > On Mon, 17 Dec 2018 at 15:19, Andreas Färber wrote: > > > > Hello Xue Liu, > > > > Am 17.12.18 um 09:50 schrieb Xue Liu: > > > I have a question about the architecture of your module. AFAIK LoRaWAN > > > is already the MAC Layer above the LoRa technology. Why do you want to > > > make a new layer called "maclorawan" ? > > > > I had asked Jian-Hong to separate between his soft-MAC implementation > > and the common bits needed to drive hard-MAC implementations found on > > several of the hardware modules made available to me. > > > As a reference Linux 802.11 uses cfg80211 to talk with hard-MAC devices. > We may also use the name “cfglora” for hard-MAC implementation. > There exists also a cfg802154. :-) Note that cfg80211 is also for providing a backwardscompatibility to the wireless ioctl() interface. In theory it's simple: netlink API -> SoftMAC (macFOOBAR layer) -> cfgFOOBAR implementation -> driver layer \-> HardMAC (driver layer) -> cfgFOOBAR implementation The "difficult" part is providing one userspace interface for both either SoftMAC layer and all HardMAC drivers. There both maintainers need to be synchronized. As a side note I want to mention that the 802.15.4 subsystem supports currently a HardMAC transceiver in the SoftMAC layer. We don't have quite HardMAC support yet but are somehow prepared according the wireless architecture above. The people who did that didn't wanted to investigate time to implement a whole HardMAC layer, as I told them when we support more in the SoftMAC layer it will break their transceiver... so they was fine with that as warning it seems. :-) - Alex
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Hello Andreas, On Mon, 17 Dec 2018 at 15:19, Andreas Färber wrote: > > Hello Xue Liu, > > Am 17.12.18 um 09:50 schrieb Xue Liu: > > I have a question about the architecture of your module. AFAIK LoRaWAN > > is already the MAC Layer above the LoRa technology. Why do you want to > > make a new layer called "maclorawan" ? > > I had asked Jian-Hong to separate between his soft-MAC implementation > and the common bits needed to drive hard-MAC implementations found on > several of the hardware modules made available to me. > As a reference Linux 802.11 uses cfg80211 to talk with hard-MAC devices. We may also use the name “cfglora” for hard-MAC implementation. > The prefix "mac" was copied from mac80211 and mac802154: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net > OK. Understood. I guess they use mac80211 and mac802154 to distinguish physical layer and MAC layer. Since LoRa and LoRaWAN are already separate I think "maclorawan" is not necessary. > If you have better ideas for how to structure this, just let us know, > ideally as inline comment where you see it (or on the cover letter). > > Only comment I have for this patch at the moment is that I would prefer > to have the Kconfig bits be in the patches adding the code, so that we > can actually build-test them before 6/6. > > Been updating my lab to 4.20-rcX with some hiccups. Ben's > regmap_noinc_write support made it into 4.20, so I expect to have Ben's > pending branch for sx1301 merged into rebased lora-next before Christmas > and my sx1276 conversion to follow, leaving the PF_PACKET vs. PF_LORA > discussion from ELCE - haven't assessed yet how much this series would > be affected by the underlying changes, but if the abstraction was done > right then only maclorawan implementation should be affected. > > Regards, > Andreas > > -- > SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Felix Imendörffer, Jane Smithard, Graham Norton > HRB 21284 (AG Nürnberg) Regards, Xue Liu --
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Hello Xue Liu, Am 17.12.18 um 09:50 schrieb Xue Liu: > I have a question about the architecture of your module. AFAIK LoRaWAN > is already the MAC Layer above the LoRa technology. Why do you want to > make a new layer called "maclorawan" ? I had asked Jian-Hong to separate between his soft-MAC implementation and the common bits needed to drive hard-MAC implementations found on several of the hardware modules made available to me. The prefix "mac" was copied from mac80211 and mac802154: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/net If you have better ideas for how to structure this, just let us know, ideally as inline comment where you see it (or on the cover letter). Only comment I have for this patch at the moment is that I would prefer to have the Kconfig bits be in the patches adding the code, so that we can actually build-test them before 6/6. Been updating my lab to 4.20-rcX with some hiccups. Ben's regmap_noinc_write support made it into 4.20, so I expect to have Ben's pending branch for sx1301 merged into rebased lora-next before Christmas and my sx1276 conversion to follow, leaving the PF_PACKET vs. PF_LORA discussion from ELCE - haven't assessed yet how much this series would be affected by the underlying changes, but if the abstraction was done right then only maclorawan implementation should be affected. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg)
Re: [PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
Hello Jian-Hong, Thanks for your work in LoRaWAN. I have a question about the architecture of your module. AFAIK LoRaWAN is already the MAC Layer above the LoRa technology. Why do you want to make a new layer called "maclorawan" ? Regards, Xue Liu On Sun, 16 Dec 2018 at 11:20, Jian-Hong Pan wrote: > > List LORAWAN and MACLORAWAN in menuconfig and make they can be built. > > Signed-off-by: Jian-Hong Pan > --- > V2: > - Split the LoRaWAN class module patch in V1 into LoRaWAN socket and > LoRaWAN Soft MAC modules > > net/Kconfig | 2 ++ > net/Makefile | 2 ++ > 2 files changed, 4 insertions(+) > > diff --git a/net/Kconfig b/net/Kconfig > index cf2e651ee31d..03b3ff306778 100644 > --- a/net/Kconfig > +++ b/net/Kconfig > @@ -224,6 +224,8 @@ source "net/6lowpan/Kconfig" > source "net/ieee802154/Kconfig" > source "net/mac802154/Kconfig" > source "net/lora/Kconfig" > +source "net/lorawan/Kconfig" > +source "net/maclorawan/Kconfig" > source "net/sched/Kconfig" > source "net/dcb/Kconfig" > source "net/dns_resolver/Kconfig" > diff --git a/net/Makefile b/net/Makefile > index e80b84313851..9d5515965a8f 100644 > --- a/net/Makefile > +++ b/net/Makefile > @@ -63,6 +63,8 @@ obj-$(CONFIG_6LOWPAN) += 6lowpan/ > obj-$(CONFIG_IEEE802154) += ieee802154/ > obj-$(CONFIG_MAC802154)+= mac802154/ > obj-$(CONFIG_LORA) += lora/ > +obj-$(CONFIG_LORAWAN) += lorawan/ > +obj-$(CONFIG_MACLORAWAN) += maclorawan/ > > ifeq ($(CONFIG_NET),y) > obj-$(CONFIG_SYSCTL) += sysctl_net.o > -- > 2.20.0 > --
[PATCH v5 6/6] net: lorawan: List LORAWAN in menuconfig
List LORAWAN and MACLORAWAN in menuconfig and make they can be built. Signed-off-by: Jian-Hong Pan --- V2: - Split the LoRaWAN class module patch in V1 into LoRaWAN socket and LoRaWAN Soft MAC modules net/Kconfig | 2 ++ net/Makefile | 2 ++ 2 files changed, 4 insertions(+) diff --git a/net/Kconfig b/net/Kconfig index cf2e651ee31d..03b3ff306778 100644 --- a/net/Kconfig +++ b/net/Kconfig @@ -224,6 +224,8 @@ source "net/6lowpan/Kconfig" source "net/ieee802154/Kconfig" source "net/mac802154/Kconfig" source "net/lora/Kconfig" +source "net/lorawan/Kconfig" +source "net/maclorawan/Kconfig" source "net/sched/Kconfig" source "net/dcb/Kconfig" source "net/dns_resolver/Kconfig" diff --git a/net/Makefile b/net/Makefile index e80b84313851..9d5515965a8f 100644 --- a/net/Makefile +++ b/net/Makefile @@ -63,6 +63,8 @@ obj-$(CONFIG_6LOWPAN) += 6lowpan/ obj-$(CONFIG_IEEE802154) += ieee802154/ obj-$(CONFIG_MAC802154)+= mac802154/ obj-$(CONFIG_LORA) += lora/ +obj-$(CONFIG_LORAWAN) += lorawan/ +obj-$(CONFIG_MACLORAWAN) += maclorawan/ ifeq ($(CONFIG_NET),y) obj-$(CONFIG_SYSCTL) += sysctl_net.o -- 2.20.0
