[PATCH] regulator: hi6421v600: Truncate long strings for trailing NUL

Kees Cook posted 1 patch 11 months ago
drivers/regulator/hi6421v600-regulator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
[PATCH] regulator: hi6421v600: Truncate long strings for trailing NUL
Posted by Kees Cook 11 months ago
GCC 15's -Wunterminated-string-initialization saw that these strings
were being truncated. Adjust the initializer so that the needed final
NUL character will be present.

Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <kees@kernel.org>
---
 drivers/regulator/hi6421v600-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/hi6421v600-regulator.c b/drivers/regulator/hi6421v600-regulator.c
index e5f6fbfc9016..e74f992fd85f 100644
--- a/drivers/regulator/hi6421v600-regulator.c
+++ b/drivers/regulator/hi6421v600-regulator.c
@@ -275,7 +275,7 @@ static int hi6421_spmi_regulator_probe(struct platform_device *pdev)
 }
 
 static const struct platform_device_id hi6421_spmi_regulator_table[] = {
-	{ .name = "hi6421v600-regulator" },
+	{ .name = "hi6421v600-regulato" },
 	{},
 };
 MODULE_DEVICE_TABLE(platform, hi6421_spmi_regulator_table);
@@ -283,7 +283,7 @@ MODULE_DEVICE_TABLE(platform, hi6421_spmi_regulator_table);
 static struct platform_driver hi6421_spmi_regulator_driver = {
 	.id_table = hi6421_spmi_regulator_table,
 	.driver = {
-		.name = "hi6421v600-regulator",
+		.name = "hi6421v600-regulato",
 		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
 	},
 	.probe	= hi6421_spmi_regulator_probe,
-- 
2.34.1
Re: [PATCH] regulator: hi6421v600: Truncate long strings for trailing NUL
Posted by Kees Cook 10 months ago
On Mon, Mar 10, 2025 at 03:24:09PM -0700, Kees Cook wrote:
> GCC 15's -Wunterminated-string-initialization saw that these strings
> were being truncated. Adjust the initializer so that the needed final
> NUL character will be present.
> 
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Signed-off-by: Kees Cook <kees@kernel.org>
> ---
>  drivers/regulator/hi6421v600-regulator.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/regulator/hi6421v600-regulator.c b/drivers/regulator/hi6421v600-regulator.c
> index e5f6fbfc9016..e74f992fd85f 100644
> --- a/drivers/regulator/hi6421v600-regulator.c
> +++ b/drivers/regulator/hi6421v600-regulator.c
> @@ -275,7 +275,7 @@ static int hi6421_spmi_regulator_probe(struct platform_device *pdev)
>  }
>  
>  static const struct platform_device_id hi6421_spmi_regulator_table[] = {
> -	{ .name = "hi6421v600-regulator" },
> +	{ .name = "hi6421v600-regulato" },
>  	{},
>  };
>  MODULE_DEVICE_TABLE(platform, hi6421_spmi_regulator_table);
> @@ -283,7 +283,7 @@ MODULE_DEVICE_TABLE(platform, hi6421_spmi_regulator_table);
>  static struct platform_driver hi6421_spmi_regulator_driver = {
>  	.id_table = hi6421_spmi_regulator_table,
>  	.driver = {
> -		.name = "hi6421v600-regulator",
> +		.name = "hi6421v600-regulato",
>  		.probe_type = PROBE_PREFER_ASYNCHRONOUS,
>  	},
>  	.probe	= hi6421_spmi_regulator_probe,

Friendly ping on this patch. Who can pick this up?

Thanks!

-Kees

-- 
Kees Cook
Re: [PATCH] regulator: hi6421v600: Truncate long strings for trailing NUL
Posted by Mark Brown 10 months ago
On Mon, Apr 07, 2025 at 11:35:33AM -0700, Kees Cook wrote:
> On Mon, Mar 10, 2025 at 03:24:09PM -0700, Kees Cook wrote:

> > GCC 15's -Wunterminated-string-initialization saw that these strings
> > were being truncated. Adjust the initializer so that the needed final
> > NUL character will be present.

> Friendly ping on this patch. Who can pick this up?

Please don't send content free pings and please allow a reasonable time
for review.  People get busy, go on holiday, attend conferences and so 
on so unless there is some reason for urgency (like critical bug fixes)
please allow at least a couple of weeks for review.  If there have been
review comments then people may be waiting for those to be addressed.

Sending content free pings adds to the mail volume (if they are seen at
all) which is often the problem and since they can't be reviewed
directly if something has gone wrong you'll have to resend the patches
anyway, so sending again is generally a better approach though there are
some other maintainers who like them - if in doubt look at how patches
for the subsystem are normally handled.