The current host-controller message-cancellation implementation suffer
from a lifetime bug as dynamically allocated URBs would complete and be
deallocated while being unlinked as part of cancellation.
The current locking is also insufficient to prevent the related race
where the URB is deallocated before being unlinked.
Fix this by pushing the cancellation implementation from greybus core
down to the host-controller drivers, and replace the "cookie" pointer
with a hcpriv field that those drivers can use to maintain their state
with the required locking and reference counting in place.
Specifically the drivers need to acquire a reference to the URB under a
lock before calling usb_kill_urb as part of cancellation.
Note that this also removes the insufficient gb_message_mutex, which
also effectively prevented us from implementing support for submissions
from atomic context.
Instead the host-controller drivers must now explicitly make sure that
the pre-allocated URBs are not reused while cancellation is in progress.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The responsibility of this routine is to configure ARA switch to
establish a connection between a cport on the AP and a cport on an
interface.
The SVC protocol is responsible for such requests and we already have
connection_{create|destroy}_operation() to take care of this.
Moreover, this request is not served by the firmware or gbsim today and
they just print a debug message on this request. And so it is safe to
drop svc_set_route_send() function and fix the required functionality of
configuring the switch in svc protocol driver later.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Add control protocol driver that is responsible for handling operations
on control CPort. The AP also needs to support incoming requests on its
control port. Features not implemented yet are marked as TODO for now.
NOTE: This also fixes cport-bundle-id to 0 and cport-id to 2 for control
protocol.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
For ES1 and ES2, we use pad bytes in an operation message header to
encode the CPort ID used for transferring the message. The pad
bytes should otherwise be zero, and we ensure this as the message
is passed to or from the upper layer.
If host-side CPort ID 0 is used, we have no way of knowing whether
the CPort field has been "packed" into the header.
To allow detection of this, reserve host CPort id 0. Update
cport_id_valid() to treat 0 as invalid.
(CPort ID 0 is reserved by one of the UniPro standards. We'll
assume for now that we never use it for Greybus.)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
We limit the number of host-side CPorts to a fixed maximum (which
is less than the 4096 that UniPro allows). This patch imposes a
similar limit on the CPort IDs defined by modules (signaling an
error if one too large is found in a manifest).
It seems reasonable to use the same value for both limits. Change
the name of the constant that defines the host limit and use it for
both. Update cport_id_valid() to enforce the maximum.
(Ultimately we should impose a limit like this; this change is being
made in preparation for supporting multiple connections over a
single CPort.)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Define a public predicate that defines whether a CPort ID is valid.
Use it in the message_send() routine, and make the message reported
more accurately reflect the error. Also use it to check whether the
CPort ID in a received message is valid; if it is not, just drop the
message.
Get rid of local variable "buffer" in message_send(); it adds no
value.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
__init does not belong in a .h file, as it does not do anything there,
so remove all instances of it.
Reviewed-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The top-level functions gb_init() and gb_exit() are tagged with
__init and __exit, respectively. These functions call a few
other functions that are similarly used only at initialization
and termination time. So mark those functions accordingly.
Note that, because gb_ap_exit() and gb_debugfs_cleanup()
are called by gb_init() in error paths, these functions
cannot be declared with the __exit attribute.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Rename greybus_deregister() to be greybus_deregister_driver(), so
its name mirrors the greybus_register_driver() function it matches.
Define greybus_deregister() to be a trivial macro.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This patch adds support for the Greybus SVC protocol. We may want
to rearrange protocol numbers at some point, since this is a pretty
fundamental protocol.
Note: It has only been compile tested; no SVC CPorts have yet been
defined, so this code is not yet exercised.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Currently, the data structure representing an Endo is set up at the
time a host device gets created. This is too early.
Once the control infrastructure is in place, there's no sense in
setting up the Endo utnil after we have heard from the SVC via a
probe operation on our control CPort. And even then, there's
no real point until we've successfully authenticated with the SVC,
which will be indicated by the arrival of the Control protocol
"connected" operation request notifying us that our SVC CPort
is operational.
In addition to this logical argument, we also can't actually
receive any messages on the Control CPort until the host device
is set up and ready to receive messages. At the point we're
currently setting up the Endo data structure, that has not yet
been done.
Define a new exported function greybus_endo_setup(), which will
be used (for now) as the entry point for setting up the Endo
data structure. Arrange to call it in the host USB driver
probe method, *after* we are set up for handling messages.
Note: Once the control protocol has been implemented, this function
may no longer need to be exported.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
The file "gpbridge.h" is now used as a single place to define
all protocol message structures. These protocols are not
necessarily related to the GP bridge, so the name of the
file is misleading.
Rename it "greybus_protocols.h".
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Avoid the need for all the source files to include "gpbridge.h"
by just having "greybus.h" include it.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Host devices impose buffer-size constraints on Greybus core which are
taken into account when allocating messages.
Make sure to verify these constraints when the host device is allocated,
rather than when the first message is allocated.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Remove a couple of unused function prototypes from the greybus header
file.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This hooks up the endo, and modules, into the device tree. All modules
for a specific endo are created when the host device is initialized.
When an interface is registered, the correct module for it is found and
that module is used for the sysfs tree. When the interface is removed,
the reference on the module is dropped.
When the host device goes away, the whole endo and modules are removed
at once.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-by: Alex Elder <elder@linaro.org>
This adds endo.c and endo.h and provides functions to create an endo and
the initial 0x0555 set of modules.
But, it doesn't hook this logic up into the running code yet, that comes
next.
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Drop the host-driver buffer headroom that was used to transfer the cport
id on ES1 and ES2.
Rather than transferring additional bytes on the wire and having to deal
with buffer-alignment issues (e.g. requiring the headroom to be a
multiple of 8 bytes) simply drop the headroom functionality.
Host drivers are expected set up their transfer descriptors separately
from the data buffers and any intermediate drivers (e.g. for Greybus
over USB) can (ab)use the operation message pad bytes for now.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Pass structured greybus messages rather than buffers to the host
drivers.
This will allow us to separate the transfer buffers from the message
structures.
Rename the related functions to reflect the new interface.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Remove unused and unnecessary buffer-alignment define that host driver
were supposed to use.
We can handle unaligned incoming buffers just fine by accessing the
operation-message header via a copy in the receive path, rather than
requiring host drivers to make sure the alignment is correct.
Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
A Greybus driver will bind to a bundle, not an interface. Lets follow
this rule in code.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
This removes the error checking for debugfs initialization as we really
don't care if it failed or not.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Add gb_debugfs_get method to access to gb_debug_root dentry,
in order to use it from other greybus modules.
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Modules in the greybus system sit above the interface, so insert them
early in the sysfs tree. We dynamically create them when we have an
interface that references a module, as we don't get a "module create"
message directly. They also dynamically go away when the last interface
associated with a module is removed.
Naming scheme for modules/interfaces/bundles/connections is bumped up by
one ':', and now looks like the following:
/sys/bus/greybus $ tree
.
├── devices
│  ├── 7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7
│  ├── 7:7 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7
│  ├── 7:7:0 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0
│  └── 7:7:0:1 -> ../../../devices/pci0000:00/0000:00:14.0/usb1/1-1/7/7:7/7:7:0/7:7:0:1
├── drivers
├── drivers_autoprobe
├── drivers_probe
└── uevent
6 directories, 3 files
/sys/bus/greybus $ grep . devices/*/uevent
devices/7/uevent:DEVTYPE=greybus_module
devices/7:7/uevent:DEVTYPE=greybus_interface
devices/7:7:0/uevent:DEVTYPE=greybus_bundle
devices/7:7:0:1/uevent:DEVTYPE=greybus_connection
We still have some "confusion" about interface ids and module ids, which
will be cleaned up later when the svc control protocol changes die down,
right now we just name a module after the interface as we don't have any
modules that have multiple interfaces in our systems.
This has been tested with gbsim.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
This is really a list of interfaces, not modules, so rename it so that
we don't get confused when we really do add modules to the whole system
later on.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
rename gb_add_module -> gb_add_interface
rename gb_remove_modules -> gb_remove_interfaces
rename gb_remove_module -> gb_remove_interface
And move the function prototypes to interface.h, where they belong.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
This moves the id structure name to not have "block" in it, as that
doesn't make sense anymore with the renaming of the gb_interface
structure.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Rename struct gb_interface_block to struct gb_interface
Lots of renaming, and variable renames as well (gb_ib->intf), but all
should be sane with regards to the new naming scheme we are using.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Interface_block is being renamed to interface, so move the file first.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Rename struct gb_interface to struct gb_bundle
It's a lot of renaming, some structures got renamed and also some
fields, but the goal was to rename things to make sense with the new
naming of how the system is put together in the 'driver model' view.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
We are renameing the "interface" term to "bundle" so rename the files
before we start changing structure names to make it easier for people to
see what really is happening in the changes.
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Reviewed-by: Alex Elder <elder@linaro.org>
I was asked to add a Linaro copyright to all Greybus source files
that anyone at Linaro has modified. This patch does that.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Because of this, rename greybus_module_id to greybus_interface_block_id.
We still need to add a way for a "class" driver to be bound to an
interface, but for now, all we really need is the vendor/product pair as
the GP Bridge interface block is going to be our main user.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
No need to keep these out in sysfs.c, move them into the
interface_block.c file so that we can see them easier, and remove some
variable definitions by taking advantage of the attribute group macro.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
The sysfs files for an interface block should not have 'module' in them.
This was a hold-over from when we thought we were going to have
all attributes of a "module" in one directory. Remove the prefix as
it's not needed, and is confusing considering modules can not have
strings or any of these attributes.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Rename struct gb_module to struct gb_interface_block
It's a complex rename, some functions got their name changed where
needed, but primarily this change is focused on the structure and where
it is used. Future changes will clean up the remaining usages of the
term "module" in individual changes, this one spanned the whole
subsystem so do it all at once.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
"modules" in the driver model here, are really "interface blocks" as
that is what they are physically tied to. So rename the files before we
start changing the code to make it obvious what is going on.
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Define a maximum size that a host device can use for its private
area ahead of the payload space used by Greybus in a message buffer.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Rather than having the host driver allocate the buffers that the
Greybus core uses to hold its data for sending or receiving, have
the host driver define what it requires those buffers to look like.
Two constraints define what the host driver requires: the maximum
number of bytes that the host device can send in a single request;
and a statement of the "headroom" that needs to be present for
use by the host device.
The direct description of the headroom is that it's the extra byte
the host device needs at the beginning of the "data" portion of
the buffer so the ES1 driver can insert the destination CPort id.
But more generally, the host driver could put other data in there
as well.
By stating these two parameters, Greybus can allocate the buffers it
uses by itself. The host driver still allocates the buffers it uses
for receiving data--the content of those are copied as needed into
Greybus buffers when data arrives.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
All the code has now been adjusted such that we can do away with the
old gbuf structure.
Three unused references remained in "greybus.h", so those are deleted.
Other than that most of the changes were done by simple global
substitution. The gb_message structure incorporates the fields that
were previously found its embedded gbuf structure. A few names have
been changed in the process:
gbuf->transfer_buffer message->buffer
gbuf->transfer_buffer_size message->buffer_size
gbuf->hcd_data; message->cookie
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Change the method that sends messages so that it sends "raw" buffers
rather than gbufs. To do this, we supply the host device and
destination CPort when sending. As with other recent patches,
change the name of the method to reflect that we're no longer
dealing with gbufs.
The interface has changed as well. Now this routine will return a
"cookie" value. The cookie is used to represent the outgoing
request, and is supplied by the caller if necessary to cancel a
previously-sent buffer. We'll store the result in gbuf->hcd_data
for now (which produces the same result as before...).
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Change the interface for canceling in-flight buffers to take a magic
cookie value as argument rather than a gbuf. Right now we pass the
gbuf->hcd_data pointer that's assumed to have been set by the submit
routine. But the next patch will change the submit routine to
return the cookie to be used, and the caller will be responsible for
keeping track of it.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Switch the host driver free routine to take a pointer to the
previously-allocated buffer that should be freed.
Rename the method to reflect it's no longer tied to a gbuf.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
This begins the transition to buffer allocation that does not rely
on the gbuf construct.
The host driver allocation routine will return a pointer to the
buffer to be used, and the caller will be responsible for keeping
track of that pointer, as well as the requested buffer size.
Rename the allocation method to reflect it's no longer tied to a
gbuf.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
For ES1 we need to insert the destination CPort id in whatever we
supply for sending over UniPro. Currently we allocate one extra
byte supply the caller with an address that's offset by one from
the beginning of the allocated space.
As a result we always return a poorly-aligned buffer pointer.
Instead, allocate enough space so that we can return a better
aligned buffer to the caller.
Notes:
- It may be that it's more important to supply an aligned
address to the hardware.
- We probably need to be more careful about writing into
these buffers at unaligned offsets anyway. (E.g., writing
a 2-byte value at an odd offset can't be assumed to work.)
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Only three functions remain in "gbuf.c". Move one of them into
"connection.c" and the other two into "operation.c".
Some more cleanup is coming that will further straighten out gbufs
but for now there's no sense in drawing this out any longer.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Nobody dynamically allocates gbufs any more, so we can get rid of
the allocation and free routines, as as the slab cache and its
related code.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
Change greybus_alloc_gbuf() so all it does is allocate the gbuf data
structure. Move all of the initialization of the gbuf structure in
the caller. Do the inverse in the caller prior to freeing the gbuf
structure via greybus_free_gbuf(). Use a null gbuf->transfer_buffer
pointer rather than a null gbuf pointer to indicate an unused gbuf.
Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
