[char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Tomas Winkler]

In order for mei client devices to use device id based on uuid we
have to use common types between user space (file2alias.c).
Similarly to vmbus,  mei  uses raw 16 byte array for that. 
To leverage on existing infrastructure around uuid_le type 
defined in uuid.h we add helper macros to handle conversions between
raw 16 byte array and uuid_{le,be} types.

Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 
Signed-off-by: Tomas Winkler <tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
V2: be verbose in the commit message 
 include/uapi/linux/uuid.h | 41 ++++++++++++++++++++++++-----------------
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/include/uapi/linux/uuid.h b/include/uapi/linux/uuid.h
index 786f0773cc33..487f098c8517 100644
--- a/include/uapi/linux/uuid.h
+++ b/include/uapi/linux/uuid.h
@@ -32,27 +32,34 @@ typedef struct {
 	__u8 b[16];
 } uuid_be;
 
-#define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)		\
-((uuid_le)								\
-{{ (a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff, \
-   (b) & 0xff, ((b) >> 8) & 0xff,					\
-   (c) & 0xff, ((c) >> 8) & 0xff,					\
-   (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
+#define __UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)                     \
+	{(a) & 0xff, ((a) >> 8) & 0xff, ((a) >> 16) & 0xff, ((a) >> 24) & 0xff,\
+	  (b) & 0xff, ((b) >> 8) & 0xff,                                       \
+	  (c) & 0xff, ((c) >> 8) & 0xff,                                       \
+	  (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7)}
+
+#define UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)	\
+	((uuid_le) {__UUID_LE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)})
+
+#define __UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)                     \
+	{((a) >> 24) & 0xff, ((a) >> 16) & 0xff, ((a) >> 8) & 0xff, (a) & 0xff,\
+	  ((b) >> 8) & 0xff, (b) & 0xff,                                       \
+	  ((c) >> 8) & 0xff, (c) & 0xff,                                       \
+	  (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7)}
 
 #define UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)		\
-((uuid_be)								\
-{{ ((a) >> 24) & 0xff, ((a) >> 16) & 0xff, ((a) >> 8) & 0xff, (a) & 0xff, \
-   ((b) >> 8) & 0xff, (b) & 0xff,					\
-   ((c) >> 8) & 0xff, (c) & 0xff,					\
-   (d0), (d1), (d2), (d3), (d4), (d5), (d6), (d7) }})
+	((uuid_be) {__UUID_BE(a, b, c, d0, d1, d2, d3, d4, d5, d6, d7)})
+
+#define __NULL_UUID_LE							\
+	__UUID_LE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00,	\
+		  0x00, 0x00, 0x00, 0x00)
 
-#define NULL_UUID_LE							\
-	UUID_LE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00,	\
-		0x00, 0x00, 0x00, 0x00)
+#define NULL_UUID_LE ((uuid_le) {__NULL_UUID_LE})
 
-#define NULL_UUID_BE							\
-	UUID_BE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00,	\
-		0x00, 0x00, 0x00, 0x00)
+#define __NULL_UUID_BE							\
+	__UUID_BE(0x00000000, 0x0000, 0x0000, 0x00, 0x00, 0x00, 0x00,	\
+		  0x00, 0x00, 0x00, 0x00)
 
+#define NULL_UUID_BE ((uuid_be) {__NULL_UUID_BE})
 
 #endif /* _UAPI_LINUX_UUID_H_ */
-- 
2.1.0

Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Greg KH]

On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> In order for mei client devices to use device id based on uuid we
> have to use common types between user space (file2alias.c).
> Similarly to vmbus,  mei  uses raw 16 byte array for that. 
> To leverage on existing infrastructure around uuid_le type 
> defined in uuid.h we add helper macros to handle conversions between
> raw 16 byte array and uuid_{le,be} types.

You aren't adding a helper macro, you are just redefining the existing
macros using a different one.  But I can't see why this is needed, what
does this solve that vmbus and other uses of the existing macros don't
need?  In other words, what makes mei so special that it needs a "lower"
level macro than every other subsystem?

thanks,

greg k-h

RE: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Winkler, Tomas]

> 
> On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > In order for mei client devices to use device id based on uuid we
> > have to use common types between user space (file2alias.c).
> > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > To leverage on existing infrastructure around uuid_le type
> > defined in uuid.h we add helper macros to handle conversions between
> > raw 16 byte array and uuid_{le,be} types.
> 
> You aren't adding a helper macro, you are just redefining the existing
> macros using a different one. 

Not exactly I'm using both the one I've added for device ids and the old one for all the other flows.

 But I can't see why this is needed, what
