Discussion:
[PATCH] Crypto: gf128mul : fixed a parentheses coding style issue
Mike Roocroft
2014-10-12 20:49:10 UTC
Permalink
Fixed a coding style issue.

Signed-off-by: Mike Roocroft <***@btinternet.com>
---
crypto/gf128mul.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index 5276607..b143d84 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -97,7 +97,7 @@
the table above
*/

-#define xx(p, q) 0x##p##q
+#define xx(p, q) (0x##p##q)

#define xda_bbe(i) ( \
(i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
--
2.1.0
Joe Perches
2014-10-12 23:01:25 UTC
Permalink
Post by Mike Roocroft
Fixed a coding style issue.
[]
Post by Mike Roocroft
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
[]
Post by Mike Roocroft
@@ -97,7 +97,7 @@
the table above
*/
-#define xx(p, q) 0x##p##q
+#define xx(p, q) (0x##p##q)
#define xda_bbe(i) ( \
(i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
I think that macro is pretty useless and nothing
but obfuscation now.

The comment above it doesn't seem useful either.

How about just removing and replacing the uses
like this?

---
crypto/gf128mul.c | 27 ++++++++-------------------
1 file changed, 8 insertions(+), 19 deletions(-)

diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index 5276607..90cf17d 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -88,29 +88,18 @@
q(0xf8), q(0xf9), q(0xfa), q(0xfb), q(0xfc), q(0xfd), q(0xfe), q(0xff) \
}

-/* Given the value i in 0..255 as the byte overflow when a field element
- in GHASH is multiplied by x^8, this function will return the values that
- are generated in the lo 16-bit word of the field value by applying the
- modular polynomial. The values lo_byte and hi_byte are returned via the
- macro xp_fun(lo_byte, hi_byte) so that the values can be assembled into
- memory as required by a suitable definition of this macro operating on
- the table above
-*/
-
-#define xx(p, q) 0x##p##q
-
#define xda_bbe(i) ( \
- (i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
- (i & 0x20 ? xx(10, e0) : 0) ^ (i & 0x10 ? xx(08, 70) : 0) ^ \
- (i & 0x08 ? xx(04, 38) : 0) ^ (i & 0x04 ? xx(02, 1c) : 0) ^ \
- (i & 0x02 ? xx(01, 0e) : 0) ^ (i & 0x01 ? xx(00, 87) : 0) \
+ (i & 0x80 ? 0x4380 : 0) ^ (i & 0x40 ? 0x21c0 : 0) ^ \
+ (i & 0x20 ? 0x10e0 : 0) ^ (i & 0x10 ? 0x0870 : 0) ^ \
+ (i & 0x08 ? 0x0438 : 0) ^ (i & 0x04 ? 0x021c : 0) ^ \
+ (i & 0x02 ? 0x010e : 0) ^ (i & 0x01 ? 0x0087 : 0) \
)

#define xda_lle(i) ( \
- (i & 0x80 ? xx(e1, 00) : 0) ^ (i & 0x40 ? xx(70, 80) : 0) ^ \
- (i & 0x20 ? xx(38, 40) : 0) ^ (i & 0x10 ? xx(1c, 20) : 0) ^ \
- (i & 0x08 ? xx(0e, 10) : 0) ^ (i & 0x04 ? xx(07, 08) : 0) ^ \
- (i & 0x02 ? xx(03, 84) : 0) ^ (i & 0x01 ? xx(01, c2) : 0) \
+ (i & 0x80 ? 0xe100 : 0) ^ (i & 0x40 ? 0x7080 : 0) ^ \
+ (i & 0x20 ? 0x3840 : 0) ^ (i & 0x10 ? 0x1c20 : 0) ^ \
+ (i & 0x08 ? 0x0e10 : 0) ^ (i & 0x04 ? 0x0708 : 0) ^ \
+ (i & 0x02 ? 0x0384 : 0) ^ (i & 0x01 ? 0x01c2 : 0) \
)

