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 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/s
> 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
On Mon, Dec 15, 2014 at 10:48 AM, devendra.aaru 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 ml.
All rig
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
> ---
> drivers/staging/lustre/lustre/os
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
> ---
> drivers/staging/rtl8723au/os_dep
On Sat, 13 Dec 2014 11:46:47 -0800
Jeremiah Mahler 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 almost
On Sat, 13 Dec 2014 22:20:52 +0100
Loic Pefferkorn 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 st
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 yo
On Mon, Dec 15, 2014 at 11:44:21AM +, One Thousand Gnomes wrote:
> On Sat, 13 Dec 2014 11:46:47 -0800
> Jeremiah Mahler 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
> > > > Documenti
On Mon, Dec 15, 2014 at 05:03:46AM -0800, Jeremiah Mahler wrote:
>
> Or another way mentioned in K&R 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 mos
Signed-off-by: Matthew Tyler
---
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 fb88733..e67a18d 100644
---
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 K&R that produces a compile error
> >
> > if (NULL = x)
> >
>
> Yes. People used to write Yoda code back in t
- Replace body-less for-loop with while loop
- Use '\0' for null character instead of 0
Signed-off-by: Matthew Tyler
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/li
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] != '
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
wrote:
> On Mon, Dec 15, 2014 at 10:05:34PM +0800
Signed-off-by: Matthew Tyler
---
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 fb88733..e67a18d 100644
---
- Replace body-less for-loop with while loop
- Use '\0' for null character instead of 0
Signed-off-by: Matthew Tyler
---
drivers/staging/lustre/lustre/libcfs/libcfs_string.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/lustre/lustre/libcfs/li
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 writes:
> On 12/12/14 19:52, Jes Sorensen wrote:
>> Larry Finger 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 I wonder why the driver is
Krzysztof Konopko 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
> rtw_wlan_util.c:
Krzysztof Konopko 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
> rtw_wlan_util.c:
Dan Carpenter 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 Strandqvist
>> ---
>>
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
>
On Mon, Dec 15, 2014 at 6:55 PM, Greg KH 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:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/
> tag
On Mon, Dec 15, 2014 at 07:23:35PM +0100, Richard Weinberger wrote:
> On Mon, Dec 15, 2014 at 6:55 PM, Greg KH 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:
> 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 di
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
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 wrote:
>>> The following changes since commit 009d0431c3914de64666bec0d350e54fdd59df6a:
>>>
>>> Linux 3.18-rc7 (2014-11-30 16:42:27 -0800)
>>
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
> >> wrote:
> >>> The following changes since commit
> >>> 009d04
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)
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
wrote:
> The f
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
---
drivers/staging/bcm/Bcmchar.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/bcm/Bcmchar.c b/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.
Signed-off-
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
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
> ---
> drivers/staging/bcm/Bcmchar.c | 4 ++--
Odd, that file is gone from my tree, I have no idea
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 b
> -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] Dr
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 P
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:
> T
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 :
> On Sun,
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 1
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 :
> On Sun, Dec 14, 2014 at 11:37:18PM +0100, Rickard Strandqvist wrote:
>> There is otherwise a risk of a
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 i
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 decid
"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
versio
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
that.
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.
Signed
On Sun, Dec 14, 2014 at 4:52 PM, Rickard Strandqvist
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 intended?
/* Specified uni
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
From: Sun Wang
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
---
drivers/staging/vt6655/ioctl.c | 1 -
drivers/staging/vt6655/ioctl.h | 5 ++
57 matches
Mail list logo
