Hello Andreas, On Mon, 17 Dec 2018 at 15:19, Andreas Färber <afaerber@xxxxxxx> 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 --