static const u16 gf128mul_table_lle[256] = gf128mul_dat(xda_lle);
Michael Roocroft
2014-10-13 20:12:25 UTC
Permalink
Post by Joe Perches
Post by Mike Roocroft
Fixed a coding style issue.
[]
Post by Mike Roocroft
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
[]
Post by Mike Roocroft
@@ -97,7 +97,7 @@
the table above
*/
-#define xx(p, q) 0x##p##q
+#define xx(p, q) (0x##p##q)
#define xda_bbe(i) ( \
(i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
I think that macro is pretty useless and nothing
but obfuscation now.
The comment above it doesn't seem useful either.
How about just removing and replacing the uses
like this?
---
crypto/gf128mul.c | 27 ++++++++-------------------
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index 5276607..90cf17d 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -88,29 +88,18 @@
q(0xf8), q(0xf9), q(0xfa), q(0xfb), q(0xfc), q(0xfd), q(0xfe), q(0xff) \
}
-/* Given the value i in 0..255 as the byte overflow when a field element
- in GHASH is multiplied by x^8, this function will return the values that
- are generated in the lo 16-bit word of the field value by applying the
- modular polynomial. The values lo_byte and hi_byte are returned via the
- macro xp_fun(lo_byte, hi_byte) so that the values can be assembled into
- memory as required by a suitable definition of this macro operating on
- the table above
-*/
-
-#define xx(p, q) 0x##p##q
-
#define xda_bbe(i) ( \
- (i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
- (i & 0x20 ? xx(10, e0) : 0) ^ (i & 0x10 ? xx(08, 70) : 0) ^ \
- (i & 0x08 ? xx(04, 38) : 0) ^ (i & 0x04 ? xx(02, 1c) : 0) ^ \
- (i & 0x02 ? xx(01, 0e) : 0) ^ (i & 0x01 ? xx(00, 87) : 0) \
+ (i & 0x80 ? 0x4380 : 0) ^ (i & 0x40 ? 0x21c0 : 0) ^ \
+ (i & 0x20 ? 0x10e0 : 0) ^ (i & 0x10 ? 0x0870 : 0) ^ \
+ (i & 0x08 ? 0x0438 : 0) ^ (i & 0x04 ? 0x021c : 0) ^ \
+ (i & 0x02 ? 0x010e : 0) ^ (i & 0x01 ? 0x0087 : 0) \
)
#define xda_lle(i) ( \
- (i & 0x80 ? xx(e1, 00) : 0) ^ (i & 0x40 ? xx(70, 80) : 0) ^ \
- (i & 0x20 ? xx(38, 40) : 0) ^ (i & 0x10 ? xx(1c, 20) : 0) ^ \
- (i & 0x08 ? xx(0e, 10) : 0) ^ (i & 0x04 ? xx(07, 08) : 0) ^ \
- (i & 0x02 ? xx(03, 84) : 0) ^ (i & 0x01 ? xx(01, c2) : 0) \
+ (i & 0x80 ? 0xe100 : 0) ^ (i & 0x40 ? 0x7080 : 0) ^ \
+ (i & 0x20 ? 0x3840 : 0) ^ (i & 0x10 ? 0x1c20 : 0) ^ \
+ (i & 0x08 ? 0x0e10 : 0) ^ (i & 0x04 ? 0x0708 : 0) ^ \
+ (i & 0x02 ? 0x0384 : 0) ^ (i & 0x01 ? 0x01c2 : 0) \
)
static const u16 gf128mul_table_lle[256] = gf128mul_dat(xda_lle);
Hi there,

I'm not really contributing anything other than getting code checkpatch clean, whilst