> does this solve that vmbus and other uses of the existing macros don't
> need?  In other words, what makes mei so special that it needs a "lower"
> level macro than every other subsystem?

It's not special there is actually a lot of code duplication around uuid handling 
every subsystem is using their own macros but it can be consolidated around uuid.h
 
So vmbus can use that 
Instead of 
/*
 * Network GUID
 * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
 */
#define HV_NIC_GUID \
        .guid = { \
                        0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
                        0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
                }

The can use the new macro to make it more readable, something in spirit of:

#define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-f2d2f965ed0e)


Thanks 
Tomas

Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Greg KH]

On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> 
> > 
> > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > In order for mei client devices to use device id based on uuid we
> > > have to use common types between user space (file2alias.c).
> > > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > > To leverage on existing infrastructure around uuid_le type
> > > defined in uuid.h we add helper macros to handle conversions between
> > > raw 16 byte array and uuid_{le,be} types.
> > 
> > You aren't adding a helper macro, you are just redefining the existing
> > macros using a different one. 
> 
> Not exactly I'm using both the one I've added for device ids and the old one for all the other flows.
> 
>  But I can't see why this is needed, what
> > does this solve that vmbus and other uses of the existing macros don't
> > need?  In other words, what makes mei so special that it needs a "lower"
> > level macro than every other subsystem?
> 
> It's not special there is actually a lot of code duplication around uuid handling 
> every subsystem is using their own macros but it can be consolidated around uuid.h
>  
> So vmbus can use that 
> Instead of 
> /*
>  * Network GUID
>  * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
>  */
> #define HV_NIC_GUID \
>         .guid = { \
>                         0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
>                         0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
>                 }
> 
> The can use the new macro to make it more readable, something in spirit of:
> 
> #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-f2d2f965ed0e)

Why the "__" usage here?  That signifies a "private" namespace, why add
that to the user visible header files?

And are you going to send patches for vmbus and other drivers to fix
everything up to use these new macros?  Someone has to...

thanks,

greg k-h

RE: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Winkler, Tomas]

> -----Original Message-----
> From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> Sent: Wednesday, May 27, 2015 20:29
> To: Winkler, Tomas
> Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw
> arrays
> 
> On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> >
> > >
> > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > > In order for mei client devices to use device id based on uuid we
> > > > have to use common types between user space (file2alias.c).
> > > > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > > > To leverage on existing infrastructure around uuid_le type
> > > > defined in uuid.h we add helper macros to handle conversions between
> > > > raw 16 byte array and uuid_{le,be} types.
> > >
> > > You aren't adding a helper macro, you are just redefining the existing
> > > macros using a different one.
> >
> > Not exactly I'm using both the one I've added for device ids and the old one for
> all the other flows.
> >
> >  But I can't see why this is needed, what
> > > does this solve that vmbus and other uses of the existing macros don't
> > > need?  In other words, what makes mei so special that it needs a "lower"
> > > level macro than every other subsystem?
> >
> > It's not special there is actually a lot of code duplication around uuid handling
> > every subsystem is using their own macros but it can be consolidated around
> uuid.h
> >
> > So vmbus can use that
> > Instead of
> > /*
> >  * Network GUID
> >  * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
> >  */
> > #define HV_NIC_GUID \
> >         .guid = { \
> >                         0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
> >                         0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
> >                 }
> >
> > The can use the new macro to make it more readable, something in spirit of:
> >
> > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-f2d2f965ed0e)
> 
> Why the "__" usage here?  That signifies a "private" namespace, why add
> that to the user visible header files?

I take any other suggestion for macro names.  
Not sure how I would reuse the macros if I don't export them both, second this can be used also by user space.  
> 
> And are you going to send patches for vmbus and other drivers to fix
> everything up to use these new macros?  Someone has to...

Can be done but I cannot test their code and  now I'm busy with splitting the big bus patch :)
Tomas

Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Greg KH]

