[PATCH] Enclose multiple statements macros in a do while loop
The formatting of macros definetion in ks7010/michael_mic.c is not
consistent with the general kernel coding style.
Fix it by the result of scripts/checkpatch.pl.
No functional changes.
Signed-off-by: Sunbing
---
drivers/staging/ks7010/michael_mic.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/ks7010/michael_mic.c
b/drivers/staging/ks7010/michael_mic.c
index e14c109..ad4f779 100644
--- a/drivers/staging/ks7010/michael_mic.c
+++ b/drivers/staging/ks7010/michael_mic.c
@@ -20,15 +20,21 @@
#define getUInt32( A, B ) (uint32_t)(A[B+0] << 0) + (A[B+1] << 8) +
(A[B+2] << 16) + (A[B+3] << 24)
// Convert from UInt32 to Byte[] in a portable way
-#define putUInt32( A, B, C ) A[B+0] = (uint8_t) (C & 0xff); \
- A[B+1] = (uint8_t) ((C>>8) & 0xff); \
- A[B+2] = (uint8_t) ((C>>16) & 0xff);\
- A[B+3] = (uint8_t) ((C>>24) & 0xff)
+#define putUInt32(A, B, C) \
+do { \
+ A[B+0] = (uint8_t) (C & 0xff); \
+ A[B+1] = (uint8_t) ((C>>8) & 0xff); \
+ A[B+2] = (uint8_t) ((C>>16) & 0xff);\
+ A[B+3] = (uint8_t) ((C>>24) & 0xff);\
+} while (0)
// Reset the state to the empty message.
-#define MichaelClear( A ) A->L = A->K0; \
- A->R = A->K1; \
- A->nBytesInM = 0;
+#define MichaelClear(A)\
+do { \
+ A->L = A->K0; \
+ A->R = A->K1; \
+ A->nBytesInM = 0; \
+} while (0)
static
void MichaelInitializeFunction(struct michel_mic_t *Mic, uint8_t * key)
--
2.1.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Enclose multiple statements macros in a do while loop
On Jul 15, 2016, at 8:32, Greg KH wrote: > On Thu, Jul 14, 2016 at 05:01:51PM +0800, Sunbing wrote: >> The formatting of macros definetion in ks7010/michael_mic.c is not >> consistent with the general kernel coding style. >> >> Fix it by the result of scripts/checkpatch.pl. >> >> No functional changes. >> >> Signed-off-by: Sunbing > > We need a "real" and "full" name here, please. > > Also, work on your subject: line to match other patches that have been > accepted into this driver. > > thanks, > > greg k-h Thanks for your reply. 1. I will change a real full subject name : staging: ks7010: Change macros definition coding style in michael_mic.c 2. Do you mean a patch fix macros definition error was accepted ? where can I find it ? I can’t find it in git and mail-list. Regards. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] Staging: ks7010: michael_mic: fixed macros coding style issue
Fixed coding style issue:
Enclose multiple statements macros definition in a do while loop.
Use one space around binary operators.
Signed-off-by: Sunbing
---
drivers/staging/ks7010/michael_mic.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/ks7010/michael_mic.c
b/drivers/staging/ks7010/michael_mic.c
index e14c109..d332678 100644
--- a/drivers/staging/ks7010/michael_mic.c
+++ b/drivers/staging/ks7010/michael_mic.c
@@ -20,15 +20,21 @@
#define getUInt32( A, B ) (uint32_t)(A[B+0] << 0) + (A[B+1] << 8) +
(A[B+2] << 16) + (A[B+3] << 24)
// Convert from UInt32 to Byte[] in a portable way
-#define putUInt32( A, B, C ) A[B+0] = (uint8_t) (C & 0xff); \
- A[B+1] = (uint8_t) ((C>>8) & 0xff); \
- A[B+2] = (uint8_t) ((C>>16) & 0xff);\
- A[B+3] = (uint8_t) ((C>>24) & 0xff)
+#define putUInt32(A, B, C) \
+do { \
+ A[B + 0] = (uint8_t)(C & 0xff); \
+ A[B + 1] = (uint8_t)((C >> 8) & 0xff); \
+ A[B + 2] = (uint8_t)((C >> 16) & 0xff); \
+ A[B + 3] = (uint8_t)((C >> 24) & 0xff); \
+} while (0)
// Reset the state to the empty message.
-#define MichaelClear( A ) A->L = A->K0; \
- A->R = A->K1; \
- A->nBytesInM = 0;
+#define MichaelClear(A)\
+do { \
+ A->L = A->K0; \
+ A->R = A->K1; \
+ A->nBytesInM = 0; \
+} while (0)
static
void MichaelInitializeFunction(struct michel_mic_t *Mic, uint8_t * key)
--
2.1.0
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
On Aug 11, 2016, at 23:25, Jes Sorensen wrote:
> Bing Sun writes:
>> Fixed sparse parse error:
>> Expected constant expression in case statement.
>>
>> Signed-off-by: Bing Sun
>> ---
>> drivers/staging/rtl8723au/os_dep/os_intfs.c | 11 +--
>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> index b8848c2..f30d5d2 100644
>> --- a/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> +++ b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>> @@ -283,14 +283,13 @@ static u32 rtw_classify8021d(struct sk_buff *skb)
>> */
>> if (skb->priority >= 256 && skb->priority <= 263)
>> return skb->priority - 256;
>> -switch (skb->protocol) {
>> -case htons(ETH_P_IP):
>> +
>> +if (skb->protocol == htons(ETH_P_IP)) {
>> dscp = ip_hdr(skb)->tos & 0xfc;
>> -break;
>> -default:
>> -return 0;
>> +return dscp >> 5;
>> }
>> -return dscp >> 5;
>> +
>> +return 0;
>> }
>
> Pardon me here, but I find it really hard to see how this change is an
> improvement over the old code in any shape or form.
>
> Jes
There is no functional improvement.
But before this patch, when we do: make C=1 M=drivers/staging/rtl8723au/
An error output:
drivers/staging/rtl8723au//os_dep/os_intfs.c:287:14: error: Expected constant
expression in case statement
To avoid sparse parse error, a case statement converts to an if statement.
So we got this patch.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: rtl8723au: os_intfs: fixed case statement is variable issue
On Aug 12, 2016, at 22:30, Jes Sorensen wrote:
> sunbing writes:
>> On Aug 11, 2016, at 23:25, Jes Sorensen wrote:
>>
>>> Bing Sun writes:
>>>> Fixed sparse parse error:
>>>> Expected constant expression in case statement.
>>>>
>>>> Signed-off-by: Bing Sun
>>>> ---
>>>> drivers/staging/rtl8723au/os_dep/os_intfs.c | 11 +--
>>>> 1 file changed, 5 insertions(+), 6 deletions(-)
>>>>
>>>> diff --git a/drivers/staging/rtl8723au/os_dep/os_intfs.c
>>>> b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>>>> index b8848c2..f30d5d2 100644
>>>> --- a/drivers/staging/rtl8723au/os_dep/os_intfs.c
>>>> +++ b/drivers/staging/rtl8723au/os_dep/os_intfs.c
>>>> @@ -283,14 +283,13 @@ static u32 rtw_classify8021d(struct sk_buff *skb)
>>>> */
>>>>if (skb->priority >= 256 && skb->priority <= 263)
>>>>return skb->priority - 256;
>>>> - switch (skb->protocol) {
>>>> - case htons(ETH_P_IP):
>>>> +
>>>> + if (skb->protocol == htons(ETH_P_IP)) {
>>>>dscp = ip_hdr(skb)->tos & 0xfc;
>>>> - break;
>>>> - default:
>>>> - return 0;
>>>> + return dscp >> 5;
>>>>}
>>>> - return dscp >> 5;
>>>> +
>>>> + return 0;
>>>> }
>>>
>>> Pardon me here, but I find it really hard to see how this change is an
>>> improvement over the old code in any shape or form.
>>>
>>> Jes
>>
>> There is no functional improvement.
>> But before this patch, when we do: make C=1 M=drivers/staging/rtl8723au/
>> An error output:
>> drivers/staging/rtl8723au//os_dep/os_intfs.c:287:14: error: Expected
>> constant expression in case statement
>> To avoid sparse parse error, a case statement converts to an if statement.
>> So we got this patch.
>
> Hello
>
> I understand this part, but it seems to me we are changing the code due
> to a broken test case in sparse. Does the warning go away if you use
> __constant_htons() instead of htons()?
>
> Jes
Thanks for your guidance.
1. If I use __constant_htons, checkpatch.pl will warning:
WARNING: __constant_htons should be htons
2. In os_intfs.c: rtw_classify8021d, there are only one case statement and a
default statement. So, convert "switch case" to "if else" is more readable in
my opinion.
So, I pushed this patch.
There are some patches convert use of __constant_htons to htons in kernel logs.
Will there be a new patch convert to htons in the future if I use
__constant_htons now ?
After search through kernel code, there are 158 "case htons(...)" statements
and
2 "case __constant_htons(...)" statements. Does this mean we can ignore sparse
error and use "case htons(...)" ?
It makes me confused. More help, please.
Regards.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
