* [PATCH v2 3/9] wlcore: remove pwr_in_suspend from platform data
From: Luciano Coelho @ 2013-07-02 14:55 UTC (permalink / raw)
To: linux-wireless, tony, nsekhar
Cc: mturquette, mark.rutland, balbi, grant.likely, rob.herring,
devicetree-discuss, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, coelho
In-Reply-To: <1372776948-24840-1-git-send-email-coelho@ti.com>
The pwr_in_suspend flag depends on the MMC settings which can be
retrieved from the SDIO subsystem, so it doesn't need to be part of
the platform data structure. Move it to the platform device data that
is passed from SDIO to wlcore.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
drivers/net/wireless/ti/wlcore/main.c | 2 +-
drivers/net/wireless/ti/wlcore/sdio.c | 2 +-
drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 +
include/linux/wl12xx.h | 1 -
4 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index e7294b8..d306cd5 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5941,7 +5941,7 @@ static void wlcore_nvs_cb(const struct firmware *fw, void *context)
if (!ret) {
wl->irq_wake_enabled = true;
device_init_wakeup(wl->dev, 1);
- if (pdata->pwr_in_suspend)
+ if (pdev_data->pwr_in_suspend)
wl->hw->wiphy->wowlan = &wlcore_wowlan_support;
}
#endif
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c b/drivers/net/wireless/ti/wlcore/sdio.c
index 29ef249..4c7e8ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -260,7 +260,7 @@ static int wl1271_probe(struct sdio_func *func,
dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
if (mmcflags & MMC_PM_KEEP_POWER)
- pdev_data->pdata->pwr_in_suspend = true;
+ pdev_data->pwr_in_suspend = true;
sdio_set_drvdata(func, glue);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index e5e1464..f2c4227 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -209,6 +209,7 @@ struct wl1271_if_operations {
struct wlcore_platdev_data {
struct wl12xx_platform_data *pdata;
struct wl1271_if_operations *if_ops;
+ bool pwr_in_suspend;
};
#define MAX_NUM_KEYS 14
diff --git a/include/linux/wl12xx.h b/include/linux/wl12xx.h
index 04e3096..1e4ed6e 100644
--- a/include/linux/wl12xx.h
+++ b/include/linux/wl12xx.h
@@ -60,7 +60,6 @@ struct wl12xx_platform_data {
unsigned long irq_flags;
int board_ref_clock;
int board_tcxo_clock;
- bool pwr_in_suspend;
};
#ifdef CONFIG_WILINK_PLATFORM_DATA
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 0/9] wilink: add device tree support
From: Luciano Coelho @ 2013-07-02 14:55 UTC (permalink / raw)
To: linux-wireless, tony, nsekhar
Cc: mturquette, mark.rutland, balbi, grant.likely, rob.herring,
devicetree-discuss, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, coelho
Hi,
This is a follow-up on a previous patch set that had a smaller
audience. This time, I added the lists and people who were involved
in the review of the bindings documentation, since most of my changes
in v2 are coming from discussions there.
This patch series adds device tree support to the wlcore_sdio driver,
which is used by WiLink6, WiLink7 and WiLink8.
The first patches do some clean-up to make the data needed in the
wilink device tree node smaller. The remaining patches implement the
actual device tree node parsing in wlcore_sdio.
I still need to figure out how to add the information about whether
the clocks are XTAL or not. I'll send it in a separate patche set.
The DTS file changes will be sent separately, since they need to go
via different trees.
The bindings documentation patch will also be updated and sent
separately, once the XTAL issue is solved.
Tony has acked some of the patches that touch OMAP areas. I still
need one more ack to a new patch I added (wl12xx: use frequency
instead of enumerations for pdata clocks).
Sekhar, can you please check the patches that touch the davinci board
file and ack them?
Changes in v2:
* New clean-up patch (4/9);
* Patch 6/9 (previously patch 5/5) now doesn't add the clock parsing,
since it became more complicated and I added separate patches for
that;
* 3 new patches (from 7/9 till 9/9) to handle the clock reading in the
device tree;
Please review.
--
Cheers,
Luca.
Luciano Coelho (9):
wl1251: split wl251 platform data to a separate structure
wlcore: use irq_flags in pdata instead of hiding it behind a quirk
wlcore: remove pwr_in_suspend from platform data
wl12xx: use frequency instead of enumerations for pdata clocks
wlcore: always use one-shot IRQ
wlcore: add initial device tree support to the sdio module
wlcore: sdio: add wilink clock providers
wlcore: sdio: get clocks from device tree
wlcore/wl12xx: check if we got correct clock data from DT
arch/arm/mach-davinci/board-da850-evm.c | 5 +-
arch/arm/mach-omap2/board-4430sdp.c | 6 +-
arch/arm/mach-omap2/board-omap3evm.c | 4 +-
arch/arm/mach-omap2/board-omap3pandora.c | 4 +-
arch/arm/mach-omap2/board-omap4panda.c | 4 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 2 +-
arch/arm/mach-omap2/board-zoom-peripherals.c | 4 +-
drivers/net/wireless/ti/wilink_platform_data.c | 37 ++++++--
drivers/net/wireless/ti/wl1251/sdio.c | 12 +--
drivers/net/wireless/ti/wl1251/spi.c | 2 +-
drivers/net/wireless/ti/wl12xx/main.c | 78 +++++++++++++++--
drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 ++++++
drivers/net/wireless/ti/wlcore/debugfs.c | 2 +-
drivers/net/wireless/ti/wlcore/main.c | 16 ++--
drivers/net/wireless/ti/wlcore/sdio.c | 112 ++++++++++++++++++++++--
drivers/net/wireless/ti/wlcore/wlcore.h | 5 +-
drivers/net/wireless/ti/wlcore/wlcore_i.h | 1 +
include/linux/wl12xx.h | 54 ++++++------
18 files changed, 295 insertions(+), 81 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints
From: Arend van Spriel @ 2013-07-02 14:13 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ilan Peer, linux-wireless, mcgrof
In-Reply-To: <1372773647.8615.1.camel@jlt4.sipsolutions.net>
On 07/02/2013 04:00 PM, Johannes Berg wrote:
> On Tue, 2013-07-02 at 15:55 +0200, Arend van Spriel wrote:
>> On 07/02/2013 02:28 PM, Ilan Peer wrote:
>>> Move the regulatory cellular base station hints support under
>>> a specific configuration option and make the option depend
>>> on CFG80211_CERTIFICATION_ONUS.
>>
>> This one seems not really related to the other patches. On itself it is
>> not clear to me what itch is being scratched here. Is the aim to get rid
>> of the CERTIFICATION_ONUS dependency further along the road?
>
> No, it's really just so patch 3 can add a separate option under
> CERTIFICATION_ONUS while allowing cell base station and the new option
> to be separate.
Thanks, Johannes
Missed that.
Gr. AvS
^ permalink raw reply
* Re: [PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints
From: Johannes Berg @ 2013-07-02 14:00 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Ilan Peer, linux-wireless, mcgrof
In-Reply-To: <51D2DBB9.4010500@broadcom.com>
On Tue, 2013-07-02 at 15:55 +0200, Arend van Spriel wrote:
> On 07/02/2013 02:28 PM, Ilan Peer wrote:
> > Move the regulatory cellular base station hints support under
> > a specific configuration option and make the option depend
> > on CFG80211_CERTIFICATION_ONUS.
>
> This one seems not really related to the other patches. On itself it is
> not clear to me what itch is being scratched here. Is the aim to get rid
> of the CERTIFICATION_ONUS dependency further along the road?
No, it's really just so patch 3 can add a separate option under
CERTIFICATION_ONUS while allowing cell base station and the new option
to be separate.
johannes
^ permalink raw reply
* Re: [PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints
From: Arend van Spriel @ 2013-07-02 13:55 UTC (permalink / raw)
To: Ilan Peer; +Cc: linux-wireless, mcgrof
In-Reply-To: <1372768095-26053-3-git-send-email-ilan.peer@intel.com>
On 07/02/2013 02:28 PM, Ilan Peer wrote:
> Move the regulatory cellular base station hints support under
> a specific configuration option and make the option depend
> on CFG80211_CERTIFICATION_ONUS.
This one seems not really related to the other patches. On itself it is
not clear to me what itch is being scratched here. Is the aim to get rid
of the CERTIFICATION_ONUS dependency further along the road?
Regards,
Arend
> Signed-off-by: Ilan Peer <ilan.peer@intel.com>
> ---
> net/wireless/Kconfig | 7 +++++++
> net/wireless/reg.c | 2 +-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
> index 16d08b3..de76078 100644
> --- a/net/wireless/Kconfig
> +++ b/net/wireless/Kconfig
> @@ -95,6 +95,13 @@ config CFG80211_CERTIFICATION_ONUS
> you are a wireless researcher and are working in a controlled
> and approved environment by your local regulatory agency.
>
> +config CFG80211_REG_CELLULAR_HINTS
> + bool "cfg80211 regulatory support for cellular base station hints"
> + depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
> + ---help---
> + This option adds support for drivers that can receive regulatory
> + hints from cellular base stations
> +
> config CFG80211_DEFAULT_PS
> bool "enable powersave by default"
> depends on CFG80211
> diff --git a/net/wireless/reg.c b/net/wireless/reg.c
> index 5a24c98..2459a69 100644
> --- a/net/wireless/reg.c
> +++ b/net/wireless/reg.c
> @@ -928,7 +928,7 @@ bool reg_last_request_cell_base(void)
> return reg_request_cell_base(get_last_request());
> }
>
> -#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
> +#ifdef CONFIG_CFG80211_REG_CELLULAR_HINTS
> /* Core specific check */
> static enum reg_request_treatment
> reg_ignore_cell_hint(struct regulatory_request *pending_request)
>
^ permalink raw reply
* Re: [RFC v2] mac80211: Use libnl-configurable values for retry counts
From: Felix Fietkau @ 2013-07-02 13:50 UTC (permalink / raw)
To: Jean-Pierre Tosoni; +Cc: linux-wireless
In-Reply-To: <000001ce7728$18b07de0$4a1179a0$@acksys.fr>
On 2013-07-02 3:28 PM, Jean-Pierre Tosoni wrote:
> Hi Felix,
>
>> -----Message d'origine-----
>> De : Felix Fietkau [mailto:nbd@openwrt.org]
>> > ---
>> > What I am seeking with this patch:
>> > I believe the configuration of the retries will help making recovery
>> > much faster when an AP (in infrastructure mode) or a peer (in mesh
>> > mode) suddenly disappears.
>> I'm all for reducing retries, but I think the way you're applying the
>> limit is problematic.
>> If minstrel decides to use many retries for a high rate and you're
>> simply cutting off all retries that exceed the configured limit, you're
>> potentially inviting quite a bit of unnecessary packet loss.
>> I'm planning to remove the use of retry rate slot 4 (fallback to lowest
>> rate) from minstrel, since max_prob_rate should already provide quite
>> decent reliability.
>
> Well, on one hand, people who want to reduce retries are more concerned with
> low latency and jitter than with reliable delivery of data.
Makes sense.
> On another hand the code should work for any rate control plugin, not just
> minstrel.
But much more important than that is to not cause regressions for other
people via aggressive packet dropping.
> Finally this code is executed for each frame, and I don’t want to bloat it
> more than necessary...
If you put the code in minstrel (and minstrel_ht), it not only allows
making a better tradeoff for retry handling, the code also doesn't have
to be run for every single packet. You can run it during the rate
control stats update.
The reduction of retry attempts definitely needs to be balanced
properly. Retries with max_prob_rate can be more important than retries
with max_tp_rate, but there needs to be a minimum for each of those.
- Felix
^ permalink raw reply
* [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels
From: Ilan Peer @ 2013-07-02 12:28 UTC (permalink / raw)
To: linux-wireless; +Cc: mcgrof, David Spinadel, Ilan Peer
In-Reply-To: <1372768095-26053-1-git-send-email-ilan.peer@intel.com>
From: David Spinadel <david.spinadel@intel.com>
Allow GO operation on a channel marked with
IEEE80211_CHAN_INDOOR_ONLY or IEEE80211_CHAN_GO_CONCURRENT
iff there is an active station interface that is associated to
an AP operating on this channel.
Note that this is a permissive approach to the FCC definitions,
that require a clear assessment that either the platform device
is an indoor device, or the device operating the AP is an indoor
device, i.e., AC powered.
It is assumed that these restrictions are enforced by user space.
Furthermore, it is assumed, that if the conditions that allowed for
the operation of the GO on such a channel change, it is the
responsibility of user space to evacuate the GO from the channel.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
---
include/net/cfg80211.h | 4 +-
net/mac80211/ibss.c | 2 +-
net/wireless/Kconfig | 10 +++++
net/wireless/chan.c | 98 ++++++++++++++++++++++++++++++++++++++++++++----
net/wireless/mesh.c | 2 +-
net/wireless/nl80211.c | 8 ++--
net/wireless/trace.h | 11 ++++--
7 files changed, 118 insertions(+), 17 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index f0badeb..17d693d 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4070,12 +4070,14 @@ void cfg80211_report_obss_beacon(struct wiphy *wiphy,
* cfg80211_reg_can_beacon - check if beaconing is allowed
* @wiphy: the wiphy
* @chandef: the channel definition
+ * @p2p_go: if the interface type is a P2P GO
*
* Return: %true if there is no secondary channel or the secondary channel(s)
* can be used for beaconing (i.e. is not a radar channel etc.)
*/
bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
- struct cfg80211_chan_def *chandef);
+ struct cfg80211_chan_def *chandef,
+ bool p2p_go);
/*
* cfg80211_ch_switch_notify - update wdev channel and notify userspace
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index ea7b9c2..1e0fac1 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -82,7 +82,7 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
sdata->drop_unencrypted = capability & WLAN_CAPABILITY_PRIVACY ? 1 : 0;
chandef = ifibss->chandef;
- if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef)) {
+ if (!cfg80211_reg_can_beacon(local->hw.wiphy, &chandef, false)) {
chandef.width = NL80211_CHAN_WIDTH_20;
chandef.center_freq1 = chan->center_freq;
}
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index de76078..d9e2be7 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -102,6 +102,16 @@ config CFG80211_REG_CELLULAR_HINTS
This option adds support for drivers that can receive regulatory
hints from cellular base stations
+config CFG80211_REG_SOFT_CONFIGURATIONS
+ bool "cfg80211 support for GO operation on additional channels"
+ depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
+ ---help---
+ This option enables the operation of a P2P Group Owner on
+ additional channels, if there is a clear assessment that
+ the platform device operates in an indoor environment or
+ in case that there is an additional BSS interface which is
+ connected to an AP which is an indoor device.
+
config CFG80211_DEFAULT_PS
bool "enable powersave by default"
depends on CFG80211
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index 50f6195..92d9e3c 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -457,18 +457,102 @@ bool cfg80211_chandef_usable(struct wiphy *wiphy,
}
EXPORT_SYMBOL(cfg80211_chandef_usable);
+#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
+static int cfg80211_get_unii_band(int freq)
+{
+ /* UNII-1 */
+ if (freq >= 5150 && freq <= 5250)
+ return 0;
+
+ /* UNII-2 */
+ if (freq > 5250 && freq <= 5350)
+ return 1;
+
+ /* UNII-2E */
+ if (freq >= 5470 && freq <= 5725)
+ return 2;
+
+ /* UNII-3 */
+ if (freq > 5725 && freq <= 5825)
+ return 3;
+
+ WARN_ON(1);
+ return -EINVAL;
+}
+#endif
+
+/* For GO only, check if the channel can be used under permissive conditions
+ * mandated by the FCC, i.e., the channel is marked as:
+ * 1. Indoor only: a GO can be operational on such a channel, iff there is
+ * clear assessment that the platform device is indoor.
+ * 2. Concurrent GO: a GO can be operational on such a channel, iff there is an
+ * additional station interface connected to an AP on this channel.
+ *
+ * TODO: The function is too permissive, as it does not verify the platform
+ * device type is indeed indoor, or that the AP is indoor/AC powered.
+ */
+static bool cfg80211_can_go_use_chan(struct cfg80211_registered_device *rdev,
+ struct ieee80211_channel *chan)
+{
+#ifdef CPTCFG_CFG80211_REG_SOFT_CONFIGURATIONS
+ struct wireless_dev *wdev_iter;
+
+ ASSERT_RTNL();
+
+ if (!(chan->flags & (IEEE80211_CHAN_INDOOR_ONLY |
+ IEEE80211_CHAN_GO_CONCURRENT)))
+ return false;
+
+ if (chan->band == IEEE80211_BAND_60GHZ)
+ return false;
+
+ list_for_each_entry(wdev_iter, &rdev->wdev_list, list) {
+ struct ieee80211_channel *other_chan = NULL;
+
+ if (wdev_iter->iftype != NL80211_IFTYPE_STATION ||
+ (!netif_running(wdev_iter->netdev)))
+ continue;
+
+
+ wdev_lock(wdev_iter);
+ if (wdev_iter->current_bss)
+ other_chan = wdev_iter->current_bss->pub.channel;
+ wdev_unlock(wdev_iter);
+
+ if (!other_chan)
+ continue;
+
+ if (chan == other_chan)
+ return true;
+ else if ((chan->band == IEEE80211_BAND_5GHZ) &&
+ (cfg80211_get_unii_band(chan->center_freq) ==
+ cfg80211_get_unii_band(other_chan->center_freq)))
+ return true;
+ }
+#endif
+ return false;
+}
+
bool cfg80211_reg_can_beacon(struct wiphy *wiphy,
- struct cfg80211_chan_def *chandef)
+ struct cfg80211_chan_def *chandef,
+ bool p2p_go)
{
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
bool res;
+ u32 flags;
- trace_cfg80211_reg_can_beacon(wiphy, chandef);
+ trace_cfg80211_reg_can_beacon(wiphy, chandef, p2p_go);
+
+ flags = IEEE80211_CHAN_DISABLED | IEEE80211_CHAN_RADAR;
+
+ /* Under certain conditions a GO can operate on channels marked
+ * with IEEE80211_CHAN_PASSIVE_SCAN and IEEE80211_CHAN_NO_IBSS, so set
+ * these flags only if the conditions are not met.
+ */
+ if (!p2p_go || !cfg80211_can_go_use_chan(rdev, chandef->chan))
+ flags |= IEEE80211_CHAN_PASSIVE_SCAN | IEEE80211_CHAN_NO_IBSS;
- res = cfg80211_chandef_usable(wiphy, chandef,
- IEEE80211_CHAN_DISABLED |
- IEEE80211_CHAN_PASSIVE_SCAN |
- IEEE80211_CHAN_NO_IBSS |
- IEEE80211_CHAN_RADAR);
+ res = cfg80211_chandef_usable(wiphy, chandef, flags);
trace_cfg80211_return_bool(res);
return res;
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index 30c4920..746c8b4 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -172,7 +172,7 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
setup->basic_rates = ieee80211_mandatory_rates(sband);
}
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef))
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef, false))
return -EINVAL;
err = cfg80211_can_use_chan(rdev, wdev, setup->chandef.chan,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index cf22b22..204c160 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1801,7 +1801,8 @@ static int __nl80211_set_channel(struct cfg80211_registered_device *rdev,
result = -EBUSY;
break;
}
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef)) {
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, &chandef,
+ iftype == NL80211_IFTYPE_P2P_GO)) {
result = -EINVAL;
break;
}
@@ -3150,7 +3151,8 @@ static int nl80211_start_ap(struct sk_buff *skb, struct genl_info *info)
} else if (!nl80211_get_ap_channel(rdev, ¶ms))
return -EINVAL;
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef))
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, ¶ms.chandef,
+ wdev->iftype == NL80211_IFTYPE_P2P_GO))
return -EINVAL;
err = cfg80211_chandef_dfs_required(wdev->wiphy, ¶ms.chandef);
@@ -6319,7 +6321,7 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
if (err)
return err;
- if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef))
+ if (!cfg80211_reg_can_beacon(&rdev->wiphy, &ibss.chandef, false))
return -EINVAL;
switch (ibss.chandef.width) {
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index e1534baf..7be32c3 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -2115,18 +2115,21 @@ TRACE_EVENT(cfg80211_cqm_rssi_notify,
);
TRACE_EVENT(cfg80211_reg_can_beacon,
- TP_PROTO(struct wiphy *wiphy, struct cfg80211_chan_def *chandef),
- TP_ARGS(wiphy, chandef),
+ TP_PROTO(struct wiphy *wiphy, struct cfg80211_chan_def *chandef,
+ bool p2p_go),
+ TP_ARGS(wiphy, chandef, p2p_go),
TP_STRUCT__entry(
WIPHY_ENTRY
CHAN_DEF_ENTRY
+ __field(bool, p2p_go)
),
TP_fast_assign(
WIPHY_ASSIGN;
CHAN_DEF_ASSIGN(chandef);
+ __entry->p2p_go = p2p_go;
),
- TP_printk(WIPHY_PR_FMT ", " CHAN_DEF_PR_FMT,
- WIPHY_PR_ARG, CHAN_DEF_PR_ARG)
+ TP_printk(WIPHY_PR_FMT ", " CHAN_DEF_PR_FMT ", p2p_go=%d",
+ WIPHY_PR_ARG, CHAN_DEF_PR_ARG, __entry->p2p_go)
);
TRACE_EVENT(cfg80211_chandef_dfs_required,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] [RFC] cfg80211: Add Kconfig option for cellular BS hints
From: Ilan Peer @ 2013-07-02 12:28 UTC (permalink / raw)
To: linux-wireless; +Cc: mcgrof, Ilan Peer
In-Reply-To: <1372768095-26053-1-git-send-email-ilan.peer@intel.com>
Move the regulatory cellular base station hints support under
a specific configuration option and make the option depend
on CFG80211_CERTIFICATION_ONUS.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
---
net/wireless/Kconfig | 7 +++++++
net/wireless/reg.c | 2 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/wireless/Kconfig b/net/wireless/Kconfig
index 16d08b3..de76078 100644
--- a/net/wireless/Kconfig
+++ b/net/wireless/Kconfig
@@ -95,6 +95,13 @@ config CFG80211_CERTIFICATION_ONUS
you are a wireless researcher and are working in a controlled
and approved environment by your local regulatory agency.
+config CFG80211_REG_CELLULAR_HINTS
+ bool "cfg80211 regulatory support for cellular base station hints"
+ depends on CFG80211 && CFG80211_CERTIFICATION_ONUS
+ ---help---
+ This option adds support for drivers that can receive regulatory
+ hints from cellular base stations
+
config CFG80211_DEFAULT_PS
bool "enable powersave by default"
depends on CFG80211
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 5a24c98..2459a69 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -928,7 +928,7 @@ bool reg_last_request_cell_base(void)
return reg_request_cell_base(get_last_request());
}
-#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+#ifdef CONFIG_CFG80211_REG_CELLULAR_HINTS
/* Core specific check */
static enum reg_request_treatment
reg_ignore_cell_hint(struct regulatory_request *pending_request)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 1/3] [RFC] cfg80211: Add indoor only and GO concurrent channel attributes
From: Ilan Peer @ 2013-07-02 12:28 UTC (permalink / raw)
To: linux-wireless; +Cc: mcgrof, David Spinadel, Ilan Peer
In-Reply-To: <1372768095-26053-1-git-send-email-ilan.peer@intel.com>
From: David Spinadel <david.spinadel@intel.com>
The FCC are clarifying some soft configuration requirements,
which among other includes the following:
1. Concurrent GO operation, where devices may support WFD in
bands where an authorized master (for example with DFS and
DFS and radar detection capability in the UNII band) is operating.
2. Indoor operation, where in bands requiring indoor operation, the
device must be programmed to detect indoor operation, or
- Device must be connected to AC Power
- Device must be under the control of a local master that is acting
as an AP and is connected to AC Power.
See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
Add support for advertising Indoor-only and Concurrent-GO channel
properties.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
---
include/net/cfg80211.h | 6 ++++++
include/uapi/linux/nl80211.h | 7 +++++++
net/wireless/nl80211.c | 6 ++++++
3 files changed, 19 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7b0730a..f0badeb 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -110,6 +110,10 @@ enum ieee80211_band {
* channel as the control or any of the secondary channels.
* This may be due to the driver or due to regulatory bandwidth
* restrictions.
+ * @IEEE80211_CHAN_INDOOR_ONLY: Only indoor use is permitted on this channel.
+ * @IEEE80211_CHAN_GO_CONCURRENT: GO operation is allowed on this channel if
+ * it's connected concurrently to a BSS on the same channel on 2.4 or
+ * to a channel in the same UNII band on 5.2.
*/
enum ieee80211_channel_flags {
IEEE80211_CHAN_DISABLED = 1<<0,
@@ -121,6 +125,8 @@ enum ieee80211_channel_flags {
IEEE80211_CHAN_NO_OFDM = 1<<6,
IEEE80211_CHAN_NO_80MHZ = 1<<7,
IEEE80211_CHAN_NO_160MHZ = 1<<8,
+ IEEE80211_CHAN_INDOOR_ONLY = 1<<9,
+ IEEE80211_CHAN_GO_CONCURRENT = 1<<10,
};
#define IEEE80211_CHAN_NO_HT40 \
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 861e5eb..09a4f6b 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2158,6 +2158,11 @@ enum nl80211_band_attr {
* @NL80211_FREQUENCY_ATTR_NO_160MHZ: any 160 MHz (but not 80+80) channel
* using this channel as the primary or any of the secondary channels
* isn't possible
+ * @NL80211_FREQUENCY_ATTR_INDOOR_ONLY: Indoor only use is permitted
+ * on this channel in current regulatory domain.
+ * @NL80211_FREQUENCY_ATTR_GO_CONCURRENT: GO operation is allowed on this
+ * channel if it's connected concurrently to a BSS on the same channel on
+ * 2.4 or to a channel in the same UNII band on 5.2.
* @NL80211_FREQUENCY_ATTR_MAX: highest frequency attribute number
* currently defined
* @__NL80211_FREQUENCY_ATTR_AFTER_LAST: internal use
@@ -2176,6 +2181,8 @@ enum nl80211_frequency_attr {
NL80211_FREQUENCY_ATTR_NO_HT40_PLUS,
NL80211_FREQUENCY_ATTR_NO_80MHZ,
NL80211_FREQUENCY_ATTR_NO_160MHZ,
+ NL80211_FREQUENCY_ATTR_INDOOR_ONLY,
+ NL80211_FREQUENCY_ATTR_GO_CONCURRENT,
/* keep last */
__NL80211_FREQUENCY_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7dc3343..cf22b22 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -563,6 +563,12 @@ static int nl80211_msg_put_channel(struct sk_buff *msg,
if ((chan->flags & IEEE80211_CHAN_NO_160MHZ) &&
nla_put_flag(msg, NL80211_FREQUENCY_ATTR_NO_160MHZ))
goto nla_put_failure;
+ if ((chan->flags & IEEE80211_CHAN_INDOOR_ONLY) &&
+ nla_put_flag(msg, NL80211_FREQUENCY_ATTR_INDOOR_ONLY))
+ goto nla_put_failure;
+ if ((chan->flags & IEEE80211_CHAN_GO_CONCURRENT) &&
+ nla_put_flag(msg, NL80211_FREQUENCY_ATTR_GO_CONCURRENT))
+ goto nla_put_failure;
}
if (nla_put_u32(msg, NL80211_FREQUENCY_ATTR_MAX_TX_POWER,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 0/3] Enable additional channels for GO
From: Ilan Peer @ 2013-07-02 12:28 UTC (permalink / raw)
To: linux-wireless; +Cc: mcgrof, Ilan Peer
The FCC are clarifying some soft configuration requirements,
which among other includes the following:
1. Concurrent GO operation, where devices may support WFD in
bands where an authorized master (for example with DFS and
DFS and radar detection capability in the UNII band) is operating.
2. Indoor operation, where in bands requiring indoor operation, the
device must be programmed to detect indoor operation, or
- Device must be connected to AC Power
- Device must be under the control of a local master that is acting
as an AP and is connected to AC Power.
See https://apps.fcc.gov/eas/comments/GetPublishedDocument.html?id=327&tn=528122
David Spinadel (2):
[RFC] cfg80211: Add indoor only and GO concurrent channel attributes
[RFC] cfg80211: Enable GO operation on additional channels
Ilan Peer (1):
[RFC] cfg80211: Add Kconfig option for cellular BS hints
include/net/cfg80211.h | 10 ++++-
include/uapi/linux/nl80211.h | 7 +++
net/mac80211/ibss.c | 2 +-
net/wireless/Kconfig | 17 ++++++++
net/wireless/chan.c | 98 +++++++++++++++++++++++++++++++++++++++---
net/wireless/mesh.c | 2 +-
net/wireless/nl80211.c | 14 ++++--
net/wireless/reg.c | 2 +-
net/wireless/trace.h | 11 +++--
9 files changed, 145 insertions(+), 18 deletions(-)
--
1.7.10.4
^ permalink raw reply
* RE: [RFC v2] mac80211: Use libnl-configurable values for retry counts
From: Jean-Pierre Tosoni @ 2013-07-02 13:28 UTC (permalink / raw)
To: 'Felix Fietkau'; +Cc: linux-wireless
In-Reply-To: <51CF3EC9.3000707@openwrt.org>
Hi Felix,
> -----Message d'origine-----
> De : Felix Fietkau [mailto:nbd@openwrt.org]
> > ---
> > What I am seeking with this patch:
> > I believe the configuration of the retries will help making recovery
> > much faster when an AP (in infrastructure mode) or a peer (in mesh
> > mode) suddenly disappears.
> I'm all for reducing retries, but I think the way you're applying the
> limit is problematic.
> If minstrel decides to use many retries for a high rate and you're
> simply cutting off all retries that exceed the configured limit, you're
> potentially inviting quite a bit of unnecessary packet loss.
> I'm planning to remove the use of retry rate slot 4 (fallback to lowest
> rate) from minstrel, since max_prob_rate should already provide quite
> decent reliability.
Well, on one hand, people who want to reduce retries are more concerned with
low latency and jitter than with reliable delivery of data.
On another hand the code should work for any rate control plugin, not just
minstrel.
Finally this code is executed for each frame, and I don’t want to bloat it
more than necessary...
I am thinking of trimming only the largest retry count in the table, but not
below 2 (one try and one retry). I'll test this today.
Do you feel this is a good path ?
Or should I just wait for the slot 4 removal ?
I could also split the trimming between 2 rates, the largest count and the
next-to-largest. Or I could use a minimum of 1 instead of 2.
>
> - Felix
Jean-Pierre
^ permalink raw reply
* Re: [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Neil Horman @ 2013-07-02 12:37 UTC (permalink / raw)
To: Arend van Spriel
Cc: Larry Finger, linville, linux-wireless, netdev, Stable,
Brett Rudley, Franky (Zhenhui) Lin, Hante Meuleman,
brcm80211-dev-list
In-Reply-To: <51D29391.4080000@broadcom.com>
On Tue, Jul 02, 2013 at 10:47:13AM +0200, Arend van Spriel wrote:
> On 07/01/2013 11:08 PM, Larry Finger wrote:
> >The driver fails to check the results of DMA mapping in twp places, which results
> >in the following warning:
> >
> >[ 28.078515] ------------[ cut here ]------------
> >[ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
> >[ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
> > single]
> >[ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
> >11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
> > cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
> >6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
> >[ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
> >[ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
> >[ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
> >[ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
> >[ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
> >[ 28.078622] Call Trace:
> >[ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
> >[ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
> >[ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
> >[ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
> >[ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
> >[ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
> >[ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
> >[ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
> >[ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
> >[ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
> >[ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
> >--snip--
> >[ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
> >[ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
> >[ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
> >[ 28.078984] Mapped at:
> >[ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
> >[ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
> >[ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
> >[ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
> >[ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
> >
> >As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
> >comment at the start of the routine to add that information, I also polished
> >the wording.
>
> Thanks, Larry
>
> I think there a bugzilla issue for this that you might want to reference:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=60261
>
Thanks Larry, you beat me too it, feel free to reassign the bz to yourself. :)
> >Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> >Cc: Stable <stable@vger.kernel.org>
> >Cc: Brett Rudley <brudley@broadcom.com>
> >Cc: Arend van Spriel <arend@broadcom.com>
> >Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> >Cc: Hante Meuleman <meuleman@broadcom.com>
> >Cc: brcm80211-dev-list@broadcom.com
> >---
> >
> > drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> >index 1860c57..6260571 100644
> >--- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> >+++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> >@@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
> >
> > /*
> > * post receive buffers
> >- * return false is refill failed completely and ring is empty this will stall
> >- * the rx dma and user might want to call rxfill again asap. This unlikely
> >- * happens on memory-rich NIC, but often on memory-constrained dongle
> >+ * return false is refill failed completely or dma mapping failed. The ring
>
> Missed some polishing opportunity: return false is refill... ->
> return false if refill...
>
> >+ * is empty, which will stall the rx dma and user might want to call rxfill
> >+ * again asap. This is unlikely to happen on a memory-rich NIC, but often on
> >+ * memory-constrained dongle
> > */
> > bool dma_rxfill(struct dma_pub *pub)
> > {
> >@@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
> >
> > pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
> > DMA_FROM_DEVICE);
> >+ if (dma_mapping_error(di->dmadev,pa))
> >+ return false;
Hmm, wouldn't it be better to set ring_empty to false and break out of the for
loop here, in the event that you partially refilled the ring? Otherwise, a
single dma mapping failure would let some useable descriptors go unused.
Neil
^ permalink raw reply
* Re: Fw: Intel 6330 N
From: Sedat Dilek @ 2013-07-02 12:16 UTC (permalink / raw)
To: Matt Allen; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1372767087.74391.YahooMailNeo@web161902.mail.bf1.yahoo.com>
On Tue, Jul 2, 2013 at 2:11 PM, Matt Allen <allencon19@yahoo.com> wrote:
>
>
>
>
> To Whom it may concern,
>
> I am having trouble getting my Intel 6330 wireless card to work on N. How long am I going to have to wait, until I am able to use N on my Intel 6330 wireless card? I have seen a lot of ways to disable it. I have found another Intel wireless card below this one that has N speed in linux, but I do not want to spend about money on a card that is not Linux compatable. Is there a current driver that I could download that works on Debian Jessie? Thank you for your time and assistance.
>
"$myDevice does not work is not a bug-report."
Please, attach some more informations like kernel-release, dmesg and
lspci/lsusb and interested people can look at this.
Might be good to CC ilw ML, too.
Also, take a look at docs websites on <http://wireless.kernel.org/>.
- Sedat -
> Matt Allen
> --
> 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
^ permalink raw reply
* Fw: Intel 6330 N
From: Matt Allen @ 2013-07-02 12:11 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1372731231.96036.YahooMailNeo@web161905.mail.bf1.yahoo.com>
To Whom it may concern,
I am having trouble getting my Intel 6330 wireless card to work on N. How long am I going to have to wait, until I am able to use N on my Intel 6330 wireless card? I have seen a lot of ways to disable it. I have found another Intel wireless card below this one that has N speed in linux, but I do not want to spend about money on a card that is not Linux compatable. Is there a current driver that I could download that works on Debian Jessie? Thank you for your time and assistance.
Matt Allen
^ permalink raw reply
* Re: [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Arend van Spriel @ 2013-07-02 8:47 UTC (permalink / raw)
To: Larry Finger
Cc: linville, linux-wireless, netdev, Stable, Brett Rudley,
Franky (Zhenhui) Lin, Hante Meuleman, brcm80211-dev-list,
Neil Horman
In-Reply-To: <1372712883-4464-1-git-send-email-Larry.Finger@lwfinger.net>
On 07/01/2013 11:08 PM, Larry Finger wrote:
> The driver fails to check the results of DMA mapping in twp places, which results
> in the following warning:
>
> [ 28.078515] ------------[ cut here ]------------
> [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
> [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
> single]
> [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
> 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
> cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
> 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
> [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
> [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
> [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
> [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
> [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
> [ 28.078622] Call Trace:
> [ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
> [ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
> [ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
> [ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
> [ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
> [ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
> [ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
> [ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
> [ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
> [ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
> [ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
> --snip--
> [ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
> [ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
> [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
> [ 28.078984] Mapped at:
> [ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
> [ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
> [ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
> [ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
> [ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
>
> As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
> comment at the start of the routine to add that information, I also polished
> the wording.
Thanks, Larry
I think there a bugzilla issue for this that you might want to reference:
https://bugzilla.kernel.org/show_bug.cgi?id=60261
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: brcm80211-dev-list@broadcom.com
> ---
>
> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> index 1860c57..6260571 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> @@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
>
> /*
> * post receive buffers
> - * return false is refill failed completely and ring is empty this will stall
> - * the rx dma and user might want to call rxfill again asap. This unlikely
> - * happens on memory-rich NIC, but often on memory-constrained dongle
> + * return false is refill failed completely or dma mapping failed. The ring
Missed some polishing opportunity: return false is refill... -> return
false if refill...
> + * is empty, which will stall the rx dma and user might want to call rxfill
> + * again asap. This is unlikely to happen on a memory-rich NIC, but often on
> + * memory-constrained dongle
> */
> bool dma_rxfill(struct dma_pub *pub)
> {
> @@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
>
> pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
> DMA_FROM_DEVICE);
> + if (dma_mapping_error(di->dmadev,pa))
> + return false;
>
> /* save the free packet pointer */
> di->rxp[rxout] = p;
> @@ -1284,7 +1287,8 @@ static void dma_txenq(struct dma_info *di, struct sk_buff *p)
>
> /* get physical address of buffer start */
> pa = dma_map_single(di->dmadev, data, len, DMA_TO_DEVICE);
> -
> + if(dma_mapping_error(di->dmadev, pa))
> + return;
I think the caller(s) should be informed or silently free the sk_buff
here so we are not leaking it.
> /* With a DMA segment list, Descriptor table is filled
> * using the segment list instead of looping over
> * buffers in multi-chain DMA. Therefore, EOF for SGLIST
>
Regards,
Arend
^ permalink raw reply
* Re: Fwd: User-level question: on wil6210
From: Vladimir Kondratiev @ 2013-07-02 6:42 UTC (permalink / raw)
To: John W. Linville
Cc: Chang Liu, Sujith Manoharan, erez.kirshenbaum, linux-wireless
In-Reply-To: <20130701160759.GA20999@tuxdriver.com>
On Monday, July 01, 2013 12:07:59 PM John W. Linville wrote:
> Chang,
>
> It looks to me like you should be using the ath9k driver. What makes
> you think that you have a wil6210?
>
> In any case, I've Cc'ed Vladimir and Sujith -- hopefully one of them
> can be more helpful. :-)
>
> John
John,
Thanks for forwarding. Indeed, it is for me.
>
> On Sat, Jun 29, 2013 at 10:41:20AM +0200, Chang Liu wrote:
> > Dear John,
> >
> > My name is Chang, currently a student. I have a problem when I try to use
> > wil6210 as driver. Sorry to bother you with this letter here. I read the
> > notice on wireless.kernel.org and asked the same question on IRC but got no
> > reply. I subscribed the mailing list and I know you are respected in this
> > field. So I am here for help. I hope this doesn't bother you much.
> >
> > The thing is: I have a laptop Dell 6430u, which has wil6210 inside. I
> > downloaded the driver "compat driver-3.8.3-2-snp" and later run *make
> > install* and *modprobe wil6210*. No error returned. When I check iw
> > --version, it shows iw version 3.2.
> >
> > Now I want to check whether or not I have installed the driver correctly
> > and whether it works. I have no docking station (the access point) at hand
> > right now. First I run* lspci -nn*, which returns:
> >
<skip>
> > 02:00.0 PCI bridge [0604]: Device [1ae9:0101] (rev 03)
> > 03:00.0 PCI bridge [0604]: Device [1ae9:0200] (rev 03)
> > 03:02.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> > 03:03.0 PCI bridge [0604]: Device [1ae9:0201] (rev 13)
> > 04:00.0 Network controller [0280]: Atheros Communications Inc. AR9462
> > Wireless Network Adapter [168c:0034] (rev 01)
Yes, these 5 devices above are from wil6210, so you definetely have wil6210
card on your laptop.
This card is composite device. For details, see wiki
http://wireless.kernel.org/en/users/Drivers/wil6210
On this card, there is firmware that is stored in the on-card flash memory, and
is not loaded by the driver. Unfortunately, firmware on your laptop (and all
laptops like this) flashed with device 1ae9:0301 disabled. This firmware support
only so called WBE, that is essentially PCIE over 60g, for wireless docking.
Wireless docking stations that are used with WBE are NOT access points; as far as I
know there is no 60g access points available at this moment. You can run AP on another
Linux laptop with wil6210.
In order to support wifi, appropriate firmware need to be flashed on this card,
and then you will see wi-fi device 1ae9:0301.
To flash firmware, you need to contact Wilocity (adding Erez).
> >
> > Now comes the question:
> > 1. I saw on the website that the device 6210 should be "wil6210 device,
> > 1ae9:0301" (from linux wireless wil6210 page
> > http://wireless.kernel.org/en/users/Drivers/wil6210), which I cannot see
> > now. How should I find where the device is?
> >
> > 2. About the driver, I have no idea how to check whether it works.
> >
> > I use Ubuntu 12.04.2 LTS, and uname -a give information as follows:
> > Linux george-Latitude-6430U 3.5.0-23-generic #35~precise1-Ubuntu SMP Fri
> > Jan 25 17:13:26 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
You better use latest kernels since support for 60g band was integrated to versions
3.7 (some initial bits) to 3.10; and even some more patches are in the pipe for
inclusion in next versions.
> >
<skip
> >
> >
> > I am not familiar with linux, please help me with this. My id on the IRC
> > channel #linux-wireless is george_.I have tried google but not much
> > found. I really hope you could help me with this. Thank you in advance!
In general, 60g technology is in very early stages; wil6210 is 1-st commercially
available device. For now, I'd say it is better to have good knowledge in Linux
and wireless to experiment with this matter. You will also need to compile latest
wpa_supplicant and iw from git, released with Ubuntu 12.10 versions are not
good for 60g.
> >
> > Best regards!
> > Chang
Thanks, Vladimir
^ permalink raw reply
* RE: [PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
From: Bing Zhao @ 2013-07-02 5:33 UTC (permalink / raw)
To: Harvey Yang, linux-wireless@vger.kernel.org; +Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1372731526-2979-1-git-send-email-harvey.huawei.yang@gmail.com>
Hi Harvey,
> From: Huawei Yang <harvey.huawei.yang@gmail.com>
>
> In function 'mwifiex_write_data_complete' it need tx info to find the
> mwifiex_private to updates statistics and wake up tx queues.
> Or we may trigger tx queues timeout when transmitting lots of mgmt frames.
>
> Signed-off-by: Huawei Yang <harvey.huawei.yang@gmail.com>
> ---
> drivers/net/wireless/mwifiex/cfg80211.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/wireless/mwifiex/cfg80211.c
> b/drivers/net/wireless/mwifiex/cfg80211.c
> index e42b266..b4e2538 100644
> --- a/drivers/net/wireless/mwifiex/cfg80211.c
> +++ b/drivers/net/wireless/mwifiex/cfg80211.c
> @@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> struct sk_buff *skb;
> u16 pkt_len;
> const struct ieee80211_mgmt *mgmt;
> + struct mwifiex_txinfo *tx_info;
> struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev-
> >netdev);
>
> if (!buf || !len) {
> @@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy,
> struct wireless_dev *wdev,
> wiphy_err(wiphy, "allocate skb failed for management
> frame\n");
> return -ENOMEM;
> }
> +
Here checkpatch.pl script reports whitespace damaged error.
I can fix it in my local tree and resend v3 to John after the 3.11 merge window.
Thanks,
Bing
> + tx_info = MWIFIEX_SKB_TXCB(skb);
> + tx_info->bss_num = priv->bss_num;
> + tx_info->bss_type = priv->bss_type;
>
> mwifiex_form_mgmt_frame(skb, buf, len);
> mwifiex_queue_tx_pkt(priv, skb);
> --
> 1.7.10.4
^ permalink raw reply
* Re: [PATCH] iwlwifi: add firmware for 7260 / 3160 devices
From: Emmanuel Grumbach @ 2013-07-02 5:03 UTC (permalink / raw)
To: Emmanuel Grumbach
Cc: Ben Hutchings, linux-wireless, Bjorn Mork, Johannes Berg
In-Reply-To: <1372075552-3253-1-git-send-email-emmanuel.grumbach@intel.com>
On Mon, Jun 24, 2013 at 3:05 PM, Emmanuel Grumbach
<emmanuel.grumbach@intel.com> wrote:
> Add new firmware for new devices: 7260 and 3160
> version:
> 22.0.7.0
>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> ---
> LICENCE.iwlwifi_firmware | 2 +-
> WHENCE | 6 ++++++
> iwlwifi-3160-7.ucode | Bin 0 -> 670172 bytes
> iwlwifi-7260-7.ucode | Bin 0 -> 682892 bytes
> 4 files changed, 7 insertions(+), 1 deletion(-)
> create mode 100644 iwlwifi-3160-7.ucode
> create mode 100644 iwlwifi-7260-7.ucode
>
ping? :)
^ permalink raw reply
* [PATCH V2 1/1] mwifiex: add tx info to skb when forming mgmt frame
From: Harvey Yang @ 2013-07-02 2:18 UTC (permalink / raw)
To: Bing Zhao, linux-wireless; +Cc: linux-kernel, Huawei Yang
From: Huawei Yang <harvey.huawei.yang@gmail.com>
In function 'mwifiex_write_data_complete' it need tx info to find
the mwifiex_private to updates statistics and wake up tx queues.
Or we may trigger tx queues timeout when transmitting lots of mgmt
frames.
Signed-off-by: Huawei Yang <harvey.huawei.yang@gmail.com>
---
drivers/net/wireless/mwifiex/cfg80211.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/mwifiex/cfg80211.c b/drivers/net/wireless/mwifiex/cfg80211.c
index e42b266..b4e2538 100644
--- a/drivers/net/wireless/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/mwifiex/cfg80211.c
@@ -186,6 +186,7 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
struct sk_buff *skb;
u16 pkt_len;
const struct ieee80211_mgmt *mgmt;
+ struct mwifiex_txinfo *tx_info;
struct mwifiex_private *priv = mwifiex_netdev_get_priv(wdev->netdev);
if (!buf || !len) {
@@ -212,6 +213,10 @@ mwifiex_cfg80211_mgmt_tx(struct wiphy *wiphy, struct wireless_dev *wdev,
wiphy_err(wiphy, "allocate skb failed for management frame\n");
return -ENOMEM;
}
+
+ tx_info = MWIFIEX_SKB_TXCB(skb);
+ tx_info->bss_num = priv->bss_num;
+ tx_info->bss_type = priv->bss_type;
mwifiex_form_mgmt_frame(skb, buf, len);
mwifiex_queue_tx_pkt(priv, skb);
--
1.7.10.4
^ permalink raw reply related
* Re: backports based on next-20130618
From: Luis R. Rodriguez @ 2013-07-01 21:39 UTC (permalink / raw)
To: backports@vger.kernel.org; +Cc: netdev@vger.kernel.org, linux-wireless
In-Reply-To: <CAB=NE6W6oa1Oa9O_s7B_4qKHdEz6S3DhVyvtpzP78XqRM_xk8A@mail.gmail.com>
On Mon, Jul 1, 2013 at 2:25 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> A new backports release has been made based on next-20130618, this has
> the new upstream alx driver, and the ath10k driver.
>
> https://www.kernel.org/pub/linux/kernel/projects/backports/2013/06/18/backports-20130618.tar.bz2
Sorry it just has alx, ath10k requires a small patch that I think
someone has sitting somewhere, next release.
Luis
^ permalink raw reply
* backports based on next-20130618
From: Luis R. Rodriguez @ 2013-07-01 21:25 UTC (permalink / raw)
To: backports@vger.kernel.org; +Cc: netdev@vger.kernel.org, linux-wireless
A new backports release has been made based on next-20130618, this has
the new upstream alx driver, and the ath10k driver.
https://www.kernel.org/pub/linux/kernel/projects/backports/2013/06/18/backports-20130618.tar.bz2
Luis
^ permalink raw reply
* Re: [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Hauke Mehrtens @ 2013-07-01 21:12 UTC (permalink / raw)
To: Larry Finger
Cc: linville, linux-wireless, netdev, Stable, Brett Rudley,
Arend van Spriel, Franky (Zhenhui) Lin, Hante Meuleman,
brcm80211-dev-list
In-Reply-To: <1372712883-4464-1-git-send-email-Larry.Finger@lwfinger.net>
On 07/01/2013 11:08 PM, Larry Finger wrote:
> The driver fails to check the results of DMA mapping in twp places, which results
> in the following warning:
>
> [ 28.078515] ------------[ cut here ]------------
> [ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
> [ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
> single]
> [ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
> 11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
> cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
> 6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
> [ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
> [ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
> [ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
> [ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
> [ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
> [ 28.078622] Call Trace:
> [ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
> [ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
> [ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
> [ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
> [ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
> [ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
> [ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
> [ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
> [ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
> [ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
> [ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
> --snip--
> [ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
> [ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
> [ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
> [ 28.078984] Mapped at:
> [ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
> [ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
> [ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
> [ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
> [ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
>
> As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
> comment at the start of the routine to add that information, I also polished
> the wording.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org>
> Cc: Brett Rudley <brudley@broadcom.com>
> Cc: Arend van Spriel <arend@broadcom.com>
> Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
> Cc: Hante Meuleman <meuleman@broadcom.com>
> Cc: brcm80211-dev-list@broadcom.com
> ---
>
> drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> index 1860c57..6260571 100644
> --- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> +++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
> @@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
>
> /*
> * post receive buffers
> - * return false is refill failed completely and ring is empty this will stall
> - * the rx dma and user might want to call rxfill again asap. This unlikely
> - * happens on memory-rich NIC, but often on memory-constrained dongle
> + * return false is refill failed completely or dma mapping failed. The ring
> + * is empty, which will stall the rx dma and user might want to call rxfill
> + * again asap. This is unlikely to happen on a memory-rich NIC, but often on
> + * memory-constrained dongle
> */
> bool dma_rxfill(struct dma_pub *pub)
> {
> @@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
>
> pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
> DMA_FROM_DEVICE);
> + if (dma_mapping_error(di->dmadev,pa))
^^
missing space
> + return false;
>
> /* save the free packet pointer */
> di->rxp[rxout] = p;
> @@ -1284,7 +1287,8 @@ static void dma_txenq(struct dma_info *di, struct sk_buff *p)
>
> /* get physical address of buffer start */
> pa = dma_map_single(di->dmadev, data, len, DMA_TO_DEVICE);
> -
> + if(dma_mapping_error(di->dmadev, pa))
^^
missing space
> + return;
> /* With a DMA segment list, Descriptor table is filled
> * using the segment list instead of looping over
> * buffers in multi-chain DMA. Therefore, EOF for SGLIST
>
^ permalink raw reply
* [PATCH] brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()
From: Larry Finger @ 2013-07-01 21:08 UTC (permalink / raw)
To: linville
Cc: linux-wireless, Larry Finger, netdev, Stable, Brett Rudley,
Arend van Spriel, Franky (Zhenhui) Lin, Hante Meuleman,
brcm80211-dev-list
The driver fails to check the results of DMA mapping in twp places, which results
in the following warning:
[ 28.078515] ------------[ cut here ]------------
[ 28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
[ 28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
single]
[ 28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
[ 28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G O 3.10.0-rc7-wl+ #42
[ 28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
[ 28.078607] 0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
[ 28.078612] ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
[ 28.078617] ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
[ 28.078622] Call Trace:
[ 28.078624] <IRQ> [<ffffffff8144f898>] dump_stack+0x19/0x1b
[ 28.078634] [<ffffffff8103e1eb>] warn_slowpath_common+0x6b/0xa0
[ 28.078638] [<ffffffff8103e2c1>] warn_slowpath_fmt+0x41/0x50
[ 28.078650] [<ffffffff8122d7ae>] check_unmap+0x47e/0x930
[ 28.078655] [<ffffffff8122de4c>] debug_dma_unmap_page+0x5c/0x70
[ 28.078679] [<ffffffffa04a808c>] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
[ 28.078691] [<ffffffffa04a9042>] dma_rx+0x62/0x240 [brcmsmac]
[ 28.078707] [<ffffffffa0479101>] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
[ 28.078717] [<ffffffffa046d927>] ? brcms_dpc+0x27/0xf0 [brcmsmac]
[ 28.078731] [<ffffffffa046d947>] brcms_dpc+0x47/0xf0 [brcmsmac]
[ 28.078736] [<ffffffff81047dcc>] tasklet_action+0x6c/0xf0
--snip--
[ 28.078974] [<ffffffff813891bd>] SyS_sendmsg+0xd/0x20
[ 28.078979] [<ffffffff81455c24>] tracesys+0xdd/0xe2
[ 28.078982] ---[ end trace 6164d1a08148e9c8 ]---
[ 28.078984] Mapped at:
[ 28.078985] [<ffffffff8122c8fd>] debug_dma_map_page+0x9d/0x150
[ 28.078989] [<ffffffffa04a9322>] dma_rxfill+0x102/0x3d0 [brcmsmac]
[ 28.079001] [<ffffffffa047a13d>] brcms_c_init+0x87d/0x1100 [brcmsmac]
[ 28.079010] [<ffffffffa046d851>] brcms_init+0x21/0x30 [brcmsmac]
[ 28.079018] [<ffffffffa04786e0>] brcms_c_up+0x150/0x430 [brcmsmac]
As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
comment at the start of the routine to add that information, I also polished
the wording.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: brcm80211-dev-list@broadcom.com
---
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/dma.c b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
index 1860c57..6260571 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/dma.c
+++ b/drivers/net/wireless/brcm80211/brcmsmac/dma.c
@@ -1015,9 +1015,10 @@ static bool dma64_txidle(struct dma_info *di)
/*
* post receive buffers
- * return false is refill failed completely and ring is empty this will stall
- * the rx dma and user might want to call rxfill again asap. This unlikely
- * happens on memory-rich NIC, but often on memory-constrained dongle
+ * return false is refill failed completely or dma mapping failed. The ring
+ * is empty, which will stall the rx dma and user might want to call rxfill
+ * again asap. This is unlikely to happen on a memory-rich NIC, but often on
+ * memory-constrained dongle
*/
bool dma_rxfill(struct dma_pub *pub)
{
@@ -1078,6 +1079,8 @@ bool dma_rxfill(struct dma_pub *pub)
pa = dma_map_single(di->dmadev, p->data, di->rxbufsize,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(di->dmadev,pa))
+ return false;
/* save the free packet pointer */
di->rxp[rxout] = p;
@@ -1284,7 +1287,8 @@ static void dma_txenq(struct dma_info *di, struct sk_buff *p)
/* get physical address of buffer start */
pa = dma_map_single(di->dmadev, data, len, DMA_TO_DEVICE);
-
+ if(dma_mapping_error(di->dmadev, pa))
+ return;
/* With a DMA segment list, Descriptor table is filled
* using the segment list instead of looping over
* buffers in multi-chain DMA. Therefore, EOF for SGLIST
--
1.8.1.4
^ permalink raw reply related
* Re: [RFC] wlcore: sdio: add wilink clock providers
From: Luciano Coelho @ 2013-07-01 20:55 UTC (permalink / raw)
To: balbi
Cc: mturquette, mark.rutland, grant.likely, rob.herring,
devicetree-discuss, --linux-doc, linux-kernel, linux-omap,
linux-wireless, linux-arm-kernel
In-Reply-To: <20130701204633.GB805@arwen.pp.htv.fi>
On Mon, 2013-07-01 at 23:46 +0300, Felipe Balbi wrote:
> Hi,
>
> On Mon, Jul 01, 2013 at 10:34:10PM +0300, Luciano Coelho wrote:
> > diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > index 670c3ce..7f061b8 100644
> > --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> > +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> > @@ -65,11 +65,19 @@
> > enable-active-high;
> > };
> >
> > +
> > wlan {
> > - compatible = "ti,wilink6";
> > - interrupt-parent = <&gpio2>;
> > - interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > - refclock = <2>; /* 38.4 MHz */
> > + compatible = "ti,wilink6";
> > + interrupt-parent = <&gpio2>;
> > + interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > + clocks = <&refclock>;
> > + clock-names = "refclock";
>
> hmmm, shouldn't you provide both clocks (refclock and tcx0clock)
> explicitly here ?
No, not needed for Panda. Panda uses WiLink6 and only the refclock
needs to be provided.
> Also, you should probably make it clear that the WiLink module is fed by
> the 32K sync clock just to make sure clock usecounts are correctly
> incremented ?
Hmmm, yes, that is probably a good idea. At least to make sure
everything is initialized properly before the WiLink module is up and
running. I'll look into it and eventually add in a separate patch.
Thanks for your comments!
--
Luca.
^ permalink raw reply
* [PATCH 3/3] backports: add SPEED_UNKNOWN and DUPLEX_UNKNOWN
From: Luis R. Rodriguez @ 2013-07-01 20:55 UTC (permalink / raw)
To: backports; +Cc: linux-wireless, Luis R. Rodriguez
In-Reply-To: <1372712120-16606-1-git-send-email-mcgrof@do-not-panic.com>
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
This gets us in synch with next-20130618.
This was added via uapi/linux/ethtool.h but using
that file causes some odd issues I simply cannot
resolve right now. I stuff these definitions into
the regular include/linux/ethtool.h for now.
This backports commit 589665f5 added via v3.2.
mcgrof@frijol ~/linux-stable (git::master)$ git describe --contains \
589665f5a6008dbce1d0af2cb93e94a80bf78151
v3.2-rc1~4^2~10
commit 589665f5a6008dbce1d0af2cb93e94a80bf78151
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri Nov 4 08:21:38 2011 +0000
bonding: comparing a u8 with -1 is always false
slave->duplex is a u8 type so the in bond_info_show_slave() when we
check "if (slave->duplex == -1)", it's always false.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
1 2.6.24 [ OK ]
2 2.6.25 [ OK ]
3 2.6.26 [ OK ]
4 2.6.27 [ OK ]
5 2.6.28 [ OK ]
6 2.6.29 [ OK ]
7 2.6.30 [ OK ]
8 2.6.31 [ OK ]
9 2.6.32 [ OK ]
10 2.6.33 [ OK ]
11 2.6.34 [ OK ]
12 2.6.35 [ OK ]
13 2.6.36 [ OK ]
14 2.6.37 [ OK ]
15 2.6.38 [ OK ]
16 2.6.39 [ OK ]
17 3.0.79 [ OK ]
18 3.1.10 [ OK ]
19 3.10-rc1 [ OK ]
20 3.2.45 [ OK ]
21 3.3.8 [ OK ]
22 3.4.46 [ OK ]
23 3.5.7 [ OK ]
24 3.6.11 [ OK ]
25 3.7.10 [ OK ]
26 3.8.13 [ OK ]
27 3.9.3 [ OK ]
real 15m7.262s
user 335m33.818s
sys 82m36.486s
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
---
backport/backport-include/linux/ethtool.h | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/backport/backport-include/linux/ethtool.h b/backport/backport-include/linux/ethtool.h
index 0c1eee6..2f323b0 100644
--- a/backport/backport-include/linux/ethtool.h
+++ b/backport/backport-include/linux/ethtool.h
@@ -3,6 +3,14 @@
#include_next <linux/ethtool.h>
#include <linux/version.h>
+#ifndef SPEED_UNKNOWN
+#define SPEED_UNKNOWN -1
+#endif /* SPEED_UNKNOWN */
+
+#ifndef DUPLEX_UNKNOWN
+#define DUPLEX_UNKNOWN 0xff
+#endif /* DUPLEX_UNKNOWN */
+
#if LINUX_VERSION_CODE < KERNEL_VERSION(3,3,0)
#define ethtool_rxfh_indir_default LINUX_BACKPORT(ethtool_rxfh_indir_default)
static inline u32 ethtool_rxfh_indir_default(u32 index, u32 n_rx_rings)
--
1.7.10.4
^ 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