[0/8] staging: sm750fb: change function naming style

Address checkpatch's "Avoid camelCase" for sm750fb module by changing
function name to conform to kernel code style.

The patches are required to be applied in sequence.

Richard Akintola (8):
  staging: sm750fb: change sii164GetDeviceID to snake_case
  staging: sm750fb: change sii164ResetChip to snake_case
  staging: sm750fb: change sii164SetPower to snake_case
  staging: sm750fb: change sii164GetChipString to snake_case
  staging: sm750fb: change sii164EnableHotPlugDetection to snake_case
  staging: sm750fb: change sii164IsConnected to snake_case
  staging: sm750fb: change sii164CheckInterrupt to snake_case
  staging: sm750fb: change sii164ClearInterrupt to snake_case

 drivers/staging/sm750fb/ddk750_dvi.c    | 16 +++++-----
 drivers/staging/sm750fb/ddk750_sii164.c | 42 ++++++++++++-------------
 drivers/staging/sm750fb/ddk750_sii164.h | 16 +++++-----
 3 files changed, 37 insertions(+), 37 deletions(-)

On Sat, Apr 5, 2025 at 2:37 PM Greg KH <gregkh@linuxfoundation.org> wrote:

> - This looks like a new version of a previously submitted patch, but you
>   did not list below the --- line any changes from the previous version.

Please, how do I resolve this issue?

Richard Akintola

On Sat, Apr 5, 2025 at 3:16 PM Samuel Abraham
<abrahamadekunle50@gmail.com> wrote:
>
> On Sat, Apr 5, 2025 at 3:07 PM Richard Akintola
> <princerichard17a@gmail.com> wrote:
> >
> > On Sat, Apr 5, 2025 at 2:37 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > > - This looks like a new version of a previously submitted patch, but you
> > >   did not list below the --- line any changes from the previous version.
> >
> > Please, how do I resolve this issue?
> >
> > Richard Akintola
>
> Hello Richard
>
> THis is the main message from the bot
>
> This looks like a new version of a previously submitted patch, but you
>   did not list below the --- line any changes from the previous version.
>   Please read the section entitled "The canonical patch format" in the
>   kernel file, Documentation/process/submitting-patches.rst for what
>   needs to be done here to properly describe this.
>
> It basically means that if you made a change to a patch, you will have
> a new version.
> You will have to indicate the patch version and also what changed
>
> So lets say you have a first Patch then after review, or you edited
> the commit message
> or made a change in the code or something,
> you will now have a new patch which you will call v2.
>
> you will use git format-patch -o /tmp/ --subject-prefix="PATCH v2" <commit-ID>
>
> then when you want to send with mutt, immediately after the signed-off
> by line there are three dashes (---),
> You will then write what changes under these three dashes in the format
>
> signedoff-by: Richard
> ---
> Changes in v1:
>    - This is what changed in v1.
>
> I hope this helps
>
Also, you can go to the "Submitting a Patchset" section down the page
of the firstPatch
documentation for more information on versioning patchsets.

Adekunle

On Mon, Apr 07, 2025 at 06:57:38AM +0100, Richard Akintola wrote:
> On Sat, Apr 5, 2025 at 3:16 PM Samuel Abraham
> <abrahamadekunle50@gmail.com> wrote:
> 
> > This looks like a new version of a previously submitted patch, but you
> >   did not list below the --- line any changes from the previous version.
> >   Please read the section entitled "The canonical patch format" in the
> >   kernel file, Documentation/process/submitting-patches.rst for what
> >   needs to be done here to properly describe this.
> 
> 
> Hi Samuel,
> 
> I sent the patches individually before, but I was instructed to send a
> patch series.
> 
> Given that I didn't change any code, should I still add version number
> and sending
> patch series as the difference?

Yes.

Think about it from our side, what would you want to see if you had to
review hundreds of different patches a day?

thanks,

greg k-h

On Mon, Apr 7, 2025 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Mon, Apr 07, 2025 at 06:57:38AM +0100, Richard Akintola wrote:
> > On Sat, Apr 5, 2025 at 3:16 PM Samuel Abraham
> > <abrahamadekunle50@gmail.com> wrote:
> >
> > > This looks like a new version of a previously submitted patch, but you
> > >   did not list below the --- line any changes from the previous version.
> > >   Please read the section entitled "The canonical patch format" in the
> > >   kernel file, Documentation/process/submitting-patches.rst for what
> > >   needs to be done here to properly describe this.
> >
> >
> > Hi Samuel,
> >
> > I sent the patches individually before, but I was instructed to send a
> > patch series.
> >
> > Given that I didn't change any code, should I still add version number
> > and sending
> > patch series as the difference?
>
> Yes.
>
> Think about it from our side, what would you want to see if you had to
> review hundreds of different patches a day?
>
> thanks,
>
> greg k-h

Hi Greg,

I have sent the new version, please do have a look at it.
Thank you.

Richard Akintola

On Tue, Apr 8, 2025 at 11:48 AM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Apr 08, 2025 at 11:38:28AM +0100, Richard Akintola wrote:
> > On Mon, Apr 7, 2025 at 7:01 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Mon, Apr 07, 2025 at 06:57:38AM +0100, Richard Akintola wrote:
> > > > On Sat, Apr 5, 2025 at 3:16 PM Samuel Abraham
> > > > <abrahamadekunle50@gmail.com> wrote:
> > > >
> > > > > This looks like a new version of a previously submitted patch, but you
> > > > >   did not list below the --- line any changes from the previous version.
> > > > >   Please read the section entitled "The canonical patch format" in the
> > > > >   kernel file, Documentation/process/submitting-patches.rst for what
> > > > >   needs to be done here to properly describe this.
> > > >
> > > >
> > > > Hi Samuel,
> > > >
> > > > I sent the patches individually before, but I was instructed to send a
> > > > patch series.
> > > >
> > > > Given that I didn't change any code, should I still add version number
> > > > and sending
> > > > patch series as the difference?
> > >
> > > Yes.
> > >
> > > Think about it from our side, what would you want to see if you had to
> > > review hundreds of different patches a day?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Hi Greg,
> >
> > I have sent the new version, please do have a look at it.
>
> Again, please realize that some of us get hundreds, if not thousands, of
> changes a day to review.  A normal delay is about 1-2 weeks to get to a
> review of a change.  Ideally it would be faster, but there are only so
> many hours in a day.
>
> To help make this faster, please help out in reviewing other changes
> submitted by other developers, that will cause your changes to bubble
> up.
>
> thanks,
>
> greg k-h

I really do understand the situation and to be candid, I am in no hurry
but won't mind helping out in the review, perhaps a help with Review 101?

thanks,

Richard Akintola