[PATCH] HID: intel_ish-hid: use %pUL for uuid formatting

We have the %pU printf extension for doing exactly this. Saves some
.text, and is likely also a little faster.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 256521509d20..f4cbc744e657 100644
--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c

@@ -585,14 +585,7 @@ int ishtp_bus_new_client(struct ishtp_device *dev)
 	 */
 	i = dev->fw_client_presentation_num - 1;
 	device_uuid = dev->fw_clients[i].props.protocol_name;
-	dev_name = kasprintf(GFP_KERNEL,
-		"{%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-%02X%02X%02X%02X%02X%02X}",
-		device_uuid.b[3], device_uuid.b[2], device_uuid.b[1],
-		device_uuid.b[0], device_uuid.b[5], device_uuid.b[4],
-		device_uuid.b[7], device_uuid.b[6], device_uuid.b[8],
-		device_uuid.b[9], device_uuid.b[10], device_uuid.b[11],
-		device_uuid.b[12], device_uuid.b[13], device_uuid.b[14],
-		device_uuid.b[15]);
+	dev_name = kasprintf(GFP_KERNEL, "{%pUL}", device_uuid.b);
 	if (!dev_name)
 		return	-ENOMEM;
 

-- 
2.1.4

On Nov 30 2016 or thereabouts, Rasmus Villemoes wrote:

We have the %pU printf extension for doing exactly this. Saves some
.text, and is likely also a little faster.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>

Reviewed-by: Benjamin Tissoires <redacted>

On Thu, 2016-12-01 at 15:21 +0100, Benjamin Tissoires wrote:

On Nov 30 2016 or thereabouts, Rasmus Villemoes wrote:

quoted

We have the %pU printf extension for doing exactly this. Saves some
.text, and is likely also a little faster.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>

Reviewed-by: Benjamin Tissoires <redacted>

Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>

quoted

---
 drivers/hid/intel-ish-hid/ishtp/bus.c | 9 +--------
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/hid/intel-ish-hid/ishtp/bus.c

b/drivers/hid/intel-ish-hid/ishtp/bus.c
index 256521509d20..f4cbc744e657 100644

--- a/drivers/hid/intel-ish-hid/ishtp/bus.c
+++ b/drivers/hid/intel-ish-hid/ishtp/bus.c

@@ -585,14 +585,7 @@ int ishtp_bus_new_client(struct ishtp_device

*dev)
 	 */
 	i = dev->fw_client_presentation_num - 1;
 	device_uuid = dev->fw_clients[i].props.protocol_name;
-	dev_name = kasprintf(GFP_KERNEL,
-		"{%02X%02X%02X%02X-%02X%02X-%02X%02X-%02X%02X-
%02X%02X%02X%02X%02X%02X}",
-		device_uuid.b[3], device_uuid.b[2],
device_uuid.b[1],
-		device_uuid.b[0], device_uuid.b[5],
device_uuid.b[4],
-		device_uuid.b[7], device_uuid.b[6],
device_uuid.b[8],
-		device_uuid.b[9], device_uuid.b[10],
device_uuid.b[11],
-		device_uuid.b[12], device_uuid.b[13],
device_uuid.b[14],
-		device_uuid.b[15]);
+	dev_name = kasprintf(GFP_KERNEL, "{%pUL}", device_uuid.b);
 	if (!dev_name)
 		return	-ENOMEM;
 
-- 
2.1.4

On Wed, 30 Nov 2016, Rasmus Villemoes wrote:

We have the %pU printf extension for doing exactly this. Saves some
.text, and is likely also a little faster.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>

Applied, thanks.

-- 
Jiri Kosina
SUSE Labs

Hi Jiri,

As per the comment here, it seems that you applied v4 version of patch.

https://patchwork.kernel.org/patch/9428715/

But when I look at the upstream kernel, the very first version of the
patch was applied, which was wrong.

Basically the change should be in sensor_hub_get_feature() not in
sensor_hub_set_feature().
Otherwise it breaks sensor functionality.

How should we handle this?


Thanks,
Srinivas

On Wed, 14 Dec 2016, Srinivas Pandruvada wrote:

As per the comment here, it seems that you applied v4 version of patch.

https://patchwork.kernel.org/patch/9428715/

But when I look at the upstream kernel, the very first version of the
patch was applied, which was wrong.

Basically the change should be in sensor_hub_get_feature() not in
sensor_hub_set_feature().
Otherwise it breaks sensor functionality.

How should we handle this?

Hi Srinivas,

my whole queue is now merged by Linus, so any fixups should be submitted 
as standalone patches on top of current Linus' tree; I'll push the fix to 
Linus then for 4.10 still.

Ideally we also put proper "Fixes:" tag, so that it gets picked up by 
4.9-stable once/if there is one.

Thanks, and sorry for my brainfart; I'll check my archives to see what 
went wrong.

-- 
Jiri Kosina
SUSE Labs

On Wed, 2016-12-14 at 21:33 +0100, Jiri Kosina wrote:

On Wed, 14 Dec 2016, Srinivas Pandruvada wrote:

quoted

As per the comment here, it seems that you applied v4 version of

patch.

quoted

https://patchwork.kernel.org/patch/9428715/

But when I look at the upstream kernel, the very first version of

the

quoted

patch was applied, which was wrong.

Basically the change should be in sensor_hub_get_feature() not in
sensor_hub_set_feature().
Otherwise it breaks sensor functionality.

How should we handle this?

Hi Srinivas,

my whole queue is now merged by Linus, so any fixups should be
submitted 
as standalone patches on top of current Linus' tree; I'll push the
fix to 
Linus then for 4.10 still.

Ideally we also put proper "Fixes:" tag, so that it gets picked up
by 
4.9-stable once/if there is one.

Thanks, and sorry for my brainfart; I'll check my archives to see
what 
went wrong.

No problem at all.

Thanks,
Srinivas