redonkable/alistair23-linux
redonkable/alistair23-linux
1
0
Fork 0
Code Releases Activity
alistair23-linux/drivers/staging/greybus/connection.h

61 lines
1.4 KiB
C
Raw Normal View History

greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
/*
* Greybus connections
*
* Copyright 2014 Google Inc.
greybus: add Linaro copyrights 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>
2014-12-12 11:08:42 -07:00
* Copyright 2014 Linaro Ltd.
greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
*
* Released under the GPLv2 only.
*/
#ifndef __CONNECTION_H
#define __CONNECTION_H
#include <linux/list.h>
greybus: define connection state Define the state of a connection. A connection will not be enabled until it has been successfully set up. Once it starts getting torn down its state will move to "being destroyed". Don't send any operation request messages unless the connection is enabled. And drop any incoming messages if if the connection is not enabled. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-22 01:04:30 -06:00
enum gb_connection_state {
GB_CONNECTION_STATE_INVALID = 0,
GB_CONNECTION_STATE_DISABLED = 1,
GB_CONNECTION_STATE_ENABLED = 2,
GB_CONNECTION_STATE_ERROR = 3,
GB_CONNECTION_STATE_DESTROYING = 4,
};
greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
struct gb_connection {
struct greybus_host_device *hd;
greybus: bundle: s/gb_interface/gb_bundle/g 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>
2014-12-12 15:10:17 -07:00
struct gb_bundle *bundle;
greybus: hook up greybus to the driver model This patch hooks up modules, interfaces, and connections to the driver model. Now we have a correct hierarchy, and drivers can be correctly bound to the proper portions in the future. Devices are correctly reference counted and torn down in the proper order on removal of a module. Some basic sysfs attributes have been created for interfaces and connections. Module attributes are not working properly, but that will be fixed in future changes. This has been tested on Alex's machine, with multiple hotplug and unplug operations of a module working correctly. Signed-off-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-24 03:34:46 -06:00
struct device dev;
greybus: get rid of functions now... We decided yesterday that we would no longer support the notion of a "function." Instead, a connection will simply exist between the AP and an interface on a module (and a CPort Id on each end). What was previously considered the "function type" will now be handled as the "protocol" associated with the connection. Update gb_connection_create() to take just the interface and a cport id associated with that interface. Right now every module points back to a host device, so for now we'll establish the connection back to that. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-02 11:30:05 -06:00
u16 hd_cport_id;
greybus: s/bundle_cport_id/intf_cport_id This isn't unique just for the bundle but the complete interface. Its wrong to call it bundle_cport_id. Lets name it intf_cport_id to make things clear. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-03 22:48:01 -06:00
u16 intf_cport_id;
greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
greybus: use a simple list of hd connections First of all, there's a bug in _gb_hd_connection_insert, which Viresh found. But pointing out that problem just called attention to the fact that I have planning to to remove the affected block of code. The set of connections associated with a host device is currently maintained in a red-black tree. The number of connections we're likely to have is on the order of a hundred, and at least for now isn't even going to approach that. When this code first went in, Greg asserted that using a list is speedier than a red-black tree for smallish numbers of elements (maybe up to a few hundred?). So this patch just removes the host device's red-black tree of connections, using a simple list instead. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-11-17 07:08:44 -07:00
struct list_head hd_links;
greybus: bundle: s/gb_interface/gb_bundle/g 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>
2014-12-12 15:10:17 -07:00
struct list_head bundle_links;
greybus: introduce protocol abstraction Define a protocol structure that will allow protocols to be registered dynamically. For now we just introduce a bookkeeping data structure. Upcoming patches will move protocol-related methods into the protocol structure, and will start registering protocol handlers dynamically. A list of connections using a given protocol is maintained so we can tell when a protocol is no longer in use. This may not be necessary (we could use a kref instead) but it may turn out to be a good way to clean things up. The interface is gb_protocol_get() and gb_protocol_put() for a connection, allowing the protocol to be looked up and the connection structure to be inserted into its list. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-28 18:36:00 -06:00
struct gb_protocol *protocol;
greybus: protocol: split binding of prototcols to connections out of init When adding a new protocol to the system, walk all bundles and try to hook up any connections that do not have a protocol already. This sets the stage to allow for protocols to be loaded at any time, not just before the device is seen in the system. Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-12-23 16:16:53 -07:00
u8 protocol_id;
u8 major;
u8 minor;
greybus: use protocol_id for numeric values Switch to using "protocol_id" to refer to a byte-sized numeric protocol number. A "protocol" will represent a protocol structure (created in the next patch). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-28 18:35:59 -06:00
greybus: define connection state Define the state of a connection. A connection will not be enabled until it has been successfully set up. Once it starts getting torn down its state will move to "being destroyed". Don't send any operation request messages unless the connection is enabled. And drop any incoming messages if if the connection is not enabled. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-22 01:04:30 -06:00
enum gb_connection_state state;
greybus: introduce an operation abstraction This patch defines a new "operation" abstraction. An operation is a request from by one end of a connection to the function (or AP) on the other, coupled with a matching response returned to the requestor. The request indicates some action to be performed by the target of the request (such as "read some data"). Once the action has completed the target sends back an operation response message. Additional data can be supplied by the sender with its request, and/or by the target with its resposne message. Each request message has a unique id, generated by the sender. The sender recognizes the matching response by the presence of this id value. Each end of a connection is responsible for creating unique ids for the requests it sends. An operation also has a type, whose interpretation is dependent on the function type on the end of the connection opposite the sender. It is up to the creator of an operation to fill in the data (if any) to be sent with the request. Note that not all requests are initiated by the AP. Incoming data on a module function can result in a request message being sent from that function to the AP to notify of the data's arrival. Once the AP has processed this, it sends a response to the sender. Every operation response contains a status byte. If it's value is 0, the operation was successful. Any other value indicates an error. Add a defintion of U16_MAX to "kernel_ver.h". Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:15 -06:00
greybus: make op_cycle atomic (again) There's no need to protect updating a connections operation id cycle counter with the operations spinlock. That spinlock protects connection lists, which do not interact with the cycle counter. All that we require is that it gets updated atomically, and we can express that requirement in its type. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-12-03 07:35:08 -07:00
atomic_t op_cycle;
greybus: introduce an operation abstraction This patch defines a new "operation" abstraction. An operation is a request from by one end of a connection to the function (or AP) on the other, coupled with a matching response returned to the requestor. The request indicates some action to be performed by the target of the request (such as "read some data"). Once the action has completed the target sends back an operation response message. Additional data can be supplied by the sender with its request, and/or by the target with its resposne message. Each request message has a unique id, generated by the sender. The sender recognizes the matching response by the presence of this id value. Each end of a connection is responsible for creating unique ids for the requests it sends. An operation also has a type, whose interpretation is dependent on the function type on the end of the connection opposite the sender. It is up to the creator of an operation to fill in the data (if any) to be sent with the request. Note that not all requests are initiated by the AP. Incoming data on a module function can result in a request message being sent from that function to the AP to notify of the data's arrival. Once the AP has processed this, it sends a response to the sender. Every operation response contains a status byte. If it's value is 0, the operation was successful. Any other value indicates an error. Add a defintion of U16_MAX to "kernel_ver.h". Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:15 -06:00
struct list_head operations;
greybus: add a connection->private field This will be used for driver-specific data for whatever drives the other end of the connection. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-03 14:05:21 -06:00
void *private;
greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
};
greybus: hook up greybus to the driver model This patch hooks up modules, interfaces, and connections to the driver model. Now we have a correct hierarchy, and drivers can be correctly bound to the proper portions in the future. Devices are correctly reference counted and torn down in the proper order on removal of a module. Some basic sysfs attributes have been created for interfaces and connections. Module attributes are not working properly, but that will be fixed in future changes. This has been tested on Alex's machine, with multiple hotplug and unplug operations of a module working correctly. Signed-off-by: Greg Kroah-Hartman <greg@kroah.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-24 03:34:46 -06:00
#define to_gb_connection(d) container_of(d, struct gb_connection, dev)
greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
greybus: bundle: s/gb_interface/gb_bundle/g 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>
2014-12-12 15:10:17 -07:00
struct gb_connection *gb_connection_create(struct gb_bundle *bundle,
greybus: use protocol_id for numeric values Switch to using "protocol_id" to refer to a byte-sized numeric protocol number. A "protocol" will represent a protocol structure (created in the next patch). Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-28 18:35:59 -06:00
u16 cport_id, u8 protocol_id);
greybus: fix connection header declarations Changes to the create/destroy connection functions were not properly reflected in the header file. Fix that. There's also no need to include anything other than "greybus.h". Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-02 11:30:01 -06:00
void gb_connection_destroy(struct gb_connection *connection);
greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
greybus: add device initialization Set up the infrastructure for initializing connections based on their protocol. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-16 05:35:35 -06:00
int gb_connection_init(struct gb_connection *connection);
greybus: improve module cleanup code When a module gets destroyed all of its state and the state of its interfaces and connections (etc.) need to be torn down. This is not now being done properly. Add this teardown code. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-20 22:01:04 -06:00
void gb_connection_exit(struct gb_connection *connection);
greybus: Cleanup connection leftovers This wouldn't happen normally, but in a buggy corner case it is possible that all the connections aren't removed properly and they are still present after the interfaces and endo are removed. Warn in such a case and cleanup connections, so that /sys/bus/greybus/ can be removed while removing greybus modules. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-07-08 23:26:30 -06:00
void gb_hd_connections_exit(struct greybus_host_device *hd);
greybus: add device initialization Set up the infrastructure for initializing connections based on their protocol. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-16 05:35:35 -06:00
greybus: rename greybus_cport_in() This function is associated with a host device (interface), not a CPort. Change its name to reflect that, and to match its "sent" callback counterpart. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-11-20 15:09:18 -07:00
void greybus_data_rcvd(struct greybus_host_device *hd, u16 cport_id,
greybus: kill off the last of gbuf.c 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>
2014-11-17 17:08:37 -07:00
u8 *data, size_t length);
greybus: define gb_connection_err() Define a function that prints error information about a Greybus connection in a standard format. This adopts the convention that [M:I:C] represents the "path" the connection represents--specifying the module id, the interface number on that module, and the connection id on that interface. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-03 14:05:22 -06:00
greybus: protocol: split binding of prototcols to connections out of init When adding a new protocol to the system, walk all bundles and try to hook up any connections that do not have a protocol already. This sets the stage to allow for protocols to be loaded at any time, not just before the device is seen in the system. Reviewed-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-12-23 16:16:53 -07:00
void gb_connection_bind_protocol(struct gb_connection *connection);
greybus: introduce a connection abstraction Within a UniPro network a pair of CPorts can be linked to form a UniPro Connection. This patch creates a new abstraction to represent an AP CPort that is connected with a CPort used by a function within a Greybus module. Signed-off-by: Alex Elder <elder@linaro.org> Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2014-10-01 20:54:14 -06:00
#endif /* __CONNECTION_H */
Copy permalink