On Wed, May 27, 2015 at 05:42:22PM +0000, Winkler, Tomas wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > Sent: Wednesday, May 27, 2015 20:29
> > To: Winkler, Tomas
> > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw
> > arrays
> > 
> > On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> > >
> > > >
> > > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > > > In order for mei client devices to use device id based on uuid we
> > > > > have to use common types between user space (file2alias.c).
> > > > > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > > > > To leverage on existing infrastructure around uuid_le type
> > > > > defined in uuid.h we add helper macros to handle conversions between
> > > > > raw 16 byte array and uuid_{le,be} types.
> > > >
> > > > You aren't adding a helper macro, you are just redefining the existing
> > > > macros using a different one.
> > >
> > > Not exactly I'm using both the one I've added for device ids and the old one for
> > all the other flows.
> > >
> > >  But I can't see why this is needed, what
> > > > does this solve that vmbus and other uses of the existing macros don't
> > > > need?  In other words, what makes mei so special that it needs a "lower"
> > > > level macro than every other subsystem?
> > >
> > > It's not special there is actually a lot of code duplication around uuid handling
> > > every subsystem is using their own macros but it can be consolidated around
> > uuid.h
> > >
> > > So vmbus can use that
> > > Instead of
> > > /*
> > >  * Network GUID
> > >  * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
> > >  */
> > > #define HV_NIC_GUID \
> > >         .guid = { \
> > >                         0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
> > >                         0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
> > >                 }
> > >
> > > The can use the new macro to make it more readable, something in spirit of:
> > >
> > > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-f2d2f965ed0e)
> > 
> > Why the "__" usage here?  That signifies a "private" namespace, why add
> > that to the user visible header files?
> 
> I take any other suggestion for macro names.  
> Not sure how I would reuse the macros if I don't export them both,
> second this can be used also by user space.  

But it's not needed at all.

Below is a patch on top of my current tree that makes this patch not
needed.  Any objection to me just applying it instead?

> > And are you going to send patches for vmbus and other drivers to fix
> > everything up to use these new macros?  Someone has to...
> 
> Can be done but I cannot test their code and  now I'm busy with splitting the big bus patch :)

Ok, that means no one is ever going to do that work, so it's not a valid
reason to accept such a change.  I prefer the patch below.

thanks,

greg k-h

diff --git a/drivers/nfc/mei_phy.h b/drivers/nfc/mei_phy.h
index a51f8f2685cc..fbfa3e61738f 100644
--- a/drivers/nfc/mei_phy.h
+++ b/drivers/nfc/mei_phy.h
@@ -5,7 +5,7 @@
 #include <net/nfc/hci.h>
 #include <linux/uuid.h>
 
-#define MEI_NFC_UUID __UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
+#define MEI_NFC_UUID UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
 		0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
 #define MEI_NFC_HEADER_SIZE 10
 #define MEI_NFC_MAX_HCI_PAYLOAD 300
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 2d2b2b571d61..048c270822f9 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -614,7 +614,7 @@ struct ipack_device_id {
  */
 struct mei_cl_device_id {
 	char name[MEI_CL_NAME_SIZE];
-	__u8 uuid[16];
+	uuid_le uuid;
 	kernel_ulong_t driver_info;
 };
 
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 62c517f4b592..718b2a29bd43 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -34,6 +34,9 @@ typedef Elf64_Addr	kernel_ulong_t;
 typedef uint32_t	__u32;
 typedef uint16_t	__u16;
 typedef unsigned char	__u8;
+typedef struct {
+	__u8 b[16];
+} uuid_le;
 
 /* Big exception to the "don't include kernel headers into userspace, which
  * even potentially has different endianness and word sizes, since
@@ -131,13 +134,13 @@ static inline void add_wildcard(char *str)
 		strcat(str + len, "*");
 }
 
-static inline void add_uuid(char *str, __u8 uuid[16])
+static inline void add_uuid(char *str, uuid_le uuid)
 {
 	int len = strlen(str);
 	int i;
 
 	for (i = 0; i < 16; i++)
-		sprintf(str + len + (i << 1), "%02x", uuid[i]);
+		sprintf(str + len + (i << 1), "%02x", uuid.b[i]);
 }
 
 /**

Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Greg KH]

On Wed, May 27, 2015 at 04:14:20PM -0700, Greg KH wrote:
> On Wed, May 27, 2015 at 05:42:22PM +0000, Winkler, Tomas wrote:
> > 
> > 
> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > > Sent: Wednesday, May 27, 2015 20:29
> > > To: Winkler, Tomas
> > > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw
> > > arrays
> > > 
> > > On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> > > >
> > > > >
> > > > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > > > > In order for mei client devices to use device id based on uuid we
> > > > > > have to use common types between user space (file2alias.c).
> > > > > > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > > > > > To leverage on existing infrastructure around uuid_le type
> > > > > > defined in uuid.h we add helper macros to handle conversions between
> > > > > > raw 16 byte array and uuid_{le,be} types.
> > > > >
> > > > > You aren't adding a helper macro, you are just redefining the existing
> > > > > macros using a different one.
> > > >
> > > > Not exactly I'm using both the one I've added for device ids and the old one for
> > > all the other flows.
> > > >
> > > >  But I can't see why this is needed, what
> > > > > does this solve that vmbus and other uses of the existing macros don't
> > > > > need?  In other words, what makes mei so special that it needs a "lower"
> > > > > level macro than every other subsystem?
> > > >
> > > > It's not special there is actually a lot of code duplication around uuid handling
> > > > every subsystem is using their own macros but it can be consolidated around
> > > uuid.h
> > > >
> > > > So vmbus can use that
> > > > Instead of
> > > > /*
> > > >  * Network GUID
> > > >  * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
> > > >  */
> > > > #define HV_NIC_GUID \
> > > >         .guid = { \
> > > >                         0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
> > > >                         0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
> > > >                 }
> > > >
> > > > The can use the new macro to make it more readable, something in spirit of:
> > > >
> > > > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-f2d2f965ed0e)
> > > 
> > > Why the "__" usage here?  That signifies a "private" namespace, why add
> > > that to the user visible header files?
> > 
> > I take any other suggestion for macro names.  
> > Not sure how I would reuse the macros if I don't export them both,
> > second this can be used also by user space.  
> 
> But it's not needed at all.
> 
> Below is a patch on top of my current tree that makes this patch not
> needed.  Any objection to me just applying it instead?
> 
> > > And are you going to send patches for vmbus and other drivers to fix
> > > everything up to use these new macros?  Someone has to...
> > 
> > Can be done but I cannot test their code and  now I'm busy with splitting the big bus patch :)
> 
> Ok, that means no one is ever going to do that work, so it's not a valid
> reason to accept such a change.  I prefer the patch below.