I relearn C and get a feel for various parts of the kernel.
Joe Perches
2014-10-13 20:15:56 UTC
Permalink
Post by Michael Roocroft
Post by Joe Perches
Post by Mike Roocroft
Fixed a coding style issue.
[]
Post by Mike Roocroft
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
[]
Post by Mike Roocroft
@@ -97,7 +97,7 @@
the table above
*/
-#define xx(p, q) 0x##p##q
+#define xx(p, q) (0x##p##q)
#define xda_bbe(i) ( \
(i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
I think that macro is pretty useless and nothing
but obfuscation now.
The comment above it doesn't seem useful either.
How about just removing and replacing the uses
like this?
---
crypto/gf128mul.c | 27 ++++++++-------------------
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index 5276607..90cf17d 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -88,29 +88,18 @@
q(0xf8), q(0xf9), q(0xfa), q(0xfb), q(0xfc), q(0xfd), q(0xfe), q(0xff) \
}
-/* Given the value i in 0..255 as the byte overflow when a field element
- in GHASH is multiplied by x^8, this function will return the values that
- are generated in the lo 16-bit word of the field value by applying the
- modular polynomial. The values lo_byte and hi_byte are returned via the
- macro xp_fun(lo_byte, hi_byte) so that the values can be assembled into
- memory as required by a suitable definition of this macro operating on
- the table above
-*/
-
-#define xx(p, q) 0x##p##q
-
#define xda_bbe(i) ( \
- (i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
- (i & 0x20 ? xx(10, e0) : 0) ^ (i & 0x10 ? xx(08, 70) : 0) ^ \
- (i & 0x08 ? xx(04, 38) : 0) ^ (i & 0x04 ? xx(02, 1c) : 0) ^ \
- (i & 0x02 ? xx(01, 0e) : 0) ^ (i & 0x01 ? xx(00, 87) : 0) \
+ (i & 0x80 ? 0x4380 : 0) ^ (i & 0x40 ? 0x21c0 : 0) ^ \
+ (i & 0x20 ? 0x10e0 : 0) ^ (i & 0x10 ? 0x0870 : 0) ^ \
+ (i & 0x08 ? 0x0438 : 0) ^ (i & 0x04 ? 0x021c : 0) ^ \
+ (i & 0x02 ? 0x010e : 0) ^ (i & 0x01 ? 0x0087 : 0) \
)
#define xda_lle(i) ( \
- (i & 0x80 ? xx(e1, 00) : 0) ^ (i & 0x40 ? xx(70, 80) : 0) ^ \
- (i & 0x20 ? xx(38, 40) : 0) ^ (i & 0x10 ? xx(1c, 20) : 0) ^ \
- (i & 0x08 ? xx(0e, 10) : 0) ^ (i & 0x04 ? xx(07, 08) : 0) ^ \
- (i & 0x02 ? xx(03, 84) : 0) ^ (i & 0x01 ? xx(01, c2) : 0) \
+ (i & 0x80 ? 0xe100 : 0) ^ (i & 0x40 ? 0x7080 : 0) ^ \
+ (i & 0x20 ? 0x3840 : 0) ^ (i & 0x10 ? 0x1c20 : 0) ^ \
+ (i & 0x08 ? 0x0e10 : 0) ^ (i & 0x04 ? 0x0708 : 0) ^ \
+ (i & 0x02 ? 0x0384 : 0) ^ (i & 0x01 ? 0x01c2 : 0) \
)
static const u16 gf128mul_table_lle[256] = gf128mul_dat(xda_lle);
Hi there,
Hi Mike.
Post by Michael Roocroft
I'm not really contributing anything other than getting code checkpatch clean, whilst
I relearn C and get a feel for various parts of the kernel.
checkpatch cleanliness, while OK for some parts of the
kernel, should not be an end-goal.

checkpatch is really a tool to "check patches".

If you want to submit neatening only patches, please
do your changes in drivers/staging/

Otherwise, please look for code that isn't simply a
style neatening bit, but something that actively makes
reading the code easier, makes the object code smaller
or faster, reduces complexity, adds extensibility,
etc, etc...

