[PATCH v2] staging: greybus: gbphy: replace sprintf() with sysfs_emit()

[PATCH v2] staging: greybus: gbphy: replace sprintf() with sysfs_emit()

[Neel Bullywon]

Replaced sprintf() with sysfs_emit() in the protocol_id_show() sysfs
attribute function. This code is safe, as replacing sprintf() with
sysfs_emit() gets rid of calls to sprintf()
as part of kernel hardening and sysfs_emit() is more appropriate in
this context.

Signed-off-by: Neel Bullywon <neelb2403@gmail.com>
---
This was compile-tested only (no VM/hardware used)
---
 drivers/staging/greybus/gbphy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/greybus/gbphy.c b/drivers/staging/greybus/gbphy.c
index 60cf09a302a7..55f132b09cee 100644
--- a/drivers/staging/greybus/gbphy.c
+++ b/drivers/staging/greybus/gbphy.c
@@ -31,7 +31,7 @@ static ssize_t protocol_id_show(struct device *dev,
 {
 	struct gbphy_device *gbphy_dev = to_gbphy_dev(dev);
 
-	return sprintf(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id);
+	return sysfs_emit(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id);
 }
 static DEVICE_ATTR_RO(protocol_id);
 
-- 
2.44.0

Re: [PATCH v2] staging: greybus: gbphy: replace sprintf() with sysfs_emit()

[Dan Carpenter]

It's best to wait a day between resends.

On Wed, Feb 04, 2026 at 05:13:42AM -0500, Neel Bullywon wrote:
> Replaced sprintf() with sysfs_emit() in the protocol_id_show() sysfs

I really hate to comment on this, because I famously get annoyed by
people who act like it's soooo important and we have one "reviewer" who
wants every sentence to be in imperative tense.  But past tense is kind
of ugly.  You did it right in the Subject on v2.  Use "Replace" instead
of "Replaced" here as well.

Btw, if someone provides you a commit message, then they're basically
obligated to allow it.

> attribute function. This code is safe, as replacing sprintf() with

s/as/as-is/?

> sysfs_emit() gets rid of calls to sprintf()

The line break is weird.

> as part of kernel hardening and sysfs_emit() is more appropriate in
> this context.
> 
> Signed-off-by: Neel Bullywon <neelb2403@gmail.com>
> ---
> This was compile-tested only (no VM/hardware used)
> ---

You need to put a little note here to say what changed.

https://staticthinking.wordpress.com/2022/07/27/how-to-send-a-v2-patch/

regards,
dan carpenter

Re: [PATCH v2] staging: greybus: gbphy: replace sprintf() with sysfs_emit()

[Greg Kroah-Hartman]

On Wed, Feb 04, 2026 at 05:13:42AM -0500, Neel Bullywon wrote:
> Replaced sprintf() with sysfs_emit() in the protocol_id_show() sysfs
> attribute function. This code is safe, as replacing sprintf() with
> sysfs_emit() gets rid of calls to sprintf()
> as part of kernel hardening and sysfs_emit() is more appropriate in
> this context.
> 
> Signed-off-by: Neel Bullywon <neelb2403@gmail.com>
> ---
> This was compile-tested only (no VM/hardware used)
> ---
>  drivers/staging/greybus/gbphy.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/greybus/gbphy.c b/drivers/staging/greybus/gbphy.c
> index 60cf09a302a7..55f132b09cee 100644
> --- a/drivers/staging/greybus/gbphy.c
> +++ b/drivers/staging/greybus/gbphy.c
> @@ -31,7 +31,7 @@ static ssize_t protocol_id_show(struct device *dev,
>  {
>  	struct gbphy_device *gbphy_dev = to_gbphy_dev(dev);
>  
> -	return sprintf(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id);
> +	return sysfs_emit(buf, "0x%02x\n", gbphy_dev->cport_desc->protocol_id);
>  }
>  static DEVICE_ATTR_RO(protocol_id);
>  
> -- 
> 2.44.0
> 

Hi,

This is the friendly patch-bot of Greg Kroah-Hartman.  You have sent him
a patch that has triggered this response.  He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created.  Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.

You are receiving this message because of the following common error(s)
as indicated below:

- This looks like a new version of a previously submitted patch, but you
  did not list below the --- line any changes from the previous version.
  Please read the section entitled "The canonical patch format" in the
  kernel file, Documentation/process/submitting-patches.rst for what
  needs to be done here to properly describe this.

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.

thanks,

greg k-h's patch email bot