[RESEND PATCH] bus: fsl-mc: Use strscpy() instead of strscpy_pad()

[RESEND PATCH] bus: fsl-mc: Use strscpy() instead of strscpy_pad()

[Thorsten Blum]

Both destination buffers are already zero-initialized, making strscpy()
sufficient for safely copying 'obj_type'. The additional NUL-padding
performed by strscpy_pad() is unnecessary.

If the destination buffer has a fixed length, strscpy() automatically
determines its size using sizeof() when the argument is omitted. This
makes the explicit size arguments unnecessary.

No functional changes intended.

Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
---
 drivers/bus/fsl-mc/dprc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/fsl-mc/dprc.c b/drivers/bus/fsl-mc/dprc.c
index dd1b5c0fb7e2..38d40c09b719 100644
--- a/drivers/bus/fsl-mc/dprc.c
+++ b/drivers/bus/fsl-mc/dprc.c
@@ -489,7 +489,7 @@ int dprc_set_obj_irq(struct fsl_mc_io *mc_io,
 	cmd_params->irq_addr = cpu_to_le64(irq_cfg->paddr);
 	cmd_params->irq_num = cpu_to_le32(irq_cfg->irq_num);
 	cmd_params->obj_id = cpu_to_le32(obj_id);
-	strscpy_pad(cmd_params->obj_type, obj_type, 16);
+	strscpy(cmd_params->obj_type, obj_type);
 
 	/* send command to mc*/
 	return mc_send_command(mc_io, &cmd);
@@ -561,7 +561,7 @@ int dprc_get_obj_region(struct fsl_mc_io *mc_io,
 	cmd_params = (struct dprc_cmd_get_obj_region *)cmd.params;
 	cmd_params->obj_id = cpu_to_le32(obj_id);
 	cmd_params->region_index = region_index;
-	strscpy_pad(cmd_params->obj_type, obj_type, 16);
+	strscpy(cmd_params->obj_type, obj_type);
 
 	/* send command to mc*/
 	err = mc_send_command(mc_io, &cmd);
-- 
2.49.0

Re: [RESEND PATCH] bus: fsl-mc: Use strscpy() instead of strscpy_pad()

[Ioana Ciornei]

On Tue, Apr 29, 2025 at 12:41:48PM +0200, Thorsten Blum wrote:
> Both destination buffers are already zero-initialized, making strscpy()
> sufficient for safely copying 'obj_type'. The additional NUL-padding
> performed by strscpy_pad() is unnecessary.
> 
> If the destination buffer has a fixed length, strscpy() automatically
> determines its size using sizeof() when the argument is omitted. This
> makes the explicit size arguments unnecessary.
> 
> No functional changes intended.
> 
> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>

Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>

Christophe, could you also pick-up this patch when you have a chance?

Thank you,
Ioana

Re: [RESEND PATCH] bus: fsl-mc: Use strscpy() instead of strscpy_pad()

[Christophe Leroy]

Le 29/04/2025 à 13:47, Ioana Ciornei a écrit :
> On Tue, Apr 29, 2025 at 12:41:48PM +0200, Thorsten Blum wrote:
>> Both destination buffers are already zero-initialized, making strscpy()
>> sufficient for safely copying 'obj_type'. The additional NUL-padding
>> performed by strscpy_pad() is unnecessary.
>>
>> If the destination buffer has a fixed length, strscpy() automatically
>> determines its size using sizeof() when the argument is omitted. This
>> makes the explicit size arguments unnecessary.
>>
>> No functional changes intended.
>>
>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
> 
> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> 
> Christophe, could you also pick-up this patch when you have a chance?
> 

Sure I will take it when time comes, but again I'd expect an explanation 
inside the patch (below the ---) for the resend. I now have this patch 
twice in the list and don't know why, see 
https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=&submitter=&state=&q=&archive=&delegate=61610

Christophe

Re: [RESEND PATCH] bus: fsl-mc: Use strscpy() instead of strscpy_pad()

[Thorsten Blum]

Hi Christophe,

On 29. Apr 2025, at 13:58, Christophe Leroy wrote:
> Le 29/04/2025 à 13:47, Ioana Ciornei a écrit:
>> On Tue, Apr 29, 2025 at 12:41:48PM +0200, Thorsten Blum wrote:
>>> Both destination buffers are already zero-initialized, making strscpy()
>>> sufficient for safely copying 'obj_type'. The additional NUL-padding
>>> performed by strscpy_pad() is unnecessary.
>>> 
>>> If the destination buffer has a fixed length, strscpy() automatically
>>> determines its size using sizeof() when the argument is omitted. This
>>> makes the explicit size arguments unnecessary.
>>> 
>>> No functional changes intended.
>>> 
>>> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
>> Reviewed-by: Ioana Ciornei <ioana.ciornei@nxp.com>
>> Christophe, could you also pick-up this patch when you have a chance?
> 
> Sure I will take it when time comes, but again I'd expect an explanation inside the patch (below the ---) for the resend. I now have this patch twice in the list and don't know why, see https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=&submitter=&state=&q=&archive=&delegate=61610

A "resend" is meant as a "ping" and the patch is always unmodified, at
least that's my understanding of it. So there's no particular reason
other than: "Did you see my patch? Let me send it again just to be sure
you didn't miss it."

From [1]: "Don’t add “RESEND” when you are submitting a modified version
of your patch or patch series - “RESEND” only applies to resubmission of
a patch or patch series which have not been modified in any way from the
previous submission."

The patches are identical - just pick one.

Thanks,
Thorsten

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html#don-t-get-discouraged-or-impatient

Re: [RESEND PATCH] bus: fsl-mc: Use strscpy() instead of strscpy_pad()

[Christophe Leroy]

On Tue, 29 Apr 2025 12:41:48 +0200, Thorsten Blum wrote:
> Both destination buffers are already zero-initialized, making strscpy()
> sufficient for safely copying 'obj_type'. The additional NUL-padding
> performed by strscpy_pad() is unnecessary.
> 
> If the destination buffer has a fixed length, strscpy() automatically
> determines its size using sizeof() when the argument is omitted. This
> makes the explicit size arguments unnecessary.
> 
> [...]

Applied, thanks!

[1/1] bus: fsl-mc: Use strscpy() instead of strscpy_pad()
      commit: 61ddf5faa7cc091b409936d571ec1af34ce487a1

Best regards,
-- 
Christophe Leroy <christophe.leroy@csgroup.eu>