> And to answer this question, no, it probably shouldn't be here in > drivers/staging/ it should be in the "real" part of the kernel as it is > a real driver. drivers/staging/ is for stuff that still needs work to > do to get it out of that part of the kernel, do the work ahead of time > and then you don't have to mess with that at all. What do you mean by "real" part of kernel? You mean non-staging? The HDLC module/code initially started out as a part of beagleplay greybus driver (which started from wpanusb [1]). I separated it out since it should be possible to use it from other drivers which need async HDLC framing, but I am not sure how suitable it is to be used outside of UART. Thus, I do not feel it should be outside staging for now. > No need for a .h file for a simple .c file, just put it all together > into one file please. Well, it is not really a standalone driver. It is supposed to be used by some other driver (like serdev) to stack HDLC on top of that. So I think it needs .h file? > > +int hdlc_rx(struct hdlc_driver *drv, const unsigned char *data, size_t count) > Why is this a global function? These functions are called by any driver that wants to stack HDLC on top of the underlying transport. The HDLC files themselves can only read an HDLC frame or create an HDLC frame. It does not really care much about the underlying transport I absolutely wish to make it clear that all the HDLC code can be put in beagleplay greybus driver (that's how it began). I just thought it might be better to separate it out for clarity and possibly allowing future drivers to use it for async HDLC framing. Ayush Singh [1]: https://git.beagleboard.org/beagleconnect/zephyr/wpanusb_bc |
_______________________________________________ greybus-dev mailing list -- greybus-dev@xxxxxxxxxxxxxxxx To unsubscribe send an email to greybus-dev-leave@xxxxxxxxxxxxxxxx
|