Oops, that didn't build, I forgot one change in the mei core (getting
rid of two casts.)  Try this one instead.

thanks,

greg k-h


diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index de8fd089a8a4..dd52f224027e 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -54,9 +54,9 @@ static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
 
 	id = driver->id_table;
 
-	while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
+	while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
 
-		if (!uuid_le_cmp(*uuid, uuid_le_cast(id->uuid))) {
+		if (!uuid_le_cmp(*uuid, id->uuid)) {
 			if (id->name[0]) {
 				if (!strncmp(name, id->name, sizeof(id->name)))
 					return 1;
diff --git a/drivers/nfc/mei_phy.h b/drivers/nfc/mei_phy.h
index a51f8f2685cc..fbfa3e61738f 100644
--- a/drivers/nfc/mei_phy.h
+++ b/drivers/nfc/mei_phy.h
@@ -5,7 +5,7 @@
 #include <net/nfc/hci.h>
 #include <linux/uuid.h>
 
-#define MEI_NFC_UUID __UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
+#define MEI_NFC_UUID UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
 		0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
 #define MEI_NFC_HEADER_SIZE 10
 #define MEI_NFC_MAX_HCI_PAYLOAD 300
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 2d2b2b571d61..048c270822f9 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -614,7 +614,7 @@ struct ipack_device_id {
  */
 struct mei_cl_device_id {
 	char name[MEI_CL_NAME_SIZE];
-	__u8 uuid[16];
+	uuid_le uuid;
 	kernel_ulong_t driver_info;
 };
 
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 62c517f4b592..718b2a29bd43 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -34,6 +34,9 @@ typedef Elf64_Addr	kernel_ulong_t;
 typedef uint32_t	__u32;
 typedef uint16_t	__u16;
 typedef unsigned char	__u8;
+typedef struct {
+	__u8 b[16];
+} uuid_le;
 
 /* Big exception to the "don't include kernel headers into userspace, which
  * even potentially has different endianness and word sizes, since
@@ -131,13 +134,13 @@ static inline void add_wildcard(char *str)
 		strcat(str + len, "*");
 }
 
-static inline void add_uuid(char *str, __u8 uuid[16])
+static inline void add_uuid(char *str, uuid_le uuid)
 {
 	int len = strlen(str);
 	int i;
 
 	for (i = 0; i < 16; i++)
-		sprintf(str + len + (i << 1), "%02x", uuid[i]);
+		sprintf(str + len + (i << 1), "%02x", uuid.b[i]);
 }
 
 /**

RE: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Winkler, Tomas]

> > > -----Original Message-----
> > > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > > Sent: Wednesday, May 27, 2015 20:29
> > > To: Winkler, Tomas
> > > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw
> > > arrays
> > >
> > > On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> > > >
> > > > >
> > > > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > > > > In order for mei client devices to use device id based on uuid we
> > > > > > have to use common types between user space (file2alias.c).
> > > > > > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > > > > > To leverage on existing infrastructure around uuid_le type
> > > > > > defined in uuid.h we add helper macros to handle conversions between
> > > > > > raw 16 byte array and uuid_{le,be} types.
> > > > >
> > > > > You aren't adding a helper macro, you are just redefining the existing
> > > > > macros using a different one.
> > > >
> > > > Not exactly I'm using both the one I've added for device ids and the old one
> for
> > > all the other flows.
> > > >
> > > >  But I can't see why this is needed, what
> > > > > does this solve that vmbus and other uses of the existing macros don't
> > > > > need?  In other words, what makes mei so special that it needs a "lower"
> > > > > level macro than every other subsystem?
> > > >
> > > > It's not special there is actually a lot of code duplication around uuid
> handling
> > > > every subsystem is using their own macros but it can be consolidated
> around
> > > uuid.h
> > > >
> > > > So vmbus can use that
> > > > Instead of
> > > > /*
> > > >  * Network GUID
> > > >  * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
> > > >  */
> > > > #define HV_NIC_GUID \
> > > >         .guid = { \
> > > >                         0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
> > > >                         0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
> > > >                 }
> > > >
> > > > The can use the new macro to make it more readable, something in spirit of:
> > > >
> > > > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-f2d2f965ed0e)
> > >
> > > Why the "__" usage here?  That signifies a "private" namespace, why add
> > > that to the user visible header files?
> >
> > I take any other suggestion for macro names.
> > Not sure how I would reuse the macros if I don't export them both,
> > second this can be used also by user space.
> 
> But it's not needed at all.
> 
> Below is a patch on top of my current tree that makes this patch not
> needed.  Any objection to me just applying it instead?

Looks like it might work I even like it more as I can drop the conversions between raw type and uuid,   but I have to look if more modification is needed in mei.
Just need to make sure these types are always in sync. 

> > > And are you going to send patches for vmbus and other drivers to fix
> > > everything up to use these new macros?  Someone has to...
> >
> > Can be done but I cannot test their code and  now I'm busy with splitting the big
> bus patch :)
> 
> Ok, that means no one is ever going to do that work, so it's not a valid
> reason to accept such a change.  I prefer the patch below

You may also here leverage for vmbus to this direction so this point is semi valid. 
> 
> thanks,
> 
> greg k-h
> 
> diff --git a/drivers/nfc/mei_phy.h b/drivers/nfc/mei_phy.h
> index a51f8f2685cc..fbfa3e61738f 100644
> --- a/drivers/nfc/mei_phy.h
> +++ b/drivers/nfc/mei_phy.h
> @@ -5,7 +5,7 @@
>  #include <net/nfc/hci.h>
>  #include <linux/uuid.h>
> 
> -#define MEI_NFC_UUID __UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
> +#define MEI_NFC_UUID UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
>  		0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
>  #define MEI_NFC_HEADER_SIZE 10
>  #define MEI_NFC_MAX_HCI_PAYLOAD 300
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 2d2b2b571d61..048c270822f9 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -614,7 +614,7 @@ struct ipack_device_id {
>   */
>  struct mei_cl_device_id {
>  	char name[MEI_CL_NAME_SIZE];
> -	__u8 uuid[16];
> +	uuid_le uuid;
>  	kernel_ulong_t driver_info;
>  };
> 
> diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
> index 62c517f4b592..718b2a29bd43 100644
> --- a/scripts/mod/file2alias.c
> +++ b/scripts/mod/file2alias.c
> @@ -34,6 +34,9 @@ typedef Elf64_Addr	kernel_ulong_t;
>  typedef uint32_t	__u32;
>  typedef uint16_t	__u16;
>  typedef unsigned char	__u8;
> +typedef struct {
> +	__u8 b[16];
> +} uuid_le;
> 
>  /* Big exception to the "don't include kernel headers into userspace, which
>   * even potentially has different endianness and word sizes, since
> @@ -131,13 +134,13 @@ static inline void add_wildcard(char *str)
>  		strcat(str + len, "*");
>  }
> 
> -static inline void add_uuid(char *str, __u8 uuid[16])
> +static inline void add_uuid(char *str, uuid_le uuid)
>  {
>  	int len = strlen(str);
>  	int i;
> 
>  	for (i = 0; i < 16; i++)
> -		sprintf(str + len + (i << 1), "%02x", uuid[i]);
> +		sprintf(str + len + (i << 1), "%02x", uuid.b[i]);
>  }
> 
>  /**

RE: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Winkler, Tomas]

> -----Original Message-----
> From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> Sent: Thursday, May 28, 2015 02:23
> To: Winkler, Tomas
> Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw
> arrays
> 
> On Wed, May 27, 2015 at 04:14:20PM -0700, Greg KH wrote:
> > On Wed, May 27, 2015 at 05:42:22PM +0000, Winkler, Tomas wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > > > Sent: Wednesday, May 27, 2015 20:29
> > > > To: Winkler, Tomas
> > > > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning
> raw
> > > > arrays
> > > >
> > > > On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> > > > >
> > > > > >
> > > > > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > > > > > In order for mei client devices to use device id based on uuid we
> > > > > > > have to use common types between user space (file2alias.c).
> > > > > > > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > > > > > > To leverage on existing infrastructure around uuid_le type
> > > > > > > defined in uuid.h we add helper macros to handle conversions
> between
> > > > > > > raw 16 byte array and uuid_{le,be} types.
> > > > > >
> > > > > > You aren't adding a helper macro, you are just redefining the existing
> > > > > > macros using a different one.
> > > > >
> > > > > Not exactly I'm using both the one I've added for device ids and the old
> one for
> > > > all the other flows.
> > > > >
> > > > >  But I can't see why this is needed, what
> > > > > > does this solve that vmbus and other uses of the existing macros don't
> > > > > > need?  In other words, what makes mei so special that it needs a
> "lower"
> > > > > > level macro than every other subsystem?
> > > > >
> > > > > It's not special there is actually a lot of code duplication around uuid
> handling
> > > > > every subsystem is using their own macros but it can be consolidated
> around
> > > > uuid.h
> > > > >
> > > > > So vmbus can use that
> > > > > Instead of
> > > > > /*
> > > > >  * Network GUID
> > > > >  * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
> > > > >  */
> > > > > #define HV_NIC_GUID \
> > > > >         .guid = { \
> > > > >                         0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
> > > > >                         0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
> > > > >                 }
> > > > >
> > > > > The can use the new macro to make it more readable, something in spirit
> of:
> > > > >
> > > > > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-
> f2d2f965ed0e)
> > > >
> > > > Why the "__" usage here?  That signifies a "private" namespace, why add
> > > > that to the user visible header files?
> > >
> > > I take any other suggestion for macro names.
> > > Not sure how I would reuse the macros if I don't export them both,
> > > second this can be used also by user space.
> >
> > But it's not needed at all.
> >
> > Below is a patch on top of my current tree that makes this patch not
> > needed.  Any objection to me just applying it instead?
> >
> > > > And are you going to send patches for vmbus and other drivers to fix
> > > > everything up to use these new macros?  Someone has to...
> > >
> > > Can be done but I cannot test their code and  now I'm busy with splitting the
> big bus patch :)
> >
> > Ok, that means no one is ever going to do that work, so it's not a valid
> > reason to accept such a change.  I prefer the patch below.
> 
> Oops, that didn't build, I forgot one change in the mei core (getting
> rid of two casts.)  Try this one instead.
> 
> thanks,
> 
> greg k-h
> 
> 
> diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
> index de8fd089a8a4..dd52f224027e 100644
> --- a/drivers/misc/mei/bus.c
> +++ b/drivers/misc/mei/bus.c
> @@ -54,9 +54,9 @@ static int mei_cl_device_match(struct device *dev, struct
> device_driver *drv)
> 
>  	id = driver->id_table;
> 
> -	while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
> +	while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
> 
> -		if (!uuid_le_cmp(*uuid, uuid_le_cast(id->uuid))) {
> +		if (!uuid_le_cmp(*uuid, id->uuid)) {
>  			if (id->name[0]) {
>  				if (!strncmp(name, id->name, sizeof(id->name)))
>  					return 1;

You can also drop the uuid_le_cast function 

Tomas

Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw arrays

[Greg KH]

On Wed, May 27, 2015 at 11:25:59PM +0000, Winkler, Tomas wrote:
> 
> 
> > -----Original Message-----
> > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > Sent: Thursday, May 28, 2015 02:23
> > To: Winkler, Tomas
> > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning raw
> > arrays
> > 
> > On Wed, May 27, 2015 at 04:14:20PM -0700, Greg KH wrote:
> > > On Wed, May 27, 2015 at 05:42:22PM +0000, Winkler, Tomas wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Greg KH [mailto:gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org]
> > > > > Sent: Wednesday, May 27, 2015 20:29
> > > > > To: Winkler, Tomas
> > > > > Cc: arnd-r2nGTMty4D4@public.gmane.org; Stephen Rothwell; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > > > > Subject: Re: [char-misc-next 04/11 V2] uuid: extract macros for assigning
> > raw
> > > > > arrays
> > > > >
> > > > > On Wed, May 27, 2015 at 05:24:01PM +0000, Winkler, Tomas wrote:
> > > > > >
> > > > > > >
> > > > > > > On Wed, May 27, 2015 at 06:42:13PM +0300, Tomas Winkler wrote:
> > > > > > > > In order for mei client devices to use device id based on uuid we
> > > > > > > > have to use common types between user space (file2alias.c).
> > > > > > > > Similarly to vmbus,  mei  uses raw 16 byte array for that.
> > > > > > > > To leverage on existing infrastructure around uuid_le type
> > > > > > > > defined in uuid.h we add helper macros to handle conversions
> > between
> > > > > > > > raw 16 byte array and uuid_{le,be} types.
> > > > > > >
> > > > > > > You aren't adding a helper macro, you are just redefining the existing
> > > > > > > macros using a different one.
> > > > > >
> > > > > > Not exactly I'm using both the one I've added for device ids and the old
> > one for
> > > > > all the other flows.
> > > > > >
> > > > > >  But I can't see why this is needed, what
> > > > > > > does this solve that vmbus and other uses of the existing macros don't
> > > > > > > need?  In other words, what makes mei so special that it needs a
> > "lower"
> > > > > > > level macro than every other subsystem?
> > > > > >
> > > > > > It's not special there is actually a lot of code duplication around uuid
> > handling
> > > > > > every subsystem is using their own macros but it can be consolidated
> > around
> > > > > uuid.h
> > > > > >
> > > > > > So vmbus can use that
> > > > > > Instead of
> > > > > > /*
> > > > > >  * Network GUID
> > > > > >  * {f8615163-df3e-46c5-913f-f2d2f965ed0e}
> > > > > >  */
> > > > > > #define HV_NIC_GUID \
> > > > > >         .guid = { \
> > > > > >                         0x63, 0x51, 0x61, 0xf8, 0x3e, 0xdf, 0xc5, 0x46, \
> > > > > >                         0x91, 0x3f, 0xf2, 0xd2, 0xf9, 0x65, 0xed, 0x0e \
> > > > > >                 }
> > > > > >
> > > > > > The can use the new macro to make it more readable, something in spirit
> > of:
> > > > > >
> > > > > > #define HV_NIC_GUID __UUID_LE(f8615163-df3e-46c5-913f-
> > f2d2f965ed0e)
> > > > >
> > > > > Why the "__" usage here?  That signifies a "private" namespace, why add
> > > > > that to the user visible header files?
> > > >
> > > > I take any other suggestion for macro names.
> > > > Not sure how I would reuse the macros if I don't export them both,
> > > > second this can be used also by user space.
> > >
> > > But it's not needed at all.
> > >
> > > Below is a patch on top of my current tree that makes this patch not
> > > needed.  Any objection to me just applying it instead?
> > >
> > > > > And are you going to send patches for vmbus and other drivers to fix
> > > > > everything up to use these new macros?  Someone has to...
> > > >
> > > > Can be done but I cannot test their code and  now I'm busy with splitting the
> > big bus patch :)
> > >
> > > Ok, that means no one is ever going to do that work, so it's not a valid
> > > reason to accept such a change.  I prefer the patch below.
> > 
> > Oops, that didn't build, I forgot one change in the mei core (getting
> > rid of two casts.)  Try this one instead.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> > 
> > diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
> > index de8fd089a8a4..dd52f224027e 100644
> > --- a/drivers/misc/mei/bus.c
> > +++ b/drivers/misc/mei/bus.c
> > @@ -54,9 +54,9 @@ static int mei_cl_device_match(struct device *dev, struct
> > device_driver *drv)
> > 
> >  	id = driver->id_table;
> > 
> > -	while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
> > +	while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
> > 
> > -		if (!uuid_le_cmp(*uuid, uuid_le_cast(id->uuid))) {
> > +		if (!uuid_le_cmp(*uuid, id->uuid)) {
> >  			if (id->name[0]) {
> >  				if (!strncmp(name, id->name, sizeof(id->name)))
> >  					return 1;
> 
> You can also drop the uuid_le_cast function 

Odd that gcc didn't complain about that.  Now removed, I'll resend it in
"official" form.

thanks,

greg k-h

[PATCH] mei: fix up uuid matching

[Greg KH]

From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

A previous commit, c93b76b34b4d ("mei: bus: report also uuid in module
alias") caused a build error as I missed applying a needed patch to add
some macros to uapi/linux/uuid.h.  Instead of those additional macros,
change the mei code to use the existing uuid structure directly.

Fixes: c93b76b34b4d
Cc: Tomas Winkler <tomas.winkler@intel.com>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index de8fd089a8a4..357b6ae4d207 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -30,11 +30,6 @@
 #define to_mei_cl_driver(d) container_of(d, struct mei_cl_driver, driver)
 #define to_mei_cl_device(d) container_of(d, struct mei_cl_device, dev)
 
-static inline uuid_le uuid_le_cast(const __u8 uuid[16])
-{
-	return *(uuid_le *)uuid;
-}
-
 static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
 {
 	struct mei_cl_device *device = to_mei_cl_device(dev);
@@ -54,9 +49,9 @@ static int mei_cl_device_match(struct device *dev, struct device_driver *drv)
 
 	id = driver->id_table;
 
-	while (uuid_le_cmp(NULL_UUID_LE, uuid_le_cast(id->uuid))) {
+	while (uuid_le_cmp(NULL_UUID_LE, id->uuid)) {
 
-		if (!uuid_le_cmp(*uuid, uuid_le_cast(id->uuid))) {
+		if (!uuid_le_cmp(*uuid, id->uuid)) {
 			if (id->name[0]) {
 				if (!strncmp(name, id->name, sizeof(id->name)))
 					return 1;
diff --git a/drivers/nfc/mei_phy.h b/drivers/nfc/mei_phy.h
index a51f8f2685cc..fbfa3e61738f 100644
--- a/drivers/nfc/mei_phy.h
+++ b/drivers/nfc/mei_phy.h
@@ -5,7 +5,7 @@
 #include <net/nfc/hci.h>
 #include <linux/uuid.h>
 
-#define MEI_NFC_UUID __UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
+#define MEI_NFC_UUID UUID_LE(0x0bb17a78, 0x2a8e, 0x4c50, \
 		0x94, 0xd4, 0x50, 0x26, 0x67, 0x23, 0x77, 0x5c)
 #define MEI_NFC_HEADER_SIZE 10
 #define MEI_NFC_MAX_HCI_PAYLOAD 300
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 2d2b2b571d61..048c270822f9 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -614,7 +614,7 @@ struct ipack_device_id {
  */
 struct mei_cl_device_id {
 	char name[MEI_CL_NAME_SIZE];
-	__u8 uuid[16];
+	uuid_le uuid;
 	kernel_ulong_t driver_info;
 };
 
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 62c517f4b592..718b2a29bd43 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -34,6 +34,9 @@ typedef Elf64_Addr	kernel_ulong_t;
 typedef uint32_t	__u32;
 typedef uint16_t	__u16;
 typedef unsigned char	__u8;
+typedef struct {
+	__u8 b[16];
+} uuid_le;
 
 /* Big exception to the "don't include kernel headers into userspace, which
  * even potentially has different endianness and word sizes, since
@@ -131,13 +134,13 @@ static inline void add_wildcard(char *str)
 		strcat(str + len, "*");
 }
 
-static inline void add_uuid(char *str, __u8 uuid[16])
+static inline void add_uuid(char *str, uuid_le uuid)
 {
 	int len = strlen(str);
 	int i;
 
 	for (i = 0; i < 16; i++)
-		sprintf(str + len + (i << 1), "%02x", uuid[i]);
+		sprintf(str + len + (i << 1), "%02x", uuid.b[i]);
 }
 
 /**

Re: [PATCH] mei: fix up uuid matching

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1012 bytes --]

Hi Greg,

On Wed, 27 May 2015 17:17:27 -0700 Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
>
> From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> 
> A previous commit, c93b76b34b4d ("mei: bus: report also uuid in module
> alias") caused a build error as I missed applying a needed patch to add
> some macros to uapi/linux/uuid.h.  Instead of those additional macros,
> change the mei code to use the existing uuid structure directly.
> 
> Fixes: c93b76b34b4d
> Cc: Tomas Winkler <tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Reported-by: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>

I added this to linux-next today (well, yesterday now :-)).
-- 
Cheers,
Stephen Rothwell                    sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: [PATCH] mei: fix up uuid matching

[Winkler, Tomas]

> -----Original Message-----
> From: Stephen Rothwell [mailto:sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org]
> Sent: Thursday, May 28, 2015 17:41
> To: Greg KH
> Cc: Winkler, Tomas; Samuel Ortiz; arnd-r2nGTMty4D4@public.gmane.org; linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Subject: Re: [PATCH] mei: fix up uuid matching
> 
> Hi Greg,
> 
> On Wed, 27 May 2015 17:17:27 -0700 Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG2l+swfVvueK@public.gmane.org'>
> wrote:
> >
> > From: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> >
> > A previous commit, c93b76b34b4d ("mei: bus: report also uuid in module
> > alias") caused a build error as I missed applying a needed patch to add
> > some macros to uapi/linux/uuid.h.  Instead of those additional macros,
> > change the mei code to use the existing uuid structure directly.
> >
> > Fixes: c93b76b34b4d
> > Cc: Tomas Winkler <tomas.winkler-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> > Cc: Samuel Ortiz <sameo-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> > Reported-by: Stephen Rothwell <sfr-3FnU+UHB4dNDw9hX6IcOSA@public.gmane.org>
> > Signed-off-by: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> 
> I added this to linux-next today (well, yesterday now :-)).

Currently I'm traveling so I cannot check the fix in runtime but it seems okay
Tomas