[PATCH] staging: rtl8187se: fix checkpatch.pl issues
From: Axel Rasmussen
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
---
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 f
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 > Cc: Greg Kroah-Hartman 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" 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
> >> > ---
> >> > 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
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
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
---
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
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
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
---
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
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
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
---
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
> 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
> 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
> ---
> 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
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
> Acked-by: Lad, Prabhakar
> ---
> 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
Re: [PATCH][RESEND] [media] davinci: vpfe: remove deprecated IRQF_DISABLED
Hi Laurent, On 02/20/2014 12:36 PM, Laurent Pinchart wrote: > 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 ? It's true a good number of my patches haven't been picked up yet, even after multiple resends. I was planning to ask the community tomorrow about what to do to finally get rid of IRQF_DISABLED. Effectively, pushing all the remaining changes in one go (or removing the definition of IRQF_DISABLED) may be the final solution. I hope to be able to answer your question by the end of the week. Thanks for getting back to me about this! Michael. -- Michael Opdenacker, CEO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com +33 484 258 098 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH][RESEND] [media] davinci: vpfe: remove deprecated IRQF_DISABLED
Hi Michael, On Thursday 20 February 2014 14:17:09 Michael Opdenacker wrote: > On 02/20/2014 12:36 PM, Laurent Pinchart wrote: > > 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 ? > > It's true a good number of my patches haven't been picked up yet, even > after multiple resends. Maintainers might have assumed that you would push all the patches yourself. That might be why Prabhakar has acked your patch but hasn't picked it up. > I was planning to ask the community tomorrow about what to do to finally > get rid of IRQF_DISABLED. Effectively, pushing all the remaining changes > in one go (or removing the definition of IRQF_DISABLED) may be the final > solution. > > I hope to be able to answer your question by the end of the week. > > Thanks for getting back to me about this! -- Regards, Laurent Pinchart ___ 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 02/20/2014 03:58 AM, Dan Carpenter wrote: > 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 >> Cc: Greg Kroah-Hartman > > Still has checkpatch errors. > > total: 10 errors, 48 warnings, 722 lines checked > > regards, > dan carpenter Thanks Dan, I think I've got them all fixed. I'll be resending shortly and hopefully it will end up back in the original thread. I must not have used the "--in-reply-to=" correctly here. Regards Mark ___ 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" 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 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 --- 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 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
---
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
#include
@@ -48,6 +74,7 @@
#include
#include
#include
+#include
#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 },
+ { "dgap/dgap.conf", "dgap/xrbios.bin", "dgap/xrfep.bin", 0, 4 },
+ {
[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
Cc: Greg Kroah-Hartman
---
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
#include
@@ -48,6 +74,7 @@
#include
#include
#include
+#include
#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 },
+ { "dgap/dgap.conf", "dgap/xrbios.bin", "dgap/xrfep.
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
---
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 > --- > 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
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Thursday, February 20, 2014 3:06 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 > > --- > > 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... I am sorry Greg. This is for 3.14-final. 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
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 > --- > 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 > > --- > > 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 > > --- > > 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 Signed-off-by: Greg Kroah-Hartman 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 > > > --- > > > 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 > Signed-off-by: Greg Kroah-Hartman > > 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 v2 0/3] mmc: rtsx: fix bug and support nonblocking request
Hi Chris, Could you please give me some idea about this patch-set? I send this patch-set many times, but didn't get any reply. Best Regards. micky On 02/17/2014 04:45 PM, micky_ch...@realsil.com.cn wrote: From: Micky Ching First we fix the card poweroff bug: the card power is not shutdown when sd/mmc card removed, this will make UHS-card failed to running in high speed mode if we insert the card again. We offer a concise tuning searching method, it is much easier to read. At last we add support for nonblocking request, which will improve card read speed at about 10% write speed about 5% normally. Micky Ching (3): mmc: rtsx: fix card poweroff bug mmc: rtsx: modify phase searching method for tuning mmc: rtsx: add support for pre_req and post_req drivers/mfd/rtsx_pcr.c| 132 ++--- drivers/mmc/host/rtsx_pci_sdmmc.c | 529 ++--- include/linux/mfd/rtsx_common.h |1 + include/linux/mfd/rtsx_pci.h |8 +- 4 files changed, 481 insertions(+), 189 deletions(-) -- 1.7.9.5 . ___ 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" 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
>> >> > ---
>> >> > 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
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 > > > --- > > > 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 > Signed-off-by: Greg Kroah-Hartman > > 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. greg k-h ___ 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 > > > > --- > > > > 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 > > Signed-off-by: Greg Kroah-Hartman > > > > 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 1/1] Drivers: hv: vmbus: Fix a bug in getting ACPI specified resources
Fix a bug in the resource walking code. This patch depends on
commit number: 90f3453585479d5beb75058da46eb573ced0e6ac
Signed-off-by: K. Y. Srinivasan
---
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
[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
Reviewed-by: K. Y. Srinivasan
---
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
#include
#include
+#include
#include
@@ -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
Reviewed-by: K. Y. Srinivasan
---
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
---
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
