Hello,
With next-20141215, i have got the following build warnings:
drivers/staging/iio/meter/ade7754.c:222:6: warning: ‘val’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
drivers/staging/iio/meter/ade7754.c:368:6: warning: ‘val’ may be used
uninitialized in this function
On Mon, Dec 15, 2014 at 10:25 AM, devendra.aaru devendra.a...@gmail.com wrote:
Hello,
With next-20141215, i have got the following build warnings:
drivers/staging/iio/meter/ade7754.c:222:6: warning: ‘val’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
drivers/staging
Hi,
Thanks for reporting! We are working on IIO cleanup project [1]
and we can take care of fixing this.
Thanks for a very quick response. I did fix those warnings. Let me
know if i need to send patches to iio ml.
--Devendra
___
devel mailing list
On Mon, Dec 15, 2014 at 10:48 AM, devendra.aaru devendra.a...@gmail.com wrote:
Hi,
Thanks for reporting! We are working on IIO cleanup project [1]
and we can take care of fixing this.
Thanks for a very quick response. I did fix those warnings. Let me
know if i need to send patches to iio
On Sun, Dec 14, 2014 at 11:37:18PM +0100, Rickard Strandqvist wrote:
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
On Sun, Dec 14, 2014 at 11:39:14PM +0100, Rickard Strandqvist wrote:
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
On Sat, 13 Dec 2014 11:46:47 -0800
Jeremiah Mahler jmmah...@gmail.com wrote:
Loïc,
On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote:
Whose convention is this? I can't find any mention in
Documention/CodingStyle. checkpatch.pl doesn't complain about them.
And there are
On Sat, 13 Dec 2014 22:20:52 +0100
Loic Pefferkorn l...@loicp.eu wrote:
On Sat, Dec 13, 2014 at 07:07:05PM +, One Thousand Gnomes wrote:
Pointless churn. It makes it less readable if anything, and it removes
the type safety as you are now checking against 0 not (void *)0
NAK
I haven't seen any bugs caused by lack of type safety with !foo...
I prefer !foo because it is more common in the kernel and I think it's
easier to read but I don't feel strongly about this.
I kind of hate if (foo != NULL) though, because it's a double negative.
But I really hate when people
On Mon, Dec 15, 2014 at 11:51:47AM +, One Thousand Gnomes wrote:
Depends what you feel confident tackling. An interesting but
challenging one to look at as a newcomer might be
https://bugzilla.kernel.org/show_bug.cgi?id=87951
because it provides you with an example .iso file you can
On Mon, Dec 15, 2014 at 11:44:21AM +, One Thousand Gnomes wrote:
On Sat, 13 Dec 2014 11:46:47 -0800
Jeremiah Mahler jmmah...@gmail.com wrote:
Loïc,
On Sat, Dec 13, 2014 at 07:22:38PM +0100, Loic Pefferkorn wrote:
Whose convention is this? I can't find any mention in
On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote:
Or another way mentioned in KR that produces a compile error
if (NULL = x)
Yes. People used to write Yoda code back in the day. Don't ever do
this in the kernel.
1) It looks stupid.
2) GCC will catch most ==
Signed-off-by: Matthew Tyler matt.ty...@flashics.com
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index
Dan,
On Mon, Dec 15, 2014 at 04:43:34PM +0300, Dan Carpenter wrote:
On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote:
Or another way mentioned in KR that produces a compile error
if (NULL = x)
Yes. People used to write Yoda code back in the day.
- Replace body-less for-loop with while loop
- Use '\0' for null character instead of 0
Signed-off-by: Matthew Tyler matt.ty...@flashics.com
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
On Mon, Dec 15, 2014 at 10:05:34PM +0800, Matthew Tyler wrote:
/* find token length */
- for (len = 0; str[len] != 0 !isspace(str[len])
- str[len] != '+' str[len] != '-'; len++);
+ len = 0;
+ while (str[len] != '\0'
Cheers. I was checking with --terse and that warning was not showing.
I'll just fix that up now.
Thanks for your help! New to this...
Matthew Tyler
Mob: +61407964325
Site: http://matthewtyler.io/
On Mon, Dec 15, 2014 at 10:13 PM, Dan Carpenter
dan.carpen...@oracle.com wrote:
On Mon, Dec 15,
Signed-off-by: Matthew Tyler matt.ty...@flashics.com
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
b/drivers/staging/lustre/lustre/libcfs/libcfs_string.c
index
- Replace body-less for-loop with while loop
- Use '\0' for null character instead of 0
Signed-off-by: Matthew Tyler matt.ty...@flashics.com
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git
Looks good. Thanks!
regards,
dan carpenter
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted
Krzysztof Konopko k...@konagma.com writes:
On 12/12/14 19:52, Jes Sorensen wrote:
Larry Finger larry.fin...@lwfinger.net writes:
On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
I was hunting particularly for inconsistencies with `sparse` and came
across this one. But I dug a bit further and
Krzysztof Konopko k...@konagma.com writes:
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
Krzysztof Konopko k...@konagma.com writes:
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
Dan Carpenter dan.carpen...@oracle.com writes:
On Sun, Dec 14, 2014 at 11:39:14PM +0100, Rickard Strandqvist wrote:
There is otherwise a risk of a possible null pointer dereference.
Was largely found by using a static code analysis program called cppcheck.
Signed-off-by: Rickard
On Sun, Dec 14, 2014 at 11:59:19PM -0800, Jeremiah Mahler wrote:
KY Srinivasan,
On Mon, Dec 15, 2014 at 07:00:45AM +, KY Srinivasan wrote:
-Original Message-
From: Jeremiah Mahler [mailto:jmmah...@gmail.com]
Sent: Wednesday, December 10, 2014 6:10 PM
To: KY
On Mon, Dec 15, 2014 at 6:55 PM, Greg KH gre...@linuxfoundation.org wrote:
The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a:
Linux 3.18-rc7 (2014-11-30 16:42:27 -0800)
are available in the git repository at:
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
On Mon, Dec 15, 2014 at 6:55 PM, Greg KH gre...@linuxfoundation.org wrote:
The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a:
Linux 3.18-rc7 (2014-11-30 16:42:27 -0800)
are available in the
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
I don't understand this kind of logic.
a) Binder is considered a piece of shite.
b) Google is working on a (hopefully sane) replacement.
Why moving it out of staging then? What is the benefit?
There is none, and Greg didn't
On Mon, Dec 15, 2014 at 10:39:15AM -0800, Christoph Hellwig wrote:
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
I don't understand this kind of logic.
a) Binder is considered a piece of shite.
b) Google is working on a (hopefully sane) replacement.
Why moving it
Am 15.12.2014 um 19:30 schrieb Greg KH:
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
On Mon, Dec 15, 2014 at 6:55 PM, Greg KH gre...@linuxfoundation.org wrote:
The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a:
Linux 3.18-rc7 (2014-11-30
On Mon, Dec 15, 2014 at 07:36:00PM +0100, Richard Weinberger wrote:
Am 15.12.2014 um 19:30 schrieb Greg KH:
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
On Mon, Dec 15, 2014 at 6:55 PM, Greg KH gre...@linuxfoundation.org
wrote:
The following changes since commit
Andy,
On Mon, Dec 15, 2014 at 03:47:04PM +, Andy Whitcroft wrote:
On Sun, Dec 14, 2014 at 11:59:19PM -0800, Jeremiah Mahler wrote:
[...]
The calculation appears identical to my reading, the original form was:
next_gpadl_handle = atomic_read(vmbus_connection.next_gpadl_handle);
On Mon, Dec 15, 2014 at 10:41:03AM -0800, Greg KH wrote:
On Mon, Dec 15, 2014 at 10:39:15AM -0800, Christoph Hellwig wrote:
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
I don't understand this kind of logic.
a) Binder is considered a piece of shite.
b) Google is
Am 15.12.2014 um 19:44 schrieb Greg KH:
On Mon, Dec 15, 2014 at 07:36:00PM +0100, Richard Weinberger wrote:
Am 15.12.2014 um 19:30 schrieb Greg KH:
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
On Mon, Dec 15, 2014 at 6:55 PM, Greg KH gre...@linuxfoundation.org
wrote:
This is a patch to the Bcmchar.c file that fixes a space before comma warning
found by checkpatch.pl.
Signed-off-by: Jack Wilson jackwilson...@gmail.com
---
drivers/staging/bcm/Bcmchar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/bcm/Bcmchar.c
Currently, the API for sending a multi-page buffer over VMBUS is limited to
a maximum pfn array of MAX_MULTIPAGE_BUFFER_COUNT. This limitation is
not imposed by the host and unnecessarily limits the maximum payload
that can be sent. Implement an API that does not have this restriction.
On Mon, Dec 15, 2014 at 08:04:53PM +0100, Richard Weinberger wrote:
Fact is, this is useful code, in this area. In the domain it is used
in, it works properly, and the abi is sufficient. Yes, it's ugly in
spaces, and insecure if used outside of Android, but that's ok for the
users of the
On Mon, Dec 15, 2014 at 11:22:29AM -0800, Jack Wilson wrote:
This is a patch to the Bcmchar.c file that fixes a space before comma warning
found by checkpatch.pl.
Signed-off-by: Jack Wilson jackwilson...@gmail.com
---
drivers/staging/bcm/Bcmchar.c | 4 ++--
Odd, that file is gone from my
On Mon, Dec 15, 2014 at 12:33:47PM -0800, K. Y. Srinivasan wrote:
Currently, the API for sending a multi-page buffer over VMBUS is limited to
a maximum pfn array of MAX_MULTIPAGE_BUFFER_COUNT. This limitation is
not imposed by the host and unnecessarily limits the maximum payload
that can be
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Monday, December 15, 2014 11:34 AM
To: KY Srinivasan
Cc: linux-ker...@vger.kernel.org; de...@linuxdriverproject.org;
o...@aepfle.de; a...@canonical.com; jasow...@redhat.com
Subject: Re: [PATCH 1/1] Drivers:
Thank you for the quick feedback.
It was my first patch to the kernel and I wanted to be sure it would get right
to the community.
I'll be making a version two with the consideration you brought me.
Thank you again,
Best regards,
Eduardo Barretto
On Sun, Dec 14, 2014 at 06:11:30PM -0800, Joe
On Mon, 2014-12-15 at 18:53 -0200, Eduardo Barretto wrote:
Thank you for the quick feedback.
It was my first patch to the kernel and I wanted to be sure it would get
right to the community.
I'll be making a version two with the consideration you brought me.
the code today is:
{
Hi Jack,
bcm is removed from the linux kernel. You are working against the
wrong tree!
Please work against staging-next of gregkh for staging drivers!
Ask me if you do not understand what the problem is!
Feel free to ask me other questions as well!
On 15-12-2014 11:22:29, Jack Wilson wrote:
Hi Joe
No, it does not look like end can be NULL then.
Then remove the end != NULL instead?
...
if (end != NULL *end == '.') {
However, I am hesitant to the tolower() I think double case is faster...?
Kind regards
Rickard Strandqvist
2014-12-15 2:51 GMT+01:00 Joe Perches
Hi
No the rtw_hw_resume23a() is not used anywhere.
I also do a check of all functions that are not used, but not in the
drivers/staging, I suspected that these might be under development and
used in the future.
What do you want to do, who decides?
Kind regards
Rickard Strandqvist
2014-12-15
Hi Dan
Quite right! Had to try it.
Do nothing then?
But you must agree that it is still ugly and confusing code.
Kind regards
Rickard Strandqvist
2014-12-15 11:25 GMT+01:00 Dan Carpenter dan.carpen...@oracle.com:
On Sun, Dec 14, 2014 at 11:37:18PM +0100, Rickard Strandqvist wrote:
There is
On Mon, 2014-12-15 at 23:23 +0100, Rickard Strandqvist wrote:
Hi Joe
Hello Rickard
No, it does not look like end can be NULL then.
Then remove the end != NULL instead?
...
if (end != NULL *end == '.') {
Up to you.
However, I am hesitant to the tolower() I think double case is
On 12/15/2014 05:01 PM, Rickard Strandqvist wrote:
Hi
No the rtw_hw_resume23a() is not used anywhere.
I also do a check of all functions that are not used, but not in the
drivers/staging, I suspected that these might be under development and
used in the future.
What do you want to do, who
isil and isl prefixes are used at various locations inside the kernel
to reference Intersil corporation. This patch is part of a series fixing
those locations were isl is used in compatible strings to use the now
expected isil prefix instead (NASDAQ symbol for Intersil and most used
version). The
Thanks Martin for the explanation.
I'll send out another patch.
-Original Message-
From: Martin K. Petersen [mailto:martin.peter...@oracle.com]
Sent: Thursday, December 11, 2014 7:04 PM
To: Long Li
Cc: Martin K. Petersen; KY Srinivasan; Haiyang Zhang;
jbottom...@parallels.com;
On Mon, 2014-12-15 at 14:59 +0300, Dan Carpenter wrote:
I prefer !foo because it is more common in the kernel and I think it's
easier to read but I don't feel strongly about this.
Me too. But I do prefer consistency.
fyi: for variants of:
if (!foo)
vs
if (foo == NULL)
a
Strongly agreed that execution speed is not critical here. It's the update of
a proc variable, not a tight loop or critical section.
Normally I'd leave it alone, but since you're writing a patch anyway, I'd do
'tolower' myself. I dislike the stacked case statements on a single line like
Fix a checkpatch.pl warning regarding quoted string splits across lines.
While each join of these quoted strings results in a new checkpatch.pl
lines over 80 characters warning, the regained ability to grep for
these log strings in the codebase is, I would argue, well worth the
trade-off.
On Sun, Dec 14, 2014 at 4:52 PM, Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
units = 1;
...
/* Specified units override the multiplier */
if (units)
That doesn't make much sense. The conditional logic will always be
executed. Maybe this is what's
Units can be passed to lprocfs_write_frac_u64_helper() via a suffix
(e.g., ...K, ...M, etc.) tacked onto the value. A comment states
that specified units override the multiplier, though the multiplier is
overridden regardless. Update the conditional logic so that it only
applies when units are
From: Sun Wang sun@gmail.com
Subject: [PATCH] staging:vt6655 Add extern variable in head file
Extern variable must be declared in head file. Compiler can catch the
inconsistency when variable changes.
Signed-off-by: Sun Wang sun@gmail.com
---
drivers/staging/vt6655/ioctl.c | 1 -
57 matches
Mail list logo
