[PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Rickard Strandqvist]

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(-)

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);
-- 
1.7.10.4

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Larry Finger]

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

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Rickard Strandqvist]

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

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Kalle Valo]

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.

-- 
Kalle Valo

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Arend van Spriel]

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.
>

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Rickard Strandqvist]

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

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Julia Lawall]

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

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Arend van Spriel]

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

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Rickard Strandqvist]

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

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Arend van Spriel]

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

Re: [PATCH] brcm80211: brcmsmac: dma: Remove some unused functions

[Kalle Valo]

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

-- 
Kalle Valo