Hi Thomas, On Mon, Sep 08, 2014 at 11:07:27AM +0200, Thomas Kühnel wrote: > Hi, > > I own a RaspBee[1] Transceiver, that I wanted to use on the Raspberry > Pi. On the wiki I noticed the page about the serial driver[2] which > sounded promising. So I used the patch[3] with some small changes to > make it work with the current net-next kernel and wrote my own > firmware for the RaspBee[4]. The firmware uses the µRacoli library for > I/O and network communication, so it should also work on other devices > supported by the library. nice. > So my actual question is, why is the serial driver not part of > net-next? Was it just never sent to the mailing list for review or are > there any problems that need to be fixed first? > > First I need to say that I am current working on a complete rework of 802.15.4 and mac handling. Adding new drivers makes more work for me to rebase this stuff according the new changes (I don't touched the driver layer too hard so this should be okay). Repository for the rework is [1]. I drifted too much in my git history and need to clean it up at the end. It's just a local working branch for me. You need new userspace software for it which is located at [2]. Both branches are currently under heavy programming by me. I know the serial driver, there exists also a open firmware for the econotag to support this serial protocol. I already thought also about a contiki app which offer this serial interface, then contiki would run as firmware. Then you could use any contiki sensornode with linux stack. But nevertheless, just an idea which pending around. The serial driver specification supports only basic functionality about 802.15.4. There was also a idea for a serialv2 interface by tony cheneau, see [0]. I need to admit, I never worked with the serial driver/interface. But what I can see at the current driver is that there much places which need to rework because it's not in a mainline able state. For example some easy issues like dev_foo instead printk. I don't take a closer look now, but I would review it. I currently think that's it's not a good idea to add new drivers before the rework is finished (If the rework ever comes mainline, but it should). The mac layer have at the moment too many issue, I mean the basic stuff works but then nothing more and it's hard to make a more correct handling of this at the current situation. I would give you the advice that you base the new implementation on the new rework from branch [1]. I will help you there, then we review the code and the new serial driver (what v1 specification says will be added to the rework). When the rework becomes mainline, the serial driver becomes, too. Please let me know if you like to do this, otherwise... maybe I will do it when I have time for this. For the general specification. Maybe you want to add more functionality, like setting of ARET or promiscous mode. We should add some spec documentation in wpan-misc repository [3]. There we should add something like that. We should clear the master branch and add the serialv1 spec. I would not adding the serial driver before that. Just send patches for this with tag "wpan-misc" for some documentation about the current v1 spec. I will add this then. Sorry, but I don't want to add new drivers since we don't have the rework mainline. I hope you understand that. - Alex [0] https://github.com/linux-wpan/ieee802154-serial-protocol-version2 [1] https://github.com/linux-wpan/linux-wpan-next/tree/wpan_rework_rfc [2] https://github.com/linux-wpan/wpan-tools [3] https://github.com/linux-wpan/wpan-misc -- 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
