Re: [PATCH v1 06/10] device property: switch to use UUID API

[Andy Shevchenko]

On Thu, 2016-02-18 at 13:07 +0200, Mika Westerberg wrote:
> On Wed, Feb 17, 2016 at 02:17:24PM +0200, Andy Shevchenko wrote:
> > Switch to use a generic UUID API instead of custom approach. It
> > allows to
> > define UUIDs, compare them, and validate.
> > 
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
> > ---
> > Âdrivers/acpi/property.c | 18 ++++++++----------
> > Â1 file changed, 8 insertions(+), 10 deletions(-)
> > 
> > diff --git a/drivers/acpi/property.c b/drivers/acpi/property.c
> > index 2aee416..1e75305 100644
> > --- a/drivers/acpi/property.c
> > +++ b/drivers/acpi/property.c
> > @@ -25,15 +25,13 @@ static int acpi_data_get_property_array(struct
> > acpi_device_data *data,
> > Â					const union acpi_object
> > **obj);
> > Â
> > Â/* ACPI _DSD device properties UUID: daffd814-6eba-4d8c-8a91-
> > bc9bbf4aa301 */
> > -static const u8 prp_uuid[16] = {
> > -	0x14, 0xd8, 0xff, 0xda, 0xba, 0x6e, 0x8c, 0x4d,
> > -	0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01
> > -};
> > +static const uuid_le prp_uuid =
> > +	UUID_LE(0xdaffd814, 0x6eba, 0x4d8c,
> > +		0x8a, 0x91, 0xbc, 0x9b, 0xbf, 0x4a, 0xa3, 0x01);
> > Â/* ACPI _DSD data subnodes UUID: dbb8e3e6-5886-4ba6-8795-
> > 1319f52a966b */
> > -static const u8 ads_uuid[16] = {
> > -	0xe6, 0xe3, 0xb8, 0xdb, 0x86, 0x58, 0xa6, 0x4b,
> > -	0x87, 0x95, 0x13, 0x19, 0xf5, 0x2a, 0x96, 0x6b
> > -};
> > +static const uuid_le ads_uuid =
> > +	UUID_LE(0xdbb8e3e6, 0x5886, 0x4ba6,
> > +		0x87, 0x95, 0x13, 0x19, 0xf5, 0x2a, 0x96, 0x6b);
> 
> This looks better than the original but it is still not too readable.
> 
> I think it would be better to have uuid as string like:
> 
> static const char *ads_uuid = "dbb8e3e6-5886-4ba6-8795-1319f52a966b";
> 
> and then convert that to the right byte presentation when first time
> used. That would match the uuid format in the ACPI (and device
> properties) spec. and thus make it easier to read and understand.

Yes we can do this on slow paths. Or in cases where we know that
conversion happens only once.


-- 
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>
Intel Finland Oy