cheers, Joe
Michael Roocroft
2014-10-13 20:52:56 UTC
Permalink
Post by Joe Perches
Post by Michael Roocroft
Post by Joe Perches
Post by Mike Roocroft
Fixed a coding style issue.
[]
Post by Mike Roocroft
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
[]
Post by Mike Roocroft
@@ -97,7 +97,7 @@
the table above
*/
-#define xx(p, q) 0x##p##q
+#define xx(p, q) (0x##p##q)
#define xda_bbe(i) ( \
(i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
I think that macro is pretty useless and nothing
but obfuscation now.
The comment above it doesn't seem useful either.
How about just removing and replacing the uses
like this?
---
crypto/gf128mul.c | 27 ++++++++-------------------
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index 5276607..90cf17d 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -88,29 +88,18 @@
q(0xf8), q(0xf9), q(0xfa), q(0xfb), q(0xfc), q(0xfd), q(0xfe), q(0xff) \
}
-/* Given the value i in 0..255 as the byte overflow when a field element
- in GHASH is multiplied by x^8, this function will return the values that
- are generated in the lo 16-bit word of the field value by applying the
- modular polynomial. The values lo_byte and hi_byte are returned via the
- macro xp_fun(lo_byte, hi_byte) so that the values can be assembled into
- memory as required by a suitable definition of this macro operating on
- the table above
-*/
-
-#define xx(p, q) 0x##p##q
-
#define xda_bbe(i) ( \
- (i & 0x80 ? xx(43, 80) : 0) ^ (i & 0x40 ? xx(21, c0) : 0) ^ \
- (i & 0x20 ? xx(10, e0) : 0) ^ (i & 0x10 ? xx(08, 70) : 0) ^ \
- (i & 0x08 ? xx(04, 38) : 0) ^ (i & 0x04 ? xx(02, 1c) : 0) ^ \
- (i & 0x02 ? xx(01, 0e) : 0) ^ (i & 0x01 ? xx(00, 87) : 0) \
+ (i & 0x80 ? 0x4380 : 0) ^ (i & 0x40 ? 0x21c0 : 0) ^ \
+ (i & 0x20 ? 0x10e0 : 0) ^ (i & 0x10 ? 0x0870 : 0) ^ \
+ (i & 0x08 ? 0x0438 : 0) ^ (i & 0x04 ? 0x021c : 0) ^ \
+ (i & 0x02 ? 0x010e : 0) ^ (i & 0x01 ? 0x0087 : 0) \
)
#define xda_lle(i) ( \
- (i & 0x80 ? xx(e1, 00) : 0) ^ (i & 0x40 ? xx(70, 80) : 0) ^ \
- (i & 0x20 ? xx(38, 40) : 0) ^ (i & 0x10 ? xx(1c, 20) : 0) ^ \
- (i & 0x08 ? xx(0e, 10) : 0) ^ (i & 0x04 ? xx(07, 08) : 0) ^ \
- (i & 0x02 ? xx(03, 84) : 0) ^ (i & 0x01 ? xx(01, c2) : 0) \
+ (i & 0x80 ? 0xe100 : 0) ^ (i & 0x40 ? 0x7080 : 0) ^ \
+ (i & 0x20 ? 0x3840 : 0) ^ (i & 0x10 ? 0x1c20 : 0) ^ \
+ (i & 0x08 ? 0x0e10 : 0) ^ (i & 0x04 ? 0x0708 : 0) ^ \
+ (i & 0x02 ? 0x0384 : 0) ^ (i & 0x01 ? 0x01c2 : 0) \
)
static const u16 gf128mul_table_lle[256] = gf128mul_dat(xda_lle);
Hi there,
Hi Mike.
Post by Michael Roocroft
I'm not really contributing anything other than getting code checkpatch clean, whilst
I relearn C and get a feel for various parts of the kernel.
checkpatch cleanliness, while OK for some parts of the
kernel, should not be an end-goal.
checkpatch is really a tool to "check patches".
If you want to submit neatening only patches, please
do your changes in drivers/staging/
Otherwise, please look for code that isn't simply a
style neatening bit, but something that actively makes
reading the code easier, makes the object code smaller
or faster, reduces complexity, adds extensibility,
etc, etc...
cheers, Joe
Hi Joe

Thanks for the Advice, I fully intend to making more meaningful contributions
when my confidence in writing C is better than it is at the moment. I'll concentrate
on making any changes to staging whilst I learn and get to grips with git, and
continue to look through the rest of the kernel tree as a learning exercise.

I am extremely new to all this and a little overwhelmed, but by looking and not doing
anyhing i'll never learn anything.
Joe Perches
2014-10-13 20:56:54 UTC
Permalink
Post by Michael Roocroft
I fully intend to making more meaningful contributions
when my confidence in writing C is better than it is at the moment. I'll concentrate
on making any changes to staging whilst I learn and get to grips with git, and
continue to look through the rest of the kernel tree as a learning exercise.
Sounds like a good plan to me. welcome btw.
Post by Michael Roocroft
by looking and not doing anything i'll never learn anything.
True words...

cheers, Joe

Loading...