Commit graph

36 commits

Author SHA1 Message Date
Johan Hovold 3e136cc9e0 greybus: operation/esx: fix message-cancellation lifetime bugs
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>
2015-07-01 16:43:02 -07:00
Johan Hovold 86f918ee7f greybus: esx: fix null-deref on hotplug events
We must be prepared to receive hotplug events as soon as we submit the
SVC URB. Since commit 2eb8a6a947d7 ("core: don't set up endo until host
device is initialized") this is no longer the case as the endo would not
have been setup, something which may lead to a null-pointer dereference
in endo_get_module_id() when the interface is created (see oops below
with an added dev_dbg for hd->endo).

Fix this by setting up the endo before submitting the SVC URB.

[   28.810610] gb_interface_create - hd->endo =   (null)
[   28.816020] Unable to handle kernel NULL pointer dereference at virtual address 0000022b
[   28.824952] pgd = c0004000
[   28.827880] [0000022b] *pgd=00000000
[   28.831913] Internal error: Oops: 17 [#1] PREEMPT ARM
[   28.837183] Modules linked in: gb_es1(O+) greybus(O) netconsole
[   28.843419] CPU: 0 PID: 21 Comm: kworker/u2:1 Tainted: G           O    4.1.0-rc7 #12
[   28.851576] Hardware name: Generic AM33XX (Flattened Device Tree)
[   28.857978] Workqueue: greybus_ap ap_process_event [greybus]
[   28.863890] task: cf2961c0 ti: cf29c000 task.ti: cf29c000
[   28.869529] PC is at endo_get_module_id+0x18/0x88 [greybus]
[   28.875355] LR is at gb_interface_add+0x88/0x204 [greybus]
[   28.881070] pc : [<bf0052d4>]    lr : [<bf005dac>]    psr: 20070013
[   28.881070] sp : cf29de08  ip : cf29de18  fp : cf29de14
[   28.893021] r10: 00000001  r9 : 0000005a  r8 : cd813ec6
[   28.898461] r7 : 00000058  r6 : cf7fa200  r5 : 00000001  r4 : cf7fa20c
[   28.905261] r3 : 00000000  r2 : cf2961c0  r1 : 00000001  r0 : 00000000
[   28.912067] Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[   28.919677] Control: 10c5387d  Table: 8f508019  DAC: 00000015
[   28.925663] Process kworker/u2:1 (pid: 21, stack limit = 0xcf29c210)
[   28.932279] Stack: (0xcf29de08 to 0xcf29e000)
[   28.936823] de00:                   cf29de44 cf29de18 bf005dac bf0052c8 00000058 cd813ec0
[   28.945349] de20: cf58b60c bf00afe0 cf7fa200 cf58b600 0000005a 00000001 cf29de84 cf29de48
[   28.953865] de40: bf004844 bf005d30 00000000 cf02d800 cf29de6c cf29de60 c00759a0 cf58b60c
[   28.962389] de60: cf2742c0 cf02d800 cf0c6000 cf29dea8 c07b745c 00000000 cf29dee4 cf29de88
[   28.970908] de80: c005943c bf004560 00000001 00000000 c0059354 cf02d800 c0059c0c 00000001
[   28.979426] dea0: 00000000 00000000 bf00b314 00000000 00000000 bf009144 c04e3710 cf02d800
[   28.987945] dec0: cf2742d8 cf02d830 00000088 c0059bd0 00000000 cf2742c0 cf29df24 cf29dee8
[   28.996464] dee0: c0059b78 c0059248 cf29c000 cf245d40 c0776890 c07b6bf3 00000000 00000000
[   29.004983] df00: cf245d40 cf2742c0 c0059b20 00000000 00000000 00000000 cf29dfac cf29df28
[   29.013502] df20: c005fe90 c0059b2c c07812d0 00000000 cf29df4c cf2742c0 00000000 00000001
[   29.022025] df40: dead4ead ffffffff ffffffff c07c86b0 00000000 00000000 c05fd8e8 cf29df5c
[   29.030542] df60: cf29df5c 00000000 00000001 dead4ead ffffffff ffffffff c07c86b0 00000000
[   29.039062] df80: 00000000 c05fd8e8 cf29df88 cf29df88 cf245d40 c005fd98 00000000 00000000
[   29.047581] dfa0: 00000000 cf29dfb0 c00108f8 c005fda4 00000000 00000000 00000000 00000000
[   29.056105] dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   29.064623] dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffff0000 ffff0000
[   29.073178] [<bf0052d4>] (endo_get_module_id [greybus]) from [<bf005dac>] (gb_interface_add+0x88/0x204 [greybus])
[   29.083887] [<bf005dac>] (gb_interface_add [greybus]) from [<bf004844>] (ap_process_event+0x2f0/0x4d8 [greybus])
[   29.094527] [<bf004844>] (ap_process_event [greybus]) from [<c005943c>] (process_one_work+0x200/0x8e4)
[   29.104228] [<c005943c>] (process_one_work) from [<c0059b78>] (worker_thread+0x58/0x500)
[   29.112668] [<c0059b78>] (worker_thread) from [<c005fe90>] (kthread+0xf8/0x110)
[   29.120295] [<c005fe90>] (kthread) from [<c00108f8>] (ret_from_fork+0x14/0x3c)
[   29.127825] Code: e24cb004 e52de004 e8bd4000 e3510000 (e5d0c22b)
[   29.137481] ---[ end trace ad95c3c26bdc98ce ]---

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-24 17:34:47 -07:00
Greg Kroah-Hartman 9df94499c4 greybus: Merge branch alex into Alexandre
This resolves a conflict with es2.c that I fixed up.

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-15 16:53:23 -07:00
Alexandre Bailon 799baa24db greybus: es1.c: Don't use magic value for USB control request
Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-15 16:51:44 -07:00
Alex Elder 4bc1389de9 greybus: esX: use one byte to encode cport ids in header
We now limit the maximum value for both host and module CPort ids,
and we know they can always be represented in a single byte.

Make use of this by using only one of the two pad bytes for encoding
the CPort id in a message header.

(Note that we have never used a CPort higher than 255.  Encoding
such a small CPort id in little endian 2-byte format has the same
result as what is done here.)

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-15 16:49:00 -07:00
Alex Elder d29b3d631e greybus: esX: encapsulate packing cport id into header
For the ES1 and ES2 host interfaces we encode the CPort ID over
which the message should be sent within the message itself.  The
CPort ID is recorded in unused pad bytes found in the operation
message header in order to avoid introducing misaligned messages.

This patch defines some helper routines to abstract this activity.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-15 16:49:00 -07:00
Alex Elder 821c620afa greybus: introduce cport_id_valid()
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>
2015-06-15 16:49:00 -07:00
Alex Elder 190241a362 greybus: drop some unnecessary headers
There's no need to include anything other than "greybus.h" in
"connection.c".  Same thing in "core.c" and "manifest.c" and
"svc.c".  Some files need headers included, but most come along
with "greybus.h".

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-10 10:38:23 -07:00
Greg Kroah-Hartman cce3103676 greybus: es?: decrease buffer size to 2k
The firmware is having a hard time with 4k buffers and memory
allocation, so decrease the size on the host side to 2k.  Also move away
from using PAGE_SIZE to denote 4k as that's not the case on all
architectures, and someone, someday, might get a rude surprise.

Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-06-10 10:35:03 -07:00
Alex Elder 4441f4759c greybus: update copyrights
Update the copyright statements for recently-modified source files.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-05-23 16:47:56 -07:00
Alex Elder eb765e4e91 greybus: core: don't set up endo until host device is initialized
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>
2015-05-23 16:45:42 -07:00
Alex Elder 8ea70fe049 greybus: core: return error code when creating host device
Return a pointer-coded error from greybus_create_hd() rather
than NULL in the event an error occurs.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-05-23 16:31:42 -07:00
Johan Hovold d933667a1e greybus: fix host-device buffer constraints
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>
2015-05-20 22:51:05 -07:00
Greg Kroah-Hartman 6cf42a447d greybus: MODULE_LICENSE cleanup
These are all GPLv2-only kernel modules, so properly set the correct
MODULE_LICENSE string to make static checkers happy.

Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-04-17 16:12:49 +02:00
Johan Hovold 24ef485398 greybus: drop host-driver buffer headroom
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>
2015-04-07 17:31:05 +02:00
Johan Hovold a9cf7da195 greybus: es1: fix transfer-buffer alignment
Fix transfer-buffer alignment of outgoing transfers which are currently
byte aligned.

Some USB host drivers cannot handle byte-aligned buffers and will
allocate temporary buffers, which the data is copied to or from on every
transfer. This affects for example musb (e.g. Beaglebone Black) and
ehci-tegra (e.g. Jetson).

Instead of transferring pad bytes on the wire, let's (ab)use the pad
bytes of the operation message header to transfer the cport id. This
gives us properly aligned buffers and more efficient transfers in both
directions.

By using both pad bytes, we can also remove the arbitrary limitation of
256 cports.

Note that the protocol between the host driver and the UniPro bridge is
not necessarily Greybus. As long as the firmware clears the pad bytes
before forwarding the data, and the host driver does the same before
passing received data up the stack, this should be considered "legal"
use.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-04-07 17:31:05 +02:00
Johan Hovold 7cf7bca9ec greybus: pass messages to host drivers
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>
2015-04-07 17:31:05 +02:00
Johan Hovold bfd9a94d1a greybus: es1: fix buffer-size limit
The maximum buffer size does not include the headroom, so subtract the
headroom size from the actual buffer size.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-04-07 14:32:42 +02:00
Johan Hovold 79940cf875 greybus: es1: fix DMA-buffer on stack
A stack-allocated buffer is not generally DMA-able and must not be used
for USB control transfers.

Note that the memset and extra buffer byte were redundant as no more
than the bytes actually transferred was ever added to the fifo.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-04-07 14:32:42 +02:00
Johan Hovold b7744b7f97 greybus: es1: drop unnecessary casts
Drop unnecessary explicit casts.

Signed-off-by: Johan Hovold <johan@hovoldconsulting.com>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
2015-04-07 14:32:42 +02:00
Alex Elder e4c4b4dce6 greybus: reduce the ranting
Cut out some comments that are no longer operative.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-04-02 11:29:58 +02:00
Alex Elder dada3b02a3 greybus: es1: test apb1_log_task safely
When usb_log_enable() is called, the global apb1_log_task is used to
hold the result of kthread_run().  It is possible for kthread_run()
to return an error pointer, so tests of apb_log_task against NULL
are insufficient to determine its validity.

Note that kthread_run() never returns NULL so we don't have to check
for that.  But apb1_log_task is initially NULL, so that global must
be both non-null and not an error in order to be considered valid.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-30 15:28:13 +02:00
Alex Elder 142f8ddf71 greybus: get rid of {conceal,reveal}_urb()
These clever macros were fine for early development, but they're
more of a distraction now.

Signed-off-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-27 11:16:35 +01:00
Greg Kroah-Hartman 25d1c37798 greybus: es1: allow the debug log to be stopped
If you write 0 to the debugfs file, the log will stop being updated.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:47:24 +01:00
Greg Kroah-Hartman 0c264c6fc2 greybus: es1: separate usb_log enable/disable logic into different functions
One function shouldn't do two different things depending on a parameter
passed to it, so split usb_log_enable() into usb_log_disable()

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:45:31 +01:00
Greg Kroah-Hartman efdc43130c greybus: es1: fix checkpatch warning about blank lines needed
Add a blank line in apb1_log_enable_read() to make checkpatch happy.

Oh, and it makes the code more readable too...

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:34:02 +01:00
Greg Kroah-Hartman 64b8a16f44 greybus: es1: move debugfs function to use kstrotoint_from_user()
No need to duplicate built-in functions that the kernel has, so have the
core kernel parse the userspace string.  Saves us an allocation and
makes the logic simpler.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:32:40 +01:00
Greg Kroah-Hartman d52f9973e2 greybus: es1: decimal modes are not what are wanted for debugfs
decimal is not octal, so use the proper mode settings for the debugfs
files.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:10:58 +01:00
Greg Kroah-Hartman 4600d03f80 greybus: es1: struct file_operations needs to be const
We aren't changing these pointers, so mark them read-only as that is the
preferred way.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:08:12 +01:00
Greg Kroah-Hartman 26164edb8f greybus: es1: no need to check for NULL on debugfs_remove()
The function can, and even expects NULL, so don't check.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:06:41 +01:00
Greg Kroah-Hartman cd674c8d4c greybus: es1: use <linux/uaccess.h> and not <asm/uaccess.h>
Asm is only for when you are doing arch-specific stuff, which we aren't
doing here.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:04:49 +01:00
Greg Kroah-Hartman 2f4e236648 greybus: es1: fix tiny whitespace issues
No trailing spaces or spaces before tabs are allowed.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 20:03:39 +01:00
Greg Kroah-Hartman 6c28f09658 greybus: es1: fix build warning for apb1_log_enable_write
It's "const char __user *buf", not "char __user *buf".

'make check' is your friend.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-03-24 19:57:53 +01:00
Alexandre Bailon 59e3344461 greybus: Dump log from APB1
On AP module (form factor), we don't have access to APBridge JTAG or UART.
But sometime, we still need to get log from APBridge. Add a new request in control endpoint
to get APBridge logs.
Logs can be accessed using debugfs (greybus/apb1_log).

Signed-off-by: Alexandre Bailon <abailon@baylibre.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-24 19:49:47 +01:00
Greg Kroah-Hartman 45a706368d greybus: es1.c: wait until the last possible minute to start the svc messages
When initializing the USB device, we were starting up the svc message
queue before the cport urbs were allocated.  This might not be an issue
for "slower" machines, but not having any allocated urbs for a cport
might be an issue if we were to handle svc messages.

So wait until everything is properly initialized and allocated before
starting the svc urb.

Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-01-23 22:55:57 +08:00
Viresh Kumar 98abb4146e greybus: Remove "gb-" prefix from .c files
Some files are still prefixed with "gb-" with the reasoning that the modules
would be named so, i.e.  gb-*.ko. But this can be done by playing a bit in
Makefile instead and keep uniform naming of .c files.

Lets try it.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Alex Elder <elder@linaro.org>
Signed-off-by: Greg Kroah-Hartman <greg@kroah.com>
2015-01-22 11:27:20 +08:00
Renamed from drivers/staging/greybus/gb-es1.c (Browse further)