The arche driver currently depends on the out-of-tree usb3613 driver and
this prevented a recent compile breakage after removing the timesync
code from being detected.
These patches remove the remaining timesync bits, and enable compile
testing of the arche driver to avoid further unintended breakage.
Johan
Changes in v2
- fix usb3613 Kconfig dependency (Randy Dunlap)
Johan Hovold (2):
staging: greybus: arche: remove timesync remains
staging: greybus: enable compile testing of arche driver
drivers/staging/greybus/Kconfig | 10 +++
drivers/staging/greybus/Makefile | 2 +-
drivers/staging/greybus/arche-apb-ctrl.c | 11 +--
drivers/staging/greybus/arche-platform.c | 150 ++-----------------------------
drivers/staging/greybus/arche_platform.h | 8 --
5 files changed, 21 insertions(+), 160 deletions(-)
--
2.13.0
The arche driver currently depends on the out-of-tree usb3613 driver and
this prevented a recent compile breakage after removing the timesync
code from being detected.
These patches remove the remaining timesync bits, and enable compile
testing of the arche driver to avoid further unintended breakage.
Johan
Johan Hovold (2):
staging: greybus: arche: remove timesync remains
staging: greybus: enable compile testing of arche driver
drivers/staging/greybus/Kconfig | 10 +++
drivers/staging/greybus/Makefile | 2 +-
drivers/staging/greybus/arche-apb-ctrl.c | 11 +--
drivers/staging/greybus/arche-platform.c | 150 ++-----------------------------
drivers/staging/greybus/arche_platform.h | 8 --
5 files changed, 21 insertions(+), 160 deletions(-)
--
2.13.0
Currently, only the es2 hd controller is supported, which restrict the
usage of greybus to few products.
This series intents to add a support of new hd controllers.
The driver doesn't support any hardware. Actually, the controller is just
a bridge between Greybus kernel and userspace. The real driver must be
implemented in userspace. This give the ability to support any kind of
transport layer (such as Bluetooth, WiFi, Ethernet).
The controller uses Generic Netlink. My original intent was to implement
a TCP/IP controller but it was very slow, unstable. In addition, some features
such as SVC or module discovery were to add to implement in kernel side.
With the generic netlink controller, we can easily add support of new
controller. It also helps to deal with all the project ARA legacy such as SVC.
I have started to implement an application which is able to emulate the SVC,
a module (like gbsim but only support control and loopback protcols),
TCP/IP, Bluetooth and UART. It is still under development but it was stable
enough to test this series. The application can found here:
https://github.com/anobli/gbridge
Alexandre Bailon (3):
staging greybus: make cport_quiesce() method optional
staging: greybus: Add Greybus netlink driver
staging: greybus: netlink: Add a way to "hot remove" SVC
drivers/staging/greybus/Kconfig | 9 ++
drivers/staging/greybus/Makefile | 2 +
drivers/staging/greybus/connection.c | 3 +
drivers/staging/greybus/gb_netlink.h | 38 ++++++
drivers/staging/greybus/netlink.c | 256 +++++++++++++++++++++++++++++++++++
5 files changed, 308 insertions(+)
create mode 100644 drivers/staging/greybus/gb_netlink.h
create mode 100644 drivers/staging/greybus/netlink.c
--
2.10.2
Is there a technical reason why greybus files mix hyphen and
underscore in their names?
$ ls drivers/staging/greybus/arch*
arche-apb-ctrl.c arche-platform.c arche_platform.h
thanks,
Tobin.
Hi,
I’m working with Greybus and I’m wondering if there’s any support or code for virtual USB devices.
On one side of Greybus I have a small nuttX environment with a UART connected device which I can write modules for, and on the other side of Greybus I’d like to provide a network interface. I can’t modify that side, so I have to work with the kernel modules it has available. I thought it might be possible to present a virtual USB CDC-EVM to Greybus, and my guess (hope) is that cdc_ether would pick it up on the other side.
Is this possible? Has this sort of virtual USB device been created before?
-Greg