Checkpatch Patches
Sudip Mukherjee
sudipm.mukherjee at gmail.com
Tue Sep 16 09:47:11 EDT 2014
On Tue, Sep 16, 2014 at 7:16 PM, Sudip Mukherjee
<sudipm.mukherjee at gmail.com> wrote:
> On Tue, Sep 16, 2014 at 7:02 PM, nick <xerofoify at gmail.com> wrote:
>>
>>
>> On 14-09-16 09:28 AM, Sudip Mukherjee wrote:
>>> On Tue, Sep 16, 2014 at 6:56 PM, nick <xerofoify at gmail.com> wrote:
>>>>
>>>>
>>>> On 14-09-16 09:21 AM, Sudip Mukherjee wrote:
>>>>> On Tue, Sep 16, 2014 at 6:41 PM, nick <xerofoify at 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 <xerofoify at 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 <xerofoify at 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 <xerofoify at 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 <xerofoify at 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 at 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 do understand how much I have screwed up. My concern now is
>> now to make it right.
>> Nick
>
> and your are screwing up even more by sending these patches.
and your are screwing up even more by sending these patches.
More information about the Kernelnewbies
mailing list