From: Julia Lawall [EMAIL PROTECTED]
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include linux/kernel.h
From: Julia Lawall [EMAIL PROTECTED]
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include linux/kernel.h
From: Julia Lawall [EMAIL PROTECTED]
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include linux/kernel.h
From: Julia Lawall [EMAIL PROTECTED]
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include linux/kernel.h
From: Julia Lawall [EMAIL PROTECTED]
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include linux/kernel.h
From: Julia Lawall [EMAIL PROTECTED]
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include linux/kernel.h
From: Julia Lawall [EMAIL PROTECTED]
Robert P.J. Day proposed to use the macro FIELD_SIZEOF in replace of code
that matches its definition.
The modification was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include linux/kernel.h
From: Julia Lawall [EMAIL PROTECTED]
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include
From: Julia Lawall [EMAIL PROTECTED]
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include
From: Julia Lawall [EMAIL PROTECTED]
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include
From: Julia Lawall [EMAIL PROTECTED]
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include
that case round_down is implemented by DIV_ROUND_UP, twice.
The round_down and default (ie round_up) cases seem to be inversed.
---
From: Julia Lawall [EMAIL PROTECTED]
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract
From: Julia Lawall [EMAIL PROTECTED]
The kernel.h macro DIV_ROUND_UP performs the computation (((n) + (d) - 1) /
(d)) but is perhaps more readable.
An extract of the semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// smpl
@haskernel@
@@
#include
On Thu, 14 Feb 2008, Pekka Enberg wrote:
Hi Nishanth,
On Thu, Feb 14, 2008 at 7:38 PM, Nishanth Aravamudan [EMAIL PROTECTED]
wrote:
Is it just me, or does
((user_addr + iov[seg].iov_len + PAGE_SIZE - 1)/PAGE_SIZE -
user_addr/PAGE_SIZE)
not simplify to
=
;
case MMC_POWER_UP:
default:
- /* ignore */;
}
There are 37 patches accepted reported by this semantic patch and
more than 300 fixes to be applied.
Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
Acked-by: Julia Lawall julia.law...@lip6.fr
The way I would envision this to be easier to manage is to break them
down by subsystem and the reviewer can then go and read the grammar
for their own subsystem of preference. The long term benefit of this
is that even if folks don't use SmPL for collateral evolutions we have
a possibility here
On Thu, 4 Oct 2012, Joe Perches wrote:
On Thu, 2012-10-04 at 14:54 -0400, David Miller wrote:
From: Peter Senna Tschudin peter.se...@gmail.com
On Thu, Oct 4, 2012 at 8:23 PM, David Miller da...@davemloft.net wrote:
We want to know the implications of the bug being fixed.
Does it potentially
On Fri, 5 Oct 2012, Joe Perches wrote:
On Fri, 2012-10-05 at 07:22 +0200, Julia Lawall wrote:
A tool was used to find a potential problem, and then Peter
studied the code to see what fix was appropriate.
Hi Julia.
Was it true that a static analysis tool found the original
potential issue
From: Julia Lawall julia.law...@lip6.fr
This patch introduces some macros for describing how an i2c_msg is being
initialized. There are three macros: I2C_MSG_READ, for a read message,
I2C_MSG_WRITE, for a write message, and I2C_MSG_OP, for some other kind of
message, which is expected to be very
This patch set introduces some macros for describing how an i2c_msg is
being initialized. There are three macros: I2C_MSG_READ, for a read
message, I2C_MSG_WRITE, for a write message, and I2C_MSG_OP, for some other
kind of message, which is expected to be very rarely used.
Some i2c_msg
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible.
A simplified version of the semantic patch that makes this change is as
follows
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
In the second initialization, a length expressed as an explicit constant is
also re-expressed as the size of the buffer (reg).
A simplified version of the semantic patch that makes this change
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A simplified version of the semantic patch that makes this change is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression a,b,c;
identifier x;
@@
struct i2c_msg x =
- {.addr = a, .buf = b
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the bufferin each case.
A simplified version of the semantic patch that makes this change is as
follows: (http
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer in each case.
A simplified version of the semantic patch that makes this change is as
follows: (http
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible.
The second case is simplified to use simple variables rather than arrays
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer in each case.
A simplified version of the semantic patch that makes this change is as
follows: (http
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible.
A simplified version of the semantic patch that makes this change is as
follows
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
In each case, a length expressed as an explicit constant is also
re-expressed as the size of the buffer, when this is possible.
A simplified version of the semantic patch that makes this change
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
In the second i2c_msg structure, a length expressed as an explicit constant
is also re-expressed as the size of the buffer, reg.
A simplified version of the semantic patch that makes this change
On Sun, 7 Oct 2012, walter harms wrote:
Am 07.10.2012 17:38, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
In the second i2c_msg structure, a length expressed as an explicit constant
is also re-expressed as the size
On Sun, 7 Oct 2012, walter harms wrote:
Am 07.10.2012 17:38, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer in each case
On Sun, 7 Oct 2012, walter harms wrote:
Am 07.10.2012 18:44, schrieb Julia Lawall:
On Sun, 7 Oct 2012, walter harms wrote:
Am 07.10.2012 17:38, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
In the second i2c_msg
Some people thought that it would be nice to have the macros rather than
the inlined field initializations, especially since there is no flag for
write. A separate question is whether an array of one element is useful,
or whether one should systematically use on a simple variable of the
On Sun, 7 Oct 2012, Joe Perches wrote:
On Sun, 2012-10-07 at 20:56 +0200, Julia Lawall wrote:
Some people thought that it would be nice to have the macros rather than
the inlined field initializations, especially since there is no flag for
write. A separate question is whether an array of one
On Sun, 7 Oct 2012, Joe Perches wrote:
On Sun, 2012-10-07 at 23:43 +0200, Julia Lawall wrote:
On Sun, 7 Oct 2012, Joe Perches wrote:
Are READ and WRITE the action names? They are really the important
information in this case.
Yes, most (all?) uses of _READ and _WRITE macros actually
On Mon, 8 Oct 2012, Ryan Mallon wrote:
On 08/10/12 02:38, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible
in question is
a pointer, so sizeof would give the wrong result. If it is preferred, I
could not use sizeof for the other structure in the same code, but it
seems just a little safer to use it.
thanks,
julia
On Mon, 8 Oct 2012, Ryan Mallon wrote:
On 08/10/12 02:38, Julia Lawall wrote:
From: Julia
On Mon, 8 Oct 2012, Ryan Mallon wrote:
On 08/10/12 02:38, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
A length expressed as an explicit constant is also re-expressed as the size
of the buffer, when this is possible
Sorry, I mean either:
I2C_MSG_WRITE(priv-cfg-i2c_address, reg, sizeof(reg)),
I2C_MSG_READ(priv-cfg-i2c_address, val, sizeof(*val)),
Of course. Sorry for not having seen that. I can do that.
julia
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
I found only 15 uses of I2C_MSG_OP, out of 653 uses of one of the three
macros. Since I2C_MSG_OP has the complete set of flags, I think it should
be OK?
One of the uses, in drivers/media/i2c/adv7604.c, is as follows:
struct i2c_msg msg[2] = { { client-addr, 0, 1, msgbuf0 },
These patches use WARN, which combines printk and WARN_ON(1), or WARN_ONCE,
which combines printk and WARN_ON_ONCE(1). This does not appear to affect
the behavior, but makes the code a little more concise.
The semantic patch that makes this transformation is as follows
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
If (count) is also merged into WARN, for further conciseness.
A simplified version of the semantic patch that makes part of this
transformation is as follows: (http://coccinelle.lip6.fr
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN(1,
es);
-WARN_ON
From: Julia Lawall julia.law...@lip6.fr
Use WARN_ONCE rather than printk followed by WARN_ON_ONCE(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression list es;
@@
-printk(
+WARN_ONCE(1
On Sat, 3 Nov 2012, walter harms wrote:
Am 03.11.2012 11:58, schrieb Julia Lawall:
From: Julia Lawall julia.law...@lip6.fr
Use WARN rather than printk followed by WARN_ON(1), for conciseness.
A simplified version of the semantic patch that makes this transformation
is as follows: (http
From: Julia Lawall julia.law...@lip6.fr
eprintk is really just WARN(1, KERN_ERR ...). Use WARN to be more
consistent with the rest of the code.
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
drivers/misc/kgdbts.c | 38 +-
1 file changed, 17
While looking i have noticed that a lot of drivers define there private
assert macro.
It is very similar to warn.
(e.g.)
#define RTL819x_DEBUG
#ifdef RTL819x_DEBUG
#define assert(expr) \
if (!(expr)) { \
printk( Assertion failed!
From: Julia Lawall julia.law...@lip6.fr
Use WARN(1,...) rather than printk followed by WARN(1).
Signed-off-by: Julia Lawall julia.law...@lip6.fr
---
scripts/coccinelle/misc/warn.cocci | 109 +
1 file changed, 109 insertions(+)
diff --git a/scripts
These patches convert a conditional with a simple test expression and a
then branch that only calls WARN_ON(1) to just a call to WARN_ON, which
will test the condition.
// smpl
@@
expression e;
@@
(
if(+...e(...)...+) WARN_ON(1);
|
- if (e) WARN_ON(1);
+ WARN_ON(e);
)// /smpl
--
To unsubscribe
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
From: Julia Lawall julia.law...@lip6.fr
Just use WARN_ON rather than an if containing only WARN_ON(1).
A simplified version of the semantic patch that makes this transformation
is as follows: (http://coccinelle.lip6.fr/)
// smpl
@@
expression e;
@@
- if (e) WARN_ON(1);
+ WARN_ON(e);
// /smpl
On Sun, 4 Nov 2012, Sasha Levin wrote:
Hi Julia,
On Sat, Nov 3, 2012 at 4:30 PM, Julia Lawall julia.law...@lip6.fr wrote:
These patches convert a conditional with a simple test expression and a
then branch that only calls WARN_ON(1) to just a call to WARN_ON, which
will test the condition
On Sun, 4 Nov 2012, Sasha Levin wrote:
On Sun, Nov 4, 2012 at 10:57 AM, Julia Lawall julia.law...@lip6.fr wrote:
On Sun, 4 Nov 2012, Sasha Levin wrote:
Hi Julia,
On Sat, Nov 3, 2012 at 4:30 PM, Julia Lawall julia.law...@lip6.fr wrote:
These patches convert a conditional with a simple test
On Sun, 4 Nov 2012, Arnd Bergmann wrote:
On Saturday 03 November 2012, Julia Lawall wrote:
@@ -113,10 +113,6 @@
printk(KERN_INFO a); \
touch_nmi_watchdog(); \
} while (0)
-#define eprintk(a...) do { \
- printk(KERN_ERR
It looks like these patches were not a good idea, because in each case the
printk provides an error level, and WARN then provides another one.
Sorry for the noise.
julia
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Sun, 4 Nov 2012, Arnd Bergmann wrote:
On Sunday 04 November 2012, Julia Lawall wrote:
Hmm, I did not think that WARN() took a KERN_ERR argument, which should
really be implied here. Looking at the code, it really seems to be required
at the moment, but only 5 out of 117 callers use
On Mon, 5 Nov 2012, Arnd Bergmann wrote:
On Sunday 04 November 2012, Julia Lawall wrote:
I don't see yet where that KERN_WARNING gets added. Looking at
warn_slowpath_common, there are two or three lines that get printed at
KERN_WARNING level, followed by the format that got passed
These patches fix cases where a called function frees some data and the
calling context frees the same data.
The complete semantic match is as follows: (http://coccinelle.lip6.fr/)
// smpl
@r exists@
parameter list[n] ps;
type T;
identifier a;
expression e;
expression ret != 0;
identifier
From: Julia Lawall julia.law...@lip6.fr
The function __iio_add_event_config_attrs is only called once, by the
function iio_device_register_eventset. If the call fails,
iio_device_register_eventset calls __iio_remove_event_config_attrs. There
is thus no need for __iio_add_event_config_attrs
From: Julia Lawall julia.law...@lip6.fr
snd_miro_probe is a static function that is only called twice in the file
that defines it. At each call site, its argument is freed using
snd_card_free. Thus, there is no need for snd_miro_probe to call
snd_card_free on its argument on any of its error
From: Julia Lawall julia.law...@lip6.fr
The function wl12xx_set_power_on is only called twice, once in
wl12xx_chip_wakeup and once in wl12xx_get_hw_info. On the failure of the
call in wl12xx_chip_wakeup, the containing function just returns, but on
the failure of the call in wl12xx_get_hw_info
From: Julia Lawall julia.law...@lip6.fr
The function initialize_flash_pde_data is only called four times. All four
calls are in the function rtas_flash_init, and on the failure of any of the
calls, remove_flash_pde is called on the third argument of each of the
calls. There is thus no need
From: Julia Lawall julia.law...@lip6.fr
This makes two changes. In ath6kl_wmi_cmd_send, a call to dev_kfree_skb on
the skb argument is added to the initial sanity check to more completely
establish the invariant that ath6kl_wmi_cmd_send owns its skb argument.
Then, in ath6kl_wmi_sync_point
I have been looking at this again, with the macros
#define I2C_MSG_OP(_addr, _buf, _len, _flags) \
{ .addr = _addr, .buf = _buf, .len = _len, .flags = _flags }
#define I2C_MSG_WRITE(addr, buf, len) \
I2C_MSG_OP(addr, buf, len, 0)
#define I2C_MSG_READ(addr, buf, len) \
On Tue, 9 Oct 2012, Jean Delvare wrote:
Hi Julia,
On Sun, 7 Oct 2012 17:38:33 +0200, Julia Lawall wrote:
From: Julia Lawall julia.law...@lip6.fr
Introduce use of I2c_MSG_READ/WRITE/OP, for readability.
Next time you send this patch set, please Cc me on every post so that I
don't have
On Tue, 9 Oct 2012, Jean Delvare wrote:
Hi Julia,
On Mon, 8 Oct 2012 07:24:11 +0200 (CEST), Julia Lawall wrote:
Sorry, I mean either:
I2C_MSG_WRITE(priv-cfg-i2c_address, reg, sizeof(reg)),
I2C_MSG_READ(priv-cfg-i2c_address, val, sizeof(*val)),
Of course. Sorry
On Tue, 9 Oct 2012, Jean Delvare wrote:
Hi Julia,
On Sun, 7 Oct 2012 17:38:30 +0200, Julia Lawall wrote:
This patch set introduces some macros for describing how an i2c_msg is
being initialized. There are three macros: I2C_MSG_READ, for a read
message, I2C_MSG_WRITE, for a write
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 and one write.
Perhaps a reasonable option would be to use
I2C_MSG_READ
I2C_MSG_WRITE
I2C_MSG_READ_OP
I2C_MSG_WRITE_OP
The
Typically, the return value desired for the failure of a function with an
integer return value is a negative integer. In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return variable within the loop.
The semantic match
From: Julia Lawall julia.law...@lip6.fr
Typically, the return value desired for the failure of a function with an
integer return value is a negative integer. In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return
From: Julia Lawall julia.law...@lip6.fr
Typically, the return value desired for the failure of a function with an
integer return value is a negative integer. In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return
From: Julia Lawall julia.law...@lip6.fr
Typically, the return value desired for the failure of a function with an
integer return value is a negative integer. In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return
From: Julia Lawall julia.law...@lip6.fr
Typically, the return value desired for the failure of a function with an
integer return value is a negative integer. In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return
From: Julia Lawall julia.law...@lip6.fr
Typically, the return value desired for the failure of a function with an
integer return value is a negative integer. In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return
From: Julia Lawall julia.law...@lip6.fr
Typically, the return value desired for the failure of a function with an
integer return value is a negative integer. In these cases, the return
value is sometimes a negative integer and sometimes 0, due to a subsequent
initialization of the return
From: Julia Lawall julia.law...@lip6.fr
Use list_for_each_entry and perform some other induced simplifications.
The semantic match that finds the opportunity for this reorganization is as
follows: (http://coccinelle.lip6.fr/)
// smpl
@@
struct list_head *pos;
struct list_head *head;
statement S
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
On Thu, Mar 28, 2013 at 9:19 AM, Julia Lawall julia.law...@lip6.fr wrote:
On Thu, 28 Mar 2013, Jesse Barnes wrote:
- info-skip_vt_switch = true;
+ fb_enable_skip_vt_switch(info);
So we'd then have to just add
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
On Thu, Mar 28, 2013 at 11:10 AM, Julia Lawall julia.law...@lip6.fr wrote:
On Thu, 28 Mar 2013, Luis R. Rodriguez wrote:
Thanks Julia! I'll be sure to try to add this to compat-drivers if the
upstream fb patch is not accepted
101 - 200 of 7749 matches
Mail list logo
