[PATCH] staging: rtl8187se: fix checkpatch.pl issues
From: Axel Rasmussen axel.rasmuss...@gmail.com
Date: Mon, 17 Feb 2014 23:50:05 -0700
Subject: [PATCH] staging: rtl8187se: fix checkpatch.pl issues
Reformatted many lines which were too long, replaced various printk
calls with appropriate netdev_* calls, and fixed some spelling errors.
Signed-off-by: Axel Rasmussen axel.rasmuss...@gmail.com
---
drivers/staging/rtl8187se/r8180_core.c | 551 +
1 file changed, 350 insertions(+), 201 deletions(-)
diff --git a/drivers/staging/rtl8187se/r8180_core.c
b/drivers/staging/rtl8187se/r8180_core.c
index 6cafee2..dc1d647 100644
--- a/drivers/staging/rtl8187se/r8180_core.c
+++ b/drivers/staging/rtl8187se/r8180_core.c
@@ -258,7 +258,8 @@ static int proc_get_stats_tx(struct seq_file *m, void *v)
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
unsigned long totalOK;
- totalOK =
priv-stats.txnpokint+priv-stats.txhpokint+priv-stats.txlpokint;
+ totalOK = priv-stats.txnpokint + priv-stats.txhpokint +
+ priv-stats.txlpokint;
seq_printf(m,
TX OK: %lu\n
TX Error: %lu\n
@@ -470,7 +471,8 @@ static short check_nic_enought_desc(struct net_device *dev,
int priority)
struct ieee80211_device *ieee = netdev_priv(dev);
int requiredbyte, required;
- requiredbyte = priv-ieee80211-fts + sizeof(struct
ieee80211_header_data);
+ requiredbyte = priv-ieee80211-fts +
+ sizeof(struct ieee80211_header_data);
if (ieee-current_network.QoS_Enable)
requiredbyte += 2;
@@ -484,7 +486,7 @@ static short check_nic_enought_desc(struct net_device *dev,
int priority)
* between the tail and the head
*/
- return (required+2 get_curr_tx_free_desc(dev, priority));
+ return required+2 get_curr_tx_free_desc(dev, priority);
}
void fix_tx_fifo(struct net_device *dev)
@@ -649,7 +651,7 @@ void rtl8180_set_chan(struct net_device *dev, short ch)
struct r8180_priv *priv = (struct r8180_priv *)ieee80211_priv(dev);
if ((ch 14) || (ch 1)) {
- printk(In %s: Invalid chnanel %d\n, __func__, ch);
+ netdev_err(dev, In %s: Invalid channel %d\n, __func__, ch);
return;
}
@@ -742,43 +744,50 @@ static short alloc_tx_desc_ring(struct net_device *dev,
int bufsize, int count,
switch (addr) {
case TX_MANAGEPRIORITY_RING_ADDR:
- if (-1 == buffer_add((priv-txmapbufs), buf, dma_tmp,
NULL)) {
+ if (-1 == buffer_add((priv-txmapbufs),
+ buf, dma_tmp, NULL)) {
DMESGE(Unable to allocate mem for buffer NP);
return -ENOMEM;
}
break;
case TX_BKPRIORITY_RING_ADDR:
- if (-1 == buffer_add((priv-txbkpbufs), buf, dma_tmp,
NULL)) {
+ if (-1 == buffer_add((priv-txbkpbufs),
+ buf, dma_tmp, NULL)) {
DMESGE(Unable to allocate mem for buffer LP);
return -ENOMEM;
}
break;
case TX_BEPRIORITY_RING_ADDR:
- if (-1 == buffer_add((priv-txbepbufs), buf, dma_tmp,
NULL)) {
+ if (-1 == buffer_add((priv-txbepbufs),
+ buf, dma_tmp, NULL)) {
DMESGE(Unable to allocate mem for buffer NP);
return -ENOMEM;
}
break;
case TX_VIPRIORITY_RING_ADDR:
- if (-1 == buffer_add((priv-txvipbufs), buf, dma_tmp,
NULL)) {
+ if (-1 == buffer_add((priv-txvipbufs),
+ buf, dma_tmp, NULL)) {
DMESGE(Unable to allocate mem for buffer LP);
return -ENOMEM;
}
break;
case TX_VOPRIORITY_RING_ADDR:
- if (-1 == buffer_add((priv-txvopbufs), buf, dma_tmp,
NULL)) {
+ if (-1 == buffer_add((priv-txvopbufs),
+ buf, dma_tmp, NULL)) {
DMESGE(Unable to allocate mem for buffer NP);
return -ENOMEM;
}
break;
case TX_HIGHPRIORITY_RING_ADDR:
- if (-1 == buffer_add((priv-txhpbufs), buf, dma_tmp,
NULL)) {
+ if (-1 == buffer_add((priv-txhpbufs),
+ buf, dma_tmp, NULL)) {
DMESGE(Unable to allocate mem for
Re: [PATCH 19/19] Add in-kernel firmware loading support
On Wed, Feb 19, 2014 at 04:01:59PM -0500, Mark Hounschell wrote: OK, thanks Dan. I'll followup with a new 19/19 patch. It did compile and work with no complaints about the above though. I should have checked that last one better as it is new code added. No worries. This is the review process. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 19/19] [v4] Add in-kernel firmware loading support
On Wed, Feb 19, 2014 at 04:54:15PM -0500, Mark Hounschell wrote: This patch adds in-kernel firmware loading support and removes support for the original userland firmware loading process. Signed-off-by: Mark Hounschell ma...@compro.net Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Still has checkpatch errors. total: 10 errors, 48 warnings, 722 lines checked regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] et131x: fix allocation failures
On Thu, Feb 20, 2014 at 11:03:45AM +0800, Zhao, Gang wrote:
On Wed, 2014-02-19 at 19:43:15 +0800, One Thousand Gnomes wrote:
On Wed, 19 Feb 2014 09:14:19 +0800
Zhao\, Gang gamer...@gmail.com wrote:
Alan, thanks for resending this patch. But it seems you overlooked
something we discussed earlier.
On Mon, 2014-02-17 at 22:13:08 +0800, Alan wrote:
We should check the ring allocations don't fail.
If we get a fail we need to clean up properly. The allocator assumes the
deallocator will be used on failure, but it isn't. Make sure the
right deallocator is always called and add a missing check against
fbr allocation failure.
[v2]: Correct check logic
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/et131x/et131x.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c
b/drivers/staging/et131x/et131x.c
index 6413500..cc600df 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -2124,7 +2124,11 @@ static int et131x_rx_dma_memory_alloc(struct
et131x_adapter *adapter)
/* Alloc memory for the lookup table */
rx_ring-fbr[0] = kmalloc(sizeof(struct fbr_lookup),
GFP_KERNEL);
+if (rx_ring-fbr[0] == NULL)
+return -ENOMEM;
rx_ring-fbr[1] = kmalloc(sizeof(struct fbr_lookup),
GFP_KERNEL);
+if (rx_ring-fbr[1] == NULL)
+return -ENOMEM;
Shouldn't rx_ring-fbr[0] be freed when allocation of rx_ring-fbr[1]
fails ? Or we will leak memory here.
No.. the tx_dma_memory_free and rx_dma_memory_free functions are
designed to handle incomplete set up. They are now called on incomplete
setup and will clean up all the resources.
Yes, you are right. By calling {tx, rx}_dma_memory_free the memory will
be freed.
But I think a comment is needed here, to make this more clear ? Without
proper comment the above code looks a little strange to let one think
it's right. :)
No. We don't need a comment. If people start adding kfree() calls
all over the place without thinking then we are already screwed and no
comment is going to help us.
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Android / binder: Fix broken walk in binder_node_release()
Hi, I've found a bug in the binder driver and I propose the attached patch to fix it. This bug could manifest itself in several situations, here is the one that made me hunt it last week. When an Android device is encrypted, Android starts all the init services of core and main levels, then it asks for the password and checks it trying to mount /data. On success, it kills all the main services, mount /data and restart all the main services. Unfortunately, on restart of those main services we observe : DisplayManager Could not get display information from display manager. DisplayManager android.os.DeadObjectException DisplayManager at android.os.BinderProxy.transact(Native Method) DisplayManager at android.hardware.display.IDisplayManager$Stub$Proxy.getDisplayInfo(IDisplayManager.java:228) DisplayManager at android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:117) DisplayManager at android.hardware.display.DisplayManagerGlobal.getCompatibleDisplay(DisplayManagerGlobal.java:176) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:96) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:74) [...] Which means that the 'display' service is registered into the service_manager but point to a dead object (understand died process). This error is the first one of a chain of missing remote objects causing the death of processes until the system can recovery by itself a few seconds later. The binder driver allows a process to ask a notification when a particular reference die. In that case, the binder driver associate a death object to this reference. When the system_server process died, the file descriptor to the binder driver is automatically released and the binder driver will walk all the references associated to this process to unallocate them. When such a reference has a death object associated it will execute a task to notify the death to the previously register process usually the service_manager process. The bug is that this walk on all the references is broken due to an unfornate refactoring made by the following patch : commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a Author: Mirsal Ennaime mir...@mirsal.fr Date: Tue Mar 12 11:41:59 2013 +0100 which break the loop if the current reference does not have a death object instead of continuing to the next reference. As a consequence all the next references will not be correctly unallocate and no death notification will be sent for them. Thanks, Jérémy -- Sent from my Emacs - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From eaf6a8f28f02220ef2154c76a5345f6aa582e8f7 Mon Sep 17 00:00:00 2001 From: Jeremy Compostella jeremy.composte...@intel.com Date: Tue, 11 Feb 2014 19:40:29 +0100 Subject: [PATCH] Android / binder: Fix broken walk in binder_node_release() Fix an issue introduced by commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a (drivers: android: binder: Move the node release code to a separate function) which move and rework some code from binder_deferred_release to the binder_node_release new function. The rework introduced an unfortunate break of the loop that prevent some death notifications to be sent. Signed-off-by: Jeremy Compostella jeremy.composte...@intel.com --- drivers/staging/android/binder.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c index eaec1da..1432d95 100644 --- a/drivers/staging/android/binder.c +++ b/drivers/staging/android/binder.c @@ -2904,7 +2904,7 @@ static int binder_node_release(struct binder_node *node, int refs) refs++; if (!ref-death) - goto out; + continue; death++; @@ -2917,7 +2917,6 @@ static int binder_node_release(struct binder_node *node, int refs) BUG(); } -out: binder_debug(BINDER_DEBUG_DEAD_BINDER, node %d now dead, refs %d, death %d\n, node-debug_id, refs, death); -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Android / binder: Fix broken walk in binder_node_release()
Hi, I've found a bug in the binder driver and I propose the attached patch to fix it. This bug could manifest itself in several situations, here is the one that made me hunt it last week. When an Android device is encrypted, Android starts all the init services of core and main levels, then it asks for the password and checks it trying to mount /data. On success, it kills all the main services, mount /data and restart all the main services. Unfortunately, on restart of those main services we observe : DisplayManager Could not get display information from display manager. DisplayManager android.os.DeadObjectException DisplayManager at android.os.BinderProxy.transact(Native Method) DisplayManager at android.hardware.display.IDisplayManager$Stub$Proxy.getDisplayInfo(IDisplayManager.java:228) DisplayManager at android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:117) DisplayManager at android.hardware.display.DisplayManagerGlobal.getCompatibleDisplay(DisplayManagerGlobal.java:176) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:96) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:74) [...] Which means that the 'display' service is registered into the service_manager but point to a dead object (understand died process). This error is the first one of a chain of missing remote objects causing the death of processes until the system can recovery by itself a few seconds later. The binder driver allows a process to ask a notification when a particular reference die. In that case, the binder driver associate a death object to this reference. When the system_server process died, the file descriptor to the binder driver is automatically released and the binder driver will walk all the references associated to this process to unallocate them. When such a reference has a death object associated it will execute a task to notify the death to the previously register process usually the service_manager process. The bug is that this walk on all the references is broken due to an unfornate refactoring made by the following patch : commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a Author: Mirsal Ennaime mir...@mirsal.fr Date: Tue Mar 12 11:41:59 2013 +0100 which break the loop if the current reference does not have a death object instead of continuing to the next reference. As a consequence all the next references will not be correctly unallocate and no death notification will be sent for them. Thanks, Jérémy -- Sent from my Emacs - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From eaf6a8f28f02220ef2154c76a5345f6aa582e8f7 Mon Sep 17 00:00:00 2001 From: Jeremy Compostella jeremy.composte...@intel.com Date: Tue, 11 Feb 2014 19:40:29 +0100 Subject: [PATCH] Android / binder: Fix broken walk in binder_node_release() Fix an issue introduced by commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a (drivers: android: binder: Move the node release code to a separate function) which move and rework some code from binder_deferred_release to the binder_node_release new function. The rework introduced an unfortunate break of the loop that prevent some death notifications to be sent. Signed-off-by: Jeremy Compostella jeremy.composte...@intel.com --- drivers/staging/android/binder.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c index eaec1da..1432d95 100644 --- a/drivers/staging/android/binder.c +++ b/drivers/staging/android/binder.c @@ -2904,7 +2904,7 @@ static int binder_node_release(struct binder_node *node, int refs) refs++; if (!ref-death) - goto out; + continue; death++; @@ -2917,7 +2917,6 @@ static int binder_node_release(struct binder_node *node, int refs) BUG(); } -out: binder_debug(BINDER_DEBUG_DEAD_BINDER, node %d now dead, refs %d, death %d\n, node-debug_id, refs, death); -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Android / binder: Fix broken walk in binder_node_release()
Yeah. Sorry about that. Your fix is correct. Is there any way you could resend it with the explanation from the email in the changelog? Remove the confidential material footer because those are not allowed on the email list and conflict with the GPL. Can you use git send-email to send the patch inline? For bug fixes like this then we try to be more flexible about dealing with patches, so Greg may decide to take it as-is. But if you are able to send it in the normal way, that would help us. regards, dan carpenter PS: Sorry for top posting. I just wanted to include the entire email because Mirsal wasn't CC'd on the original. On Thu, Feb 20, 2014 at 11:35:04AM +0100, Compostella, Jeremy wrote: Hi, I've found a bug in the binder driver and I propose the attached patch to fix it. This bug could manifest itself in several situations, here is the one that made me hunt it last week. When an Android device is encrypted, Android starts all the init services of core and main levels, then it asks for the password and checks it trying to mount /data. On success, it kills all the main services, mount /data and restart all the main services. Unfortunately, on restart of those main services we observe : DisplayManager Could not get display information from display manager. DisplayManager android.os.DeadObjectException DisplayManager at android.os.BinderProxy.transact(Native Method) DisplayManager at android.hardware.display.IDisplayManager$Stub$Proxy.getDisplayInfo(IDisplayManager.java:228) DisplayManager at android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:117) DisplayManager at android.hardware.display.DisplayManagerGlobal.getCompatibleDisplay(DisplayManagerGlobal.java:176) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:96) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:74) [...] Which means that the 'display' service is registered into the service_manager but point to a dead object (understand died process). This error is the first one of a chain of missing remote objects causing the death of processes until the system can recovery by itself a few seconds later. The binder driver allows a process to ask a notification when a particular reference die. In that case, the binder driver associate a death object to this reference. When the system_server process died, the file descriptor to the binder driver is automatically released and the binder driver will walk all the references associated to this process to unallocate them. When such a reference has a death object associated it will execute a task to notify the death to the previously register process usually the service_manager process. The bug is that this walk on all the references is broken due to an unfornate refactoring made by the following patch : commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a Author: Mirsal Ennaime mir...@mirsal.fr Date: Tue Mar 12 11:41:59 2013 +0100 which break the loop if the current reference does not have a death object instead of continuing to the next reference. As a consequence all the next references will not be correctly unallocate and no death notification will be sent for them. Thanks, Jérémy -- Sent from my Emacs - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From eaf6a8f28f02220ef2154c76a5345f6aa582e8f7 Mon Sep 17 00:00:00 2001 From: Jeremy Compostella jeremy.composte...@intel.com Date: Tue, 11 Feb 2014 19:40:29 +0100 Subject: [PATCH] Android / binder: Fix broken walk in binder_node_release() Fix an issue introduced by commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a (drivers: android: binder: Move the node release code to a separate function) which move and rework some code from binder_deferred_release to the binder_node_release new function. The rework introduced an unfortunate break of the loop that prevent some death notifications to be sent. Signed-off-by: Jeremy Compostella jeremy.composte...@intel.com --- drivers/staging/android/binder.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c index eaec1da..1432d95 100644 --- a/drivers/staging/android/binder.c +++ b/drivers/staging/android/binder.c
Re: [PATCH][RESEND] [media] davinci: vpfe: remove deprecated IRQF_DISABLED
Hi Michael,
What's the status of this patch ? Do expect Prabhakar to pick it up, or do you
plan to push all your IRQF_DISABLED removal patches in one go ?
On Monday 09 December 2013 11:16:22 Michael Opdenacker wrote:
This patch proposes to remove the use of the IRQF_DISABLED flag
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com
Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com
---
drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c index
d8ce20d2fbda..cda8388cbb89 100644
--- a/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
+++ b/drivers/staging/media/davinci_vpfe/vpfe_mc_capture.c
@@ -298,7 +298,7 @@ static int vpfe_attach_irq(struct vpfe_device *vpfe_dev)
{
int ret = 0;
- ret = request_irq(vpfe_dev-ccdc_irq0, vpfe_isr, IRQF_DISABLED,
+ ret = request_irq(vpfe_dev-ccdc_irq0, vpfe_isr, 0,
vpfe_capture0, vpfe_dev);
if (ret 0) {
v4l2_err(vpfe_dev-v4l2_dev,
@@ -306,7 +306,7 @@ static int vpfe_attach_irq(struct vpfe_device *vpfe_dev)
return ret;
}
- ret = request_irq(vpfe_dev-ccdc_irq1, vpfe_vdint1_isr, IRQF_DISABLED,
+ ret = request_irq(vpfe_dev-ccdc_irq1, vpfe_vdint1_isr, 0,
vpfe_capture1, vpfe_dev);
if (ret 0) {
v4l2_err(vpfe_dev-v4l2_dev,
@@ -316,7 +316,7 @@ static int vpfe_attach_irq(struct vpfe_device *vpfe_dev)
}
ret = request_irq(vpfe_dev-imp_dma_irq, vpfe_imp_dma_isr,
- IRQF_DISABLED, Imp_Sdram_Irq, vpfe_dev);
+ 0, Imp_Sdram_Irq, vpfe_dev);
if (ret 0) {
v4l2_err(vpfe_dev-v4l2_dev,
Error: requesting IMP IRQ interrupt\n);
--
Regards,
Laurent Pinchart
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Android / binder: Fix broken walk in binder_node_release()
From: Compostella, Jeremy jeremy.composte...@intel.com This bug can manifest itself in several situations, here is the one that made me hunt it last week: When an Android device is encrypted, Android starts all the init services of core and main levels, then it asks for the password and checks it trying to mount /data. On success, it kills all the main services, mount /data and restart all the main services. Unfortunately, on restart of those main services we observe : DisplayManager Could not get display information from display manager. DisplayManager android.os.DeadObjectException DisplayManager at android.os.BinderProxy.transact(Native Method) DisplayManager at android.hardware.display.IDisplayManager$Stub$Proxy.getDisplayInfo(IDisplayManager.java:228) DisplayManager at android.hardware.display.DisplayManagerGlobal.getDisplayInfo(DisplayManagerGlobal.java:117) DisplayManager at android.hardware.display.DisplayManagerGlobal.getCompatibleDisplay(DisplayManagerGlobal.java:176) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:96) DisplayManager at android.app.ResourcesManager.getDisplayMetricsLocked(ResourcesManager.java:74) [...] Which means that the 'display' service is registered into the service_manager but point to a dead object (understand died process). This error is the first one of a chain of missing remote objects causing the death of processes until the system can recovery by itself a few seconds later. The binder driver allows a process to ask a notification when a particular reference die. In that case, the binder driver associate a death object to this reference. When the system_server process died, the file descriptor to the binder driver is automatically released and the binder driver will walk all the references associated to this process to unallocate them. When such a reference has a death object associated it will execute a task to notify the death to the previously register process usually the service_manager process. The bug is that this walk on all the references is broken due to an unfornate refactoring made by the following patch : commit 008fa749e0fe5b2fffd20b7fe4891bb80d072c6a Author: Mirsal Ennaime mir...@mirsal.fr Date: Tue Mar 12 11:41:59 2013 +0100 which break the loop if the current reference does not have a death object instead of continuing to the next reference. As a consequence all the next references will not be correctly unallocate and no death notification will be sent for them. Signed-off-by: Jeremy Compostella jeremy.composte...@intel.com --- drivers/staging/android/binder.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/staging/android/binder.c b/drivers/staging/android/binder.c index eaec1da..1432d95 100644 --- a/drivers/staging/android/binder.c +++ b/drivers/staging/android/binder.c @@ -2904,7 +2904,7 @@ static int binder_node_release(struct binder_node *node, int refs) refs++; if (!ref-death) - goto out; + continue; death++; @@ -2917,7 +2917,6 @@ static int binder_node_release(struct binder_node *node, int refs) BUG(); } -out: binder_debug(BINDER_DEBUG_DEAD_BINDER, node %d now dead, refs %d, death %d\n, node-debug_id, refs, death); -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Android / binder: Fix broken walk in binder_node_release()
Fantastic. Thanks. Reviewed-by: Dan Carpenter dan.carpen...@oracle.com regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] [v5] Add in-kernel firmware loading support
This patch adds in-kernel firmware loading support and removes
support for the original userland firmware loading process.
Signed-off-by: Mark Hounschell ma...@compro.net
---
drivers/staging/dgap/dgap.c | 525 +++-
1 file changed, 323 insertions(+), 202 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 6f07e27..21af5fa 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -29,6 +29,32 @@
*
*/
+/*
+ * In the original out of kernel Digi dgap driver, firmware
+ * loading was done via user land to driver handshaking.
+ *
+ * For cards that support a concentrator (port expander),
+ * I believe the concentrator its self told the card which
+ * concentrator is actually attached and then that info
+ * was used to tell user land which concentrator firmware
+ * image was to be downloaded. I think even the BIOS or
+ * FEP images required could change with the connection
+ * of a particular concentrator.
+ *
+ * Since I have no access to any of these cards or
+ * concentrators, I cannot put the correct concentrator
+ * firmware file names into the firmware_info structure
+ * as is now done for the BIOS and FEP images.
+ *
+ * I think, but am not certain, that the cards supporting
+ * concentrators will function without them. So support
+ * of these cards has been left in this driver.
+ *
+ * In order to fully support those cards, they would
+ * either have to be acquired for dissection or maybe
+ * Digi International could provide some assistance.
+ */
+#undef DIGI_CONCENTRATORS_SUPPORTED
#include linux/kernel.h
#include linux/module.h
@@ -48,6 +74,7 @@
#include linux/string.h
#include linux/device.h
#include linux/kdev_t.h
+#include linux/firmware.h
#include dgap.h
@@ -191,11 +218,18 @@ static intdgap_ms_sleep(ulong ms);
static char*dgap_ioctl_name(int cmd);
static voiddgap_do_bios_load(struct board_t *brd, uchar __user *ubios, int
len);
static voiddgap_do_fep_load(struct board_t *brd, uchar __user *ufep, int
len);
+#ifdef DIGI_CONCENTRATORS_SUPPORTED
static voiddgap_do_conc_load(struct board_t *brd, uchar *uaddr, int len);
-static voiddgap_do_config_load(uchar __user *uaddr, int len);
-static int dgap_after_config_loaded(void);
+#endif
+static int dgap_after_config_loaded(int board);
static int dgap_finalize_board_init(struct board_t *brd);
+static void dgap_get_vpd(struct board_t *brd);
+static void dgap_do_reset_board(struct board_t *brd);
+static void dgap_do_wait_for_bios(struct board_t *brd);
+static void dgap_do_wait_for_fep(struct board_t *brd);
+static void dgap_sysfs_create(struct board_t *brd);
+static int dgap_firmware_load(struct pci_dev *pdev, int card_type);
/* Driver load/unload functions */
intdgap_init_module(void);
@@ -249,6 +283,24 @@ static ulong dgap_poll_time;
/* Time of next poll */
static uintdgap_poll_stop; /* Used to tell
poller to stop */
static struct timer_list dgap_poll_timer;
+/*
+ SUPPORTED PRODUCTS
+
+ Card Model Number of Ports Interface
+
+ Acceleport Xem 4 - 64 (EIA232 EIA422)
+ Acceleport Xr4 8 (EIA232)
+ Acceleport Xr 9204 8 (EIA232)
+ Acceleport C/X 8 - 128 (EIA232)
+ Acceleport EPC/X 8 - 224 (EIA232)
+ Acceleport Xr/4224 8 (EIA422)
+ Acceleport 2r/9202 (EIA232)
+ Acceleport 4r/9204 (EIA232)
+ Acceleport 8r/9208 (EIA232)
+
+ IBM 8-Port Asynchronous PCI Adapter (EIA232)
+ IBM 128-Port Asynchronous PCI Adapter(EIA232 EIA422)
+*/
static struct pci_device_id dgap_pci_tbl[] = {
{ DIGI_VID, PCI_DEVICE_XEM_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
0 },
@@ -308,6 +360,35 @@ static struct pci_driver dgap_driver = {
.remove = dgap_remove_one,
};
+struct firmware_info {
+ uchar *conf_name; /* dgap.conf */
+ uchar *bios_name; /* BIOS filename */
+ uchar *fep_name;/* FEP filename */
+ uchar *con_name;/* Concentrator filename FIXME*/
+ int num;/* sequence number */
+};
+
+/*
+ * Firmware - BIOS, FEP, and CONC filenames
+ */
+static struct firmware_info fw_info[] = {
+ { dgap/dgap.conf, dgap/sxbios.bin, dgap/sxfep.bin, 0, 0 },
+ { dgap/dgap.conf, dgap/cxpbios.bin, dgap/cxpfep.bin, 0, 1 },
+ { dgap/dgap.conf, dgap/cxpbios.bin, dgap/cxpfep.bin, 0, 2 },
+ { dgap/dgap.conf, dgap/pcibios.bin, dgap/pcifep.bin, 0, 3 },
+ {
[PATCH] [v5] Add in-kernel firmware loading support
This patch adds in-kernel firmware loading support and removes
support for the original userland firmware loading process.
Signed-off-by: Mark Hounschell ma...@compro.net
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
drivers/staging/dgap/dgap.c | 525 +++-
1 file changed, 323 insertions(+), 202 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index 6f07e27..21af5fa 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -29,6 +29,32 @@
*
*/
+/*
+ * In the original out of kernel Digi dgap driver, firmware
+ * loading was done via user land to driver handshaking.
+ *
+ * For cards that support a concentrator (port expander),
+ * I believe the concentrator its self told the card which
+ * concentrator is actually attached and then that info
+ * was used to tell user land which concentrator firmware
+ * image was to be downloaded. I think even the BIOS or
+ * FEP images required could change with the connection
+ * of a particular concentrator.
+ *
+ * Since I have no access to any of these cards or
+ * concentrators, I cannot put the correct concentrator
+ * firmware file names into the firmware_info structure
+ * as is now done for the BIOS and FEP images.
+ *
+ * I think, but am not certain, that the cards supporting
+ * concentrators will function without them. So support
+ * of these cards has been left in this driver.
+ *
+ * In order to fully support those cards, they would
+ * either have to be acquired for dissection or maybe
+ * Digi International could provide some assistance.
+ */
+#undef DIGI_CONCENTRATORS_SUPPORTED
#include linux/kernel.h
#include linux/module.h
@@ -48,6 +74,7 @@
#include linux/string.h
#include linux/device.h
#include linux/kdev_t.h
+#include linux/firmware.h
#include dgap.h
@@ -191,11 +218,18 @@ static intdgap_ms_sleep(ulong ms);
static char*dgap_ioctl_name(int cmd);
static voiddgap_do_bios_load(struct board_t *brd, uchar __user *ubios, int
len);
static voiddgap_do_fep_load(struct board_t *brd, uchar __user *ufep, int
len);
+#ifdef DIGI_CONCENTRATORS_SUPPORTED
static voiddgap_do_conc_load(struct board_t *brd, uchar *uaddr, int len);
-static voiddgap_do_config_load(uchar __user *uaddr, int len);
-static int dgap_after_config_loaded(void);
+#endif
+static int dgap_after_config_loaded(int board);
static int dgap_finalize_board_init(struct board_t *brd);
+static void dgap_get_vpd(struct board_t *brd);
+static void dgap_do_reset_board(struct board_t *brd);
+static void dgap_do_wait_for_bios(struct board_t *brd);
+static void dgap_do_wait_for_fep(struct board_t *brd);
+static void dgap_sysfs_create(struct board_t *brd);
+static int dgap_firmware_load(struct pci_dev *pdev, int card_type);
/* Driver load/unload functions */
intdgap_init_module(void);
@@ -249,6 +283,24 @@ static ulong dgap_poll_time;
/* Time of next poll */
static uintdgap_poll_stop; /* Used to tell
poller to stop */
static struct timer_list dgap_poll_timer;
+/*
+ SUPPORTED PRODUCTS
+
+ Card Model Number of Ports Interface
+
+ Acceleport Xem 4 - 64 (EIA232 EIA422)
+ Acceleport Xr4 8 (EIA232)
+ Acceleport Xr 9204 8 (EIA232)
+ Acceleport C/X 8 - 128 (EIA232)
+ Acceleport EPC/X 8 - 224 (EIA232)
+ Acceleport Xr/4224 8 (EIA422)
+ Acceleport 2r/9202 (EIA232)
+ Acceleport 4r/9204 (EIA232)
+ Acceleport 8r/9208 (EIA232)
+
+ IBM 8-Port Asynchronous PCI Adapter (EIA232)
+ IBM 128-Port Asynchronous PCI Adapter(EIA232 EIA422)
+*/
static struct pci_device_id dgap_pci_tbl[] = {
{ DIGI_VID, PCI_DEVICE_XEM_DID, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
0 },
@@ -308,6 +360,35 @@ static struct pci_driver dgap_driver = {
.remove = dgap_remove_one,
};
+struct firmware_info {
+ uchar *conf_name; /* dgap.conf */
+ uchar *bios_name; /* BIOS filename */
+ uchar *fep_name;/* FEP filename */
+ uchar *con_name;/* Concentrator filename FIXME*/
+ int num;/* sequence number */
+};
+
+/*
+ * Firmware - BIOS, FEP, and CONC filenames
+ */
+static struct firmware_info fw_info[] = {
+ { dgap/dgap.conf, dgap/sxbios.bin, dgap/sxfep.bin, 0, 0 },
+ { dgap/dgap.conf, dgap/cxpbios.bin, dgap/cxpfep.bin, 0, 1 },
+ { dgap/dgap.conf, dgap/cxpbios.bin, dgap/cxpfep.bin, 0, 2 },
+ { dgap/dgap.conf,
Re: [PATCH] [v5] Add in-kernel firmware loading support
Much better. Now it looks like proper kernel code! regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
Fix a bug in the resource walking code.
Signed-off-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/hv/vmbus_drv.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
index b37c91b..2352ae48 100644
--- a/drivers/hv/vmbus_drv.c
+++ b/drivers/hv/vmbus_drv.c
@@ -899,10 +899,12 @@ static acpi_status vmbus_walk_resources(struct
acpi_resource *res, void *ctx)
switch (res-type) {
case ACPI_RESOURCE_TYPE_IRQ:
irq = res-data.irq.interrupts[0];
+ break;
case ACPI_RESOURCE_TYPE_ADDRESS64:
hyperv_mmio_start = res-data.address64.minimum;
hyperv_mmio_size = res-data.address64.address_length;
+ break;
}
return AE_OK;
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
On Thu, Feb 20, 2014 at 03:45:12PM -0800, K. Y. Srinivasan wrote: Fix a bug in the resource walking code. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/vmbus_drv.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Is this for 3.14-final or 3.15? I ask this every time, someday you will let me know ahead of time... ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
On Thu, Feb 20, 2014 at 03:45:12PM -0800, K. Y. Srinivasan wrote: Fix a bug in the resource walking code. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/vmbus_drv.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Fails to apply to my char-misc-next branch (if you want it in 3.14-final, that's where it belongs...): checking file drivers/hv/vmbus_drv.c Hunk #1 FAILED at 899. 1 out of 1 hunk FAILED ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
-Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, February 20, 2014 3:47 PM To: KY Srinivasan Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources On Thu, Feb 20, 2014 at 03:45:12PM -0800, K. Y. Srinivasan wrote: Fix a bug in the resource walking code. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/vmbus_drv.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Fails to apply to my char-misc-next branch (if you want it in 3.14-final, that's where it belongs...): checking file drivers/hv/vmbus_drv.c Hunk #1 FAILED at 899. 1 out of 1 hunk FAILED I will rebase it send it to you shortly. Thanks, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
-Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, February 20, 2014 3:47 PM To: KY Srinivasan Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources On Thu, Feb 20, 2014 at 03:45:12PM -0800, K. Y. Srinivasan wrote: Fix a bug in the resource walking code. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/vmbus_drv.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Fails to apply to my char-misc-next branch (if you want it in 3.14-final, that's where it belongs...): checking file drivers/hv/vmbus_drv.c Hunk #1 FAILED at 899. 1 out of 1 hunk FAILED Greg, This patch is based on this commit: commit 90f3453585479d5beb75058da46eb573ced0e6ac Signed-off-by: K. Y. Srinivasan k...@microsoft.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org I just got your char-misc-next branch and it does not have the needed commit. Regards, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
-Original Message- From: driverdev-devel-boun...@linuxdriverproject.org [mailto:driverdev-devel- boun...@linuxdriverproject.org] On Behalf Of KY Srinivasan Sent: Thursday, February 20, 2014 4:19 PM To: Greg KH Cc: de...@linuxdriverproject.org; linux-ker...@vger.kernel.org Subject: RE: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, February 20, 2014 3:47 PM To: KY Srinivasan Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources On Thu, Feb 20, 2014 at 03:45:12PM -0800, K. Y. Srinivasan wrote: Fix a bug in the resource walking code. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/vmbus_drv.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Fails to apply to my char-misc-next branch (if you want it in 3.14-final, that's where it belongs...): checking file drivers/hv/vmbus_drv.c Hunk #1 FAILED at 899. 1 out of 1 hunk FAILED Greg, This patch is based on this commit: commit 90f3453585479d5beb75058da46eb573ced0e6ac Signed-off-by: K. Y. Srinivasan k...@microsoft.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org I just got your char-misc-next branch and it does not have the needed commit. Greg, The commit referenced above was checked into your char-misc.git tree on the 7th of Feb. Can you check in this patch to the same tree. I could resend this patch. Regards, K. Y Regards, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] et131x: fix allocation failures
On Thu, 2014-02-20 at 17:03:39 +0800, Dan Carpenter wrote:
On Thu, Feb 20, 2014 at 11:03:45AM +0800, Zhao, Gang wrote:
On Wed, 2014-02-19 at 19:43:15 +0800, One Thousand Gnomes wrote:
On Wed, 19 Feb 2014 09:14:19 +0800
Zhao\, Gang gamer...@gmail.com wrote:
Alan, thanks for resending this patch. But it seems you overlooked
something we discussed earlier.
On Mon, 2014-02-17 at 22:13:08 +0800, Alan wrote:
We should check the ring allocations don't fail.
If we get a fail we need to clean up properly. The allocator assumes the
deallocator will be used on failure, but it isn't. Make sure the
right deallocator is always called and add a missing check against
fbr allocation failure.
[v2]: Correct check logic
Signed-off-by: Alan Cox a...@linux.intel.com
---
drivers/staging/et131x/et131x.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/et131x/et131x.c
b/drivers/staging/et131x/et131x.c
index 6413500..cc600df 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -2124,7 +2124,11 @@ static int et131x_rx_dma_memory_alloc(struct
et131x_adapter *adapter)
/* Alloc memory for the lookup table */
rx_ring-fbr[0] = kmalloc(sizeof(struct fbr_lookup),
GFP_KERNEL);
+ if (rx_ring-fbr[0] == NULL)
+ return -ENOMEM;
rx_ring-fbr[1] = kmalloc(sizeof(struct fbr_lookup),
GFP_KERNEL);
+ if (rx_ring-fbr[1] == NULL)
+ return -ENOMEM;
Shouldn't rx_ring-fbr[0] be freed when allocation of rx_ring-fbr[1]
fails ? Or we will leak memory here.
No.. the tx_dma_memory_free and rx_dma_memory_free functions are
designed to handle incomplete set up. They are now called on incomplete
setup and will clean up all the resources.
Yes, you are right. By calling {tx, rx}_dma_memory_free the memory will
be freed.
But I think a comment is needed here, to make this more clear ? Without
proper comment the above code looks a little strange to let one think
it's right. :)
No. We don't need a comment. If people start adding kfree() calls
all over the place without thinking then we are already screwed and no
comment is going to help us.
Hi, I thought this a little more.
AFAIK, most functions deal with this fail in the middle allocation
failure themselves. Honestly, relying on the caller to handle this type
of error seems a bad idea to me.
Code reviewer has to check *every* caller of this function to make sure
whether rx_ring-fbr[0] is leaked or not when allocation of
rx_ring-fbr[1] fails.(By examing if the caller called the correct
freeing function when this function returns error) This is just a waste
of time. By freeing rx_ring-fbr[0] in this function the above type of
memory leak can't be happen at the beginning.
So now my suggestion is freeing rx_ring-fbr[0] *and* set the pointer
rx_ring-fbr[0] to NULL when allocation of rx_ring-fbr[1] fails *in*
this function. The freeing function which can handle fail in the
middle allocation failure surely can handle this situation correctly,
isn't it ?
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
-Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, February 20, 2014 6:21 PM To: KY Srinivasan Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources On Fri, Feb 21, 2014 at 12:19:22AM +, KY Srinivasan wrote: -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Thursday, February 20, 2014 3:47 PM To: KY Srinivasan Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org Subject: Re: [PATCH 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources On Thu, Feb 20, 2014 at 03:45:12PM -0800, K. Y. Srinivasan wrote: Fix a bug in the resource walking code. Signed-off-by: K. Y. Srinivasan k...@microsoft.com --- drivers/hv/vmbus_drv.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) Fails to apply to my char-misc-next branch (if you want it in 3.14-final, that's where it belongs...): checking file drivers/hv/vmbus_drv.c Hunk #1 FAILED at 899. 1 out of 1 hunk FAILED Greg, This patch is based on this commit: commit 90f3453585479d5beb75058da46eb573ced0e6ac Signed-off-by: K. Y. Srinivasan k...@microsoft.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org I just got your char-misc-next branch and it does not have the needed commit. Then I guess this isn't 3.14-final material, right? Please resend it when you have determined which branch it should go into, it's out of my queue now. Thanks Greg, I will resend the patch. Please apply it to char-misc.git tree. Regards, K. Y ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2,0/2] Re-sending two patches for hyperv_fb
They were sent out during tree closing, I'm re-sending them now. --- v2: Updated the variable type gen2vm to int, because efi_enabled() returns int. Haiyang Zhang (2): hyperv_fb: Add screen refresh after pause/resume operation hyperv_fb: Add support for Gen2 VM drivers/video/hyperv_fb.c | 70 - 1 files changed, 50 insertions(+), 20 deletions(-) -- 1.7.4.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2,2/2] hyperv_fb: Add support for Gen2 VM
This patch enables Hyper-V FB driver to run on Gen2 VM.
The Gen2 VM provides MMIO area for synthetic video from ACPI module,
which is exported by vmbus. The generic video is provided by UEFI. PCI
video in Gen1 is no longer available.
To support synthetic video on Hyper-V Gen2 VM, this patch updated
code related to the changes above.
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Reviewed-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/video/hyperv_fb.c | 60 ++--
1 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index bbcc8c0..5db1f20 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -42,6 +42,7 @@
#include linux/completion.h
#include linux/fb.h
#include linux/pci.h
+#include linux/efi.h
#include linux/hyperv.h
@@ -461,13 +462,13 @@ static int synthvid_connect_vsp(struct hv_device *hdev)
goto error;
}
- if (par-synthvid_version == SYNTHVID_VERSION_WIN7) {
+ if (par-synthvid_version == SYNTHVID_VERSION_WIN7)
screen_depth = SYNTHVID_DEPTH_WIN7;
- screen_fb_size = SYNTHVID_FB_SIZE_WIN7;
- } else {
+ else
screen_depth = SYNTHVID_DEPTH_WIN8;
- screen_fb_size = SYNTHVID_FB_SIZE_WIN8;
- }
+
+ screen_fb_size = hdev-channel-offermsg.offer.
+ mmio_megabytes * 1024 * 1024;
return 0;
@@ -635,22 +636,33 @@ static void hvfb_get_option(struct fb_info *info)
/* Get framebuffer memory from Hyper-V video pci space */
static int hvfb_getmem(struct fb_info *info)
{
- struct pci_dev *pdev;
+ struct pci_dev *pdev = NULL;
ulong fb_phys;
void __iomem *fb_virt;
+ int gen2vm = efi_enabled(EFI_BOOT);
- pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
+ if (gen2vm) {
+ if (!hyperv_mmio_start || hyperv_mmio_size screen_fb_size) {
+ pr_err(Unable to find ACPI MMIO area\n);
+ return -ENODEV;
+ }
+
+ fb_phys = hyperv_mmio_start;
+ } else {
+ pdev = pci_get_device(PCI_VENDOR_ID_MICROSOFT,
PCI_DEVICE_ID_HYPERV_VIDEO, NULL);
- if (!pdev) {
- pr_err(Unable to find PCI Hyper-V video\n);
- return -ENODEV;
- }
+ if (!pdev) {
+ pr_err(Unable to find PCI Hyper-V video\n);
+ return -ENODEV;
+ }
- if (!(pci_resource_flags(pdev, 0) IORESOURCE_MEM) ||
- pci_resource_len(pdev, 0) screen_fb_size)
- goto err1;
+ if (!(pci_resource_flags(pdev, 0) IORESOURCE_MEM) ||
+ pci_resource_len(pdev, 0) screen_fb_size)
+ goto err1;
+
+ fb_phys = pci_resource_end(pdev, 0) - screen_fb_size + 1;
+ }
- fb_phys = pci_resource_end(pdev, 0) - screen_fb_size + 1;
if (!request_mem_region(fb_phys, screen_fb_size, KBUILD_MODNAME))
goto err1;
@@ -662,14 +674,22 @@ static int hvfb_getmem(struct fb_info *info)
if (!info-apertures)
goto err3;
- info-apertures-ranges[0].base = pci_resource_start(pdev, 0);
- info-apertures-ranges[0].size = pci_resource_len(pdev, 0);
+ if (gen2vm) {
+ info-apertures-ranges[0].base = screen_info.lfb_base;
+ info-apertures-ranges[0].size = screen_info.lfb_size;
+ } else {
+ info-apertures-ranges[0].base = pci_resource_start(pdev, 0);
+ info-apertures-ranges[0].size = pci_resource_len(pdev, 0);
+ }
+
info-fix.smem_start = fb_phys;
info-fix.smem_len = screen_fb_size;
info-screen_base = fb_virt;
info-screen_size = screen_fb_size;
- pci_dev_put(pdev);
+ if (!gen2vm)
+ pci_dev_put(pdev);
+
return 0;
err3:
@@ -677,7 +697,9 @@ err3:
err2:
release_mem_region(fb_phys, screen_fb_size);
err1:
- pci_dev_put(pdev);
+ if (!gen2vm)
+ pci_dev_put(pdev);
+
return -ENOMEM;
}
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH v2, 1/2] hyperv_fb: Add screen refresh after pause/resume operation
This is necessary because after VM is pause/resumed, some portion of
the screen may need refresh.
Signed-off-by: Haiyang Zhang haiya...@microsoft.com
Reviewed-by: K. Y. Srinivasan k...@microsoft.com
---
drivers/video/hyperv_fb.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/video/hyperv_fb.c b/drivers/video/hyperv_fb.c
index 130708f..bbcc8c0 100644
--- a/drivers/video/hyperv_fb.c
+++ b/drivers/video/hyperv_fb.c
@@ -218,6 +218,7 @@ struct hvfb_par {
struct delayed_work dwork;
bool update;
+ bool xrefresh;
u32 pseudo_palette[16];
u8 init_buf[MAX_VMBUS_PKT_SIZE];
@@ -369,7 +370,7 @@ static void synthvid_recv_sub(struct hv_device *hdev)
synthvid_send_situ(hdev);
}
- par-update = msg-feature_chg.is_dirt_needed;
+ par-xrefresh = par-update = msg-feature_chg.is_dirt_needed;
if (par-update)
schedule_delayed_work(par-dwork, HVFB_UPDATE_DELAY);
}
@@ -522,6 +523,13 @@ static void hvfb_update_work(struct work_struct *w)
{
struct hvfb_par *par = container_of(w, struct hvfb_par, dwork.work);
struct fb_info *info = par-info;
+ char *argv[] = {/usr/bin/xrefresh, -display, :0.0, NULL};
+ char *envp[] = {HOME=/, PATH=/sbin:/usr/sbin:/bin:/usr/bin, NULL };
+
+ if (par-xrefresh) {
+ par-xrefresh = false;
+ call_usermodehelper(argv[0], argv, envp, UMH_NO_WAIT);
+ }
if (par-fb_ready)
synthvid_update(info);
--
1.7.4.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: et131x: let the freeing of memory more reasonable in error path
The original code relies on the caller to deal with fail in the
middle memory allocation failure in et131x_rx_dma_memory_alloc(). The
relying on the caller to handle this memory allocation failure could
cause some inconveniences:
Code reviewer has to check the caller of this function to make sure
whether rx_ring-fbr[0] is leaked or not when allocation of
rx_ring-fbr[1] fails(By examing if the caller called the correct
freeing function when this function returns error). This unnecessary
check can be avoided. By freeing rx_ring-fbr[0] in this function the
above type of memory leak can't happen at the beginning. This also
makes the code a little more readable.
The changes is to free rx_ring-fbr[0] and set the pointer
rx_ring-fbr[0] to NULL when allocation of rx_ring-fbr[1] fails in
et131x_rx_dma_memory_alloc(). The freeing function
rx_dma_memory_free() can handle this situation correctly.
Signed-off-by: Zhao, Gang gamer...@gmail.com
---
I didn't notice Alan's et131x patch on the list have been applied.
Now combine my comments on that patch to a new patch for review.
drivers/staging/et131x/et131x.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/et131x/et131x.c b/drivers/staging/et131x/et131x.c
index 29895a4..cc9803a 100644
--- a/drivers/staging/et131x/et131x.c
+++ b/drivers/staging/et131x/et131x.c
@@ -2123,8 +2123,11 @@ static int et131x_rx_dma_memory_alloc(struct
et131x_adapter *adapter)
if (rx_ring-fbr[0] == NULL)
return -ENOMEM;
rx_ring-fbr[1] = kmalloc(sizeof(struct fbr_lookup), GFP_KERNEL);
- if (rx_ring-fbr[1] == NULL)
+ if (rx_ring-fbr[1] == NULL) {
+ kfree(rx_ring-fbr[0]);
+ rx_ring-fbr[0] = NULL;
return -ENOMEM;
+ }
/* The first thing we will do is configure the sizes of the buffer
* rings. These will change based on jumbo packet support. Larger
--
1.8.5.3
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: et131x: let the freeing of memory more reasonable in error path
I don't think this is the right thing because it is needless code. Overall it doesn't really simplify anything. You are worried that reviewers will be confused and think there is a leak in et131x_rx_dma_memory_alloc() and then add a kfree() which breaks the code. I think you are right that a reviewer would initially wonder why the code does not call kfree() but then you do a search for fb[0] and it becomes obvious. If we add your patch and the reviewer does a search for fb[0] then it is confusing what the right thing to do is. These kinds of free later code, are not the most common way to do things in the kernel but they are used other places as well. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
