| Message ID | 1420332469-5907-1-git-send-email-rickard_strandqvist@spectrumdigital.se (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Kalle Valo |
| Headers | show |
On 01/03/2015 06:47 PM, Rickard Strandqvist wrote: > Removes some functions that are not used anywhere: > dma_txflush() dma_txsuspended() > > This was partially found by using a static code analysis program called cppcheck. > > Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> > --- > drivers/net/wireless/brcm80211/brcmsmac/dma.c | 19 ------------------- > drivers/net/wireless/brcm80211/brcmsmac/dma.h | 2 -- > 2 files changed, 21 deletions(-) Just because file dma.c is involved, it does not need to be, nor should it be in the subject line. You could specify the driver names in the file tree after wireless. In this instance, one possible subject would be "brcm80211: brcmsmac: Remove some unused functions". On the other hand, if you look at "git log" to see past patches, the driver maintainers even leave off the brcm80211 part, thus to match them, the subject should be "brcmsmac: Remove some unused functions". As was suggested earlier, you need to look at the precedents. Keeping a uniform method of patch naming helps when looking for patches in the git log. Larry -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-01-04 7:21 GMT+01:00 Larry Finger <Larry.Finger@lwfinger.net>: > On 01/03/2015 06:47 PM, Rickard Strandqvist wrote: >> >> Removes some functions that are not used anywhere: >> dma_txflush() dma_txsuspended() >> >> This was partially found by using a static code analysis program called >> cppcheck. >> >> Signed-off-by: Rickard Strandqvist >> <rickard_strandqvist@spectrumdigital.se> >> --- >> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 19 ------------------- >> drivers/net/wireless/brcm80211/brcmsmac/dma.h | 2 -- >> 2 files changed, 21 deletions(-) > > > Just because file dma.c is involved, it does not need to be, nor should it > be in the subject line. You could specify the driver names in the file tree > after wireless. In this instance, one possible subject would be "brcm80211: > brcmsmac: Remove some unused functions". On the other hand, if you look at > "git log" to see past patches, the driver maintainers even leave off the > brcm80211 part, thus to match them, the subject should be "brcmsmac: Remove > some unused functions". > > As was suggested earlier, you need to look at the precedents. Keeping a > uniform method of patch naming helps when looking for patches in the git > log. > > Larry > Hi Larry As I hope you can see I have made some changes regarding the subject-line. Thought it was an advantage to be able to see which file I actually removed something from. There seems to be a big focus on getting right on subject-line right in recent weeks. I wonder why there is a script that takes a file name, and respond with an appropriate subject line? But ok, I change my script accordingly. Should I submit the patch again? Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Larry Finger <Larry.Finger@lwfinger.net> writes: > On 01/03/2015 06:47 PM, Rickard Strandqvist wrote: >> Removes some functions that are not used anywhere: >> dma_txflush() dma_txsuspended() >> >> This was partially found by using a static code analysis program called cppcheck. >> >> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> >> --- >> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 19 ------------------- >> drivers/net/wireless/brcm80211/brcmsmac/dma.h | 2 -- >> 2 files changed, 21 deletions(-) > > Just because file dma.c is involved, it does not need to be, nor > should it be in the subject line. You could specify the driver names > in the file tree after wireless. In this instance, one possible > subject would be "brcm80211: brcmsmac: Remove some unused functions". > On the other hand, if you look at "git log" to see past patches, the > driver maintainers even leave off the brcm80211 part, thus to match > them, the subject should be "brcmsmac: Remove some unused functions". This is a handy way to check what kind of format you should use: $ git log --oneline --no-merges drivers/net/wireless/brcm80211/brcmsmac/dma.c | head a38a9ef1c064 brcm80211: use container_of to resolve dma_info from dma_pub 67d0cf50bd32 brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error() 55cec505559d brcmsmac: Fix possible NULL pointer dereference in _dma_ctrlflags() 9242c7261b8c brcmsmac: Remove some noisy and uninformative debug messages 0c9a0a1dd145 brcmsmac: Add tracepoint for AMPDU session information 90123e045cac brcmsmac: Add brcms_dbg_dma() debug macro b05618deb4ac brcmsmac: Use correct descriptor count when calculating next rx descriptor e041f65d5f00 brcmsmac: Remove internal tx queue 05f8a6160491 brcmsmac: Add helper function for updating txavail count ec5ab1dd73a4 brcmsmac: fix DMA on SoCs > As was suggested earlier, you need to look at the precedents. Keeping > a uniform method of patch naming helps when looking for patches in the > git log. Yeah, and also having clean[1] patch titles makes working with patchwork so much easier and hence me happier :) [1] clean patch title == short, clear and unique
Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> writes: > As I hope you can see I have made some changes regarding the > subject-line. Thought it was an advantage to be able to see which file > I actually removed something from. There seems to be a big focus on > getting right on subject-line right in recent weeks. > > I wonder why there is a script that takes a file name, and respond > with an appropriate subject line? I don't think you can really automate this as some drivers do this a bit differently. You always need to manually check the commit log. > But ok, I change my script accordingly. Should I submit the patch again? Yes, please resubmit.
On 01/05/15 11:49, Kalle Valo wrote: > Rickard Strandqvist<rickard_strandqvist@spectrumdigital.se> writes: > >> As I hope you can see I have made some changes regarding the >> subject-line. Thought it was an advantage to be able to see which file >> I actually removed something from. There seems to be a big focus on >> getting right on subject-line right in recent weeks. >> >> I wonder why there is a script that takes a file name, and respond >> with an appropriate subject line? Is there a script for this? Anyway, I would say driver name is enough. Enough about the subject line ;-) I would like to give some general remarks as you seem to touch a lot of kernel code. First off, I think it is good to remove unused stuff. However, I would like some more explanation on your methodology apart from "partially found by using a static code analysis program". So a cover-letter explaining that would have been nice (maybe still is). Things like Kconfig option can affect whether function are used or not so how did you cover that. Regards, Arend > I don't think you can really automate this as some drivers do this a bit > differently. You always need to manually check the commit log. > >> But ok, I change my script accordingly. Should I submit the patch again? > > Yes, please resubmit. > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-01-05 12:06 GMT+01:00 Arend van Spriel <arend@broadcom.com>: > On 01/05/15 11:49, Kalle Valo wrote: >> >> Rickard Strandqvist<rickard_strandqvist@spectrumdigital.se> writes: >> >>> As I hope you can see I have made some changes regarding the >>> subject-line. Thought it was an advantage to be able to see which file >>> I actually removed something from. There seems to be a big focus on >>> getting right on subject-line right in recent weeks. >>> >>> I wonder why there is a script that takes a file name, and respond >>> with an appropriate subject line? > > > Is there a script for this? Anyway, I would say driver name is enough. > Enough about the subject line ;-) I would like to give some general remarks > as you seem to touch a lot of kernel code. First off, I think it is good to > remove unused stuff. However, I would like some more explanation on your > methodology apart from "partially found by using a static code analysis > program". So a cover-letter explaining that would have been nice (maybe > still is). Things like Kconfig option can affect whether function are used > or not so how did you cover that. > > Regards, > Arend > > >> I don't think you can really automate this as some drivers do this a bit >> differently. You always need to manually check the commit log. >> >>> But ok, I change my script accordingly. Should I submit the patch again? >> >> >> Yes, please resubmit. >> > Hi Arend Yes, a script that had been excellent, I think! I have one as part of my git send-email script, until a week ago, it was enough that I removed the "drivers/" and changed all "/" to ": " I have now been expanded my sed pipe a lot (tell me if anyone is interested) But now I've seen everything from uppercase and [DIR], etc. So I can not understand how anyone should be able to get the right name without a good help. Sure i like to share how I use cppcheck, but is very hesitant to write this with each patch mails I send though! I run: cppcheck --force --quiet --enable=all . Or a specific file instead of . This will include, among other things get a lot of error message such, +4000 for the kernel. (style) The function 'xxx' is never used For these I made a script that searched through all the files after the function name (cppcheck missed a few). And save the rest so I go through them and possibly send patches. Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 7 Jan 2015, Rickard Strandqvist wrote: > 2015-01-05 12:06 GMT+01:00 Arend van Spriel <arend@broadcom.com>: > > On 01/05/15 11:49, Kalle Valo wrote: > >> > >> Rickard Strandqvist<rickard_strandqvist@spectrumdigital.se> writes: > >> > >>> As I hope you can see I have made some changes regarding the > >>> subject-line. Thought it was an advantage to be able to see which file > >>> I actually removed something from. There seems to be a big focus on > >>> getting right on subject-line right in recent weeks. > >>> > >>> I wonder why there is a script that takes a file name, and respond > >>> with an appropriate subject line? > > > > > > Is there a script for this? Anyway, I would say driver name is enough. > > Enough about the subject line ;-) I would like to give some general remarks > > as you seem to touch a lot of kernel code. First off, I think it is good to > > remove unused stuff. However, I would like some more explanation on your > > methodology apart from "partially found by using a static code analysis > > program". So a cover-letter explaining that would have been nice (maybe > > still is). Things like Kconfig option can affect whether function are used > > or not so how did you cover that. > > > > Regards, > > Arend > > > > > >> I don't think you can really automate this as some drivers do this a bit > >> differently. You always need to manually check the commit log. > >> > >>> But ok, I change my script accordingly. Should I submit the patch again? > >> > >> > >> Yes, please resubmit. > >> > > > > Hi Arend > > Yes, a script that had been excellent, I think! > I have one as part of my git send-email script, until a week ago, it > was enough that I removed the "drivers/" and changed all "/" to ": " > I have now been expanded my sed pipe a lot (tell me if anyone is interested) > But now I've seen everything from uppercase and [DIR], etc. > So I can not understand how anyone should be able to get the right > name without a good help. > > Sure i like to share how I use cppcheck, but is very hesitant to write > this with each patch mails I send though! > > I run: > cppcheck --force --quiet --enable=all . > > Or a specific file instead of . > > This will include, among other things get a lot of error message such, > +4000 for the kernel. > (style) The function 'xxx' is never used > > For these I made a script that searched through all the files after > the function name (cppcheck missed a few). And save the rest so I go > through them and possibly send patches. I think that the question was about what methodology is cppcheck using to find the given issue. But probably cppcheck is a black box that does whatever it does, so the user doesn't know what the rationale is. However, I think you mentioned that cppcheck found only some of the issues. You could thus describe what was the methodology for finding the other ones. julia -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/07/15 00:33, Rickard Strandqvist wrote: > 2015-01-05 12:06 GMT+01:00 Arend van Spriel<arend@broadcom.com>: >> On 01/05/15 11:49, Kalle Valo wrote: >>> >>> Rickard Strandqvist<rickard_strandqvist@spectrumdigital.se> writes: >>> >>>> As I hope you can see I have made some changes regarding the >>>> subject-line. Thought it was an advantage to be able to see which file >>>> I actually removed something from. There seems to be a big focus on >>>> getting right on subject-line right in recent weeks. >>>> >>>> I wonder why there is a script that takes a file name, and respond >>>> with an appropriate subject line? >> >> >> Is there a script for this? Anyway, I would say driver name is enough. >> Enough about the subject line ;-) I would like to give some general remarks >> as you seem to touch a lot of kernel code. First off, I think it is good to >> remove unused stuff. However, I would like some more explanation on your >> methodology apart from "partially found by using a static code analysis >> program". So a cover-letter explaining that would have been nice (maybe >> still is). Things like Kconfig option can affect whether function are used >> or not so how did you cover that. >> >> Regards, >> Arend >> >> >>> I don't think you can really automate this as some drivers do this a bit >>> differently. You always need to manually check the commit log. >>> >>>> But ok, I change my script accordingly. Should I submit the patch again? >>> >>> >>> Yes, please resubmit. >>> >> > > Hi Arend > > Yes, a script that had been excellent, I think! > I have one as part of my git send-email script, until a week ago, it > was enough that I removed the "drivers/" and changed all "/" to ": " > I have now been expanded my sed pipe a lot (tell me if anyone is interested) > But now I've seen everything from uppercase and [DIR], etc. > So I can not understand how anyone should be able to get the right > name without a good help. > > Sure i like to share how I use cppcheck, but is very hesitant to write > this with each patch mails I send though! > > I run: > cppcheck --force --quiet --enable=all . And . is the top-level directory in the kernel repo? I am not familiar with cppcheck, but does it invoke the kernel Makefile. From a quick glance on cppcheck webpage I guess you could enable only the unused function checker. > Or a specific file instead of . > > This will include, among other things get a lot of error message such, > +4000 for the kernel. > (style) The function 'xxx' is never used > > For these I made a script that searched through all the files after > the function name (cppcheck missed a few). And save the rest so I go > through them and possibly send patches. All the file? Within the same driver or kernel-wide. So now "go through them" means compile testing with applicable Kconfig selections? Gr. AvS -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/07/15 07:29, Julia Lawall wrote: > > > On Wed, 7 Jan 2015, Rickard Strandqvist wrote: > >> 2015-01-05 12:06 GMT+01:00 Arend van Spriel<arend@broadcom.com>: >>> On 01/05/15 11:49, Kalle Valo wrote: >>>> >>>> Rickard Strandqvist<rickard_strandqvist@spectrumdigital.se> writes: >>>> >>>>> As I hope you can see I have made some changes regarding the >>>>> subject-line. Thought it was an advantage to be able to see which file >>>>> I actually removed something from. There seems to be a big focus on >>>>> getting right on subject-line right in recent weeks. >>>>> >>>>> I wonder why there is a script that takes a file name, and respond >>>>> with an appropriate subject line? >>> >>> >>> Is there a script for this? Anyway, I would say driver name is enough. >>> Enough about the subject line ;-) I would like to give some general remarks >>> as you seem to touch a lot of kernel code. First off, I think it is good to >>> remove unused stuff. However, I would like some more explanation on your >>> methodology apart from "partially found by using a static code analysis >>> program". So a cover-letter explaining that would have been nice (maybe >>> still is). Things like Kconfig option can affect whether function are used >>> or not so how did you cover that. >>> >>> Regards, >>> Arend >>> >>> >>>> I don't think you can really automate this as some drivers do this a bit >>>> differently. You always need to manually check the commit log. >>>> >>>>> But ok, I change my script accordingly. Should I submit the patch again? >>>> >>>> >>>> Yes, please resubmit. >>>> >>> >> >> Hi Arend >> >> Yes, a script that had been excellent, I think! >> I have one as part of my git send-email script, until a week ago, it >> was enough that I removed the "drivers/" and changed all "/" to ": " >> I have now been expanded my sed pipe a lot (tell me if anyone is interested) >> But now I've seen everything from uppercase and [DIR], etc. >> So I can not understand how anyone should be able to get the right >> name without a good help. >> >> Sure i like to share how I use cppcheck, but is very hesitant to write >> this with each patch mails I send though! >> >> I run: >> cppcheck --force --quiet --enable=all . >> >> Or a specific file instead of . >> >> This will include, among other things get a lot of error message such, >> +4000 for the kernel. >> (style) The function 'xxx' is never used >> >> For these I made a script that searched through all the files after >> the function name (cppcheck missed a few). And save the rest so I go >> through them and possibly send patches. > > I think that the question was about what methodology is cppcheck using to > find the given issue. But probably cppcheck is a black box that does > whatever it does, so the user doesn't know what the rationale is. That would have been nice, but I also wanted to know what his subsequent steps were to validate the output from cppcheck. I went through some cppcheck web pages, but they only elaborate on what is can do and not the how. But hey, it is an open-source tool so there is always the code to check. > However, I think you mentioned that cppcheck found only some of the > issues. You could thus describe what was the methodology for finding the > other ones. Maybe upon removing an unused function it had a ripple effect on others becoming unused as well? Still this is speculating and with this kind of cleanup effort all over the place it is better to review the methodology. Regards, Arend > julia -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2015-01-07 9:58 GMT+01:00 Arend van Spriel <arend@broadcom.com>: > On 01/07/15 07:29, Julia Lawall wrote: >> >> >> >> On Wed, 7 Jan 2015, Rickard Strandqvist wrote: >> >>> 2015-01-05 12:06 GMT+01:00 Arend van Spriel<arend@broadcom.com>: >>>> >>>> On 01/05/15 11:49, Kalle Valo wrote: >>>>> >>>>> >>>>> Rickard Strandqvist<rickard_strandqvist@spectrumdigital.se> writes: >>>>> >>>>>> As I hope you can see I have made some changes regarding the >>>>>> subject-line. Thought it was an advantage to be able to see which file >>>>>> I actually removed something from. There seems to be a big focus on >>>>>> getting right on subject-line right in recent weeks. >>>>>> >>>>>> I wonder why there is a script that takes a file name, and respond >>>>>> with an appropriate subject line? >>>> >>>> >>>> >>>> Is there a script for this? Anyway, I would say driver name is enough. >>>> Enough about the subject line ;-) I would like to give some general >>>> remarks >>>> as you seem to touch a lot of kernel code. First off, I think it is good >>>> to >>>> remove unused stuff. However, I would like some more explanation on your >>>> methodology apart from "partially found by using a static code analysis >>>> program". So a cover-letter explaining that would have been nice (maybe >>>> still is). Things like Kconfig option can affect whether function are >>>> used >>>> or not so how did you cover that. >>>> >>>> Regards, >>>> Arend >>>> >>>> >>>>> I don't think you can really automate this as some drivers do this a >>>>> bit >>>>> differently. You always need to manually check the commit log. >>>>> >>>>>> But ok, I change my script accordingly. Should I submit the patch >>>>>> again? >>>>> >>>>> >>>>> >>>>> Yes, please resubmit. >>>>> >>>> >>> >>> Hi Arend >>> >>> Yes, a script that had been excellent, I think! >>> I have one as part of my git send-email script, until a week ago, it >>> was enough that I removed the "drivers/" and changed all "/" to ": " >>> I have now been expanded my sed pipe a lot (tell me if anyone is >>> interested) >>> But now I've seen everything from uppercase and [DIR], etc. >>> So I can not understand how anyone should be able to get the right >>> name without a good help. >>> >>> Sure i like to share how I use cppcheck, but is very hesitant to write >>> this with each patch mails I send though! >>> >>> I run: >>> cppcheck --force --quiet --enable=all . >>> >>> Or a specific file instead of . >>> >>> This will include, among other things get a lot of error message such, >>> +4000 for the kernel. >>> (style) The function 'xxx' is never used >>> >>> For these I made a script that searched through all the files after >>> the function name (cppcheck missed a few). And save the rest so I go >>> through them and possibly send patches. >> >> >> I think that the question was about what methodology is cppcheck using to >> find the given issue. But probably cppcheck is a black box that does >> whatever it does, so the user doesn't know what the rationale is. > > > That would have been nice, but I also wanted to know what his subsequent > steps were to validate the output from cppcheck. I went through some > cppcheck web pages, but they only elaborate on what is can do and not the > how. But hey, it is an open-source tool so there is always the code to > check. > >> However, I think you mentioned that cppcheck found only some of the >> issues. You could thus describe what was the methodology for finding the >> other ones. > > > Maybe upon removing an unused function it had a ripple effect on others > becoming unused as well? Still this is speculating and with this kind of > cleanup effort all over the place it is better to review the methodology. > > Regards, > Arend > >> julia Hi all Julia cppcheck is a gpl projekt. http://sourceforge.net/projects/cppcheck/ Arend I used cppcheck with all option in the linux root, and then use grep to pick out what I was interested in. I agree that there is a lack of documentation, unfortunately. More exactly how I have done this is, I searched with grep for the 4000 functions, put the result in a lot of files. These were input to a script that open a file editor, did a visual overview of all over the place where the function was found, several of them were used, for example, directly in asambler code. And in recent times I have also started doing git blame on the file to see how old the code is. Then I made the choice to remove or not. Hope this was clear enough :) Kind regards Rickard Strandqvist -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c index 796f5f9..bca233a 100644 --- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c +++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c @@ -1192,16 +1192,6 @@ void dma_txresume(struct dma_pub *pub) bcma_mask32(di->core, DMA64TXREGOFFS(di, control), ~D64_XC_SE); } -bool dma_txsuspended(struct dma_pub *pub) -{ - struct dma_info *di = container_of(pub, struct dma_info, dma); - - return (di->ntxd == 0) || - ((bcma_read32(di->core, - DMA64TXREGOFFS(di, control)) & D64_XC_SE) == - D64_XC_SE); -} - void dma_txreclaim(struct dma_pub *pub, enum txd_range range) { struct dma_info *di = container_of(pub, struct dma_info, dma); @@ -1425,15 +1415,6 @@ int dma_txfast(struct brcms_c_info *wlc, struct dma_pub *pub, return -ENOSPC; } -void dma_txflush(struct dma_pub *pub) -{ - struct dma_info *di = container_of(pub, struct dma_info, dma); - struct brcms_ampdu_session *session = &di->ampdu_session; - - if (!skb_queue_empty(&session->skb_list)) - ampdu_finalize(di); -} - int dma_txpending(struct dma_pub *pub) { struct dma_info *di = container_of(pub, struct dma_info, dma); diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.h b/drivers/net/wireless/brcm80211/brcmsmac/dma.h index ff5b80b..210ec72 100644 --- a/drivers/net/wireless/brcm80211/brcmsmac/dma.h +++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.h @@ -88,11 +88,9 @@ bool dma_txreset(struct dma_pub *pub); void dma_txinit(struct dma_pub *pub); int dma_txfast(struct brcms_c_info *wlc, struct dma_pub *pub, struct sk_buff *p0); -void dma_txflush(struct dma_pub *pub); int dma_txpending(struct dma_pub *pub); void dma_kick_tx(struct dma_pub *pub); void dma_txsuspend(struct dma_pub *pub); -bool dma_txsuspended(struct dma_pub *pub); void dma_txresume(struct dma_pub *pub); void dma_txreclaim(struct dma_pub *pub, enum txd_range range); void dma_rxreclaim(struct dma_pub *pub);
Removes some functions that are not used anywhere: dma_txflush() dma_txsuspended() This was partially found by using a static code analysis program called cppcheck. Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se> --- drivers/net/wireless/brcm80211/brcmsmac/dma.c | 19 ------------------- drivers/net/wireless/brcm80211/brcmsmac/dma.h | 2 -- 2 files changed, 21 deletions(-)