A couple of items about how Motorola used Greybus: We were rebasing on the upstream code, with hopes of maintaining compatibility, but had to freeze before some significant changes upstream. We added support to make greybus less dependent on unipro by adding a switching layer and SPI and I2C as transports. We also support unipro but ended up not using greybus over unipro because the idle current on the TSB was too high to leave up when not actively transmitting high speed data. So we don't use unipro for greybus. We ended up using greybus primarily as a control channel for other speed buses (mydp, csi and dsi over unipro, usb), but also for a few low speed protocols like battery and lights. We faked out the SVC to maintain compatibility and support multiple module support. May not be how you would want approach the problem. The only portion of SVC we really utilized was the CREATE/DESTROY messages in order to route traffic between the interface:cport pairs. Everything else is either stubbed out or faked/hard-coded (i.e. DME Attributes) to keep the core greybus initialization happy. Protocol versioning required some changes to get to work as the greybus implementation at the time of our fork was hard-coding everything to 0.1. We had to add additional logic to support multiple major versions and implement a 'best match' algorithm. This can probably be done better as well as we were trying to minimize changes to core greybus at the time. Before extending the supported devices, it might be wise to give security some thought. If the host is just sending generally available information like battery levels then it might not be big concern, but it would be easy to write something that hands over kernel access to an external chip. Jim On Thu, Dec 1, 2016 at 4:35 AM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > On Wednesday 30 Nov 2016 17:29:32 Bryan O'Donoghue wrote: >> On 30/11/16 16:52, Laurent Pinchart wrote: >> > I first want to define what we mean by IoT >> >> Heh. >> >> IoT technically means (my understanding) a way of accessing edge devices >> over the internet or allowing edge devices access to the Internet. > > Greybus seems of little value in that context, given that it can't be > transported over the internet (now if we want to change that I'm open for > discussions, but it will be a very different concept). > > Greybus can be useful to access sensors and other similar embedded devices > (most of them being too tiny to run Linux, but that's not a requirement). > While this can be used for "IoT", it's in no way limited to that, or even > dependent on it. > > I still don't know how we should position ourselves when compared to field > buses for instance. > >> The self-describing bits of greybus and the ability to create standard >> Linux devices without caring about the actual hardware bus is the >> interesting part. Unlike say USB - which is a self-describing network >> but, is tightly coupled to a wire-level bus, greybus (can be made to be) >> hardware agnostic. >> >> I think self-describing, pluggable network is what makes it a candidate >> for people to rehash the abused and unloved IoT term. >> >> If it helps I will never type the TLA IoT again in a greybus email... :) > > -- > Regards, > > Laurent Pinchart > _______________________________________________ greybus-dev mailing list greybus-dev@xxxxxxxxxxxxxxxx https://lists.linaro.org/mailman/listinfo/greybus-dev
|