linux-kernel - Re: [PATCH 2/8] staging: sm750fb: rename gDviCtrlChipName

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6a47dc48a803b6a07a7fcd33eec8df9e60e86144.camel@aol.com>
Date: Fri, 18 Apr 2025 12:45:28 +0100
From: Ruben Wauters <rubenru09@....com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Sudip Mukherjee <sudipm.mukherjee@...il.com>, Teddy Wang
	 <teddy.wang@...iconmotion.com>, Sudip Mukherjee
	 <sudip.mukherjee@...ethink.co.uk>, linux-fbdev@...r.kernel.org, 
	linux-staging@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/8] staging: sm750fb: rename gDviCtrlChipName

On Fri, 2025-04-18 at 12:36 +0200, Greg Kroah-Hartman wrote:
> On Thu, Apr 17, 2025 at 08:02:50PM +0100, Ruben Wauters wrote:
> > Renames gDviCtrlChipName to dvi_controller_chip_name
> > This fixes checkpatch.pl's camel case check.
> > 
> > Signed-off-by: Ruben Wauters <rubenru09@....com>
> > 
> > ---
> > 
> > I changed the name to dvi_controller_chip_name as I
> > believe it is somewhat more descriptive than
> > g_dvi_ctrl_chip_name. If the second one is wanted instead
> > please let me know and I will change it
> > ---
> >  drivers/staging/sm750fb/ddk750_sii164.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/staging/sm750fb/ddk750_sii164.c
> > b/drivers/staging/sm750fb/ddk750_sii164.c
> > index dd7811b18bf6..d4309e0d807f 100644
> > --- a/drivers/staging/sm750fb/ddk750_sii164.c
> > +++ b/drivers/staging/sm750fb/ddk750_sii164.c
> > @@ -14,7 +14,7 @@
> >  
> >  #ifdef SII164_FULL_FUNCTIONS
> 
> This is never defined, so instead of papering over variable names
> that
> are crazy, why not just remove all of the code in the blocks for this
> define entirely?

Given the amount of code that is never used and the time went into
writing this, it does make me wonder whether this code *should* be used
instead of being removed. I don't know exactly how it would be
integrated however, removal as of now might be the easiest option, but
I'm not entirely sure whether it would be the best option in terms of
functionality.

> thanks,
> 
> greg k-h