Re: Improve my Rep
On Mon, 2014-09-15 at 10:38 -0400, Nick Krause wrote: After issues with the community I am wondering how to improve my rep Since you ignore good advice from *lots of* people and you are incapable to learn anything: by going somewhere else and not trolling here around. Bernd -- I dislike type abstraction if it has no real reason. And saving on typing is not a good reason - if your typing speed is the main issue when you're coding, you're doing something seriously wrong. - Linus Torvalds ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: a couple other common patch submission boo boos
Robert P. J. Day rpj...@crashcourse.ca writes: oh, and while i'm here, i'm going to point out a couple other things you should avoid if you're trying to get your first patch into the kernel -- unsurprisingly, nick has violated both of these guidelines a number of times. first, good grammar. seriously, good grammar. if you can't use proper grammar for the single-line Subject field, you really have no business submitting patches. and second, your explanation for the patch (what goes into the commit log) should *match* the patch. in particular, do not claim that you are fixing an error when all you're doing is cleaning up a *warning*. nick is a major violator of this prime directive -- do not categorize something as an error if it isn't. end of story. I do understand who you are addressing here, but I fear this is a little like a school teacher asking the children to be quiet - Those who listen are never the ones you want to shut up... So, with that in mind, I'd like to disagree about *first* patch requirements. The only way you can truly screw up your first kernel patch, is by not submitting it. It's of course always an advantage to have read and followed any advice you have found. And with everything indexed by a search engine, you are expected to have found some. But not everything. Do not worry, you will be politely pointed to the rest if necessary. For subsequent submissions you are of course required to read all comments and fixup the issues that are pointed out, so you might as well fix as much as possible before the first submission. But you shouldn't worry about posting a patch with some unresolved issues you weren't aware of, if it's your first kernel patch submission ever. Bjørn ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
I wouldn't touch those with a ten foot pole. On 16 Sep 2014 14:46, nick xerofo...@gmail.com wrote: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On 14-09-16 08:47 AM, Kristofer Hallin wrote: I wouldn't touch those with a ten foot pole. On 16 Sep 2014 14:46, nick xerofo...@gmail.com wrote: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies Kristofer, I would appreciate if you look at them and see if there any good. I understand based on my other patches so assumptions but it would be nice if you only too a look for me. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Checkpatch Patches
I am attaching two check patch patches I wrote in the last few days as I am
unable to get a reply
from the maintainers. Would someone please send them off for me.
Thanks,
Nick
From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] staging wlan-ng: Add missing a blank line after declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void *buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
1.9.1
From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Mon, 15 Sep 2014 17:07:24 -0400
Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
This removes the checkpatch errors related to a needed line below
declaration of a struct and another about a non nessary printk
message about a NULL allocated skb due to the function returning
NULL to the caller of the function and the printk no longer being'
used or needed by any callers.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err(SKB allocation failed\n);
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014, nick wrote: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. hey, kids ... remember what i wrote recently about, at the very least, having a grammatically correct subject line? well, there you go. why nick has not been banned from this list is purely a mystery at this point. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014, nick wrote: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. oh, and remember how i wrote *explicitly* that the patch message should match the properties of the patch, and that one should not claim to be fixing an error if what is being rectified is merely a *warning*? remember i wrote that? take a wild guess as to what nick did in his second patch. go ahead, guess. you'll never guess. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 08:44:27AM -0400, nick wrote:
I am attaching two check patch patches I wrote in the last few days as I am
unable to get a reply
from the maintainers. Would someone please send them off for me.
Thanks,
Nick
From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] staging wlan-ng: Add missing a blank line after declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
1.9.1
From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Mon, 15 Sep 2014 17:07:24 -0400
Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
This removes the checkpatch errors related to a needed line below
declaration of a struct and another about a non nessary printk
message about a NULL allocated skb due to the function returning
NULL to the caller of the function and the printk no longer being'
used or needed by any callers.
spelling mistakes
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
- if (!skb) {
- pr_err(SKB allocation failed\n);
why the error message was removed ?
+ if (!skb)
return NULL;
- }
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
ohhh .. yeah .. and both the patch failed when i tried to apply them to
next-20140916
why are we wasting our time for your patches , which are bound to have some
problem
thanks
sudip
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 7:16 PM, Sudip Mukherjee
sudipm.mukher...@gmail.com wrote:
On Tue, Sep 16, 2014 at 7:02 PM, nick xerofo...@gmail.com wrote:
On 14-09-16 09:28 AM, Sudip Mukherjee wrote:
On Tue, Sep 16, 2014 at 6:56 PM, nick xerofo...@gmail.com wrote:
On 14-09-16 09:21 AM, Sudip Mukherjee wrote:
On Tue, Sep 16, 2014 at 6:41 PM, nick xerofo...@gmail.com wrote:
On 14-09-16 09:06 AM, Sudip Mukherjee wrote:
On Tue, Sep 16, 2014 at 08:44:27AM -0400, nick wrote:
I am attaching two check patch patches I wrote in the last few days as
I am unable to get a reply
from the maintainers. Would someone please send them off for me.
Thanks,
Nick
From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] staging wlan-ng: Add missing a blank line after
declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16
rid, void *buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid,
void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int
hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid,
u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value,
sizeof(value),
NULL, NULL);
}
1.9.1
From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Mon, 15 Sep 2014 17:07:24 -0400
Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
This removes the checkpatch errors related to a needed line below
declaration of a struct and another about a non nessary printk
message about a NULL allocated skb due to the function returning
NULL to the caller of the function and the printk no longer being'
used or needed by any callers.
spelling mistakes
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
-if (!skb) {
-pr_err(SKB allocation failed\n);
why the error message was removed ?
+if (!skb)
return NULL;
-}
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
ohhh .. yeah .. and both the patch failed when i tried to apply them to
next-20140916
why are we wasting our time for your patches , which are bound to have
some problem
thanks
sudip
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I tried these on Greg's tree of staging-next and they worked for me.
Nick
in drivers/staging/netlogic/xlr_net.c file of next-20140916
1) in line 142 we just have an } else { (doesnot match your patch)
2) in the same file , there is only one instance of pr_err(SKB
allocation failed\n); , and that is at line 208 , and that is
followed by a return -ENOMEM; , but your patch is showing that there
is a return NULL
thanks
sudip
Thanks Sudip,
I will fix the patch later if you want. In addition is my other patch OK
or do I need to fix it still?
Nick
allow me to quote from my mail : ohhh .. yeah .. and both the patch
failed when i tried to apply them to next-20140916
i mentioned both ...
Thanks for the Help, I really do appreciate it and I
Re: Page fault in kernel code
On Thu, 11 Sep 2014, Leon Romanovsky wrote:
Linux kernel memory is not page-able, but memory allocated through vmalloc
can still cause page fault. How device drivers using vmalloc handle this?
Pages allocated via vmalloc call won't generate page-faults.
Kernel faults are used on some platforms in a very limited way but not
for swapping in or paging in from disk. Have a look at
linux/arch/x86/mm/fault.c:
/*
* We fault-in kernel-space virtual memory on-demand. The
* 'reference' page table is init_mm.pgd.
*
* NOTE! We MUST NOT take any locks for this case. We may
* be in an interrupt or a critical region, and should
* only copy the information from the master page table,
* nothing more.
*
* This verifies that the fault happens in kernel space
* (error_code 4) == 0, and that the fault was not a
* protection error (error_code 9) == 0.
*/
if (unlikely(fault_in_kernel_space(address))) {
if (!(error_code (PF_RSVD | PF_USER | PF_PROT))) {
if (vmalloc_fault(address) = 0)
return;
if (kmemcheck_fault(regs, address, error_code))
return;
}
/* Can handle a stale RO-RW TLB: */
if (spurious_fault(error_code, address))
return;
/* kprobes don't want to hook the spurious faults: */
if (kprobes_fault(regs))
return;
/*
* Don't take the mm semaphore here. If we fixup a prefetch
* fault we could otherwise deadlock:
*/
bad_area_nosemaphore(regs, error_code, address);
return;
}
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On 14-09-16 09:21 AM, Sudip Mukherjee wrote:
On Tue, Sep 16, 2014 at 6:41 PM, nick xerofo...@gmail.com wrote:
On 14-09-16 09:06 AM, Sudip Mukherjee wrote:
On Tue, Sep 16, 2014 at 08:44:27AM -0400, nick wrote:
I am attaching two check patch patches I wrote in the last few days as I
am unable to get a reply
from the maintainers. Would someone please send them off for me.
Thanks,
Nick
From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] staging wlan-ng: Add missing a blank line after
declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid,
void *buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void
*val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16
val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
1.9.1
From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Mon, 15 Sep 2014 17:07:24 -0400
Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
This removes the checkpatch errors related to a needed line below
declaration of a struct and another about a non nessary printk
message about a NULL allocated skb due to the function returning
NULL to the caller of the function and the printk no longer being'
used or needed by any callers.
spelling mistakes
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
-if (!skb) {
-pr_err(SKB allocation failed\n);
why the error message was removed ?
+if (!skb)
return NULL;
-}
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
ohhh .. yeah .. and both the patch failed when i tried to apply them to
next-20140916
why are we wasting our time for your patches , which are bound to have some
problem
thanks
sudip
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I tried these on Greg's tree of staging-next and they worked for me.
Nick
in drivers/staging/netlogic/xlr_net.c file of next-20140916
1) in line 142 we just have an } else { (doesnot match your patch)
2) in the same file , there is only one instance of pr_err(SKB
allocation failed\n); , and that is at line 208 , and that is
followed by a return -ENOMEM; , but your patch is showing that there
is a return NULL
thanks
sudip
Thanks Sudip,
I will fix the patch later if you want. In addition is my other patch OK or do
I need to fix it still?
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On 14-09-16 09:06 AM, Sudip Mukherjee wrote:
On Tue, Sep 16, 2014 at 08:44:27AM -0400, nick wrote:
I am attaching two check patch patches I wrote in the last few days as I am
unable to get a reply
from the maintainers. Would someone please send them off for me.
Thanks,
Nick
From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] staging wlan-ng: Add missing a blank line after declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid,
void *buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void
*val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
1.9.1
From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Mon, 15 Sep 2014 17:07:24 -0400
Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
This removes the checkpatch errors related to a needed line below
declaration of a struct and another about a non nessary printk
message about a NULL allocated skb due to the function returning
NULL to the caller of the function and the printk no longer being'
used or needed by any callers.
spelling mistakes
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
-if (!skb) {
-pr_err(SKB allocation failed\n);
why the error message was removed ?
+if (!skb)
return NULL;
-}
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
ohhh .. yeah .. and both the patch failed when i tried to apply them to
next-20140916
why are we wasting our time for your patches , which are bound to have some
problem
thanks
sudip
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I tried these on Greg's tree of staging-next and they worked for me.
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014 08:44:27 -0400, nick said: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. I am attaching. Fail 3 words in. That's why you aren't getting a reply from the maintainers. They don't bother reading patches they know will probably *never* be correct. And yes, at least one of the two patches is incorrect. Thanks for the Help, I really do appreciate it and I do understand how much I have screwed up. My concern now is now to make it right. You don't make it right by posting more wrong patches. Now do us all a favor and *stop* being either an idiot, or a troll, or whatever your problem is. We have *zero* desire to see *any* more patches from somebody who is either unable or unwilling to post a *single* correct patch after *two months* of trying. So please do us a favor and go piss off some other open source project. THE KERNEL DOES NOT WANT YOUR BULLSHIT. pgpp7qwMl6MMy.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 6:41 PM, nick xerofo...@gmail.com wrote:
On 14-09-16 09:06 AM, Sudip Mukherjee wrote:
On Tue, Sep 16, 2014 at 08:44:27AM -0400, nick wrote:
I am attaching two check patch patches I wrote in the last few days as I am
unable to get a reply
from the maintainers. Would someone please send them off for me.
Thanks,
Nick
From 7bf4229fa2f9c4fcf3243bc738c74bfdc58a6594 Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Sat, 13 Sep 2014 11:53:24 -0400
Subject: [PATCH] staging wlan-ng: Add missing a blank line after
declarations
Fixing trivial checkpatch warnings about missing line after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
Tested by compilation only.
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid,
void *buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void
*val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
1.9.1
From 5eb3de22f0760ece1e838d48c8dd9148b4331cdc Mon Sep 17 00:00:00 2001
From: Nicholas Krause xerofo...@gmail.com
Date: Mon, 15 Sep 2014 17:07:24 -0400
Subject: [PATCH] staging netlogic: Fix checkpatch errors in xlr_net.c
This removes the checkpatch errors related to a needed line below
declaration of a struct and another about a non nessary printk
message about a NULL allocated skb due to the function returning
NULL to the caller of the function and the printk no longer being'
used or needed by any callers.
spelling mistakes
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/netlogic/xlr_net.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/netlogic/xlr_net.c
b/drivers/staging/netlogic/xlr_net.c
index 9bf407d..28a42831 100644
--- a/drivers/staging/netlogic/xlr_net.c
+++ b/drivers/staging/netlogic/xlr_net.c
@@ -142,10 +142,8 @@ static inline struct sk_buff *xlr_alloc_skb(void)
/* skb-data is cache aligned */
skb = alloc_skb(XLR_RX_BUF_SIZE, GFP_ATOMIC);
-if (!skb) {
-pr_err(SKB allocation failed\n);
why the error message was removed ?
+if (!skb)
return NULL;
-}
mac_put_skb_back_ptr(skb);
return skb;
}
@@ -1104,6 +1102,7 @@ err_gmac:
static int xlr_net_remove(struct platform_device *pdev)
{
struct xlr_net_priv *priv = platform_get_drvdata(pdev);
+
unregister_netdev(priv-ndev);
mdiobus_unregister(priv-mii_bus);
mdiobus_free(priv-mii_bus);
--
1.9.1
ohhh .. yeah .. and both the patch failed when i tried to apply them to
next-20140916
why are we wasting our time for your patches , which are bound to have some
problem
thanks
sudip
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I tried these on Greg's tree of staging-next and they worked for me.
Nick
in drivers/staging/netlogic/xlr_net.c file of next-20140916
1) in line 142 we just have an } else { (doesnot match your patch)
2) in the same file , there is only one instance of pr_err(SKB
allocation failed\n); , and that is at line 208 , and that is
followed by a return -ENOMEM; , but your patch is showing that there
is a return NULL
thanks
sudip
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
RE: x86_64_defconfig and i386_defconfig: What is the difference?
To add to this, if you're trying to compile a kernel to work for a specific platform or board and it's not working, 'make menuconfig' is your friend for taking a bare bones kernel .config and making it your own. -Original Message- From: linux-newbie-ow...@vger.kernel.org [mailto:linux-newbie-ow...@vger.kernel.org] On Behalf Of valdis.kletni...@vt.edu Sent: Tuesday, September 09, 2014 10:28 AM To: Matthias Brugger Cc: Rajat Jain; linux-new...@vger.kernel.org; kernelnewbies Subject: Re: x86_64_defconfig and i386_defconfig: What is the difference? On Tue, 09 Sep 2014 16:06:07 +0200, Matthias Brugger said: Can someone tell me if the i386 one is to be used when we want to build for a 32bit machine and the x86_64 is to be used for 64 bit machine? You can build the kernel with any architecture for any architecture. This is called cross-compiling. The homepage [0] should explain you how to do that. Right, but you still need to use a .config appropriate for the target machine, which is what I think Rajat was asking about. A defconfig is usually only known verified to boot on a few (possibly one) examples of that architecture hardware. For embedded ARM, it may be one specific development board or hardware device. For x86, I think they try to keep it will probably kind of sort of boot on generic PC hardware with a common distro, but anything fancylike a webcam or better graphics than vga tty emulation may not work. A defconfig is pretty much just a proof of concept starting point for an actual working config for a given hardware system. smime.p7s Description: S/MIME cryptographic signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How to debug Malformed Packet (Exception occurred) when send a udp packet?
On 2014-09-07 17:12:33 (+0800), lx lxlenovos...@gmail.com wrote: I want to send a udp packet in kernel module. the codes is: Why? // iph-version = 4; iph-ihl = 5; put_unaligned(0x45, (unsigned char *)send_iph); send_iph-tos = 0; put_unaligned(htons(iph_len), (send_iph-tot_len)); ^- That's probably your problem. Regards, Kristof ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 10:19 AM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 08:44:27 -0400, nick said: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. I am attaching. Fail 3 words in. That's why you aren't getting a reply from the maintainers. They don't bother reading patches they know will probably *never* be correct. And yes, at least one of the two patches is incorrect. Thanks for the Help, I really do appreciate it and I do understand how much I have screwed up. My concern now is now to make it right. You don't make it right by posting more wrong patches. Now do us all a favor and *stop* being either an idiot, or a troll, or whatever your problem is. We have *zero* desire to see *any* more patches from somebody who is either unable or unwilling to post a *single* correct patch after *two months* of trying. So please do us a favor and go piss off some other open source project. THE KERNEL DOES NOT WANT YOUR BULLSHIT. I am going to attach it again and I understand Valdis. I am going to talk to Sudip about reading and checking my patches first. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 5:44 PM, Nick Krause xerofo...@gmail.com wrote: On Tue, Sep 16, 2014 at 10:19 AM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 08:44:27 -0400, nick said: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. I am attaching. Fail 3 words in. That's why you aren't getting a reply from the maintainers. They don't bother reading patches they know will probably *never* be correct. And yes, at least one of the two patches is incorrect. Thanks for the Help, I really do appreciate it and I do understand how much I have screwed up. My concern now is now to make it right. You don't make it right by posting more wrong patches. Now do us all a favor and *stop* being either an idiot, or a troll, or whatever your problem is. We have *zero* desire to see *any* more patches from somebody who is either unable or unwilling to post a *single* correct patch after *two months* of trying. So please do us a favor and go piss off some other open source project. THE KERNEL DOES NOT WANT YOUR BULLSHIT. I am going to attach it again and I understand Valdis. I am going to talk to Sudip about reading and checking my patches first. Rik, probably it's time to ban Nick also from this ml. -- Carlo Caione ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
Nick, Use this guide: http://kernelnewbies.org/OPWfirstpatch It's a tutorial that shows you how to setup and send patches. And memorize these references: http://lxr.free-electrons.com/source/Documentation/SubmitChecklist http://lxr.free-electrons.com/source/Documentation/development-process/ Lidza On Tue, Sep 16, 2014 at 11:50 AM, Carlo Caione ca...@caione.org wrote: On Tue, Sep 16, 2014 at 5:44 PM, Nick Krause xerofo...@gmail.com wrote: On Tue, Sep 16, 2014 at 10:19 AM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 08:44:27 -0400, nick said: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. I am attaching. Fail 3 words in. That's why you aren't getting a reply from the maintainers. They don't bother reading patches they know will probably *never* be correct. And yes, at least one of the two patches is incorrect. Thanks for the Help, I really do appreciate it and I do understand how much I have screwed up. My concern now is now to make it right. You don't make it right by posting more wrong patches. Now do us all a favor and *stop* being either an idiot, or a troll, or whatever your problem is. We have *zero* desire to see *any* more patches from somebody who is either unable or unwilling to post a *single* correct patch after *two months* of trying. So please do us a favor and go piss off some other open source project. THE KERNEL DOES NOT WANT YOUR BULLSHIT. I am going to attach it again and I understand Valdis. I am going to talk to Sudip about reading and checking my patches first. Rik, probably it's time to ban Nick also from this ml. -- Carlo Caione ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014 11:57:35 -0400, Lidza Louina said: Use this guide: http://kernelnewbies.org/OPWfirstpatch It's a tutorial that shows you how to setup and send patches. Don't bother. He's been pointed at that at least once a week for the past two months, and everybody from me to Greg KH to Ted T'so and at least a half dozen other experienced kernel people have told him *repeatedly* what to do and not do, and he has *yet* to post a correct patch - and he keeps making the same mistakes that he was told not to. For instance, I didn't even *bother* looking at his last two patches, because they were attachments, even *after* Robert PJ Day told him *yesterday* to not do that. pgp35oNCc5ASc.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 11:44:59AM -0400, Nick Krause wrote: On Tue, Sep 16, 2014 at 10:19 AM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 08:44:27 -0400, nick said: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. I am attaching. Fail 3 words in. [snip] I am going to attach it again and I understand Valdis. I am going to talk to Sudip about reading and checking my patches first. The email that you are replying to repeats the statement that attaching the patches is the wrong thing to be doing. And yet, in the reply, you talk about attaching patches. Can you please explain what's going on here? Did you forget about it while you were writing the three line response? Did you simply ignore the words? Did you assume that it didn't apply to you? Did you merely think it wasn't important? Do you have short-term memory problems? Is there something else I don't know about? I understand that you're a student (or will shortly be one), and so far you're showing *major* learning difficulties, without any apparent self-identification of the fact. If you do actually have some kind of learning difficulty, you're going to have to take charge of it yourself, seek professional advice, use that to work out how you can learn, and start doing it, because if you behave like this in any institution of higher learning, you're going to have big problems, probably very quickly. You've spent two months, with *lots* of explicit recommendations on how you should be modifying your behaviour (i.e. learning), and so far you've utterly failed to do so. It's up to you to seek help in identifying the difficulties you have in learning, and to use the results of that to work out how you can do so. This kernel development environment is *absolutely* the wrong one for you to be doing that exercise in. I doubt that there are many (if any) people on this mailing list who have the knowledge or skills to help you. I am certain that if there are any, none of them would be willing to start the process via email. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- Big data doesn't just mean increasing the font size --- signature.asc Description: Digital signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 11:57:35 -0400, Lidza Louina said: Use this guide: http://kernelnewbies.org/OPWfirstpatch It's a tutorial that shows you how to setup and send patches. Don't bother. He's been pointed at that at least once a week for the past two months, and everybody from me to Greg KH to Ted T'so and at least a half dozen other experienced kernel people have told him *repeatedly* what to do and not do, and he has *yet* to post a correct patch - and he keeps making the same mistakes that he was told not to. For instance, I didn't even *bother* looking at his last two patches, because they were attachments, even *after* Robert PJ Day told him *yesterday* to not do that. i posted three simple pieces of advice yesterday: * proper grammar, at the very least in the subject line * make sure the commit description matches the patch * no attachments nick promptly violated all of the above. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014, Lidza Louina wrote: Nick, Use this guide: http://kernelnewbies.org/OPWfirstpatch It's a tutorial that shows you how to setup and send patches. And memorize these references: http://lxr.free-electrons.com/source/Documentation/SubmitChecklist http://lxr.free-electrons.com/source/Documentation/development-process/ Lidza i'm going to back up carlo ... time to ban nick as i suggested a while back. giving nick more references is not going to help -- he is simply unteachable. in a nutshell, nick brings no value to this mailing list. quite the opposite -- he devalues it significantly by wasting bandwidth and just plain pissing people off. all by himself, nick makes this mailing list a worse place. if nick showed any sign of progress whatsoever, that would be different. but he doesn't. so, please, pull the plug on him. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On 9/16/14, Nick Krause xerofo...@gmail.com wrote: On Tue, Sep 16, 2014 at 10:19 AM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 08:44:27 -0400, nick said: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. I am attaching. Fail 3 words in. That's why you aren't getting a reply from the maintainers. They don't bother reading patches they know will probably *never* be correct. And yes, at least one of the two patches is incorrect. Thanks for the Help, I really do appreciate it and I do understand how much I have screwed up. My concern now is now to make it right. You don't make it right by posting more wrong patches. Now do us all a favor and *stop* being either an idiot, or a troll, or whatever your problem is. We have *zero* desire to see *any* more patches from somebody who is either unable or unwilling to post a *single* correct patch after *two months* of trying. So please do us a favor and go piss off some other open source project. THE KERNEL DOES NOT WANT YOUR BULLSHIT. I am going to attach it again and I understand Valdis. I am going to talk to Sudip about reading and checking my patches first. Nick plzzz .. NO ... today i checked your patches just to take a break from what i was doing.. and besides , i am also a newbie , i also make mistakes when submitting patches, but i try to learn from my mistakes and see to it that they are never repeated. apart from the numerous advises you got from the LKML , i think just yesterday Robert P. J. Day has pointed out something, day before yesterday Valdis , before that ( sorry i lost track) ... and you have not cared to listen to any of that .. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 12:57 PM, Sudip Mukherjee sudipm.mukher...@gmail.com wrote: On 9/16/14, Nick Krause xerofo...@gmail.com wrote: On Tue, Sep 16, 2014 at 10:19 AM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 08:44:27 -0400, nick said: I am attaching two check patch patches I wrote in the last few days as I am unable to get a reply from the maintainers. Would someone please send them off for me. I am attaching. Fail 3 words in. That's why you aren't getting a reply from the maintainers. They don't bother reading patches they know will probably *never* be correct. And yes, at least one of the two patches is incorrect. Thanks for the Help, I really do appreciate it and I do understand how much I have screwed up. My concern now is now to make it right. You don't make it right by posting more wrong patches. Now do us all a favor and *stop* being either an idiot, or a troll, or whatever your problem is. We have *zero* desire to see *any* more patches from somebody who is either unable or unwilling to post a *single* correct patch after *two months* of trying. So please do us a favor and go piss off some other open source project. THE KERNEL DOES NOT WANT YOUR BULLSHIT. I am going to attach it again and I understand Valdis. I am going to talk to Sudip about reading and checking my patches first. Nick plzzz .. NO ... today i checked your patches just to take a break from what i was doing.. and besides , i am also a newbie , i also make mistakes when submitting patches, but i try to learn from my mistakes and see to it that they are never repeated. apart from the numerous advises you got from the LKML , i think just yesterday Robert P. J. Day has pointed out something, day before yesterday Valdis , before that ( sorry i lost track) ... and you have not cared to listen to any of that .. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies I am going to resend my patch and see if it's good and if not I am going to leave for a while. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014, Nick Krause wrote: I am going to resend my patch and see if it's good ... because, of course, that's the correct order of events -- send the patch, *then* validate its correctness. ban. for the love of mutt, please, ban. there is no excuse for this anymore. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/16/2014 01:12 PM, Nick Krause wrote: I am going to resend my patch and see if it's good and if not I am going to leave for a while. You may want to consider fixing them, by applying the advice provided by many people, before resending them. - -- All rights reversed. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUGHMmAAoJEM553pKExN6Dvw4IAKi2no5OpH9TUgcCd5zRHTsb oqFsZ2xR21bgnIyfM93V+h9QtG+Fuc+WOScCL1Ofk4OWVXWV6gIgHHSGBOb0cEBf zGTxhMyRdPUl7WHAn7KHWAEqhCGQlIp0QyyRiXjnNLmSmGYt/9yv3TrvmZE0xuJw /jrq+H93AxTXXVzIjfpnziXMD5w3/Zt9+FPlyuNjyVh2Hnlf2CbwfSqsgsJETZOx ML+CNsl/2CAXkJ1++CUQ94iC4plAPekVrpXAea4xqWqargD8Hcm0jqWuD9vns0ZA VDJU669ocBlZRVCdZI6axGm4JAdtceQLLMMVZtzre8IAELB9JPiUC/C6g7e60Cg= =oeV3 -END PGP SIGNATURE- ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014 13:12:32 -0400, Nick Krause said: I am going to resend my patch and see if it's good Why bother? We already *know* it won't be. You could amaze and astound us all by seeing if it's good *before* you hit send. But I'm not holding my breath. and if not I am going to leave for a while. Actions. Not words. pgpPFmcc0SEED.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014 13:28:06 -0400, Rik van Riel said: -BEGIN PGP SIGNED MESSAGE- On 09/16/2014 01:12 PM, Nick Krause wrote: I am going to resend my patch and see if it's good and if not I am going to leave for a while. You may want to consider fixing them, by applying the advice provided by many people, before resending them. That's just crazy talk. pgptnWJkjpmHX.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
PCI error handlers in Linux
Hello, In my pci driver for a certain pci device, I implemented the pci error handler functions (error_detected, slot_reset methods, etc). I want to trigger a pci error for me to exercise those handlers and observe its behavior. I've read from the pci error recovery kernel documentation that the 1st step is with error_detected method, called by the system if it detected any error related to the pci device. The good thing is that the system will detect it for the driver, simplifying things. But I'm having problems with error detection itself. I tried to trigger the error via the PCI device. On its FW, I triggered a reset of its PCI subsystem. As a result, the I/O rate dropped to zero and the driver now can't send to the device. Something indeed happened in their PCI connection. However, I couldn't see my error_detected method being called, when I was expecting the kernel will detect the PCI error and call the handler. Instead, some warning message appeared in the console as follows: irq 16: nobody cared handlers: ... ... Disabling IRQ # 16 What baffles me more is that the injected PCI error seemed to brought down that IRQ 16 device as well - which is definitely not the irq # of my driver/device. Any thoughts on why the kernel did not detect that PCI error? Is there anything I could possibly missed during registration of error handler methods? If that is so, I'd like to ask for other means of injecting PCI errors, in order for me to exercise my error handlers. Thanks! ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: PCI error handlers in Linux
On Wed, Sep 17, 2014 at 02:04:04AM +0800, Alvin Abitria wrote: Hello, In my pci driver for a certain pci device, I implemented the pci error handler functions (error_detected, slot_reset methods, etc). I want to trigger a pci error for me to exercise those handlers and observe its behavior. I've read from the pci error recovery kernel documentation that the 1st step is with error_detected method, called by the system if it detected any error related to the pci device. The good thing is that the system will detect it for the driver, simplifying things. But I'm having problems with error detection itself. I tried to trigger the error via the PCI device. On its FW, I triggered a reset of its PCI subsystem. As a result, the I/O rate dropped to zero and the driver now can't send to the device. Something indeed happened in their PCI connection. However, I couldn't see my error_detected method being called, when I was expecting the kernel will detect the PCI error and call the handler. Instead, some warning message appeared in the console as follows: irq 16: nobody cared handlers: ... ... Disabling IRQ # 16 What baffles me more is that the injected PCI error seemed to brought down that IRQ 16 device as well - which is definitely not the irq # of my driver/device. Any thoughts on why the kernel did not detect that PCI error? Is there anything I could possibly missed during registration of error handler methods? If that is so, I'd like to ask for other means of injecting PCI errors, in order for me to exercise my error handlers. Thanks! You might want to ask this on the linux-...@vger.kernel.org mailing list instead. The developers there can help you out better than the people here can. Hope this helps, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, Sep 16, 2014 at 1:39 PM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 13:28:06 -0400, Rik van Riel said: -BEGIN PGP SIGNED MESSAGE- On 09/16/2014 01:12 PM, Nick Krause wrote: I am going to resend my patch and see if it's good and if not I am going to leave for a while. You may want to consider fixing them, by applying the advice provided by many people, before resending them. That's just crazy talk. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies I am fixing them first and them sending them out. I am going to listen now and only do them correctly. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/16/2014 02:36 PM, Kristofer Hallin wrote: On Tue, Sep 16, 2014 at 8:29 PM, Nick Krause xerofo...@gmail.com wrote: On Tue, Sep 16, 2014 at 1:39 PM, valdis.kletni...@vt.edu wrote: On Tue, 16 Sep 2014 13:28:06 -0400, Rik van Riel said: -BEGIN PGP SIGNED MESSAGE- On 09/16/2014 01:12 PM, Nick Krause wrote: I am going to resend my patch and see if it's good and if not I am going to leave for a while. You may want to consider fixing them, by applying the advice provided by many people, before resending them. That's just crazy talk. I am fixing them first and them sending them out. I am going to listen now and only do them correctly. Nick No, you won't. Nick, this is a chance for you to prove the nay-sayers wrong (or right). When re-posting your patch, you can include information on what tips you got on how to improve the patch, and how you applied that information in the new version of the patch. This is a good idea for anybody resubmitting a changed patch, because it tells other reviewers what changes were made, why, and who pointed out the idea for the change. - -- All rights reversed. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUGIUeAAoJEM553pKExN6DEt8H/36FILPmG4wOK3TZFpQEVJHv Lxq4DLq7GBUS37PhL/wjdYnLD4RJmOhpGk+FlZBhJ0StnCvS38Su7wwyZTzgCPIS ir3EYOKhiFgEEuoB4iVaDc2FNv9jKKRVy/QK3jwkdt5oTBvr/I6YZzj2XAFJaUp9 0/RvdSNZU6kcvhTkd5xdDaaX1iOpxrggccRl+Pv2GBapeIEKvO6zk9U2GuLw+r6q OLfJ5BElpEReoqFJNUXxzT+UyTmMel21REdfyu9UxAEONrQ2A3UHx/7upy71YpyR a/IADIuBSXTdb31b+uuoFPfSUp4cs7WMyIDK2/tlL8wF28GLoL39X2xhWE3gkUU= =7mL1 -END PGP SIGNATURE- ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
I am fixing them first and them sending them out. I am going to listen now and only do them correctly. Nick, you're very close to being banned from kernelnewbies too, so please give some thought to other people's advise or else this might be your last email to kernelnewbies. As a first step, DON'T send patches as attachments, send them INLINE in PLAIN TEXT. You need to demonstrate an understanding of this basic instruction or else nobody will be able to help you. And frankly, you need to stop fixing anything in the kernel till you get some level of proficiency in basic programming and working collaboratively in opensource projects. Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: Checkpatch Patches
On Tue, 16 Sep 2014, Rik van Riel wrote: Nick, this is a chance for you to prove the nay-sayers wrong (or right). When re-posting your patch, you can include information on what tips you got on how to improve the patch, and how you applied that information in the new version of the patch. This is a good idea for anybody resubmitting a changed patch, because it tells other reviewers what changes were made, why, and who pointed out the idea for the change. my god, rik, you're adorable. :-) i predict that, despite what i've posted *twice*, nick will describe as an error what is simply a checkpatch coding style *warning*. let's watch ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH] staging wlan-ng: Add missing a blank line after declarations
Fixing trivial checkpatch warnings about missing line after declarations
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw,
u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing a blank line after declarations
On 14-09-16 05:20 PM, Nicholas Krause wrote:
Fixing trivial checkpatch warnings about missing line after declarations
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
I checked this patch and there seems to be issues that any of you have stated
before after not applying or grammar e.t.c. If there are any other errors I am
missing please let me known.
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing a blank line after declarations
and for a third (fourth?) time, unable to use proper grammar in the commit message. shocked ... shocked, i am. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH] staging wlan-ng: Add missing blank lines after declarations
Fixing trivial checkpatch warnings about missing line after declarations
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw,
u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing a blank line after declarations
On Tue, 16 Sep 2014, Nicholas Krause wrote:
Fixing trivial checkpatch warnings about missing line after declarations
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
for the benefit of other kernel newbies who would, some day, like to
get some patches into the linux kernel, let me explain why the above,
even if it was correct, is utterly worthless rubbish.
among all the other properties of a good kernel patch, one property
suggests that a patch should have some *value*. it should address some
actual issue, fix a bug or, at the very least, clean up some code. and
if you're going to just clean things up, then it would make sense to
do that cleanup across a wide swath of code to avoid submitting
trivial patch after trivial patch.
as you can see above, nick has submitted a patch whose *entire*
functionality is ... to add three blank lines to a file. yes, after
two months of failure after failure, nick has become so desperate to
get *something* into the kernel that he has officially submitted a
patch that adds three blank lines to a file, and fixes no errors
whatever.
this is where have finally ended up ... nick is reduced to a patch
that adds blank lines to a file, and he can't even get *that* right.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing a blank line after declarations
On Tue, 16 Sep 2014 17:23:05 -0400, nick said: I checked this patch and there seems to be issues that any of you have stated before after not applying or grammar e.t.c. If there seem to be issues, why did you bother posting it? pgpf6oJH5i0Dq.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH] staging wlan-ng: Add missing blank lines after declarations
Fixing trivial checkpatch warnings about missing blanks lines after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw,
u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing blank lines after declarations
On 14-09-16 05:58 PM, Nicholas Krause wrote:
Fixing trivial checkpatch warnings about missing blanks lines after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
I checked my grammar. I am assuming I am still wrong through.
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Issues with Community
After numerous tries at good patches and still failing , I am listening to what you guys stated about my patches check it applies, grammar and build checks. I am still unable to get a good patch and would really appreciate it if someone walks me through one good patch as I will learn this will a tutor and the tutor can help be my router to the community for now in order to start helping me learn how to be involved correctly and follow the community rules. I am willing to work on my patches if someone is willing to do this for me and help me improve my taste in the communities mouth. Thanks, Nick ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
A quick guide to why stand-alone checkpatch patches suck...
In general, stand-alone patches to fix checkpatch whining are a Bad Idea(TM). Here's why... First off, the type of programmer who is tempted to do checkpatch cleanup as My First Kernel Patch are, by and large, novices. The code in the kernel falls into one of several states of use and stability. Some code is old and heavily used, some is old and not used, and some of it is under active development. Let's look at each case. There's parts of the kernel that have been around for *years* and are beat on constantly - the VFS, the driver core code, large parts of the network stack for example. Stand-alone checkpatch fixes here aren't a good idea, because they're potentially destabilizing if somebody gets the fix wrong. And yes, this has happened, and checkpatch fixes have actually introduced bugs - it's part of why there's a one thing, one patch rule, to make it easier to audit a patch and ensure it doesn't introduce regressions. Oh, and most of this sort of code is already *really* clean, because professionals have cleaned it up. There's parts of the kernel that are digital archaeology waiting to happen (I'm looking at you, floppy.c :). Again, fixing style is probably a Bad Idea, because (a) you might introduce a bug and (b) nobody is even looking at this code anymore, so nobody *cares* about the style. And if it's an abandoned part of the code, there may be nobody who cares/understands it well enough to notice if a subtle bug is introduced. So that leaves us code that's under active development. And here, checkpatch fixes are actually a *detriment*, and they tick the subsystem maintainer off. That's because they have a high probability of causing merge conflicts with somebody else's patches that are doing *actual code improvement*. The end result? Unless you *are* that somebody else who's doing other work on the code, you shouldn't submit checkpatch cleanups. So we shouldn't see these from anybody except as prep work for actual coding. (But by all means, if you're about to apply a can-opener to a .c file to do some Real Work, feel free to spin a preparatory set of cleanup patches so you're performing code surgery on a properly scrubbed, prepped, and anesthetized patient :) pgpmlpJ3Qbd8_.pgp Description: PGP signature ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Tue, Sep 16, 2014 at 08:25:51PM -0400, Valdis Kletnieks wrote: In general, stand-alone patches to fix checkpatch whining are a Bad Idea(TM). snip And here's why checkpatch patches are a Good Idea(TM): - it teaches you how to set up your email client properly - it teaches you how to describe a patch properly - it teaches you how to submit a patch properly - it gives you a good feedback loop - it is an easy place to start. But, and this is a huge BUT, which you ignored, you should ONLY submit a checkpatch cleanup for a subsystem that has a maintainer that welcomes them. Like drivers/staging/*. Checkpatch cleanups are welcome, and encouraged there. If you want to do a checkpatch cleanup, do it there, you will not be yelled at. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing blank lines after declarations
On Tue, 2014-09-16 at 17:59 -0400, nick wrote: On 14-09-16 05:58 PM, Nicholas Krause wrote: Fixing trivial checkpatch warnings about missing blanks lines after declarations. blanks lines after declarations. I checked my grammar. I am assuming I am still wrong through. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Tue, Sep 16, 2014 at 7:25 PM, Valdis Kletnieks valdis.kletni...@vt.edu wrote: In general, stand-alone patches to fix checkpatch whining are a Bad Idea(TM). That's just YOUR opinion. GregKH actually made a presentation to help us n00bs do exactly that: https://www.youtube.com/watch?v=LLBrBBImJt4 And he has been applying my cleanup patches for nearly a month now: http://git.kernel.org/cgit/linux/kernel/git/gregkh/staging.git/log/?h=staging-nextqt=authorq=gdonald First off, the type of programmer who is tempted to do checkpatch cleanup as My First Kernel Patch are, by and large, novices. OMG, I'm a novice.. cat's out of the bag! Your point? There's parts of the kernel that have been around for *years* and are beat on constantly - the VFS, the driver core code, large parts of the network stack for example. Stand-alone checkpatch fixes here aren't a good idea, because they're potentially destabilizing if somebody gets the fix wrong. And yes, this has happened, and checkpatch fixes have actually introduced bugs - it's part of why there's a one thing, one patch rule, to make it easier to audit a patch and ensure it doesn't introduce regressions. Oh, and most of this sort of code is already *really* clean, because professionals have cleaned it up. fs/* currently contains 96,375 errors and 22,555 warnings. net/* currently contains 3,366 errors and 19,536 warnings. *really* clean? LOL. So that leaves us code that's under active development. And here, checkpatch fixes are actually a *detriment*, and they tick the subsystem maintainer off. That's because they have a high probability of causing merge conflicts with somebody else's patches that are doing *actual code improvement*. So? Either you suck it up and re-spin your patch or you go home and cry. The end result? Unless you *are* that somebody else who's doing other work on the code, you shouldn't submit checkpatch cleanups. I do Kernel janitor work for the *fun* of it. I program in Python, Java, and ObjC and manage a bunch of Linux servers at my day job.. so changing up and doing Kernel cleanups in my spare time is *fun*. I may or may not ever actually become a full-fledged Kernel hacker and I don't really care either way. Meanwhile drivers/staging/* contains 19,004 errors and 35,292 warnings and until the man stops taking my patches I'm going to continue sending them. As for you I'm just gonna ignore you and your discouraging posts from here on. It's not like you're in MAINTAINERS or anything. -- Greg Donald ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
[PATCH] staging wlan-ng: Add missing blank lines after declarations
Fixing trivial checkpatch warnings about missing blank lines after declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw,
u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
--
1.9.1
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: [PATCH] staging wlan-ng: Add missing blank lines after declarations
On 14-09-16 10:41 PM, Nicholas Krause wrote:
Fixing trivial checkpatch warnings about missing blank lines after
declarations.
Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
drivers/staging/wlan-ng/hfa384x.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/wlan-ng/hfa384x.h
b/drivers/staging/wlan-ng/hfa384x.h
index 1f2c78c..20d146b 100644
--- a/drivers/staging/wlan-ng/hfa384x.h
+++ b/drivers/staging/wlan-ng/hfa384x.h
@@ -1376,6 +1376,7 @@ int hfa384x_drvr_setconfig(hfa384x_t *hw, u16 rid, void
*buf, u16 len);
static inline int hfa384x_drvr_getconfig16(hfa384x_t *hw, u16 rid, void *val)
{
int result = 0;
+
result = hfa384x_drvr_getconfig(hw, rid, val, sizeof(u16));
if (result == 0)
*((u16 *) val) = le16_to_cpu(*((u16 *) val));
@@ -1385,6 +1386,7 @@ static inline int hfa384x_drvr_getconfig16(hfa384x_t
*hw, u16 rid, void *val)
static inline int hfa384x_drvr_setconfig16(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig(hw, rid, value, sizeof(value));
}
@@ -1402,6 +1404,7 @@ static inline int
hfa384x_drvr_setconfig16_async(hfa384x_t *hw, u16 rid, u16 val)
{
u16 value = cpu_to_le16(val);
+
return hfa384x_drvr_setconfig_async(hw, rid, value, sizeof(value),
NULL, NULL);
}
Greg and others,
Thanks to Amit for checking my grammar firstly. I would like to known before I
start cleaning drivers/staging/ and it's subdirectories if this patch is good
and valid so I can use it as a template for me to look at when I send out
my other patches.
Thanks and Am So Thankful for all the Chances Here,
Nick
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: suspend/resume PM criterion for application
On Sun, Sep 14, 2014 at 2:11 AM, Ran Shalit ransha...@gmail.com wrote: On Thu, Sep 11, 2014 at 12:24 PM, Ran Shalit ransha...@gmail.com wrote: On Thu, Sep 11, 2014 at 8:32 AM, AYAN KUMAR HALDER ayankum...@gmail.com wrote: On Thu, Sep 11, 2014 at 12:55 AM, valdis.kletni...@vt.edu wrote: On Wed, 10 Sep 2014 21:58:48 +0300, Ran Shalit said: 1. How can I make a process to notice this inactivity ? Do you think it can be implemented by some periodic process who check if there is activity ? It returns to the original question I raised, that I will use some periodic process who checks maybe cpu load or something like that. What do you think ? That's going to depend on your system and what processes are running. You may have an MP3 player going that doesn't take much CPU at all - but shutting down because the user hasn't hit a button in 47 minutes will probably irritate the user no end. Or there may be a screensaver running that takes twice as much CPU as the MP3 player, but is totally OK on the system suspending whenever the rest of the system wants it. You're going to have to look at your system design, and decide for yourself what the criteria are. Please correct me if my understanding is wrong:- I believe that autosuspend feature (for system suspend) is not present in kernel. I believe that there is no feature in kernel which checks for system ( cpu, devices) inactivity and suspends the entire system. System suspend is caused when :- 1. the user issues a command 2. The system receives some interrupt or event (lid closing event) 3. There is an external process which monitors system inactivity and suspends the system. For runtime suspend of a device, I believe it is the driver who has the complete responsibility to decide when to suspend the device or resume it. The driver can take this decision on user intervention (eg when user writes to /sys/devices/my-device/power/* ) or when the driver has completed servicing an interrupt and feels it has nothing more to do, etc Thanks Vlaid, Ayan, I am a bit yet struggling for couple of days on this PM issue, and I would appreciate your continous advise. The system requirement I have is as following: 1. make everything as automatic as possible , so that there won't be any need to add any userspace application for the matter. 2. wakeup from all relevant wakeup sources 3. should not use sysfs (it should be disabled from kernel) 4. platform is OMAP3530. a. look into /arch/arm/mach-omap2 of kernel source and grep for sleep and wakeup functionality: power management is just managing with the different frequencies of the the CPU. as far as I can tell, once sleep, only uart pin can be used for waking upnot sure. b. read this: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/30005.aspx http://www.ti.com/lit/an/slva310b/slva310b.pdf (read page 2, which describe the different powerup-sequence of the CPU, Powering-Up Sequence. c. the technology brand name for omap3530 is DVFSsearch for this inside the arch/arm kernel source.you can find lots of sample codes there. (don't confuse with another omap CPU brand name DeepSleep but is PM for another type of omap cpu.) d. http://www.ti.com/product/omap3530 -- on the right is a DVSDK + Android source code for 3530grep the codes for the above keywords... hopefully it helps? Now, As I understand thus far, I have the following options ( requirement 3 above I will ignore, don't know how to handle it yet, and assume for meanwhile that I have sysfs) : 1. use suspend scheme (no runtime PM) 1.a. create some kernel thread who check cpu load and will decide to disable system only if its below some minimum threshold (which should indicate no activity) 1.b. initialize all HW interrupts (gpio, uart, etc) as wakeup sources with this scheme only this thread is responsible for the suspend, and there is no use of the runtime PM, right ? 2. use runtime PM scheme : With this scheme I don't understand how some device will wake the system , or doesn't it need to ? If a driver wakes up maybe it need to deliver some info to system? I think option 1 is also easier to support, what do you think about both ? Thanks!! Ran Does Anyone have any suggestions and feedback on the above requirements ? Thank you, Ran ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: suspend/resume PM criterion for application
On Wed, Sep 17, 2014 at 11:16 AM, Peter Teoh htmldevelo...@gmail.com wrote: On Sun, Sep 14, 2014 at 2:11 AM, Ran Shalit ransha...@gmail.com wrote: On Thu, Sep 11, 2014 at 12:24 PM, Ran Shalit ransha...@gmail.com wrote: On Thu, Sep 11, 2014 at 8:32 AM, AYAN KUMAR HALDER ayankum...@gmail.com wrote: On Thu, Sep 11, 2014 at 12:55 AM, valdis.kletni...@vt.edu wrote: On Wed, 10 Sep 2014 21:58:48 +0300, Ran Shalit said: 1. How can I make a process to notice this inactivity ? Do you think it can be implemented by some periodic process who check if there is activity ? It returns to the original question I raised, that I will use some periodic process who checks maybe cpu load or something like that. What do you think ? That's going to depend on your system and what processes are running. You may have an MP3 player going that doesn't take much CPU at all - but shutting down because the user hasn't hit a button in 47 minutes will probably irritate the user no end. Or there may be a screensaver running that takes twice as much CPU as the MP3 player, but is totally OK on the system suspending whenever the rest of the system wants it. You're going to have to look at your system design, and decide for yourself what the criteria are. Please correct me if my understanding is wrong:- I believe that autosuspend feature (for system suspend) is not present in kernel. I believe that there is no feature in kernel which checks for system ( cpu, devices) inactivity and suspends the entire system. System suspend is caused when :- 1. the user issues a command 2. The system receives some interrupt or event (lid closing event) 3. There is an external process which monitors system inactivity and suspends the system. For runtime suspend of a device, I believe it is the driver who has the complete responsibility to decide when to suspend the device or resume it. The driver can take this decision on user intervention (eg when user writes to /sys/devices/my-device/power/* ) or when the driver has completed servicing an interrupt and feels it has nothing more to do, etc Thanks Vlaid, Ayan, I am a bit yet struggling for couple of days on this PM issue, and I would appreciate your continous advise. The system requirement I have is as following: 1. make everything as automatic as possible , so that there won't be any need to add any userspace application for the matter. 2. wakeup from all relevant wakeup sources 3. should not use sysfs (it should be disabled from kernel) 4. platform is OMAP3530. a. look into /arch/arm/mach-omap2 of kernel source and grep for sleep and wakeup functionality: power management is just managing with the different frequencies of the the CPU. as far as I can tell, once sleep, only uart pin can be used for waking upnot sure. b. read this: http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/t/30005.aspx http://www.ti.com/lit/an/slva310b/slva310b.pdf (read page 2, which describe the different powerup-sequence of the CPU, Powering-Up Sequence. c. the technology brand name for omap3530 is DVFSsearch for this inside the arch/arm kernel source.you can find lots of sample codes there. (don't confuse with another omap CPU brand name DeepSleep but is PM for another type of omap cpu.) d. http://www.ti.com/product/omap3530 -- on the right is a DVSDK + Android source code for 3530grep the codes for the above keywords... hopefully it helps? at the risk of missing out other files: how about this two files: inside arch/arm/mach-omap2: omap-pm.h omap-pm-noop.c which I think provide a lot of hint for you. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Tue, 16 Sep 2014 20:35:35 -0500, Greg Donald said:
fs/* currently contains 96,375 errors and 22,555 warnings.
[/usr/src/linux-next] find fs -type f -name '*.[ch]' | xargs cat | wc -l
1138557
96K errors seemed to be a tad high. So.. doublechecking..
[/usr/src/linux-next] for i in `find fs -type f -name '*.[ch]'`; do
scripts/checkpatch.pl -f $i; done /tmp/fs.check
And sure enough, looking through egrep '^total|^fs' /tmp/fs.check, we find
4 really big offenders.
total: 9823 errors, 0 warnings, 7933 lines checked
fs/nls/nls_cp932.c has style problems, please review.
total: 19512 errors, 0 warnings, 9482 lines checked
fs/nls/nls_cp950.c has style problems, please review.
total: 27672 errors, 0 warnings, 13946 lines checked
fs/nls/nls_cp949.c has style problems, please review.
total: 27252 errors, 4 warnings, 1 lines checked
fs/nls/nls_cp936.c has style problems, please review.
And git blame says this about nls_cp932.c:
b9ec0339d8e22 (Denys Vlasenko 2007-10-16 23:29:54 -0700 16) static const
wchar_t c2u_81[256] = {
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 17)
0x,0x,0x,0x,0x,0x,0x,0x,/* 0x00-0x07 */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 18)
0x,0x,0x,0x,0x,0x,0x,0x,/* 0x08-0x0F */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 19)
0x,0x,0x,0x,0x,0x,0x,0x,/* 0x10-0x17 */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 20)
0x,0x,0x,0x,0x,0x,0x,0x,/* 0x18-0x1F */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 21)
0x,0x,0x,0x,0x,0x,0x,0x,/* 0x20-0x27 */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 22)
0x,0x,0x,0x,0x,0x,0x,0x,/* 0x28-0x2F */
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 23)
0x,0x,0x,0x,0x,0x,0x,0x,/* 0x30-0x37 */
You're looking at 56 checkpatch errors right there.
Yes, it's been missing the 8 spaces after the 8 commas since the initial import
into git almost a decade ago. And those lines are already 74 characters, so you
can't add the missing blanks after the ','s without putting the line over 80
chars... So maybe it's time to actually *think* a bit about what checkpatch
is telling us.
Excluding those 4 files, we're down to 12116 errors which works out
to one every 93 lines.
grep ^ERROR /tmp/fs.check | sort | uniq -c | sort -nr | head
84812 ERROR: space required after that ',' (ctx:VxV)
2105 ERROR: trailing whitespace
1518 ERROR: foo * bar should be foo *bar
1393 ERROR: code indent should use tabs where possible
989 ERROR: do not use assignment in if condition
Wow. Another 2,105 errors are trailing whitespace, and another
1,393 are places somebody used spaces instead of tabs. Oh, the humanity.
Especially since these are invisible to somebody reading the code (unlike
the foo * bar/ foo *bar thing).
Exclude those two cases and we're up to one error every 132 lines.
(For comparison, the first few most popular warnings:
6215 WARNING: line over 80 characters
3241 WARNING: quoted string split across lines
2715 WARNING: Missing a blank line after declarations
1771 WARNING: please, no spaces at the start of a line
1742 WARNING: __constant_cpu_to_le32 should be cpu_to_le32
1030 WARNING: space prohibited between function name and open parenthesis '('
681 WARNING: please, no space before tabs
530 WARNING: Prefer [subsystem eg: netdev]_err([subsystem]dev, ... then
dev_err(dev, ... then pr_err(... to printk(KERN_ERR ...
Obviously, the checkpatch distinction of warning versus error could itself
use some tuning. Though it's right that somebody should probably
smack fs/cifs/nterr.h around with a large trout, that's a bunch of
precedence bugs waiting to happen.
net/* currently contains 3,366 errors and 19,536 warnings.
[/usr/src/linux-next] find net -type f -name '*.[ch]' | xargs cat | wc -l
850658
That works out to 1 error in net/ every 252 lines.
Meanwhile drivers/staging/* contains 19,004 errors and 35,292 warnings
find drivers/staging -type f -name '*.[ch]' | xargs cat | wc -l
1037877
That works out to 1 error every 54 lines. You'll have to fix around 7,800
of those 19,004 errors before the code is as clean as fs/, and 15,000 of
them to get drivers/staging up to net/ standards. Better get patching. :)
(And this sort of analysis is exactly *why* people need to apply their brains
when looking at checkpatch output)
pgp0qMqErYDWh.pgp
Description: PGP signature
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Tue, Sep 16, 2014 at 11:42:18PM -0400, valdis.kletni...@vt.edu wrote: (And this sort of analysis is exactly *why* people need to apply their brains when looking at checkpatch output) No one has ever said that they shouldn't. Remember, I know _lots_ of kernel developers who started with just checkpatch cleanups on staging drivers and they moved on to much higher roles in the kernel developer ecosystem (jobs, maintainers of subsystems, keynote talks at conferences, etc.) Don't po po it as something that shouldn't be a valid place to start, it is, and is why I do the work to review all of the many thousands of staging patches every release cycle. No one is forcing you to write those patches, or read / review them, so don't discourage others to provide them either please. I most certainly do not. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: A quick guide to why stand-alone checkpatch patches suck...
On Wed, Sep 17, 2014 at 10:26 AM, Greg KH g...@kroah.com wrote: On Tue, Sep 16, 2014 at 11:42:18PM -0400, valdis.kletni...@vt.edu wrote: (And this sort of analysis is exactly *why* people need to apply their brains when looking at checkpatch output) No one has ever said that they shouldn't. Remember, I know _lots_ of kernel developers who started with just checkpatch cleanups on staging drivers and they moved on to much higher roles in the kernel developer ecosystem (jobs, maintainers of subsystems, keynote talks at conferences, etc.) thats encouraging information . :) thanks Greg Don't po po it as something that shouldn't be a valid place to start, it is, and is why I do the work to review all of the many thousands of staging patches every release cycle. No one is forcing you to write those patches, or read / review them, so don't discourage others to provide them either please. I most certainly do not. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
