On Fri, Oct 13, 2023 at 02:33:00PM +0300, Dorcas Litunya wrote: > On Fri, Oct 13, 2023 at 01:48:08PM +0300, Dan Carpenter wrote: > > On Fri, Oct 13, 2023 at 01:42:15PM +0300, Dorcas AnonoLitunya wrote: > > > From: Dorcas Anono Litunya <anonolitunya@xxxxxxxxx> > > > > > > Change camelCase variables in file to snake_case for consistent naming > > > practices. Issue found by checkpatch. > > > > > > Signed-off-by: Dorcas Anono Litunya <anonolitunya@xxxxxxxxx> > > > --- > > > drivers/staging/sm750fb/ddk750_mode.c | 86 +++++++++++++-------------- > > > drivers/staging/sm750fb/ddk750_mode.h | 2 +- > > > drivers/staging/sm750fb/sm750_hw.c | 2 +- > > > 3 files changed, 45 insertions(+), 45 deletions(-) > > > > > > diff --git a/drivers/staging/sm750fb/ddk750_mode.c b/drivers/staging/sm750fb/ddk750_mode.c > > > index e00a6cb31947..f08dcab29172 100644 > > > --- a/drivers/staging/sm750fb/ddk750_mode.c > > > +++ b/drivers/staging/sm750fb/ddk750_mode.c > > > @@ -14,13 +14,13 @@ > > > * in bit 29:27 of Display Control register. > > > */ > > > static unsigned long > > > -displayControlAdjust_SM750LE(struct mode_parameter *pModeParam, > > > - unsigned long dispControl) > > > +display_control_adjust_SM750LE(struct mode_parameter *p_mode_param, > > > > The p stands for pointer. We don't like that naming style. Just call > > it mode_param. > > > > Thes are the renamed things. > > > > displayControlAdjust_SM750LE => display_control_adjust_SM750LE > > pModeParam => p_mode_param > > dispControl => disp_control > > programModeRegisters => program_mode_registers > > ddk750_setModeTiming => ddk750_set_mode_timing > > > > I feel like this would be better broken up probably into one variable > > per patch. It's jumping around between files. These variables are not > > closely related. > Thanks for the feedback Dan. I will revise to do one variable per patch. > > However,I have an inquiry the main reason its jumping between files is because one of the > functions I am modifying(the ddk_set_mode_timing) is imported and used > in other files. In this case, should I do one patch per variable per > file? No that would break the build... It's just that I felt that in this case it's especially useful to break it apart because some of them affect multiple files and some of the variables are local to a given function. (You should still adjust the header file to match even though the compiler doesn't care). regards, dan carpenter
