| Message ID | cover.1743857160.git.princerichard17a@gmail.com |
|---|---|
| Headers | show |
| Series | staging: sm750fb: change function naming style | expand |
On Sat, Apr 05, 2025 at 02:00:51PM +0100, Richard Akintola wrote: > 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(-) > > -- > 2.39.5 > > Hi, This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him a patch that has triggered this response. He used to manually respond to these common problems, but in order to save his sanity (he kept writing the same thing over and over, yet to different people), I was created. Hopefully you will not take offence and will fix the problem in your patch and resubmit it so that it can be accepted into the Linux kernel tree. You are receiving this message because of the following common error(s) as indicated below: - 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. If you wish to discuss this problem further, or you have questions about how to resolve this issue, please feel free to respond to this email and Greg will reply once he has dug out from the pending patches received from other developers. thanks, greg k-h's patch email bot
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: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 Adekunle.
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 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? Richard Akintola
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: > Yes. > > Think about it from our side, what would you want to see if you had to > review hundreds of different patches a day? Thank you for the clarification Greg K-H, the change in perspective made it clear, would send them in as soon as I get hold of my PC. Richard Akintola
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 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
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