[PATCH 0/3] wifi: brcm80211: Deadcoding around phy_cmn

linux@treblig.org posted 3 patches 3 months, 1 week ago
.../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 443 ------------------
.../broadcom/brcm80211/brcmsmac/phy/phy_hal.h |  27 --
.../broadcom/brcm80211/brcmsmac/phy/phy_int.h |  11 -
.../broadcom/brcm80211/brcmsmac/phy/phy_n.c   |  19 -
4 files changed, 500 deletions(-)
[PATCH 0/3] wifi: brcm80211: Deadcoding around phy_cmn
Posted by linux@treblig.org 3 months, 1 week ago
From: "Dr. David Alan Gilbert" <linux@treblig.org>

Hi,
  This set removes a bunch of unused functions in phy_cmn.c;
I've checked the history of most of them, and they look like they've
been unused since all the way back to 2010 when they were added
to staging.

There are a lot of them, so I've arbitrarily split it up into
convenient size chunks of about 10 functions each.

I see back in 2014, Rickard Strandqvist also tried to clean some
of this up, but I don't see any reply to that thread.

(Build tested only)

Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org>

Dave

Dr. David Alan Gilbert (3):
  wifi: brcm80211: Remove unused functions
  wifi: brcm80211: Remove more unused functions
  wifi: brcm80211: Remove yet more unused functions

 .../broadcom/brcm80211/brcmsmac/phy/phy_cmn.c | 443 ------------------
 .../broadcom/brcm80211/brcmsmac/phy/phy_hal.h |  27 --
 .../broadcom/brcm80211/brcmsmac/phy/phy_int.h |  11 -
 .../broadcom/brcm80211/brcmsmac/phy/phy_n.c   |  19 -
 4 files changed, 500 deletions(-)

-- 
2.50.0
Re: [PATCH 0/3] wifi: brcm80211: Deadcoding around phy_cmn
Posted by Johannes Berg 3 months, 1 week ago
Hi,

Just a couple of general comments for the future:

1) you can drop Kalle, he hasn't been involved for a while now

2) it'd help for the automatic bot runs etc. to have, in the subject,
   '[PATCH wireless-next]' (or perhaps rtw-next etc.)

Thanks,
johannes
Re: [PATCH 0/3] wifi: brcm80211: Deadcoding around phy_cmn
Posted by Dr. David Alan Gilbert 3 months, 1 week ago
* Johannes Berg (johannes@sipsolutions.net) wrote:
> Hi,

Hi Johannes,

> Just a couple of general comments for the future:
> 
> 1) you can drop Kalle, he hasn't been involved for a while now

Oh yeh, I forgot about that.

> 2) it'd help for the automatic bot runs etc. to have, in the subject,
>    '[PATCH wireless-next]' (or perhaps rtw-next etc.)

Oh right; that wasn't too obvious to me because get_maintainer has
linux-wireless@ in the list but also had the brcm80211 - so I
didn't know if this went through brcm or wireless picked it up.
And what's rtw ?

(Perhaps a Documenation/process/maintainer-wireless.rst would be good? )

Thanks again,

Dave

> Thanks,
> johannes
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/
Re: [PATCH 0/3] wifi: brcm80211: Deadcoding around phy_cmn
Posted by Johannes Berg 3 months, 1 week ago
Hi,

> > 2) it'd help for the automatic bot runs etc. to have, in the subject,
> >    '[PATCH wireless-next]' (or perhaps rtw-next etc.)
> 
> Oh right; that wasn't too obvious to me because get_maintainer has
> linux-wireless@ in the list but also had the brcm80211 - so I
> didn't know if this went through brcm or wireless picked it up.
> And what's rtw ?

Hmm, right, brcm80211 does have a separate list but patches still flow
only via the wireless list.

Currently, we have:
ath/ath-next - Qualcomm drivers
rtw/rtw-next - Realtek drivers
iwlwifi-fixes/iwlwifi-next - Intel iwlwifi driver
mt76 - Mediatek drivers
wireless / wireless-next - catch-all for everything else

> (Perhaps a Documenation/process/maintainer-wireless.rst would be good? )

Yeah, perhaps, though it's kind of difficult to really pin down the
exact list, it has been changing a bit.

TBH, wireless / wireless-next is mostly just fine anyway. Only if
something depends on other work in the specific trees would the other
tags really be needed, i.e. for people who work on it more actively.
With wireless / wireless-next the bot will still build-test it etc.,
whereas without a tag it may never do that at all.

johannes