* Re: [PATCH v13 5/5] ath9k: implement .get_antenna and .set_antenna
From: Felix Fietkau @ 2011-10-05 22:43 UTC (permalink / raw)
To: Daniel Smith; +Cc: linux-wireless, Felix Fietkau
In-Reply-To: <4E8C9D53.1080307@gmail.com>
On 2011-10-05 8:09 PM, Daniel Smith wrote:
> On 9/2/2011 7:40 PM, Felix Fietkau wrote:
>> On MIMO chips this can be used to enable/disable hardware chains, ensuring
>> that the MCS information is updated accordingly.
>> On non-MIMO chips with rx diversity (e.g. 9285), this configures the rx
>> input antenna.
>
> I have been working with this patch as I needed the ability to select
> the rx chain/antenna on an AR9820.. A problem I have ran into is that
> regardless of what I set the antenna chain to, the radiotap header
> always reports antenna 1. I know this originates from the rx status
> descriptor, but is this really what should be used to report the antenna
> when using chains to select the antenna?
Typically all receive chains are used simultaneously when receiving
packets, and the antenna field in the rx status is meaningless. I'm
currently working on a patch that makes per-chain rx signal strength
available in the status info and puts it in the station info available
via nl80211.
- Felix
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:37 UTC (permalink / raw)
To: Adrian Chadd
Cc: Christian Lamparter, Zefir Kurtisi, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <CAJ-VmomWYUtd84APvEg7mKC-sevT3UVaX2qKBn3KiVriPZybgQ@mail.gmail.com>
On Tue, Oct 4, 2011 at 7:50 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> Also whilst I'm at it, "SPECTRUM_MANAGEMENT" is a very broad flag to set.
>
> For example: you may not want to do DFS on the AR5416 NICs because (as
> documented in the open hal and earlier ath9k bits) there isn't support
> for radar pulses on the ext channel. So even if you had a successful
> DFS algorithm for this NIC, you'd have to somehow tell the DFS
> machinery that HT40+DFS channels aren't supported but HT20+DFS
> channels are.
Good point. I simply rather start out with the best possible DFS
support on Linux and go with the best hardware we have instead of
dealing with old hardware. Think about the support issues that can
come up with supporting the above. I rather simply not deal with it as
I also do not care about Turbo crap. Let legacy crap die.
> But then, the AR5416 supports per-packet TPC, so you could use it in
> STA mode perfectly fine and it'd support that part of spectrum
> management. Since you get per-frame RSSI of RX'ed frames, you can
> support the spectrum power histogram IE.
TPC is not implemented even in a lot of proprietary code bases,
although TPC is part of 802.11h its requirements are me by statically
reducing the maximum EIRP by 3 dB in frequency bands requiring TPC in
consideration for interference with satellites. In my latest
evaluation of TPC the only thing we want to do is simply enable the
option to explicitly state the max delta on power in consideration for
TPC in such a way that *if* TPC is implemented we can reduce the
reduction. But given that this is hardware specific and vendor
specific and not many people implement it right now I frankly don't
care too much about it. DFS is a bigger aspect.
Luis
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:31 UTC (permalink / raw)
To: Adrian Chadd
Cc: Zefir Kurtisi, Christian Lamparter, linux-wireless, ath9k-devel,
kgiori, nbd
In-Reply-To: <CAJ-Vmo=TACq_d7JU0stibcqnvWgzUO7Ozue=4VayeHNcgXTejw@mail.gmail.com>
On Tue, Oct 4, 2011 at 7:34 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> .. erm, how complicated is the pattern matching code when it's compiled?
>
> The port of the fusion radar detection module didn't end up being all that big.
Adrian, please keep terms like "fusion codebase" out of public lists.
Luis
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:30 UTC (permalink / raw)
To: Zefir Kurtisi
Cc: Christian Lamparter, linux-wireless, ath9k-devel, kgiori, nbd
In-Reply-To: <4E8B157F.2080203@neratec.com>
On Tue, Oct 4, 2011 at 7:17 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> On 10/04/2011 03:38 PM, Christian Lamparter wrote:
>> On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
>>> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
>>> <chunkeey@googlemail.com> wrote:
>>>> On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
>>>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>>>>>>
>>>>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>>>>>> ---
>>>>>> drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>>>>>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>>>>>> index e8aeb98..5defebe 100644
>>>>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>>>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>>>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>>>>>> "Unable to reset channel, reset status %d\n", r);
>>>>>> goto out;
>>>>>> }
>>>>>> +#ifdef CONFIG_ATH9K_DFS
>>>>>
>>>>> Please spare the #ifdef and just call something within dfs.c, then
>>>>> dfs.h would wrap it to nothing if DFS is disabled.
>>>> Why would anyone want to disable DFS driver support?
>>>> I would say: drop the ifdefs altogether since DFS
>>>> is and will be "required".
>>>
>>> Because DFS requires to be properly tested before being enabled.
>> Testing if a driver detects a pulse is "trivial" compared to the
>> stuff mac80211/cfg80211 and hostapd will have to do to make a
>> channel-change as smooth as possible. I think if there's a DFS
>> "OFF" switch, it should be in hostapd and I hope more people
>> agree on this one.
>>
> Yes on both. Work on the management part of the DFS module has just been started by TI guys. When this is in, hostapd will be able to query the driver's DFS detection capabilities and leave DFS channels disabled for those devices with no (or insufficient) support (like it is generally done today for DFS channels).
>
> The proper way for a driver's OFF switch would then be to just announce missing DFS capabilities.
And this is what I meant by leaving a kernel build option available
for each driver to enable/disable DFS. If a vendor does not want to
deal with the question of enabling DFS they can disable it on the
driver front.
>>> You may also want to simply disable DFS if you do not want to
>>> deal with the regulatory test implications of having it enabled.
>> AFAIK you can't "simply" disable the DFS requirement: hostapd
>> (hw_features.c), [cfg80211] (checks if tx on secondary channel
>> is possible) and mac80211 (tx.c) all have checks. Indeed, the
>> easiest way is to modify crda's database. So there's no need
>> for an extra compile-time option.
>>
> There might be a demand for conditional compiling in addition to DFS capabilities announcements to reduce memory footprint, since (especially) pattern matching algorithms will increase it significantly.
I doubt space considerations will be that much given that we don't
even have build options to disable hardware families, at least nbd had
determine already that separating families at build time wouldn't save
us much. Given that -- I suspect using build size as an argument for
introducing a flag here doesn't carry much weight. The argument I'm
using is to simply enable integrators to decide whether or not to have
to deal with testing such features.
Luis
^ permalink raw reply
* Re: [ath9k-devel] [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:27 UTC (permalink / raw)
To: Christian Lamparter; +Cc: kgiori, ath9k-devel, linux-wireless, Zefir Kurtisi
In-Reply-To: <201110041538.12885.chunkeey@googlemail.com>
On Tue, Oct 4, 2011 at 6:38 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Monday, October 03, 2011 09:31:12 PM Luis R. Rodriguez wrote:
>> On Mon, Oct 3, 2011 at 12:24 PM, Christian Lamparter
>> <chunkeey@googlemail.com> wrote:
>> > On Monday, October 03, 2011 08:27:39 PM Luis R. Rodriguez wrote:
>> >> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>> >> >
>> >> > Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>> >> > ---
>> >> > drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>> >> > 1 files changed, 12 insertions(+), 0 deletions(-)
>> >> >
>> >> > diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>> >> > index e8aeb98..5defebe 100644
>> >> > --- a/drivers/net/wireless/ath/ath9k/main.c
>> >> > +++ b/drivers/net/wireless/ath/ath9k/main.c
>> >> > @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>> >> > "Unable to reset channel, reset status %d\n", r);
>> >> > goto out;
>> >> > }
>> >> > +#ifdef CONFIG_ATH9K_DFS
>> >>
>> >> Please spare the #ifdef and just call something within dfs.c, then
>> >> dfs.h would wrap it to nothing if DFS is disabled.
>> > Why would anyone want to disable DFS driver support?
>> > I would say: drop the ifdefs altogether since DFS
>> > is and will be "required".
>>
>> Because DFS requires to be properly tested before being enabled.
> Testing if a driver detects a pulse is "trivial" compared to the
> stuff mac80211/cfg80211 and hostapd will have to do to make a
> channel-change as smooth as possible. I think if there's a DFS
> "OFF" switch, it should be in hostapd and I hope more people
> agree on this one.
You do have a good point, but I disagree that you do not need to test
/ regress test hardware / driver code for DFS. This is what I'm
talking about. But yes, userspace also submits itself to the same
criteria.
>> You may also want to simply disable DFS if you do not want to
>> deal with the regulatory test implications of having it enabled.
> AFAIK you can't "simply" disable the DFS requirement: hostapd
> (hw_features.c), [cfg80211] (checks if tx on secondary channel
> is possible) and mac80211 (tx.c) all have checks. Indeed, the
> easiest way is to modify crda's database. So there's no need
> for an extra compile-time option.
No, DFS is set for certain channels on wireless-regdb/CRDA, I just
posted DFS master region support for wireless-regdb and CRDA. Apart
from this we then need driver support. To get DFS you need all of
these + hostapd part. Each one has its own set of components and does
deserve its own set of tests and review.
Luis
^ permalink raw reply
* Re: [RFC 5/6] ath9k: enable DFS pulse detection
From: Luis R. Rodriguez @ 2011-10-05 22:23 UTC (permalink / raw)
To: Zefir Kurtisi; +Cc: linux-wireless, ath9k-devel, kgiori, nbd
In-Reply-To: <4E8ADBE0.6050406@neratec.com>
On Tue, Oct 4, 2011 at 3:11 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
> On 10/03/2011 08:27 PM, Luis R. Rodriguez wrote:
>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi <zefir.kurtisi@neratec.com> wrote:
>>>
>>> Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
>>> ---
>>> drivers/net/wireless/ath/ath9k/main.c | 12 ++++++++++++
>>> 1 files changed, 12 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
>>> index e8aeb98..5defebe 100644
>>> --- a/drivers/net/wireless/ath/ath9k/main.c
>>> +++ b/drivers/net/wireless/ath/ath9k/main.c
>>> @@ -344,6 +344,18 @@ static int ath_reset_internal(struct ath_softc *sc, struct ath9k_channel *hchan,
>>> "Unable to reset channel, reset status %d\n", r);
>>> goto out;
>>> }
>>> +#ifdef CONFIG_ATH9K_DFS
>>> + /**
>>> + * enable radar pulse detection
>>> + *
>>> + * TODO: do this only for DFS channels
>>> + */
>>> + ah->private_ops.set_radar_params(ah, &ah->radar_conf);
>>> + ath9k_hw_setrxfilter(ah,
>>> + ath9k_hw_getrxfilter(ah) | ATH9K_RX_FILTER_PHYRADAR);
>>> + ath_dbg(common, ATH_DBG_DFS,
>>> + "DFS enabled for channel %d\n", hchan->chan->center_freq);
>>> +#endif
>>
>> Please spare the #ifdef and just call something within dfs.c, then
>> dfs.h would wrap it to nothing if DFS is disabled.
>>
> This possibly won't work, since setting up DFS registers is part of HW layer and not
> done in the dfs module. If you want to have DFS conditionally compilable, you can not spare this #ifdefs.
Its not about sparing the ifdefs completely but instead to place them
strategically to remove #ifdef sprinkling all over C code. You can
leave ifdefs on header files, and for C files leaves this as a
conditional build time option.
Luis
^ permalink raw reply
* Re: [RFC 4/6] ath9k: add DFS build parameter
From: Luis R. Rodriguez @ 2011-10-05 22:20 UTC (permalink / raw)
To: Felix Fietkau; +Cc: Zefir Kurtisi, linux-wireless, ath9k-devel, kgiori
In-Reply-To: <4E8AE1CC.5060703@openwrt.org>
On Tue, Oct 4, 2011 at 3:37 AM, Felix Fietkau <nbd@openwrt.org> wrote:
> On 2011-10-04 11:55 AM, Zefir Kurtisi wrote:
>>
>> On 10/03/2011 08:26 PM, Luis R. Rodriguez wrote:
>>>
>>> On Mon, Oct 3, 2011 at 3:29 AM, Zefir Kurtisi<zefir.kurtisi@neratec.com>
>>> wrote:
>>>>
>>>> Signed-off-by: Zefir Kurtisi<zefir.kurtisi@neratec.com>
>>>> ---
>>>> drivers/net/wireless/ath/ath9k/Kconfig | 7 +++++++
>>>> drivers/net/wireless/ath/ath9k/Makefile | 2 ++
>>>> 2 files changed, 9 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
>>>> b/drivers/net/wireless/ath/ath9k/Kconfig
>>>> index d9c08c6..adddcca 100644
>>>> --- a/drivers/net/wireless/ath/ath9k/Kconfig
>>>> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
>>>> @@ -58,6 +58,13 @@ config ATH9K_RATE_CONTROL
>>>> Say Y, if you want to use the ath9k specific rate control
>>>> module instead of minstrel_ht.
>>>>
>>>> +config ATH9K_DFS
>>>> + bool "Atheros ath9k DFS support"
>>>> + depends on ATH9K
>>>> + default y
>>>
>>> At this point selecting y does nothing. Leave this patch out until
>>> selecting "y" means something.
>>>
>> What do you mean by 'nothing'? It allows you to select DFS as ath9k
>> feature in your kernel configuration, or? Though, I agree that enabling it
>> by default is not a good idea.
>>
>>> Default should be n, and in particular Atheros itself can only likely
>>> commit to supporting DFS for AR9003 when it finds resources to do so
>>> as well as properly test it, so DFS support kconfig should state this.
>>> If someone wants to step up to completely support all bugs for older
>>> families that is their prerogative but we cannot commit to it, due to
>>> the regulatory considerations though unless this happens this cannot
>>> and should not be enabled for older families in code.
>>>
>> In fact, AR9003 is the platform we are interested in. Although it
>> seems that older chipsets do also detect pulses with this patches
>> (AR9280 does, IIRC), I agree to limit DFS support to AR9003 (and later).
>> This should be easily possible by setting priv_ops->set_radar_params for
>> AR9003 only. I'll remove it for AR5008 in my v2 RFC.
>
> Please don't remove support code for older hardware. I'm fine with adding a
> SREV check that prevents it from being enabled by default on older hardware,
> but eventually I will need at least AR9280 DFS support for a few devices in
> OpenWrt.
That's fine, leaving it disabled is what I meant, and only once
something has been properly tested do we enable it. I personally only
want to spend my own energy on AR9003 and newer.
Luis
^ permalink raw reply
* [PATCH] mwifiex: fix smatch errors
From: Bing Zhao @ 2011-10-05 21:58 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Kiran Divekar, Yogesh Powar,
Frank Huang, Bing Zhao, Dan Carpenter
From: Yogesh Ashok Powar <yogeshp@marvell.com>
drivers/net/wireless/mwifiex/main.c +828 mwifiex_remove_card(52)
error: potential null derefence 'priv'.
drivers/net/wireless/mwifiex/main.c +828 mwifiex_remove_card(52)
error: we previously assumed 'priv' could be null (see line 820)
drivers/net/wireless/mwifiex/txrx.c +90 mwifiex_process_tx(24)
error: potential null derefence 'local_tx_pd'.
drivers/net/wireless/mwifiex/sta_ioctl.c +766
mwifiex_rate_ioctl_set_rate_value(30)
error: buffer overflow 'rate' 14 <= 14
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/main.c | 4 ++++
drivers/net/wireless/mwifiex/sta_ioctl.c | 2 +-
drivers/net/wireless/mwifiex/txrx.c | 3 ++-
3 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 8486451..277ea84 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -825,6 +825,10 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter, struct semaphore *sem)
rtnl_unlock();
}
+ priv = adapter->priv[0];
+ if (!priv)
+ goto exit_remove;
+
wiphy_unregister(priv->wdev->wiphy);
wiphy_free(priv->wdev->wiphy);
kfree(priv->wdev);
diff --git a/drivers/net/wireless/mwifiex/sta_ioctl.c b/drivers/net/wireless/mwifiex/sta_ioctl.c
index 520800b..f20550a 100644
--- a/drivers/net/wireless/mwifiex/sta_ioctl.c
+++ b/drivers/net/wireless/mwifiex/sta_ioctl.c
@@ -763,7 +763,7 @@ static int mwifiex_rate_ioctl_set_rate_value(struct mwifiex_private *priv,
if ((rate[i] & 0x7f) == (rate_cfg->rate & 0x7f))
break;
}
- if (!rate[i] || (i == MWIFIEX_SUPPORTED_RATES)) {
+ if ((i == MWIFIEX_SUPPORTED_RATES) || !rate[i]) {
dev_err(adapter->dev, "fixed data rate %#x is out "
"of range\n", rate_cfg->rate);
return -1;
diff --git a/drivers/net/wireless/mwifiex/txrx.c b/drivers/net/wireless/mwifiex/txrx.c
index 6190b2f..5d95c4b 100644
--- a/drivers/net/wireless/mwifiex/txrx.c
+++ b/drivers/net/wireless/mwifiex/txrx.c
@@ -87,7 +87,8 @@ int mwifiex_process_tx(struct mwifiex_private *priv, struct sk_buff *skb,
(adapter->pps_uapsd_mode) &&
(adapter->tx_lock_flag)) {
priv->adapter->tx_lock_flag = false;
- local_tx_pd->flags = 0;
+ if (local_tx_pd)
+ local_tx_pd->flags = 0;
}
dev_dbg(adapter->dev, "data: -EBUSY is returned\n");
break;
--
1.7.0.2
^ permalink raw reply related
* Re: [PATCH 00/15] staging: brcm80211: cleanup fullmac structs and softmac srom lookup
From: Greg KH @ 2011-10-05 20:47 UTC (permalink / raw)
To: Arend van Spriel; +Cc: gregkh, devel, linux-wireless
In-Reply-To: <1317820814-7083-1-git-send-email-arend@broadcom.com>
On Wed, Oct 05, 2011 at 03:19:59PM +0200, Arend van Spriel wrote:
> This series addresses more community feedback items received on mainline
> patch (v2) posted August 25, 2011. The driver structures in brcmfmac could
> do with some tidying and in the brcmsmac variables loaded from srom were
> accessed by string identifiers. This has been replaced by enumerated
> identifiers and the entries are stored in kernel standard linked list.
>
> This series applies to staging-next and depends on the patch series posted
> on Oct 4, 2011 (see Message-ID below).
>
> Message-ID: <1317763152-17607-1-git-send-email-arend@broadcom.com>
All applied, thanks.
greg k-h
^ permalink raw reply
* Re: [PATCH 00/26] various cleanup changes for brcmfmac and brcmsmac
From: Greg KH @ 2011-10-05 20:40 UTC (permalink / raw)
To: Arend van Spriel; +Cc: gregkh, devel, linux-wireless
In-Reply-To: <1317763152-17607-1-git-send-email-arend@broadcom.com>
On Tue, Oct 04, 2011 at 11:18:46PM +0200, Arend van Spriel wrote:
> Third attempt as the mailer somehow did not sent these outside the
> Broadcom intranet. Another series of cleanup changes based on community
> feedback received on the mainline patch (v2) as sent August 25, 2011.
>
> This series is to be applied to the staging-next branch. There are no
> pending patches that this series depend on.
Applied, thanks.
greg k-h
^ permalink raw reply
* Re: mwifiex: add cfg80211 handlers add/del_virtual_intf
From: Dan Carpenter @ 2011-10-05 19:52 UTC (permalink / raw)
To: Bing Zhao; +Cc: Yogesh Powar, linux-wireless@vger.kernel.org
In-Reply-To: <477F20668A386D41ADCC57781B1F70430815597445@SC-VEXCH1.marvell.com>
On Wed, Oct 05, 2011 at 12:08:36PM -0700, Bing Zhao wrote:
> Since the first element of priv[] cannot be NULL. How about this fix?
>
> + priv = adapter->priv[0];
> + BUG_ON(!priv);
> +
> wiphy_unregister(priv->wdev->wiphy);
>
I don't know the code at all, so I'll trust you on that. :)
But please don't add the BUG_ON(). Calls to BUG_ON() make the code
messier, and they are more painful than needed for the user. If we
don't have the BUG_ON() then we get an Oops and the driver will die,
but we can still can close our documents and reboot the system.
Debugging NULL dereference bugs is normally super easy. Just compile
with CONFIG_DEBUG_INFO=y, run gdb on the .ko file and type:
"list *(function_name+0x63)" at the gdb prompt. Done.
regards,
dan carpenter
^ permalink raw reply
* RE: mwifiex: add cfg80211 handlers add/del_virtual_intf
From: Bing Zhao @ 2011-10-05 19:08 UTC (permalink / raw)
To: Dan Carpenter, Yogesh Powar; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20111005060744.GB32513@elgon.mountain>
Hi Dan,
Thanks for your comment.
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Tuesday, October 04, 2011 11:08 PM
> To: Yogesh Powar
> Cc: Bing Zhao; linux-wireless@vger.kernel.org
> Subject: re: mwifiex: add cfg80211 handlers add/del_virtual_intf
>
> Hi Yogesh,
>
> The Smatch static checker complains that 93a1df48d22429 "mwifiex: add
> cfg80211 handlers add/del_virtual_intf" introduces a potential NULL
> dereference.
>
> @@ -985,9 +817,20 @@ int mwifiex_remove_card(struct mwifiex_adapter *adapter, struct semaphore *sem)
> atomic_read(&adapter->cmd_pending));
> }
>
> - /* Remove interface */
> - for (i = 0; i < adapter->priv_num; i++)
> - mwifiex_remove_interface(adapter, i);
> + for (i = 0; i < adapter->priv_num; i++) {
> + priv = adapter->priv[i];
> +
> + if (!priv)
> + continue;
> +
> + rtnl_lock();
> + mwifiex_del_virtual_intf(priv->wdev->wiphy, priv->netdev);
> + rtnl_unlock();
> + }
> +
> + wiphy_unregister(priv->wdev->wiphy);
> ^^^^^^^^^^
> Can priv be NULL here? How do we know that the last element of
> adapter->priv[]; is non-NULL when we have to check the others?
That's a good catch.
Since the first element of priv[] cannot be NULL. How about this fix?
+ priv = adapter->priv[0];
+ BUG_ON(!priv);
+
wiphy_unregister(priv->wdev->wiphy);
Thanks,
Bing
>
> regards,
> dan carpenter
^ permalink raw reply
* Compat-wireless release for 2011-10-05 is baked
From: Compat-wireless cronjob account @ 2011-10-05 19:04 UTC (permalink / raw)
To: linux-wireless
>From git://github.com/mcgrof/compat-wireless
ed03ef8..2309ddb master -> origin/master
>From git://github.com/mcgrof/compat
2239769..966e847 master -> origin/master
>From git://github.com/sfrothwell/linux-next
+ 8f37235...a2851f2 akpm-end -> origin/akpm-end (forced update)
0f86267..a8062e4 akpm-start -> origin/akpm-start
+ db5dbd6...09d70e2 master -> origin/master (forced update)
0f86267..a8062e4 stable -> origin/stable
* [new tag] next-20111005 -> next-20111005
/usr/bin/sha1sum: *.tar.bz2: No such file or directory
compat-wireless code metrics
812096 - Total upstream lines of code being pulled
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]
^ permalink raw reply
* Re: [PATCH v13 5/5] ath9k: implement .get_antenna and .set_antenna
From: Daniel Smith @ 2011-10-05 18:09 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau
In-Reply-To: <1315006827-81443-5-git-send-email-nbd@openwrt.org>
On 9/2/2011 7:40 PM, Felix Fietkau wrote:
> On MIMO chips this can be used to enable/disable hardware chains, ensuring
> that the MCS information is updated accordingly.
> On non-MIMO chips with rx diversity (e.g. 9285), this configures the rx
> input antenna.
I have been working with this patch as I needed the ability to select
the rx chain/antenna on an AR9820.. A problem I have ran into is that
regardless of what I set the antenna chain to, the radiotap header
always reports antenna 1. I know this originates from the rx status
descriptor, but is this really what should be used to report the antenna
when using chains to select the antenna?
V/r,
Daniel
^ permalink raw reply
* Re: [PATCH 00/15] staging: brcm80211: cleanup fullmac structs and softmac srom lookup
From: Arend van Spriel @ 2011-10-05 16:56 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: gregkh@suse.de, devel@linuxdriverproject.org,
linux-wireless@vger.kernel.org
In-Reply-To: <4E8C6C77.9000402@hauke-m.de>
On 10/05/2011 04:40 PM, Hauke Mehrtens wrote:
> On 10/05/2011 03:19 PM, Arend van Spriel wrote:
>> This series addresses more community feedback items received on mainline
>> patch (v2) posted August 25, 2011. The driver structures in brcmfmac could
>> do with some tidying and in the brcmsmac variables loaded from srom were
>> accessed by string identifiers. This has been replaced by enumerated
>> identifiers and the entries are stored in kernel standard linked list.
>>
>> This series applies to staging-next and depends on the patch series posted
>> on Oct 4, 2011 (see Message-ID below).
>>
>> Message-ID:<1317763152-17607-1-git-send-email-arend@broadcom.com>
>>
>> Arend van Spriel (11):
>> staging: brcm80211: move driver variable functions to srom.c
>> staging: brcm80211: remove code duplication for driver variable
>> lookup
>> staging: brcm80211: change parameter in driver variable lookup
>> staging: brcm80211: remove locking macro definitions
>> staging: brcm80211: fix thread blocking issue in
>> brcmf_sdbrcm_bus_stop()
>> staging: brcm80211: remove invalid variable lookup from srom
>> staging: brcm80211: use identifiers instead of string for srom lookup
>> staging: brcm80211: use enum identifiers in srom variable tables
>> staging: brcm80211: replace string based variable storage by linked
>> list
>> staging: brcm80211: remove parameter 'off' from _initvars_srom_pci()
>> staging: brcm80211: cleanup driver variable references
>>
>> Franky Lin (4):
>> staging: brcm80211: remove threads_only code from fullmac
>> staging: brcm80211: remove redundant bus register layer from fullmac
>> staging: brcm80211: clean up struct brcmf_if in fullmac
>> staging: brcm80211: remove brcmf_op_if from fullmac
>>
>> drivers/staging/brcm80211/brcmfmac/bcmsdh.c | 10 -
>> drivers/staging/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 16 +-
>> drivers/staging/brcm80211/brcmfmac/dhd_linux.c | 134 +--
>> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c | 133 +--
>> drivers/staging/brcm80211/brcmfmac/sdio_host.h | 4 -
>> drivers/staging/brcm80211/brcmsmac/aiutils.c | 32 +-
>> drivers/staging/brcm80211/brcmsmac/aiutils.h | 6 +-
>> drivers/staging/brcm80211/brcmsmac/antsel.c | 15 +-
>> drivers/staging/brcm80211/brcmsmac/channel.c | 2 +-
>> drivers/staging/brcm80211/brcmsmac/mac80211_if.c | 157 ++--
>> drivers/staging/brcm80211/brcmsmac/main.c | 144 +---
>> drivers/staging/brcm80211/brcmsmac/main.h | 5 -
>> drivers/staging/brcm80211/brcmsmac/nicpci.c | 5 +-
>> drivers/staging/brcm80211/brcmsmac/nicpci.h | 2 +-
>> drivers/staging/brcm80211/brcmsmac/phy/phy_cmn.c | 42 +-
>> drivers/staging/brcm80211/brcmsmac/phy/phy_hal.h | 4 +-
>> drivers/staging/brcm80211/brcmsmac/phy/phy_int.h | 7 -
>> drivers/staging/brcm80211/brcmsmac/phy/phy_lcn.c | 64 +-
>> drivers/staging/brcm80211/brcmsmac/phy/phy_n.c | 330 ++++--
>> drivers/staging/brcm80211/brcmsmac/phy_shim.c | 9 +
>> drivers/staging/brcm80211/brcmsmac/phy_shim.h | 4 +
>> drivers/staging/brcm80211/brcmsmac/pub.h | 263 +++++-
>> drivers/staging/brcm80211/brcmsmac/srom.c | 1124 +++++++++++----------
>> drivers/staging/brcm80211/brcmsmac/srom.h | 4 +-
>> drivers/staging/brcm80211/brcmsmac/stf.c | 4 +-
>> 25 files changed, 1342 insertions(+), 1178 deletions(-)
>>
> Hi Arend,
>
> the code handling sprom looks better that before, but why don't you use
> a struct for the sprom and put all the stuff into it like it is done in
> ssb/bcma? We have haven't observance any problem using structs in b43 on
> pci bus and SoCs with a nvram storing the sprom variables.
If all lookup is done during driver initialization I guess it is not
such a problem. I do not know how much cycles are involved in sprom or
nvram access so it may not even matter.
> I found some references to SROM4_ and other older version, but I think
> this driver only supports devices with sprom 8 and 9.
>
> Hauke
Older sprom revisions can indeed go.
Thanks,
Arend
^ permalink raw reply
* RE: [PATCH v3] move brcm80211 drivers to mainline
From: Arend Van Spriel @ 2011-10-05 16:38 UTC (permalink / raw)
To: Larry Finger
Cc: Hauke Mehrtens, John W. Linville, linux-wireless@vger.kernel.org,
devel@linuxdriverproject.org, Brett Rudley, Franky (Zhenhui) Lin,
Roland Vossen, Alwin Beukers, gregkh@suse.de
In-Reply-To: <4E8C7B72.8070106@lwfinger.net>
> From: Larry Finger [mailto:larry.finger@gmail.com] On Behalf Of Larry
> Finger
> Sent: woensdag 5 oktober 2011 17:45
>
> On 10/05/2011 10:40 AM, Arend Van Spriel wrote:
> >> From: Hauke Mehrtens [mailto:hauke@hauke-m.de]
> >> Sent: woensdag 5 oktober 2011 17:07
> >>
> >> Hi Arend,
> >>
> >> Most of the things defined in
> >> drivers/net/wireless/brcm80211/include/soc.h are also defined in
> >> drivers/net/wireless/brcm80211/brcmsmac/aiutils.h.
> >>
> >> Hauke
> >
> > Thanks, Hauke
> >
> > One of the reasons we wanted to move to mainline is that bcma
> > is worked on from John's repo and we want our brcmsmac driver
> > to use that. The aiutils.h file is going away when we are
> > using bcma.
>
> Good to hear that patches to switch to bcma will be coming soon.
>
> Larry
>
Hi Larry,
Reading between the lines? ;-) It will not be there yesterday, but
we will definitely make an effort to make that switch. Work was
started on it but other cleanup was interfering so we decided
to focus on the cleanup.
Gr. AvS
^ permalink raw reply
* Re: [PATCH v3] move brcm80211 drivers to mainline
From: Larry Finger @ 2011-10-05 15:44 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Hauke Mehrtens, John W. Linville, linux-wireless@vger.kernel.org,
devel@linuxdriverproject.org, Brett Rudley, Franky (Zhenhui) Lin,
Roland Vossen, Alwin Beukers, gregkh@suse.de
In-Reply-To: <400C43189542CE41BC0A5B252FC90136BC0D574E7D@SJEXCHCCR02.corp.ad.broadcom.com>
On 10/05/2011 10:40 AM, Arend Van Spriel wrote:
>> From: Hauke Mehrtens [mailto:hauke@hauke-m.de]
>> Sent: woensdag 5 oktober 2011 17:07
>>
>> Hi Arend,
>>
>> Most of the things defined in
>> drivers/net/wireless/brcm80211/include/soc.h are also defined in
>> drivers/net/wireless/brcm80211/brcmsmac/aiutils.h.
>>
>> Hauke
>
> Thanks, Hauke
>
> One of the reasons we wanted to move to mainline is that bcma
> is worked on from John's repo and we want our brcmsmac driver
> to use that. The aiutils.h file is going away when we are
> using bcma.
Good to hear that patches to switch to bcma will be coming soon.
Larry
^ permalink raw reply
* RE: [PATCH v3] move brcm80211 drivers to mainline
From: Arend Van Spriel @ 2011-10-05 15:40 UTC (permalink / raw)
To: Hauke Mehrtens
Cc: John W. Linville, linux-wireless@vger.kernel.org,
devel@linuxdriverproject.org, Brett Rudley, Franky (Zhenhui) Lin,
Roland Vossen, Alwin Beukers, gregkh@suse.de
In-Reply-To: <4E8C7289.50706@hauke-m.de>
> From: Hauke Mehrtens [mailto:hauke@hauke-m.de]
> Sent: woensdag 5 oktober 2011 17:07
>
> Hi Arend,
>
> Most of the things defined in
> drivers/net/wireless/brcm80211/include/soc.h are also defined in
> drivers/net/wireless/brcm80211/brcmsmac/aiutils.h.
>
> Hauke
Thanks, Hauke
One of the reasons we wanted to move to mainline is that bcma
is worked on from John's repo and we want our brcmsmac driver
to use that. The aiutils.h file is going away when we are
using bcma.
Gr. AvS
^ permalink raw reply
* RE: [PATCH v3] move brcm80211 drivers to mainline
From: Arend Van Spriel @ 2011-10-05 15:34 UTC (permalink / raw)
To: Johannes Berg
Cc: John W. Linville, linux-wireless@vger.kernel.org,
devel@linuxdriverproject.org, Brett Rudley, Franky (Zhenhui) Lin,
Roland Vossen, Alwin Beukers, gregkh@suse.de
In-Reply-To: <1317826602.4839.46.camel@jlt3.sipsolutions.net>
PiBGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWlsdG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0N
Cj4gU2VudDogd29lbnNkYWcgNSBva3RvYmVyIDIwMTEgMTY6NTcNCj4gDQo+IFNvbWUgY29tbWVu
dHMuDQo+IA0KPiBJIHNvcnQgb2YgdW5kZXJzdGFuZCB5b3VyIGZhc2NpbmF0aW9uIHdpdGggImdl
bmVyaWMgdXRpbHMiIGJ1dCB0aGV5J3JlDQo+IHdhc3RlZnVsIGlmIHRoZXkncmUgaW4gYSBzaW5n
bGUgZHJpdmVyIG9ubHkuIFRoZXkgc2hvdWxkIGVpdGhlciBiZSBtYWRlDQo+IG1vcmUgZ2VuZXJp
YyAoZm9yIGFsbCBkcml2ZXJzKSBvciBkaXNzb2x2ZWQsIHNvOg0KPiANCj4gICogWW91IGNhbiBn
ZXQgcmlkIG9mIEJSQ01TX0JJVFNDTlQgYW5kIGJyY211X2JpdGNvdW50LCB0aGV5J3JlIG5vDQo+
ICAgIGxvbmdlciB1c2VkIGF0IGFsbC4NCj4gICogYnJjbXVfbWh6MmNoYW5uZWwgaXNuJ3QgdXNl
ZCBhbnl3aGVyZSBlaXRoZXINCj4gICogbmVpdGhlciBpcyBicmNtdV9jaHNwZWNfY3RsY2hhbg0K
PiAgKiBicmNtdV9td190b19xZGJtIGlzIHVzZWQgb25seSBpbiBhIHNpbmdsZSBmaWxlLA0KPiAg
ICBpdCBjYW4gbW92ZSB0aGVyZSB0byBzYXZlIHRoZSBleHBvcnQgZXRjLg0KPiAgKiBzYW1lIGZv
ciBicmNtdV9xZGJtX3RvX213LCBicmNtdV9jaGlwbmFtZSwgYnJjbXVfcGFyc2VfdGx2cywNCj4g
ICAgYnJjbXVfY2hzcGVjX21hbGZvcm1lZA0KPiAgKiBicmNtdV9ta2lvdmFyIGlzIHVzZWQgb25s
eSBpbiBmbWFjLCBzbyB5b3UgY2FuIG1vdmUgaXQgdGhlcmUNCj4gICAgdG8gc2F2ZSB0aGUgZXhw
b3J0DQo+ICAqIGJyY211X2Zvcm1hdF9mbGFncyBpcyB1c2VkIG9ubHkgaW4gc21hYywgc28gc2Ft
ZQ0KPiAgKiBzYW1lIGZvciBicmNtdV9mb3JtYXRfZmxhZ3MNCj4gDQo+IEFmdGVyIGFsbCB0aGUg
YWJvdmUsIGJjbXV0aWxzIGFyZSBsZWZ0IHdpdGggb25seSB0aGUgcGt0cSBhbmQgcGt0YnVmDQo+
IHN0dWZmLCB3aGljaCBob3BlZnVsbHkgd2lsbCBiZSBlaXRoZXIgbW9yZSBnZW5lcmljIG9yIGRp
c3NvbHZlZCBhdCBzb21lDQo+IHBvaW50IGluIHRoZSBmdXR1cmUgc2luY2UgaXQgc2hvdWxkIHJl
YWxseSBqdXN0IGJlIGEgZmV3IHNrYiBxdWV1ZXMuDQoNCkFncmVlLiBUaGVyZSBpcyBvcHBvcnR1
bml0eSB0byBjbGVhbnVwIG9uIHRoZSBicmNtdXRpbCBtb2R1bGUgb3INCmV2ZW4gZ2V0IHJpZCBv
ZiBpdC4NCg0KPiBOb3cgdGhlIGRyaXZlcnMgOi0pDQo+IA0KPiBGTUFDOg0KPiAgKiBBIHdob2xl
IGJ1bmNoIG9mIHRoaW5ncyBpbiBkaGQuaCBzdGlsbCBzZWVtIHRvIGxhY2sgZW5kaWFuDQo+ICAg
IGFubm90YXRpb25zLCB3aGljaCBJIHdvdWxkbid0IGJlIHRvbyB3b3JyaWVkIGFib3V0LCBpZiBp
dCBkaWRuJ3QNCj4gICAgYWxzbyBzZWVtIHRvIGxhY2sgY29udmVyc2lvbnMuIEZvciBleGFtcGxl
IGJyY21mX3BrdF9maWx0ZXJfZW5hYmxlLA0KPiAgICBicmNtZl9wa3RfZmlsdGVyLCBicmNtZl9w
a3RfZmlsdGVyX3BhdHRlcm4uDQo+ICAqIFRoZXNlLCBhbG9uZyB3aXRoIG90aGVycyBsaWtlIGJy
Y21mX2Jzc19pbmZvLCBhbHNvIHNlZW0gdG8gbGFjaw0KPiAgICBfX3BhY2tlZCBhbm5vdGF0aW9u
cy4gSSB0aG91Z2h0IHlvdSBmaXhlZCBhbGwgdGhpcywgd2hhdCBhbSBJDQo+ICAgIG1pc3Npbmc/
DQo+ICAqIGJzc19pbmZvWzFdOyBhbmQgc2ltaWxhciBzaG91bGQganVzdCBiZSBbXSBJIHRoaW5r
Pw0KPiAgKiBzb21lIHZlcnkgb2RkIGluZGVudGF0aW9uIG9uIGxpbmUgMTE3MiBvZiB3bF9jZmc4
MDIxMS5jDQo+IA0KPiBTTUFDOg0KPiAgKiBkbyB5b3UgcmVhbGx5IHdhbnQgdG8gYmUgNDBNSHog
aW50b2xlcmFudCBhbGwgdGhlIHRpbWU/IG5vdA0KPiAgICBzdXBwb3J0aW5nIDQwIE1IeiBpcyBv
bmUgdGhpbmcsIGJ1dCBiZWluZyBpbnRvbGVyYW50Pw0KPiAgKiBicmNtc19vcHNfc3RvcCBkb2Vz
bid0IHNlZW0gcmlnaHQgLS0gdGhpcyBzaG91bGQgcmVhbGx5IHBvd2VyIGRvd24NCj4gICAgdGhl
IGRldmljZSwgdGhpcyBzaG91bGRuJ3QgYmUgZG9uZSBwZXIgaW50ZXJmYWNlIHNpbmNlIHRoZSBt
b25pdG9yDQo+ICAgIGNhc2Ugd2lsbCB3YW50IHRvIFJYL1RYIGV2ZW4gd2hlbiBubyBpbnRlcmZh
Y2UgaXMgdGhlcmU7IGFsc28sDQo+IHlvdSdsbA0KPiAgICB3YW50IG11bHRpLXZpZiBzdXBwb3J0
IHNvb24gOi0pDQoNCkFncmVlLiBXZSBub3RpY2VkIHJlYWRpbmcgbWFjODAyMTEuaCB3aXRoIHN0
YXRlbWVudCBhYm91dCBhZGRfaW50ZXJmYWNlDQpjYWxsYmFjayBub3QgYmVpbmcgdXNlZCBpbiBt
b25pdG9yIG1vZGUuDQoNCj4gICogbG9ja2luZyB0eCgpIGlzIGluZWZmaWNpZW50LCB5b3Ugc2hv
dWxkIGJlIGFibGUgdG8gZ28gd2l0aCBhIGxvY2sNCj4gcGVyDQo+ICAgIEhXIHF1ZXVlDQo+ICAq
IGJyY21zX29wc19zdGFfYWRkIGlzIHN0cmFuZ2UgLS0gaXQgc2hvdWxkbid0IGJlIG1vZGlmeWlu
ZyB0aGUNCj4gc3RhdGlvbg0KPiAgICBwYXJhbWV0ZXJzLCB3aHkgd291bGQgaXQgZG8gdGhhdD8g
c2VlbXMgbGlrZSBhIGJ1ZyB0byBtZSwgZXNwZWNpYWxseQ0KPiAgICBhbHdheXMgYXNzdW1pbmcg
dGhlIHBlZXIgY2FuIGRvIGdyZWVuZmllbGQgZXRjLiBUaGlzIGRhdGEgc2hvdWxkDQo+ICAgIGFs
cmVhZHkgYmUgc2V0IGJ5IG1hYzgwMjExLCBpZiBub3QgdGhhdCdzIGEgYnVnLCBub3Qgc29tZXRo
aW5nIHRvDQo+ICAgICJmaXgiIGluIHRoZSBkcml2ZXINCj4gICogSSBzdGlsbCB0aGluayB0aGlu
Z3MgbGlrZSBicmNtc19tc2xlZXAoKSBhcmUgZ3VhcmFudGVlZCB0byBjcmVhdGUNCj4gICAgc3Vi
dGxlIGxvY2tpbmcgYnVncyB0aGF0IGFyZSBhbG1vc3QgaW1wb3NzaWJsZSB0byBmaW5kIHNpbmNl
IGl0DQo+IGRyb3BzDQo+ICAgIHRoZSBzcGlubG9jayBhbmQgaWYgc29tZWJvZHkgY2FsbHMgdGhl
IGZ1bmN0aW9uIHNvbWV3aGVyZSB0aGV5IHdvbid0DQo+ICAgIG5lY2Vzc2FyaWx5IGtlZXAgdGhh
dCBpbiBtaW5kLiBUaGVyZSBhcmUgYSB3aG9sZSBidW5jaCBvZiBmdW5jdGlvbnMNCj4gICAgYmVo
YXZpbmcgbGlrZSB0aGF0Lg0KDQpBZ3JlZS4gVGhlIGxvY2tpbmcgc3RyYXRlZ3kgaW4gdGhlIGRy
aXZlciB3b3JrcyBhbmQgaGFzIGJlZW4gcHJvdmVuDQp0byB3b3JrIGZvciB0aGUgY3VycmVudCBj
b2RlIGJhc2UgaW4gbWFueSB0ZXN0IGN5Y2xlcywgYnV0IGl0IHBvc2VzDQphIHJpc2sgZm9yIHVw
Y29taW5nIGZlYXR1cmUgZGV2ZWxvcG1lbnQuDQoNCj4gDQo+IEFueXdheSwgdGhlIGNvZGUgaXMg
bm93IHJlYWRhYmxlIHRvIG1lLCBJIHNlZSBubyBnbGFyaW5nIG1hYzgwMjExIG9yDQo+IGNmZzgw
MjExIGludGVyZmFjaW5nIGVycm9ycywgc28gSSBndWVzcyB5b3UgY2FuIHdvcmsgdGhlIHJlc3Qg
aW4NCj4gbWFpbmxpbmUuDQo+IA0KPiBqb2hhbm5lcw0KPiANCg0KVGhhbmtzIGZvciB0aGUgZmVl
ZGJhY2suIFRoZXNlIGFyZSBhbGwgdmFsaWQgcG9pbnRzIGFuZCBhcyBzdWNoIGRlc2VydmUNCm91
ciBhdHRlbnRpb24uDQoNCkFyZW5kDQo=
^ permalink raw reply
* Re: 答复: 答复: 答复: 3.1-rc6+ rtl8192se issue
From: Borislav Petkov @ 2011-10-05 15:15 UTC (permalink / raw)
To: Larry Finger; +Cc: 李朝明, linux-wireless, 'LKML'
In-Reply-To: <4E83D092.7010405@lwfinger.net>
On Wed, Sep 28, 2011 at 08:57:38PM -0500, Larry Finger wrote:
> Asa you probably do not want to kill your standard tree, unpack the
> Realtek version normally, cd to where it unpacked, and do a make.
> Once it builds, do the following:
>
> sudo modprobe -rv rtl8192se
> sudo modprobe -v mac80211
> sudo insmod rtlwifi.ko
> sudo insmod rtl8192se/rtl8192se.ko
>
> >
> >Also, any preferred module parameters settings you want me to test?
>
> Try it first with the default parameters. If that fails, use "ips=0".
Ok, I can cautiosly say now that after a couple days of running the
Realtek version that the box runs just fine, no hiccups whatsoever.
Larry, you said in an earlier mail that you've gone through the
rtl8192se changes and weren't optimistic with the attached diff you sent
me. What about the rtlwifi changes, is there something in Realtek's
version which is missing upstream that would cause the sluggishness?
Thanks.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* Re: [PATCH v3] move brcm80211 drivers to mainline
From: Hauke Mehrtens @ 2011-10-05 15:06 UTC (permalink / raw)
To: Arend van Spriel
Cc: John W. Linville, linux-wireless@vger.kernel.org,
devel@linuxdriverproject.org, Brett Rudley, Franky (Zhenhui) Lin,
Roland Vossen, Alwin Beukers, gregkh@suse.de
In-Reply-To: <4E8C64EF.3070203@broadcom.com>
On 10/05/2011 04:08 PM, Arend van Spriel wrote:
> With number of cleanup patch series merged in by Greg KH, I'd like to
> once again propose moving brcm80211 out of staging and into mainline.
>
> I've put together a patch to add a copy of the current sources from
> staging-next into drivers/net/wireless/brcm80211 of the wireless-next
> repository.
>
> The patch is somewhat large, so I've posted the patch at:
>
> http://linuxwireless.org/en/users/Drivers/brcm80211?action=AttachFile&do=view&target=0001-net-wireless-add-brcm80211-drivers-v3.patch
>
>
> Changes from the previous version:
>
> V3:
> - remove -D line from Makefiles
> - use endian annotated structures
> - enable sparse endian checking
> - remove use of (static) global variables
> - remove own buffer printing implementation
> - remove static function prototypes
> - replace macros by inline functions
> - reduce sparse warnings
> - remove using string-based iovars
> - remove driver internal use of ioctls
> - remove (un)likely
> - remove uncoditional curly braces for variable scoping
> - remove error messages upon alloc failures
> - reduced code indentation levels
> - cleanup in brcmutil module
> - remove changing lock state which is acquired by other layer
> (wpa_supplicant)
> - brcmfmac:
> - use ffs() instead of brcmf_find_msb()
> - replace threads with work queues
> - cleanup module parameters
> - brcmsmac:
> - not modifying ssn value upon AMPDU start
> - use hweight8() instead of brcmu_bitcount()
> - remove unnecessary mac80211 callbacks
> - remove brcms_c_set_par and get_par functions
> - remove bmac wrapper functions
> - remove lock related macros
> - add debugfs based event tracing (not functional in staging)
>
> The brcmsmac driver has been verified to work on x86 (both 32- and
> 64-bit), PPC
> (64-bit), SPARC, MIPS BE, and ARM. The brcmfmac driver has been
> verified to
> work on x86 32-bit and ARM (additional testing is in progress, but
> getting a
> working sdio controller on some of the other platforms remains
> challenging).
>
> The drivers compile cleanly for x86 (32- and 64-bit), PPC (32- and 64-bit),
> SPARC, MIPS BE, MIPS LE, and ARM.
>
> Thanks,
> Arend van Spriel
>
Hi Arend,
Most of the things defined in
drivers/net/wireless/brcm80211/include/soc.h are also defined in
drivers/net/wireless/brcm80211/brcmsmac/aiutils.h.
Hauke
^ permalink raw reply
* Re: [PATCH v3] move brcm80211 drivers to mainline
From: Johannes Berg @ 2011-10-05 14:56 UTC (permalink / raw)
To: Arend van Spriel
Cc: John W. Linville, linux-wireless@vger.kernel.org,
devel@linuxdriverproject.org, Brett Rudley, Franky (Zhenhui) Lin,
Roland Vossen, Alwin Beukers, gregkh@suse.de
In-Reply-To: <4E8C64EF.3070203@broadcom.com>
On Wed, 2011-10-05 at 16:08 +0200, Arend van Spriel wrote:
With number of cleanup patch series merged in by Greg KH, I'd like to
> once again propose moving brcm80211 out of staging and into mainline.
>
> I've put together a patch to add a copy of the current sources from
> staging-next into drivers/net/wireless/brcm80211 of the wireless-next
> repository.
>
> The patch is somewhat large, so I've posted the patch at:
>
> http://linuxwireless.org/en/users/Drivers/brcm80211?action=AttachFile&do=view&target=0001-net-wireless-add-brcm80211-drivers-v3.patch
Some comments.
I sort of understand your fascination with "generic utils" but they're
wasteful if they're in a single driver only. They should either be made
more generic (for all drivers) or dissolved, so:
* You can get rid of BRCMS_BITSCNT and brcmu_bitcount, they're no
longer used at all.
* brcmu_mhz2channel isn't used anywhere either
* neither is brcmu_chspec_ctlchan
* brcmu_mw_to_qdbm is used only in a single file,
it can move there to save the export etc.
* same for brcmu_qdbm_to_mw, brcmu_chipname, brcmu_parse_tlvs,
brcmu_chspec_malformed
* brcmu_mkiovar is used only in fmac, so you can move it there
to save the export
* brcmu_format_flags is used only in smac, so same
* same for brcmu_format_flags
After all the above, bcmutils are left with only the pktq and pktbuf
stuff, which hopefully will be either more generic or dissolved at some
point in the future since it should really just be a few skb queues.
Now the drivers :-)
FMAC:
* A whole bunch of things in dhd.h still seem to lack endian
annotations, which I wouldn't be too worried about, if it didn't
also seem to lack conversions. For example brcmf_pkt_filter_enable,
brcmf_pkt_filter, brcmf_pkt_filter_pattern.
* These, along with others like brcmf_bss_info, also seem to lack
__packed annotations. I thought you fixed all this, what am I
missing?
* bss_info[1]; and similar should just be [] I think?
* some very odd indentation on line 1172 of wl_cfg80211.c
SMAC:
* do you really want to be 40MHz intolerant all the time? not
supporting 40 MHz is one thing, but being intolerant?
* brcms_ops_stop doesn't seem right -- this should really power down
the device, this shouldn't be done per interface since the monitor
case will want to RX/TX even when no interface is there; also, you'll
want multi-vif support soon :-)
* locking tx() is inefficient, you should be able to go with a lock per
HW queue
* brcms_ops_sta_add is strange -- it shouldn't be modifying the station
parameters, why would it do that? seems like a bug to me, especially
always assuming the peer can do greenfield etc. This data should
already be set by mac80211, if not that's a bug, not something to
"fix" in the driver
* I still think things like brcms_msleep() are guaranteed to create
subtle locking bugs that are almost impossible to find since it drops
the spinlock and if somebody calls the function somewhere they won't
necessarily keep that in mind. There are a whole bunch of functions
behaving like that.
Anyway, the code is now readable to me, I see no glaring mac80211 or
cfg80211 interfacing errors, so I guess you can work the rest in
mainline.
johannes
^ permalink raw reply
* Re: [PATCH 00/15] staging: brcm80211: cleanup fullmac structs and softmac srom lookup
From: Hauke Mehrtens @ 2011-10-05 14:40 UTC (permalink / raw)
To: Arend van Spriel; +Cc: gregkh, devel, linux-wireless
In-Reply-To: <1317820814-7083-1-git-send-email-arend@broadcom.com>
On 10/05/2011 03:19 PM, Arend van Spriel wrote:
> This series addresses more community feedback items received on mainline
> patch (v2) posted August 25, 2011. The driver structures in brcmfmac could
> do with some tidying and in the brcmsmac variables loaded from srom were
> accessed by string identifiers. This has been replaced by enumerated
> identifiers and the entries are stored in kernel standard linked list.
>
> This series applies to staging-next and depends on the patch series posted
> on Oct 4, 2011 (see Message-ID below).
>
> Message-ID: <1317763152-17607-1-git-send-email-arend@broadcom.com>
>
> Arend van Spriel (11):
> staging: brcm80211: move driver variable functions to srom.c
> staging: brcm80211: remove code duplication for driver variable
> lookup
> staging: brcm80211: change parameter in driver variable lookup
> staging: brcm80211: remove locking macro definitions
> staging: brcm80211: fix thread blocking issue in
> brcmf_sdbrcm_bus_stop()
> staging: brcm80211: remove invalid variable lookup from srom
> staging: brcm80211: use identifiers instead of string for srom lookup
> staging: brcm80211: use enum identifiers in srom variable tables
> staging: brcm80211: replace string based variable storage by linked
> list
> staging: brcm80211: remove parameter 'off' from _initvars_srom_pci()
> staging: brcm80211: cleanup driver variable references
>
> Franky Lin (4):
> staging: brcm80211: remove threads_only code from fullmac
> staging: brcm80211: remove redundant bus register layer from fullmac
> staging: brcm80211: clean up struct brcmf_if in fullmac
> staging: brcm80211: remove brcmf_op_if from fullmac
>
> drivers/staging/brcm80211/brcmfmac/bcmsdh.c | 10 -
> drivers/staging/brcm80211/brcmfmac/bcmsdh_sdmmc.c | 16 +-
> drivers/staging/brcm80211/brcmfmac/dhd_linux.c | 134 +--
> drivers/staging/brcm80211/brcmfmac/dhd_sdio.c | 133 +--
> drivers/staging/brcm80211/brcmfmac/sdio_host.h | 4 -
> drivers/staging/brcm80211/brcmsmac/aiutils.c | 32 +-
> drivers/staging/brcm80211/brcmsmac/aiutils.h | 6 +-
> drivers/staging/brcm80211/brcmsmac/antsel.c | 15 +-
> drivers/staging/brcm80211/brcmsmac/channel.c | 2 +-
> drivers/staging/brcm80211/brcmsmac/mac80211_if.c | 157 ++--
> drivers/staging/brcm80211/brcmsmac/main.c | 144 +---
> drivers/staging/brcm80211/brcmsmac/main.h | 5 -
> drivers/staging/brcm80211/brcmsmac/nicpci.c | 5 +-
> drivers/staging/brcm80211/brcmsmac/nicpci.h | 2 +-
> drivers/staging/brcm80211/brcmsmac/phy/phy_cmn.c | 42 +-
> drivers/staging/brcm80211/brcmsmac/phy/phy_hal.h | 4 +-
> drivers/staging/brcm80211/brcmsmac/phy/phy_int.h | 7 -
> drivers/staging/brcm80211/brcmsmac/phy/phy_lcn.c | 64 +-
> drivers/staging/brcm80211/brcmsmac/phy/phy_n.c | 330 ++++--
> drivers/staging/brcm80211/brcmsmac/phy_shim.c | 9 +
> drivers/staging/brcm80211/brcmsmac/phy_shim.h | 4 +
> drivers/staging/brcm80211/brcmsmac/pub.h | 263 +++++-
> drivers/staging/brcm80211/brcmsmac/srom.c | 1124 +++++++++++----------
> drivers/staging/brcm80211/brcmsmac/srom.h | 4 +-
> drivers/staging/brcm80211/brcmsmac/stf.c | 4 +-
> 25 files changed, 1342 insertions(+), 1178 deletions(-)
>
Hi Arend,
the code handling sprom looks better that before, but why don't you use
a struct for the sprom and put all the stuff into it like it is done in
ssb/bcma? We have haven't observance any problem using structs in b43 on
pci bus and SoCs with a nvram storing the sprom variables.
I found some references to SROM4_ and other older version, but I think
this driver only supports devices with sprom 8 and 9.
Hauke
^ permalink raw reply
* Re: [PATCH v3] move brcm80211 drivers to mainline
From: John W. Linville @ 2011-10-05 14:24 UTC (permalink / raw)
To: Arend van Spriel
Cc: linux-wireless@vger.kernel.org, devel@linuxdriverproject.org,
Brett Rudley, Franky (Zhenhui) Lin, Roland Vossen, Alwin Beukers,
gregkh@suse.de
In-Reply-To: <4E8C64EF.3070203@broadcom.com>
On Wed, Oct 05, 2011 at 04:08:47PM +0200, Arend van Spriel wrote:
> With number of cleanup patch series merged in by Greg KH, I'd like to
> once again propose moving brcm80211 out of staging and into mainline.
>
> I've put together a patch to add a copy of the current sources from
> staging-next into drivers/net/wireless/brcm80211 of the wireless-next
> repository.
>
> The patch is somewhat large, so I've posted the patch at:
>
> http://linuxwireless.org/en/users/Drivers/brcm80211?action=AttachFile&do=view&target=0001-net-wireless-add-brcm80211-drivers-v3.patch
Feel free to complain, but I plan to merge this in time for the merge
window unless someone identifies a true "showstopper" problem with
this patch in the next day or so.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] ath6kl:Fix execution address of OTP AR6003 HW2.0
From: Sangwook Lee @ 2011-10-05 14:14 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, patches, Sangwook Lee
Fix OTP execution address for AR6003 HW2.0
ath6kl: writing otp to 0x543180 (3689 B)
ath6kl: bmi LZ stream start: addr: 0x543180)
ath6kl: bmi send LZ data: len: 3688)
ath6kl: bmi send LZ data: len: 4)
ath6kl: bmi LZ stream start: addr: 0x0)
ath6kl: bmi read memory: device: addr: 0x54061c, len: 4
ath6kl: app_start_override_addr 0x0
ath6kl: executing OTP at 0x0
ath6kl: bmi execute: addr: 0x0, param: 0)
ath6kl: bmi_recv_buf FIFO empty
ath6kl: Unable to read from the device: -22
Signed-off-by: Sangwook Lee <sangwook.lee@linaro.org>
---
drivers/net/wireless/ath/ath6kl/init.c | 3 +++
drivers/net/wireless/ath/ath6kl/target.h | 1 +
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/init.c b/drivers/net/wireless/ath/ath6kl/init.c
index b277111..bfe802b 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -1211,6 +1211,9 @@ static int ath6kl_upload_otp(struct ath6kl *ar)
return ret;
}
+ if (ar->version.target_ver == AR6003_REV2_VERSION)
+ address = AR6003_REV2_APP_START_OVERRIDE;
+
ar->hw.app_start_override_addr = address;
ath6kl_dbg(ATH6KL_DBG_BOOT, "app_start_override_addr 0x%x\n",
diff --git a/drivers/net/wireless/ath/ath6kl/target.h b/drivers/net/wireless/ath/ath6kl/target.h
index c9a7605..253c489 100644
--- a/drivers/net/wireless/ath/ath6kl/target.h
+++ b/drivers/net/wireless/ath/ath6kl/target.h
@@ -331,6 +331,7 @@ struct host_interest {
(((target_type) == TARGET_TYPE_AR6003) ? AR6003_VTOP(vaddr) : \
(((target_type) == TARGET_TYPE_AR6004) ? AR6004_VTOP(vaddr) : 0))
+#define AR6003_REV2_APP_START_OVERRIDE 0x944C00
#define AR6003_REV2_APP_LOAD_ADDRESS 0x543180
#define AR6003_REV2_BOARD_EXT_DATA_ADDRESS 0x57E500
#define AR6003_REV2_DATASET_PATCH_ADDRESS 0x57e884
--
1.7.4.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox