Hi, 2017-09-27 16:42 GMT+08:00 Stefan Schmidt <stefan@xxxxxxxxxxxxxxx>: > Hello. > > On 09/26/2017 02:34 PM, Alexander Aring wrote: >> Hi, >> >> On Tue, Sep 26, 2017 at 6:16 AM, Stefan Schmidt <stefan@xxxxxxxxxxxxxxx> wrote: >>> Hello. >>> >>> [I dropped the device tree list as this is really unrelated to them now] >>> >>> On 09/24/2017 04:53 PM, StarNight wrote: >>>> Hi, >>>> >>>> I have written a note which is reordered and extracted from LoRaWAN 1.0.2. >>>> https://hackmd.io/s/S1kg6Ymo-# >>>> Hope this wiil be easier for readers. >>>> >>>> LoRaWAN defiened by LoRa Alliance is the MAC layer over LoRa PHY. >>>> (The relation between LoRaWAN and LoRa PHY) >>> >>> Thanks a lot for putting thee notes together. >>> >>> Reading the MAC frame format I see not much in common with IEEE 802.15.4. >>> Maybe they really refer to the link layer security parts only. >>> >>> Given that your driver operates in LoRa and thus will not work with any >>> other 802.15.4 device I would not apply it to the ieee802154 subsystem. >>> >>> The driver is a good start for real LoRa support in the Linux kernel thought. >>> I would very much welcome such support and would also be happy to help. >>> (Not before November though as my next weeks will be to busy) >>> >>> Xue (in CC now) also has an interest in LoRa support in the Linux Kernel and >>> already started some work if I remember correctly. If you both are interested >>> to actively contribute to such a subsystem I would be happy to help getting >>> it into the mainline kernel. >>> >> >> For security stuff this should be shared between these subsystems >> then... Don't know how currently - we need to look. > > This will become clearer when being worked on. For now we only need to keep in mind that this needs to be shared. > >> The only possibility how to put lora in _softmac_ 802.15.4 is for me >> to introduce new "lora_register_hw" function who registered a special >> "lora" interface type (like node in 802.15.4) and use some of >> ieee802154 infrastructure and of course a lora.c which do some frame >> parsing on upper layer... > > I still do not see a good use case for this. LoRa is even more MTU constrained than 15.4 already is. Their own MAC frame format shows that > by being even more sparse. Why would one use the 15.4 MAC on LoRA? > > If there are some good arguments for this I would like to hear them. So far I am not convinced that this is a good idea. > > Putting the efforts into implementing a real LoRA MAC is imho way better. I think what Alexander concerns is no more duplex work for the same works. Like the API problem of SPI and I2C, then the regmap comes out. For the MAC of LoRaWAN or LoRa ... We need the functions for device like: (just for example) struct lrw_hw { ... }; struct lrw_ops { ... }; struct lrw_hw * lrw_alloc_hw(size_t priv_data_len, const struct lrw_ops *ops); void lrw_free_hw(struct lrw_hw *hw); int lrw_register_hw(struct lrw_hw *hw); void lrw_unregister_hw(struct lrw_hw *hw); void lrw_rx_irqsafe(struct lrw_hw *hw, struct sk_buff *skb, u8 lqi); void lrw_xmit_complete(struct lrw_hw *hw, struct sk_buff *skb, bool ifs_handling); ... some more functions We also could make it as a type of wpan_phy for upper layer. All of the mentioned are like the template which exists in IEEE 802.15.4 MAC. The difference will be how to parse the MAC frame format. If I misunderstand the words or have wrong idea, just point out. It is okay. Jian-Hong Pan -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
