- 15 Sep, 2015 1 commit
-
-
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:
Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by:
Johan Hovold <johan@hovoldconsulting.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@google.com>
-
- 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 <abailon@baylibre.com> 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 11 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:
-
Johan Hovold authored
Use scnprintf in the generic attribute helper, which does not currently check for buffer overflow. The attribute helper is used to print generic strings, which could potentially overflow the buffer. Note that the only strings currently exported are taken from greybus string descriptors and should therefore be limited to 255 chars. Signed-off-by:
-
Johan Hovold authored
Use GFP_KERNEL for hot-plug state allocation in gb_svc_intf_hotplug_recv, which is called from a request handler (i.e. a work queue). Signed-off-by:
-
Johan Hovold authored
Use GFP_KERNEL for device-id allocation in svc_process_hotplug, which is called from a work queue. Signed-off-by:
-
Johan Hovold authored
Use GFP_KERNEL for endo ida allocation in gb_endo_register, which is not called from atomic context. Signed-off-by:
-
- 01 Sep, 2015 3 commits
-
-
Rui Miguel Silva authored
Broadcast command with response and without response where swapped related to what is defined in greybus specification. Make it coherent with the document. Signed-off-by:
Rui Miguel Silva <rui.silva@linaro.org> Signed-off-by:
-
Johan Hovold authored
Use snprintf when generating the firmware name to avoid stack corruption if the fixed-size buffer overflows. Note that the current buffer size appears to expect 16-bit ids while the they are actually 32-bit, something which could trigger the corruption. Signed-off-by:
-
Alexandre Bailon authored
Greybus messages with a multiple size of 512B generate timeouts (any other message size doesn't). 512B is exactly the packet size of a bulk out endpoint. Hence USB device is expecting a short (< 512B) or zero-length packet to finish the transfer, which is never generated and causes the timeout. Set the transfer flag to send a zero-length packet in this situation. Signed-off-by:
Patrick Titiano <ptitiano@baylibre.com> Reviewed-by:
-
- 18 Aug, 2015 1 commit
-
-
Bryan O'Donoghue authored
Alex previously post a patch to fix this typo. Somehow it fell through the cracks in the meantime. Do it again 'stastic' is a word 'statistic' is not. Signed-off-by:
-
