- 15 Sep, 2015 9 commits
-
-
Viresh Kumar authored
Its a very useful piece of information, i.e. the cport id of the AP to which the cport of the module is connected, and is required lots of times. It isn't known in advance as it is allocated at runtime. This patch creates another file 'ap_cport_id', only for the connection directories, which will give the cport id of the AP. Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@google.com>
-
Viresh Kumar authored
We created two-way routes between the AP and module's interface on hotplug, and forgot to remove them on hot-unplug. The same is also required while handling errors in hotplug case. Reviewed-by:
Johan Hovold <johan@hovoldconsulting.com> Signed-off-by:
-
Viresh Kumar authored
The route-create request creates bi-directional routes and there is no need to make separate calls for setting up routes on both the directions. Signed-off-by:
-
Viresh Kumar authored
This helps in removing special per-protocol code, with the help of generic flags passed by protocol drivers. Reviewed-by:
-
Viresh Kumar authored
connection_create() is called right after svc is requested to create the connection and so connection_destroy() must be called just before we request the SVC to destroy the connection. Over that, this fixes the inconsistency where connection_create() is called for all connections except SVC connection, but connection_destroy() is called always. Acked-by:
Alexandre Bailon <abailon@baylibre.com> Fixes: 5313ca607afb ("Greybus driver: add a new callbacks to driver") Signed-off-by:
-
Viresh Kumar authored
While initializing a connection, the AP requests the SVC to create a connection between a cport on AP and a cport on the Module. The opposite of that is missing, when connection is destroyed or if errors occur after creating the connection. Fix it. Reviewed-by:
-
Viresh Kumar authored
There are two operations which very much work together: - AP asks the SVC to create a connection between a cport of AP and a cport of module. - AP tells the module that the connection is created. Its better (logically) to do these two operations together and so call gb_svc_connection_create() from gb_connection_init() instead. Also check its return value properly. Reviewed-by:
-
Viresh Kumar authored
If we fail to initialize a cport of a bundle, we abort the entire bundle. But that leads to following (unnecessary) warnings as few of the cport descriptors, belonging to the aborted bundle were never parsed: "greybus: excess descriptors in interface manifest" Fix that by releasing all cport descriptors for the aborted bundle. Signed-off-by:
-
Viresh Kumar authored
A 'bundle' represents a device in greybus. It may require multiple cports for its functioning. If we fail to setup any cport of a bundle, we better reject the complete bundle as the device may not be able to function properly then. But, failing to setup a cport of bundle X doesn't mean that the device corresponding to bundle Y will not work properly. Bundles should be treated as separate independent devices. While parsing manifest for an interface, treat bundles as separate entities and don't reject entire interface and its bundles on failing to initialize a cport. But make sure the bundle which needs the cport, gets destroyed properly. We now release the bundle descriptor before parsing the cports, but that shouldn't make any difference. Signed-off-by:
-
- 04 Sep, 2015 4 commits
-
-
Bryan O'Donoghue authored
gb_loopback_connection_exit does a kfree on a data structure associated with a loopback connection but fails to do a corresponding list_del(). On subsequent enumerations this can lead to a NULL pointer dereference. Each list_add in gb_loopback_connection_init() must have a corresponding list_del in gb_loopback_connection_exit(), this patch adds the relevant list_del() and ensures that an appropriate mutex protecting gb_dev.list is held while doing so. Signed-off-by:
Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reported-by:
-
Alexandre Bailon authored
The endpoint set 0 is currently considered as invalid. But 0 mean muxed cports on ep1 and ep2, then it must not return -EINVAL. Signed-off-by:
-
Alexandre Bailon authored
Add connection_create and connection_destroy callbacks. ES2 can map a cport to a pair of endpoints. Because ES2 have only a few pair of endpoints, ES2 need to have access to some high level connection information such as protocol id to effectively map the cports. These callback will provide these information and help ES2 to map cports. Signed-off-by:
-
Viresh Kumar authored
And that fixes these warnings generated with BDB: WARNING: at /home/viresh/ara/jetson-kernel-build/tegra/fs/sysfs/dir.c:530 sysfs_add_one+0xa4/0xb4() sysfs: cannot create duplicate filename '/class/spi_master/spi0' Modules linked in: gb_es2(O) gb_phy(O) greybus(O) CPU: 2 PID: 111 Comm: kworker/u8:3 Tainted: G W O 3.10.40-gf32f9c5ca7e8 #2 Workqueue: events_unbound svc_process_hotplug [greybus] [<c0016844>] (unwind_backtrace+0x0/0x13c) from [<c0012fc4>] (show_stack+0x18/0x1c) [<c0012fc4>] (show_stack+0x18/0x1c) from [<c0067d4c>] (warn_slowpath_common+0x5c/0x74) [<c0067d4c>] (warn_slowpath_common+0x5c/0x74) from [<c0067d9c>] (warn_slowpath_fmt+0x38/0x48) [<c0067d9c>] (warn_slowpath_fmt+0x38/0x48) from [<c01bc218>] (sysfs_add_one+0xa4/0xb4) [<c01bc218>] (sysfs_add_one+0xa4/0xb4) from [<c01bcc24>] (sysfs_do_create_link_sd+0xc0/0x20c) [<c01bcc24>] (sysfs_do_create_link_sd+0xc0/0x20c) from [<c042e088>] (device_add+0x2e8/0x5f4) [<c042e088>] (device_add+0x2e8/0x5f4) from [<c04ae008>] (spi_register_master+0x15c/0x654) [<c04ae008>] (spi_register_master+0x15c/0x654) from [<bf015df4>] (gb_spi_connection_init+0x164/0x19c [gb_phy]) [<bf015df4>] (gb_spi_connection_init+0x164/0x19c [gb_phy]) from [<bf002604>] (gb_connection_bind_protocol+0x160/0x1b4 [greybus]) [<bf002604>] (gb_connection_bind_protocol+0x160/0x1b4 [greybus]) from [<bf002880>] (gb_connection_create_range+0x228/0x2fc [greybus]) [<bf002880>] (gb_connection_create_range+0x228/0x2fc [greybus]) from [<bf002994>] (gb_connection_create+0x40/0x48 [greybus]) [<bf002994>] (gb_connection_create+0x40/0x48 [greybus]) from [<bf000be0>] (gb_manifest_parse+0x61c/0x628 [greybus]) [<bf000be0>] (gb_manifest_parse+0x61c/0x628 [greybus]) from [<bf0019ac>] (gb_interface_init+0x130/0x170 [greybus]) [<bf0019ac>] (gb_interface_init+0x130/0x170 [greybus]) from [<bf003bf0>] (svc_process_hotplug+0x214/0x258 [greybus]) [<bf003bf0>] (svc_process_hotplug+0x214/0x258 [greybus]) from [<c0087ecc>] (process_one_work+0x13c/0x454) [<c0087ecc>] (process_one_work+0x13c/0x454) from [<c0088c20>] (worker_thread+0x140/0x3dc) [<c0088c20>] (worker_thread+0x140/0x3dc) from [<c008f20c>] (kthread+0xe0/0xe4) [<c008f20c>] (kthread+0xe0/0xe4) from [<c000f098>] (ret_from_fork+0x14/0x20) Reported-by:
Mitchell Tasman <tasman@leaflabs.com> Suggested-by:
-
- 03 Sep, 2015 20 commits
-
-
Viresh Kumar authored
gb_connection_exit() is getting called from gb_connection_destroy() now, which will get called from failure path of gb_connection_create_range() (in a later commit). And at that point connection->protocol will be NULL. Don't print an error message if this happens in gb_connection_exit(). Signed-off-by:
-
Fabien Parent authored
gb_connection_init() can fail and will return proper error code in that case, but the caller is ignoring it currently. Fix that by properly handling errors returned from gb_connection_init() and propagating them to callers of gb_connection_bind_protocol(). Signed-off-by:
Fabien Parent <fparent@baylibre.com> Signed-off-by:
-
Viresh Kumar authored
Both the routines are always called together and in the same sequence. Rather than duplicating this at different places, make gb_connection_destroy() call gb_connection_exit(). This also makes it more sensible, as gb_connection_init() is never called directly by the users and so its its counterpart shouldn't be called directly as well. Signed-off-by:
-
Viresh Kumar authored
We just got an error, propagate the exact return value instead of 0. Reviewed-by:
-
Viresh Kumar authored
connection->protocol will always be valid in gb_connection_init() as it is called only from a single routine, after initializing the 'protocol' field. No need to check it again. Reviewed-by:
-
Viresh Kumar authored
Failures from control-connected operations are fatal errors and must be reported with dev_err() instead of dev_warn(). Fix it. Reviewed-by:
-
Viresh Kumar authored
Its not used by external users, mark it static. This required some shuffling of the code. Reviewed-by:
-
Viresh Kumar authored
Move the function to an earlier place, to kill the unnecessary forward declaration. Reviewed-by:
-
Viresh Kumar authored
There are no external users of these, and probably would never be. Make them static. Reviewed-by:
-
Viresh Kumar authored
Not sure why they were created, but there is no need for them. Kill them. Reviewed-by:
-
Viresh Kumar authored
These routines are responsible to destroy a connection that is going away, the return value is of no use. At best, print an error message to show that we got an error. Make their return type void. Reviewed-by:
-
Viresh Kumar authored
These structures are exchanged between the AP and the module and must be packed to avoid any unwanted holes. Its all working currently because compiler doesn't add any pad bytes for these structures, as their elements are already aligned to their size. But these structures can change in future and we better mark them packed. Signed-off-by:
-
Viresh Kumar authored
These structures are expected to be packed by the module firmware code, but the kernel wasn't following it until now. Its all working currently because compiler doesn't add any pad bytes for these structures, as their elements are already aligned to their size. But these structures can change in future and we better mark them packed. Signed-off-by:
-
Viresh Kumar authored
All request/responses either have a structure representing them or a comment saying the request/response payload doesn't exist. The comment was missing for route create response message, add it. Reviewed-by:
-
Viresh Kumar authored
The request sequence for SVC protocol is fixed at least upto SVC_HELLO request. The first request has to be Protocol Version, followed by SVC_HELLO. Any other request can follow them, but these two. Add another field in 'struct gb_svc' that keeps track of current state of the protocol driver. It tracks only upto SVC_HELLO, as we don't need to track later ones. Also add a comment, about the order in which the requests are allowed and why a race can't happen while accessing 'state'. This removes the WARN_ON() in gb_svc_hello() as we track state transition with 'state' field. This also fixes a crash, when the hotplug request is received before fully initializing the svc connection. The crash mostly happens while accessing svc->connection->bundle, which is NULL, but can happen at other places too, as svc connection isn't fully initialized. Reported-by:
-
Viresh Kumar authored
System headers should get included before greybus.h. Its followed everywhere except svc.c. Fix it. Reported-by:
-
Vishal Bhoj authored
For sdk related targets, the greybus build will error out due to missing kernel dependency. Let's avoid those targets by checking TARGET_NO_KERNEL. Signed-off-by:
Vishal Bhoj <vishal.bhoj@linaro.org> Signed-off-by:
Michael Scott <michael.scott@linaro.org> Signed-off-by:
-
Johan Hovold authored
The CPORT_ID_MAX define has been used by host drivers as a device limit, but also for sanity checks when parsing manifests. Now that it's only used for sanity checks we can increase it to the specification maximum (4095) and get rid of the config-option that could be used to override the previous limit (128). Signed-off-by:
-
Johan Hovold authored
The CPort count of es1 is now defined by CPORT_COUNT. Signed-off-by:
-
Johan Hovold authored
Make sure to return an errno when a host-device buffer-size check fails. Fixes: 1f92f6404614 ("core: return error code when creating host device") Signed-off-by:
-
- 02 Sep, 2015 7 commits
-
-
Fabien Parent authored
There is no need to store the endpoint number of the control requests since the default control endpoint is used and the USB standard defines for it a fixed endpoint number of 0. Remove every instance of the field control_endpoint and replace it with a hardcoded 0 value. Signed-off-by:
-
Fabien Parent authored
Use the control request REQUEST_CPORT_COUNT in order to get the number of CPorts supported by the UniPro IP. Signed-off-by:
-
Fabien Parent authored
In order to be able to dynamically determine the number of CPorts supported by the UniPro IP instead of hardcoding the value we need to dynamically allocate the array that is doing the cport-ep mapping. Signed-off-by:
-
Fabien Parent authored
This commit is doing the preparation work in order to get the number of cports supported from the UniPro IP instead of using a constant defined in a Kconfig file. Greybus host device is now holding the cport count, and all the code will now use this value instead of the constant CPORT_ID_MAX when referring to an AP's CPort ID. Signed-off-by:
-
Fabien Parent authored
Rename the misnamed macro CPORT_MAX into CPORT_COUNT. CPORT_MAX could let people think that the macro is holding the value of the last CPort ID usable. Signed-off-by:
-
Viresh Kumar authored
There is no need to perform connection->bundle->intf->hd as the same can be done with connection->hd. Signed-off-by:
-
Johan Hovold authored
Replace pr_err with the more descriptive dev_err. Also include the error code on failure to register the PWM chip. Signed-off-by:
-
