From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
fs/ext2/balloc.c |3 +--
fs/ext2/dir.c|3 +--
fs/ext3/balloc.c |3 +--
fs/ext4/balloc.c
From: Julia Lawall [EMAIL PROTECTED]
if (...) BUG(); should be replaced with BUG_ON(...) when the test has no
side-effects to allow a definition of BUG_ON that drops the code completely.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
The complete semantic match that finds this
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. The patch
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. Replace c
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. Replace
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. Replace
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
The complete semantic match that finds this
From: Julia Lawall [EMAIL PROTECTED]
Combine list_for_each and list_entry into list_for_each_entry.
An excerpt of the semantic patch implementing these changes is as follows:
@ra@
type T,T1;
identifier I, x;
expression E, E1, E2;
iterator list_for_each_entry;
@@
... when != _Y(I
From: Julia Lawall [EMAIL PROTECTED]
Remove an unnecessary pci_dev_put. pci_dev_put is called implicitly by the
subsequent call to pci_get_device.
The problem was detected using the following semantic patch, and corrected
by hand.
@@
expression dev;
expression E;
@@
- pci_dev_put(dev
From: Julia Lawall [EMAIL PROTECTED]
Move pci_dev_put outside the loops in which it occurs. Within the loop,
pci_dev_put is done implicitly by pci_get_device.
The problem was detected using the following semantic patch, and corrected
by hand.
@@
expression dev;
expression E;
@@
- pci_dev_put
On Sun, 8 Jul 2012, Paul Menzel wrote:
Dear Julia,
Am Sonntag, den 08.07.2012, 13:37 +0200 schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
A break
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
After
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
A break
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator. Replace
From: Julia Lawall julia.law...@lip6.fr
If list_for_each_entry, etc complete a traversal of the list, the iterator
variable ends up pointing to an address at an offset from the list head,
and not a meaningful structure. Thus this value should not be used after
the end of the iterator.
Signed
From: Julia Lawall julia.law...@lip6.fr
dev_get_platdata returns a pointer, so the failure value would be NULL
rather than a negative integer.
The semantic match that finds this problem is: (http://coccinelle.lip6.fr/)
// smpl
@@
expression x,e;
statement S1,S2;
@@
*x = dev_get_platdata
From: Julia Lawall ju...@diku.dk
Add missing free_domain_mem on failure path after alloc_domain.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@km exists@
local idexpression e;
expression e1,e2,e3;
type T,T1;
identifier f
From: Julia Lawall julia.law...@lip6.fr
Add missing free_domain_mem on failure path after alloc_domain.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@km exists@
local idexpression e;
expression e1,e2,e3;
type T,T1
From: Julia Lawall julia.law...@lip6.fr
Add missing usb_free_urb on failure path after usb_alloc_urb.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@km exists@
local idexpression e;
expression e1,e2,e3;
type T,T1
From: Julia Lawall julia.law...@lip6.fr
Add missing usb_free_urb on failure path after usb_alloc_urb.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@km exists@
local idexpression e;
expression e1,e2,e3;
type T,T1
with the lock held, or where there is some preceding
/// function call that releases the lock.
///
// Confidence: Moderate
// Copyright: (C) 2010-2012 Nicolas Palix. GPLv2.
// Copyright: (C) 2010-2012 Julia Lawall, INRIA/LIP6. GPLv2.
// Copyright: (C) 2010-2012 Gilles Muller, INRIA/LiP6. GPLv2
/// function call that releases the lock.
///
// Confidence: Moderate
// Copyright: (C) 2010-2012 Nicolas Palix. GPLv2.
// Copyright: (C) 2010-2012 Julia Lawall, INRIA/LIP6. GPLv2.
// Copyright: (C) 2010-2012 Gilles Muller, INRIA/LiP6. GPLv2.
// URL: http://coccinelle.lip6.fr/
// Comments
On Wed, 25 Jul 2012, Fengguang Wu wrote:
Hi Julia,
On Wed, Jul 25, 2012 at 04:15:19PM +0200, Julia Lawall wrote:
Do you use a timeout when you run Coccinelle You could put the argument
--timeout 120.
Good to know that! I'll definitely try it.
Are you using the existing framework within
I looked at it a bit more, and I think the timeout is the best solution.
The big jump backwards is under an if, and the pattern tries to match an
if up to a return, which tries to go across gotos. So I think it is just
a pathologically bad case.
julia
--
To unsubscribe from this list: send the
From: Julia Lawall julia.law...@lip6.fr
devm_kzalloc allocates memory that is released when a driver detaches.
This patch uses devm_kzalloc for data that is allocated in the probe
function of a platform device and is only freed in the remove function.
Signed-off-by: Julia Lawall julia.law
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
At the same time
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
Signed-off-by: Julia
From: Julia Lawall julia.law...@lip6.fr
devm_kzalloc allocates memory that is released when a driver detaches.
This patch uses devm_kzalloc for data that is allocated in the probe
function of a platform device and is only freed in the remove function.
Signed-off-by: Julia Lawall julia.law
From: Julia Lawall julia.law...@lip6.fr
devm_clk_get allocates a resource that is released when a driver detaches.
This patch uses devm_clk_get for data that is allocated in the probe
function of a platform device and is only released in the remove function.
Signed-off-by: Julia Lawall julia.law
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The patch makes some other
The function at91_dt_node_to_map in drivers/pinctrl/pinctrl-at91.c
contains the following code:
new_map = devm_kzalloc(pctldev-dev, sizeof(*new_map) * map_num,
GFP_KERNEL);
if (!new_map)
return -ENOMEM;
*map = new_map;
*num_maps = map_num;
From: Julia Lawall julia.law...@lip6.fr
devm_request_threaded_irq requests and irq that is freed when a driver
detaches. This patch uses devm_request_threaded_irq for irqs that are
requested in the probe function of a platform device and are only freed in
the remove function.
Additionally
The function pm860x_charger_probe in the file
drivers/power/88pm860x_charger.c contains the following code:
count = pdev-num_resources;
for (i = 0, j = 0; i count; i++) {
info-irq[j] = platform_get_irq(pdev, i);
if (info-irq[j] 0)
From: Julia Lawall julia.law...@lip6.fr
Using kfree to free data allocated with devm_kzalloc causes double frees.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression x;
@@
x = devm_kzalloc(...)
...
?-kfree(x);
// /smpl
Signed-off
Rather than the goto, add the fail path code in directly, and return.
ret = register_framebuffer(fbi-fb);
if (ret 0) {
dev_err(pdev-dev,
Failed to register framebuffer device: %d\n, ret);
if (fbi-fb.cmap.len)
fb_dealloc_cmap(fbi-fb.cmap);
return ret;
}
So there is no need for the
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The patch makes some other
From: Julia Lawall julia.law...@lip6.fr
The various devm_ functions allocate memory that is released when a driver
detaches. This patch uses these functions for data that is allocated in
the probe function of a platform device and is only freed in the remove
function.
The patch makes some other
On Mon, 10 Dec 2012, Mark Brown wrote:
On Sat, Dec 08, 2012 at 07:01:20PM +0100, Julia Lawall wrote:
The kfrees were introduced in b761c0ca.
I sent this a few months ago, and I still think it should be applied...
I'm missing patches 1 and 2?
Sorry, I just resent the patch as is. 1 and 2
On Tue, 11 Dec 2012, Linus Walleij wrote:
On Sat, Dec 8, 2012 at 4:52 PM, Julia Lawall julia.law...@lip6.fr wrote:
The function at91_dt_node_to_map in drivers/pinctrl/pinctrl-at91.c contains
the following code:
new_map = devm_kzalloc(pctldev-dev, sizeof(*new_map) * map_num
From: Julia Lawall julia.law...@lip6.fr
The function at91_dt_node_to_map is ultimately called by the function
pinctrl_get, which is an exported function. Since it is possible that this
function is not called from within a probe function, for safety, the kfree
is converted to a devm_kfree
On Tue, 11 Dec 2012, Linus Walleij wrote:
On Tue, Dec 11, 2012 at 10:04 AM, Julia Lawall julia.law...@lip6.fr wrote:
On Tue, 11 Dec 2012, Linus Walleij wrote:
I was under the impression that if you exit the probe function
with a negative value anything allocated with devm_* was freed
On Tue, 11 Dec 2012, Sergei Shtylyov wrote:
Hello.
On 11-12-2012 14:58, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
The function at91_dt_node_to_map is ultimately called by the function
pinctrl_get, which is an exported function. Since it is possible
On Tue, 18 Dec 2012, Jean Delvare wrote:
Hi Julia,
On Thu, 11 Oct 2012 08:45:43 +0200 (CEST), Julia Lawall wrote:
I found 6 cases where there are more than 2 messages in the array. I
didn't check how many cases where there are two messages but there is
something other than one read
On Wed, 2 Jan 2013, Tony Prisk wrote:
On Wed, 2013-01-02 at 08:10 +0300, Dan Carpenter wrote:
clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
I told Tony about this but everyone has been gone with end of year
holidays so it hasn't been addressed.
Tony, please fix it so people don't
On Wed, 2 Jan 2013, Russell King - ARM Linux wrote:
On Wed, Jan 02, 2013 at 08:10:36AM +0300, Dan Carpenter wrote:
clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
I told Tony about this but everyone has been gone with end of year
holidays so it hasn't been addressed.
Tony,
On Thu, 3 Jan 2013, Dan Carpenter wrote:
On Wed, Jan 02, 2013 at 06:31:53PM +1300, Tony Prisk wrote:
On Wed, 2013-01-02 at 08:10 +0300, Dan Carpenter wrote:
clk_get() returns NULL if CONFIG_HAVE_CLK is disabled.
I told Tony about this but everyone has been gone with end of year
From: Julia Lawall julia.law...@lip6.fr
A struct clk value is intended to be an abstract pointer, so it should be
manipulated using the various API functions.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression e,e1;
identifier i;
@@
*e
From: Julia Lawall julia.law...@lip6.fr
A struct clk value is intended to be an abstract pointer, so it should be
manipulated using the various API functions.
clk_put is additionally added on the failure paths.
The semantic match that finds the first problem is as follows:
(http
There has been a discussion recently about how the result of get_clk
should be an opaque handle, not a value that can be dereferenced:
https://lkml.org/lkml/2012/12/20/105
There is such a dereference in arch/sh/kernel/cpufreq.c, in the function
sh_cpufreq_cpu_init:
freq_table = cpuclk-nr_freqs
There has been a discussion recently about how the result of get_clk
should be an opaque handle, not a value that can be dereferenced:
https://lkml.org/lkml/2012/12/20/105
There is such a dereference in drivers/net/ethernet/ti/cpts.c, in the
function cpts_clk_init:
cpts-freq =
From: Julia Lawall julia.law...@lip6.fr
The function at91_dt_node_to_map is ultimately called by the function
pinctrl_get, which is an exported function. Since it is possible that this
function is not called from within a probe function, for safety, the kfree
is converted to a devm_kfree
On Thu, 13 Dec 2012, Dan Carpenter wrote:
On Wed, Dec 12, 2012 at 01:25:56AM +0400, Evgeniy Polyakov wrote:
I suppose mdev will be automatically freed, but who will release
mdev-clk and other private members of mdev structure?
+ mdev-clk = devm_clk_get(pdev-dev, NULL);
-clk is now a
On Thu, 13 Dec 2012, Dan Carpenter wrote:
On Thu, Dec 13, 2012 at 11:18:53AM +0100, Julia Lawall wrote:
On Thu, 13 Dec 2012, Dan Carpenter wrote:
On Wed, Dec 12, 2012 at 01:25:56AM +0400, Evgeniy Polyakov wrote:
I suppose mdev will be automatically freed, but who will release
mdev
On Sat, 5 Jan 2013, Anton Vorontsov wrote:
On Sat, Dec 08, 2012 at 06:16:35PM +0100, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
devm_request_threaded_irq requests and irq that is freed when a driver
detaches. This patch uses devm_request_threaded_irq for irqs
From: Julia Lawall julia.law...@lip6.fr
devm_kzalloc should not be followed by kfree, as this results in a double
free. The problem was found using the following semantic match
(http://coccinelle.lip6.fr/):
// smpl
@@
expression x,e;
@@
x = devm_kzalloc(...)
... when != x = e
?-kfree(x
The function davinci_i2c_remove in drivers/i2c/busses/i2c-davinci.c
contains the following code:
put_device(pdev-dev);
clk_disable_unprepare(dev-clk);
clk_put(dev-clk);
dev-clk = NULL;
davinci_i2c_write_reg(dev, DAVINCI_I2C_MDR_REG, 0);
On Mon, 7 Jan 2013, Dan Carpenter wrote:
On Sun, Jan 06, 2013 at 01:16:50PM -0800, Anton Vorontsov wrote:
The patch is whitespace-damaged (for some reason there are two spaces in
the beginning of each non-change line). I repeated changes manually, but
you might want to fix your mail/patch
On Sun, 6 Jan 2013, Anton Vorontsov wrote:
On Mon, Jan 07, 2013 at 09:42:23AM +0300, Dan Carpenter wrote:
On Sun, Jan 06, 2013 at 01:16:50PM -0800, Anton Vorontsov wrote:
The patch is whitespace-damaged (for some reason there are two spaces in
the beginning of each non-change line). I
From: Julia Lawall julia.law...@lip6.fr
The data referenced by an interrupt handler should not be freed before the
interrupt is ended. The handler is bfin_crypto_crc_handler. It may refer
to crc-regs, which is released by the iounmap.
Furthermore, the second argument to all calls to free_irq
The data referenced by an interrupt handler should not be freed before the
interrupt is ended.
The semantic match that finds this problem is as follows
(http://coccinelle.lip6.fr/). The basic idea behind this semantic match is
to find cases where the order of the call to free_irq is different
From: Julia Lawall julia.law...@lip6.fr
The data referenced by an interrupt handler should not be freed before the
interrupt is ended. The handler is pxa_camera_irq. This handler may call
pxa_dma_start_channels, which references the channels that are freed on the
lines before the call
On Mon, 7 Jan 2013, Guennadi Liakhovetski wrote:
(adding Robert to CC)
Hi Julia
Thanks for the patch.
On Mon, 7 Jan 2013, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
The data referenced by an interrupt handler should not be freed before the
interrupt is ended
From: Julia Lawall julia.law...@lip6.fr
This patch uses various devm_ functions for data that is allocated in the
probe function of a platform driver and is only freed in the remove
function.
This also fixes a checkpatch warning, removing a space before a \n in a
string.
Signed-off-by: Julia
On Mon, 7 Jan 2013, Robert Jarzmik wrote:
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:
(adding Robert to CC)
I don't think any data is freed by pxa_free_dma(), it only disables DMA on
a certain channel. Theoretically there could be a different problem:
pxa_free_dma()
+@r1@
+identifier fn;
+identifier xfers;
+@@
+fn(...)
+{
+ ...
+(
+ struct spi_transfer xfers[...];
+|
+ struct spi_transfer xfers[];
+)
+ ...
+}
Can it happen that there would be more than one spi_transfer or spi_message
variable per function? This semantic patch
On Thu, 10 Jan 2013, Paul Mundt wrote:
On Thu, Jan 03, 2013 at 10:40:20AM +0100, Julia Lawall wrote:
There has been a discussion recently about how the result of get_clk
should be an opaque handle, not a value that can be dereferenced:
https://lkml.org/lkml/2012/12/20/105
On Thu, 10 Jan 2013, Lars-Peter Clausen wrote:
On 01/10/2013 09:53 AM, Julia Lawall wrote:
+@r1@
+identifier fn;
+identifier xfers;
+@@
+fn(...)
+{
+ ...
+(
+ struct spi_transfer xfers[...];
+|
+ struct spi_transfer xfers[];
+)
+ ...
+}
Can it happen
These patches result from the following semantic patch
(http://coccinelle.lip6.fr/), which checks for successive statements that
are not aligned.
@bad@
statement S;
expression e;
position p1,p;
@@
S@p1
e@p;
@script:ocaml@
p1 bad.p1;
p bad.p;
@@
if not ((List.hd p1).line = (List.hd p).line)
From: Julia Lawall julia.law...@lip6.fr
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
This patch adjusts the code so that the alignment matches the current
semantics. I have no idea if it is the intended semantics, though. Should
the call to nfs_setsecurity also be under the else?
fs
From: Julia Lawall julia.law...@lip6.fr
Drop the semicolon at the end of the list_for_each_entry loop header.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
Not tested, but I can't imagine how the current code could work, since vsk
should end up pointing to a dummy value.
net/vmw_vsock
From: Julia Lawall julia.law...@lip6.fr
Adjust code alignment so that each statement is lined up with its neighbor.
In the second case, it could be desirable to put the call to
lpfc_destroy_vport_work_array under the if. The call, is, however, safe
in case vports is NULL, so the patch just
On Mon, 5 Aug 2013, Dan Carpenter wrote:
On Mon, Aug 05, 2013 at 04:47:39PM +0200, Julia Lawall wrote:
diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
index e8a1ce2..4a5a5dc 100644
--- a/drivers/media/i2c/ov7670.c
+++ b/drivers/media/i2c/ov7670.c
@@ -1369,8 +1369,8
On Mon, 5 Aug 2013, walter harms wrote:
Hello Julia,
IMHO keep the patch as it is.
It does not change any code that is good.
Suspicious code that comes up here can be addressed
in a separate patch.
OK, thanks!
julia
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
From: Julia Lawall julia.law...@lip6.fr
Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource. The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.
This was done using
Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource. The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.
The semantic patch used to perform this transformation is as
From: Julia Lawall julia.law...@lip6.fr
Convert the composition of devm_request_mem_region and devm_ioremap to a
single call to devm_ioremap_resource. The associated call to
platform_get_resource is also simplified and moved next to the new call to
devm_ioremap_resource.
This was done using
devm_ioremap_resource often uses the result of a call to
platform_get_resource_byname as its last argument. devm_ioremap_resource
does appropriate error handling on this argument, so error handling can be
removed from the call to platform_get_resource_byname.
The semantic patch that makes this
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to devm_ioremap_resource.
In the case of omap-dmic.c, the error-handling code of
devm_ioremap_resource is also corrected to include releasing
On Mon, 19 Aug 2013, walter harms wrote:
Am 19.08.2013 10:51, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to
devm_ioremap_resource.
A simplified
On Mon, 19 Aug 2013, walter harms wrote:
Am 19.08.2013 10:51, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call to
platform_get_resource_byname when the value is passed to
devm_ioremap_resource.
A simplified
The function affected by this patch also calls devm_ioremap_nocache twice,
with no form of request_mem_region. I wonder if these calls should also
use devm_ioremap_resource?
julia
On Mon, 19 Aug 2013, walter harms wrote:
Am 19.08.2013 10:51, schrieb Julia Lawall:
From: Julia Lawall
On Mon, 19 Aug 2013, walter harms wrote:
Am 19.08.2013 12:12, schrieb Julia Lawall:
On Mon, 19 Aug 2013, walter harms wrote:
Am 19.08.2013 10:51, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Remove unneeded error handling on the result of a call
From: Julia Lawall julia.law...@lip6.fr
Use devm_ioremap_resource instead of devm_request_and_ioremap.
This was done using the semantic patch
scripts/coccinelle/api/devm_ioremap_resource.cocci
The relevant call to platform_get_resource was manually moved down to the
call
devm_request_and_ioremap has been replaced by devm_ioremap_resource, which
gives more informative error return code information. This patch series
removes the remaining uses of devm_request_and_ioremap.
This patch series was generated using the semantic patch
From: Julia Lawall julia.law...@lip6.fr
Use devm_ioremap_resource instead of devm_request_and_ioremap.
This was done using the semantic patch
scripts/coccinelle/api/devm_ioremap_resource.cocci
The initialization of drvdata-regs_phys was manually moved lower, to take
advantage of the NULL test
401 - 500 of 7749 matches
Mail list logo
