From fce21ae4ccfcee0c28fb18f5507e145fb0b02dec Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= Date: Wed, 22 Mar 2017 21:09:00 +0100 Subject: brcm2708: rename all patches from raspberrypi git tree to use 950 prefix MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Acked-by: Florian Fainelli Acked-by: Stijn Tintel --- ...rm-Access-the-dequeue_pending-flag-locked.patch | 58 ++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 target/linux/brcm2708/patches-4.9/950-0096-vchiq_arm-Access-the-dequeue_pending-flag-locked.patch (limited to 'target/linux/brcm2708/patches-4.9/950-0096-vchiq_arm-Access-the-dequeue_pending-flag-locked.patch') 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 +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 +--- + .../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, -- cgit v1.2.3