[PATCH v3] staging: sm750fb: Keep g_fbmode array non-const

[PATCH v3] staging: sm750fb: Keep g_fbmode array non-const

[Chhabilal Dangal]

The g_fbmode array is modified at runtime, so it must remain
non-const. Added clarifying comment.

Signed-off-by: Chhabilal Dangal <yogeshdangal66@gmail.com>
---
 drivers/staging/sm750fb/sm750.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 9f3e3d37e82a..a553099f42f3 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -33,6 +33,7 @@
 static int g_hwcursor = 1;
 static int g_noaccel;
 static int g_nomtrr;
+/* intentionally non-const since array is modified at runtime */
 static const char *g_fbmode[] = {NULL, NULL};
 static const char *g_def_fbmode = "1024x768-32@60";
 static char *g_settings;
-- 
2.54.0

Re: [PATCH v3] staging: sm750fb: Keep g_fbmode array non-const

[Greg Kroah-Hartman]

On Mon, May 11, 2026 at 10:47:45PM +0545, Chhabilal Dangal wrote:
> The g_fbmode array is modified at runtime, so it must remain
> non-const. Added clarifying comment.
> 
> Signed-off-by: Chhabilal Dangal <yogeshdangal66@gmail.com>
> ---
>  drivers/staging/sm750fb/sm750.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
> index 9f3e3d37e82a..a553099f42f3 100644
> --- a/drivers/staging/sm750fb/sm750.c
> +++ b/drivers/staging/sm750fb/sm750.c
> @@ -33,6 +33,7 @@
>  static int g_hwcursor = 1;
>  static int g_noaccel;
>  static int g_nomtrr;
> +/* intentionally non-const since array is modified at runtime */

No comment is needed, if you change the code, it breaks the build, so
that is very obvious as you would never submit a patch that you did not
build, right?  :)

thanks,

greg k-h

Re: [PATCH v3] staging: sm750fb: Keep g_fbmode array non-const

[Greg Kroah-Hartman]

On Tue, May 12, 2026 at 12:48:05AM +0545, Alone wrote:
> Thanks for the clarification and guidance.
> 
> I want to learn the correct workflow. As a student contributor, what checks
> and testing steps should I always perform before sending a patch?

Please start with not top-posting and sending html email :)

After that, go through the kernelnewbies.org first-patch tutorial, as
well as the free Linux Foundation kernel development online class.
Between those two, you should have a good basis for working on this
correctly.

Also read all of the documentation we have about submitting a patch.
People wrote that for a reason, don't ignore it :)

thanks,

greg k-h