brcm2708: rename all patches from raspberrypi git tree to use 950 prefix

Right now all brcm2708 patches are extracted from the non-mainline
raspberrypi/linux git tree. Many of them are hacks and/or are unneeded
in LEDE. Raspberry Pi is getting better and better mainline support so
it would be nice to finally start maintaining patches in a cleaner way:
1) Backport patches accepted in upstream tree
2) Start using upstream drivers
3) Pick only these patches that are needed for more complete support

Handling above tasks requires grouping patches - ideally using the same
prefixes as generic ones. It means we should rename existing patches to
use some high prefix. This will allow e.g. use 0xx for backported code.

Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Stijn Tintel <stijn@linux-ipv6.be>

1 files changed, 58 insertions, 0 deletions

diff --git a/target/linux/brcm2708/patches-4.9/950-0096-vchiq_arm-Access-the-dequeue_pending-flag-locked.patch b/target/linux/brcm2708/patches-4.9/950-0096-vchiq_arm-Access-the-dequeue_pending-flag-locked.patch
new file mode 100644
index 0000000000..71c0e304dd
--- /dev/null
+++ b/target/linux/brcm2708/patches-4.9/950-0096-vchiq_arm-Access-the-dequeue_pending-flag-locked.patch
@@ -0,0 +1,58 @@
+From 64e39b18b8d51eb332a84ef79ed3ce0dd2a76808 Mon Sep 17 00:00:00 2001
+From: Phil Elwell <phil@raspberrypi.org>
+Date: Wed, 23 Mar 2016 14:16:25 +0000
+Subject: [PATCH] vchiq_arm: Access the dequeue_pending flag locked
+
+Reading through this code looking for another problem (now found in userland)
+the use of dequeue_pending outside a lock didn't seem safe.
+
+Signed-off-by: Phil Elwell <phil@raspberrypi.org>
+---
+ .../vc04_services/interface/vchiq_arm/vchiq_arm.c       | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
++++ b/drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c
+@@ -279,6 +279,7 @@ service_callback(VCHIQ_REASON_T reason,
+ 	USER_SERVICE_T *user_service;
+ 	VCHIQ_SERVICE_T *service;
+ 	VCHIQ_INSTANCE_T instance;
++	int skip_completion = 0;
+ 	DEBUG_INITIALISE(g_state.local)
+ 
+ 	DEBUG_TRACE(SERVICE_CALLBACK_LINE);
+@@ -345,9 +346,6 @@ service_callback(VCHIQ_REASON_T reason,
+ 		user_service->msg_queue[user_service->msg_insert &
+ 			(MSG_QUEUE_SIZE - 1)] = header;
+ 		user_service->msg_insert++;
+-		spin_unlock(&msg_queue_spinlock);
+-
+-		up(&user_service->insert_event);
+ 
+ 		/* If there is a thread waiting in DEQUEUE_MESSAGE, or if
+ 		** there is a MESSAGE_AVAILABLE in the completion queue then
+@@ -356,13 +354,22 @@ service_callback(VCHIQ_REASON_T reason,
+ 		if (((user_service->message_available_pos -
+ 			instance->completion_remove) >= 0) ||
+ 			user_service->dequeue_pending) {
+-			DEBUG_TRACE(SERVICE_CALLBACK_LINE);
+ 			user_service->dequeue_pending = 0;
+-			return VCHIQ_SUCCESS;
++			skip_completion = 1;
+ 		}
+ 
++		spin_unlock(&msg_queue_spinlock);
++
++		up(&user_service->insert_event);
++
+ 		header = NULL;
+ 	}
++
++	if (skip_completion) {
++		DEBUG_TRACE(SERVICE_CALLBACK_LINE);
++		return VCHIQ_SUCCESS;
++	}
++
+ 	DEBUG_TRACE(SERVICE_CALLBACK_LINE);
+ 
+ 	return add_completion(instance, reason, header, user_service,