Re: [PATCH 0/5] wireless: ti: Convert specialized logging macros to kernel style

[Eliad Peller]

On Thu, Mar 31, 2016 at 11:07 AM, Joe Perches <j...@perches.com> wrote:
> On Thu, 2016-03-31 at 10:39 +0300, Kalle Valo wrote:
>> Joe Perches <j...@perches.com> writes:
>> > On Wed, 2016-03-30 at 14:51 +0300, Kalle Valo wrote:
>> > > Joe Perches <j...@perches.com> writes:
>> > > >
>> > > > Using the normal kernel logging mechanisms makes this code
>> > > > a bit more like other wireless drivers.
>> > > Personally I don't see the point but I don't have any strong opinions. A
>> > > bigger problem is that TI drivers are not really in active development
>> > > and that's I'm not thrilled to take big patches like this for dormant
>> > > drivers.
>> > Not very dormant.
>> >
>> > 35 patches in the last year, most of them adding functionality.
>> Oh, I didn't realise it had that many patches. But the driver is
>> orphaned and doesn't have a maintainer so could I then have an ack from
>> one of the active contributors that this ok?
>
> Fine by me.
>
> $ ./scripts/get_maintainer.pl -f --git drivers/net/wireless/ti/
>
> Kalle Valo <kv...@codeaurora.org> (maintainer:NETWORKING DRIVERS 
> (WIRELESS),commit_signer:27/35=77%)
> Eliad Peller <el...@wizery.com> (commit_signer:9/35=26%,authored:7/35=20%)
> Guy Mishol <g...@ti.com> (commit_signer:6/35=17%,authored:5/35=14%)
> Johannes Berg <johannes.b...@intel.com> 
> (commit_signer:6/35=17%,authored:3/35=9%)
> Uri Mashiach <uri.mashi...@compulab.co.il> 
> (commit_signer:4/35=11%,authored:4/35=11%)
>
> For those people now added to the cc list,
> here's the original patch thread:
>
> https://lkml.org/lkml/2016/3/7/1099

I don't have a strong opinion here either.
(I do like the trailing newline being added automatically, but that's
hardly an issue...)

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/2] wlcore/wl18xx: add radar_debug_mode handling

[Eliad Peller]

Add debugfs key (under CFG80211_CERTIFICATION_ONUS
configuration) to set/clear radar_debug_mode.
In this mode, the driver simply ignores radar
events (but prints them).

The fw is notified about this mode through
a special generic_cfg_feature command.

This mode is relevant only for ap mode. look for
it when initializing ap vif.

Signed-off-by: Eliad Peller <el...@wizery.com>
---
 drivers/net/wireless/ti/wl18xx/debugfs.c | 66 
 drivers/net/wireless/ti/wl18xx/event.c   |  3 +-
 drivers/net/wireless/ti/wlcore/init.c|  5 +++
 drivers/net/wireless/ti/wlcore/wlcore.h  |  1 +
 4 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wl18xx/debugfs.c 
b/drivers/net/wireless/ti/wl18xx/debugfs.c
index 4edfe28..86ccf84 100644
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -345,6 +345,69 @@ static const struct file_operations dynamic_fw_traces_ops 
= {
.llseek = default_llseek,
 };
 
+#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+static ssize_t radar_debug_mode_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct wl1271 *wl = file->private_data;
+   struct wl12xx_vif *wlvif;
+   unsigned long value;
+   int ret;
+
+   ret = kstrtoul_from_user(user_buf, count, 10, );
+   if (ret < 0) {
+   wl1271_warning("illegal radar_debug_mode value!");
+   return -EINVAL;
+   }
+
+   /* valid values: 0/1 */
+   if (!(value == 0 || value == 1)) {
+   wl1271_warning("value is not in valid!");
+   return -EINVAL;
+   }
+
+   mutex_lock(>mutex);
+
+   wl->radar_debug_mode = value;
+
+   if (unlikely(wl->state != WLCORE_STATE_ON))
+   goto out;
+
+   ret = wl1271_ps_elp_wakeup(wl);
+   if (ret < 0)
+   goto out;
+
+   wl12xx_for_each_wlvif_ap(wl, wlvif) {
+   wlcore_cmd_generic_cfg(wl, wlvif,
+  WLCORE_CFG_FEATURE_RADAR_DEBUG,
+  wl->radar_debug_mode, 0);
+   }
+
+   wl1271_ps_elp_sleep(wl);
+out:
+   mutex_unlock(>mutex);
+   return count;
+}
+
+static ssize_t radar_debug_mode_read(struct file *file,
+char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+   struct wl1271 *wl = file->private_data;
+
+   return wl1271_format_buffer(userbuf, count, ppos,
+   "%d\n", wl->radar_debug_mode);
+}
+
+static const struct file_operations radar_debug_mode_ops = {
+   .write = radar_debug_mode_write,
+   .read = radar_debug_mode_read,
+   .open = simple_open,
+   .llseek = default_llseek,
+};
+#endif /* CFG80211_CERTIFICATION_ONUS */
+
 int wl18xx_debugfs_add_files(struct wl1271 *wl,
 struct dentry *rootdir)
 {
@@ -510,6 +573,9 @@ int wl18xx_debugfs_add_files(struct wl1271 *wl,
 
DEBUGFS_ADD(conf, moddir);
DEBUGFS_ADD(radar_detection, moddir);
+#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+   DEBUGFS_ADD(radar_debug_mode, moddir);
+#endif
DEBUGFS_ADD(dynamic_fw_traces, moddir);
 
return 0;
diff --git a/drivers/net/wireless/ti/wl18xx/event.c 
b/drivers/net/wireless/ti/wl18xx/event.c
index 719907a..ff6e46d 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -146,7 +146,8 @@ int wl18xx_process_mailbox_events(struct wl1271 *wl)
mbox->radar_channel,
wl18xx_radar_type_decode(mbox->radar_type));
 
-   ieee80211_radar_detected(wl->hw);
+   if (!wl->radar_debug_mode)
+   ieee80211_radar_detected(wl->hw);
}
 
if (vector & PERIODIC_SCAN_REPORT_EVENT_ID) {
diff --git a/drivers/net/wireless/ti/wlcore/init.c 
b/drivers/net/wireless/ti/wlcore/init.c
index e92f263..d0b7734 100644
--- a/drivers/net/wireless/ti/wlcore/init.c
+++ b/drivers/net/wireless/ti/wlcore/init.c
@@ -558,6 +558,11 @@ static int wl12xx_init_ap_role(struct wl1271 *wl, struct 
wl12xx_vif *wlvif)
if (ret < 0)
return ret;
 
+   if (wl->radar_debug_mode)
+   wlcore_cmd_generic_cfg(wl, wlvif,
+  WLCORE_CFG_FEATURE_RADAR_DEBUG,
+  wl->radar_debug_mode, 0);
+
return 0;
 }
 
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h 
b/drivers/net/wireless/ti/wlcore/wlcore.h
index dda01b1..72c31a8 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -463,6 +463,7 @@ struct wl1271 {
 
/* the current dfs region */
enum n

[PATCH v2 1/2] wlcore: don't WARN_ON in case of existing ROC

[Eliad Peller]

When working with AP + P2P, it's possible to get into
a state when the AP is in ROC (due to assiciating station)
while trying to ROC on the P2P interface.

Replace the WARN_ON with wl1271_error to avoid warnings
in this case.

Signed-off-by: Eliad Peller <el...@wizery.com>
---
v2: fix kbuild warning (printf format)

 drivers/net/wireless/ti/wlcore/main.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index d1109c4..5127243 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5493,7 +5493,7 @@ static int wlcore_op_remain_on_channel(struct 
ieee80211_hw *hw,
 {
struct wl12xx_vif *wlvif = wl12xx_vif_to_data(vif);
struct wl1271 *wl = hw->priv;
-   int channel, ret = 0;
+   int channel, active_roc, ret = 0;
 
channel = ieee80211_frequency_to_channel(chan->center_freq);
 
@@ -5506,9 +5506,9 @@ static int wlcore_op_remain_on_channel(struct 
ieee80211_hw *hw,
goto out;
 
/* return EBUSY if we can't ROC right now */
-   if (WARN_ON(wl->roc_vif ||
-   find_first_bit(wl->roc_map,
-  WL12XX_MAX_ROLES) < WL12XX_MAX_ROLES)) {
+   active_roc = find_first_bit(wl->roc_map, WL12XX_MAX_ROLES);
+   if (wl->roc_vif || active_roc < WL12XX_MAX_ROLES) {
+   wl1271_warning("active roc on role %d", active_roc);
ret = -EBUSY;
goto out;
}
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] wlcore/wl18xx: add radar_debug_mode handling

[Eliad Peller]

Add debugfs key (under CFG80211_CERTIFICATION_ONUS
configuration) to set/clear radar_debug_mode.
In this mode, the driver simply ignores radar
events (but prints them).

The fw is notified about this mode through
a special generic_cfg_feature command.

This mode is relevant only for ap mode. look for
it when initializing ap vif.

Signed-off-by: Eliad Peller <el...@wizery.com>
---
 drivers/net/wireless/ti/wl18xx/debugfs.c | 66 
 drivers/net/wireless/ti/wl18xx/event.c   |  3 +-
 drivers/net/wireless/ti/wlcore/init.c|  5 +++
 drivers/net/wireless/ti/wlcore/wlcore.h  |  1 +
 4 files changed, 74 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wl18xx/debugfs.c 
b/drivers/net/wireless/ti/wl18xx/debugfs.c
index 4edfe28..86ccf84 100644
--- a/drivers/net/wireless/ti/wl18xx/debugfs.c
+++ b/drivers/net/wireless/ti/wl18xx/debugfs.c
@@ -345,6 +345,69 @@ static const struct file_operations dynamic_fw_traces_ops 
= {
.llseek = default_llseek,
 };
 
+#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+static ssize_t radar_debug_mode_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct wl1271 *wl = file->private_data;
+   struct wl12xx_vif *wlvif;
+   unsigned long value;
+   int ret;
+
+   ret = kstrtoul_from_user(user_buf, count, 10, );
+   if (ret < 0) {
+   wl1271_warning("illegal radar_debug_mode value!");
+   return -EINVAL;
+   }
+
+   /* valid values: 0/1 */
+   if (!(value == 0 || value == 1)) {
+   wl1271_warning("value is not in valid!");
+   return -EINVAL;
+   }
+
+   mutex_lock(>mutex);
+
+   wl->radar_debug_mode = value;
+
+   if (unlikely(wl->state != WLCORE_STATE_ON))
+   goto out;
+
+   ret = wl1271_ps_elp_wakeup(wl);
+   if (ret < 0)
+   goto out;
+
+   wl12xx_for_each_wlvif_ap(wl, wlvif) {
+   wlcore_cmd_generic_cfg(wl, wlvif,
+  WLCORE_CFG_FEATURE_RADAR_DEBUG,
+  wl->radar_debug_mode, 0);
+   }
+
+   wl1271_ps_elp_sleep(wl);
+out:
+   mutex_unlock(>mutex);
+   return count;
+}
+
+static ssize_t radar_debug_mode_read(struct file *file,
+char __user *userbuf,
+size_t count, loff_t *ppos)
+{
+   struct wl1271 *wl = file->private_data;
+
+   return wl1271_format_buffer(userbuf, count, ppos,
+   "%d\n", wl->radar_debug_mode);
+}
+
+static const struct file_operations radar_debug_mode_ops = {
+   .write = radar_debug_mode_write,
+   .read = radar_debug_mode_read,
+   .open = simple_open,
+   .llseek = default_llseek,
+};
+#endif /* CFG80211_CERTIFICATION_ONUS */
+
 int wl18xx_debugfs_add_files(struct wl1271 *wl,
 struct dentry *rootdir)
 {
@@ -510,6 +573,9 @@ int wl18xx_debugfs_add_files(struct wl1271 *wl,
 
DEBUGFS_ADD(conf, moddir);
DEBUGFS_ADD(radar_detection, moddir);
+#ifdef CONFIG_CFG80211_CERTIFICATION_ONUS
+   DEBUGFS_ADD(radar_debug_mode, moddir);
+#endif
DEBUGFS_ADD(dynamic_fw_traces, moddir);
 
return 0;
diff --git a/drivers/net/wireless/ti/wl18xx/event.c 
b/drivers/net/wireless/ti/wl18xx/event.c
index 719907a..ff6e46d 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -146,7 +146,8 @@ int wl18xx_process_mailbox_events(struct wl1271 *wl)
mbox->radar_channel,
wl18xx_radar_type_decode(mbox->radar_type));
 
-   ieee80211_radar_detected(wl->hw);
+   if (!wl->radar_debug_mode)
+   ieee80211_radar_detected(wl->hw);
}
 
if (vector & PERIODIC_SCAN_REPORT_EVENT_ID) {
diff --git a/drivers/net/wireless/ti/wlcore/init.c 
b/drivers/net/wireless/ti/wlcore/init.c
index e92f263..d0b7734 100644
--- a/drivers/net/wireless/ti/wlcore/init.c
+++ b/drivers/net/wireless/ti/wlcore/init.c
@@ -558,6 +558,11 @@ static int wl12xx_init_ap_role(struct wl1271 *wl, struct 
wl12xx_vif *wlvif)
if (ret < 0)
return ret;
 
+   if (wl->radar_debug_mode)
+   wlcore_cmd_generic_cfg(wl, wlvif,
+  WLCORE_CFG_FEATURE_RADAR_DEBUG,
+  wl->radar_debug_mode, 0);
+
return 0;
 }
 
diff --git a/drivers/net/wireless/ti/wlcore/wlcore.h 
b/drivers/net/wireless/ti/wlcore/wlcore.h
index dda01b1..72c31a8 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore.h
@@ -463,6 +463,7 @@ struct wl1271 {
 
/* the current dfs region */
enum n

[PATCH 1/2] wlcore: don't WARN_ON in case of existing ROC

[Eliad Peller]

When working with AP + P2P, it's possible to get into
a state when the AP is in ROC (due to assiciating station)
while trying to ROC on the P2P interface.

Replace the WARN_ON with wl1271_error to avoid warnings
in this case.

Signed-off-by: Eliad Peller <el...@wizery.com>
---
 drivers/net/wireless/ti/wlcore/main.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index d1109c4..cb2e8b6 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5506,9 +5506,10 @@ static int wlcore_op_remain_on_channel(struct 
ieee80211_hw *hw,
goto out;
 
/* return EBUSY if we can't ROC right now */
-   if (WARN_ON(wl->roc_vif ||
-   find_first_bit(wl->roc_map,
-  WL12XX_MAX_ROLES) < WL12XX_MAX_ROLES)) {
+   if (wl->roc_vif ||
+   find_first_bit(wl->roc_map, WL12XX_MAX_ROLES) < WL12XX_MAX_ROLES) {
+   wl1271_warning("active roc on role %d",
+  find_first_bit(wl->roc_map, WL12XX_MAX_ROLES));
ret = -EBUSY;
goto out;
}
-- 
2.6.3

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V10 1/2] nl80211: add feature for BSS selection support

[Eliad Peller]

On Mon, Feb 29, 2016 at 11:44 AM, Arend van Spriel  wrote:
> Introducing a new feature that the driver can use to
> indicate the driver/firmware supports configuration of BSS
> selection criteria upon CONNECT command. This can be useful
> when multiple BSS-es are found belonging to the same ESS,
> ie. Infra-BSS with same SSID. The criteria can then be used to
> offload selection of a preferred BSS.
>
[...]

> +   /* only do bss selection when no BSSID is specified. */
> +   if (!connect.bssid && info->attrs[NL80211_ATTR_BSS_SELECT]) {
> +   if (connect.bssid) {

i guess you wanted to remove the !connect.bssid condition in the outer if :)
other than that, looks go to me.

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V9 1/2] nl80211: add feature for BSS selection support

[Eliad Peller]

hi Arend,

On Fri, Feb 26, 2016 at 10:59 PM, Arend van Spriel  wrote:
> Introducing a new feature that the driver can use to
> indicate the driver/firmware supports configuration of BSS
> selection criteria upon CONNECT command. This can be useful
> when multiple BSS-es are found belonging to the same ESS,
> ie. Infra-BSS with same SSID. The criteria can then be used to
> offload selection of a preferred BSS.
>
[...]

>
> +/**
> + * struct nl80211_bss_select_rssi_adjust - RSSI adjustment parameters.
> + *
> + * @band: band of BSS that must match for RSSI value adjustment.
> + * @delta: value used to adjust the RSSI value of matching BSS.
> + */
> +struct nl80211_bss_select_rssi_adjust {
> +   enum nl80211_band band;
> +   __s8 delta;
> +} __attribute__((packed));
> +
i think enum can't be considered as fixed-size field, so better use u8 or so.

> @@ -626,6 +626,10 @@ int wiphy_register(struct wiphy *wiphy)
>  !rdev->ops->set_mac_acl)))
> return -EINVAL;
>
> +   if (WARN_ON(wiphy->bss_select_support &&
> +   (wiphy->bss_select_support & 
> ~(BIT(__NL80211_BSS_SELECT_ATTR_AFTER_LAST) - 2
> +   return -EINVAL;
> +
worth noting that the "-2" counts for the invalid enum value (at least
it wasn't clear to me)

> @@ -7995,6 +8086,21 @@ static int nl80211_connect(struct sk_buff *skb, struct 
> genl_info *info)
> return -EOPNOTSUPP;
> }
>
> +   /* only do bss selection when no BSSID is specified. */
> +   if (!connect.bssid && wiphy->bss_select_support &&
> +   info->attrs[NL80211_ATTR_BSS_SELECT]) {

you don't have to check wiphy->bss_select_support here - we actually
want to fail if NL80211_ATTR_BSS_SELECT was given although the driver
doesn't support it.

> +   err = parse_bss_select(info->attrs[NL80211_ATTR_BSS_SELECT],
> +  wiphy, _select);
> +   if (err) {
> +   kzfree(connkeys);
> +   return err;
> +   }
> +   if (!(wiphy->bss_select_support & 
> BIT(connect.bss_select.behaviour))) {

(it will fail here instead)

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

[Eliad Peller]

On Mon, Feb 15, 2016 at 11:16 AM, Grumbach, Emmanuel
<emmanuel.grumb...@intel.com> wrote:
>
>
> On 02/15/2016 11:06 AM, Eliad Peller wrote:
>> On Sun, Feb 14, 2016 at 9:37 PM, Grumbach, Emmanuel
>> <emmanuel.grumb...@intel.com> wrote:
>>>
>>> On 02/14/2016 09:33 PM, Johannes Berg wrote:
>>>> On Sun, 2016-02-14 at 19:34 +0200, Emmanuel Grumbach wrote:
>>>>> Since the 3rd patch needs to be dropped anyway, let's route this one
>>>>> through my tree as usual.
>>>> It doesn't really have to be dropped, why? We can just make the same
>>>> adjustment as for dvm in the patch.
>>>>
>>> But I am not sure I really want to play with drivers/staging/vt6656/rxtx.c
>> here you go:
>>
>> diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
>> index b668db6..1a2dda0 100644
>> --- a/drivers/staging/vt6655/rxtx.c
>> +++ b/drivers/staging/vt6655/rxtx.c
>>
> Want to send that patch to Greg? :)

why? can't you simply amend it to the third patch?

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/3] iwlwifi: mvm: move TX PN assignment for TKIP to the driver

[Eliad Peller]

On Sun, Feb 14, 2016 at 9:37 PM, Grumbach, Emmanuel
 wrote:
>
>
> On 02/14/2016 09:33 PM, Johannes Berg wrote:
>> On Sun, 2016-02-14 at 19:34 +0200, Emmanuel Grumbach wrote:
>>>
>>> Since the 3rd patch needs to be dropped anyway, let's route this one
>>> through my tree as usual.
>> It doesn't really have to be dropped, why? We can just make the same
>> adjustment as for dvm in the patch.
>>
>
> But I am not sure I really want to play with drivers/staging/vt6656/rxtx.c

here you go:

diff --git a/drivers/staging/vt6655/rxtx.c b/drivers/staging/vt6655/rxtx.c
index b668db6..1a2dda0 100644
--- a/drivers/staging/vt6655/rxtx.c
+++ b/drivers/staging/vt6655/rxtx.c
@@ -1210,7 +1210,7 @@ static void vnt_fill_txkey(struct ieee80211_hdr
*hdr, u8 *key_buffer,
struct sk_buff *skb, u16 payload_len,
struct vnt_mic_hdr *mic_hdr)
 {
- struct ieee80211_key_seq seq;
+ u64 pn64;
  u8 *iv = ((u8 *)hdr + ieee80211_get_hdrlen_from_skb(skb));

  /* strip header and icv len from payload */
@@ -1243,9 +1243,13 @@ static void vnt_fill_txkey(struct ieee80211_hdr
*hdr, u8 *key_buffer,
  mic_hdr->payload_len = cpu_to_be16(payload_len);
  ether_addr_copy(mic_hdr->mic_addr2, hdr->addr2);

- ieee80211_get_key_tx_seq(tx_key, );
-
- memcpy(mic_hdr->ccmp_pn, seq.ccmp.pn, IEEE80211_CCMP_PN_LEN);
+ pn64 = atomic64_read(_key->tx_pn);
+ mic_hdr->ccmp_pn[5] = pn64;
+ mic_hdr->ccmp_pn[4] = pn64 >> 8;
+ mic_hdr->ccmp_pn[3] = pn64 >> 16;
+ mic_hdr->ccmp_pn[2] = pn64 >> 24;
+ mic_hdr->ccmp_pn[1] = pn64 >> 32;
+ mic_hdr->ccmp_pn[0] = pn64 >> 40;

  if (ieee80211_has_a4(hdr->frame_control))
  mic_hdr->hlen = cpu_to_be16(28);
diff --git a/drivers/staging/vt6656/rxtx.c b/drivers/staging/vt6656/rxtx.c
index efb54f5..76378d2 100644
--- a/drivers/staging/vt6656/rxtx.c
+++ b/drivers/staging/vt6656/rxtx.c
@@ -719,7 +719,7 @@ static void vnt_fill_txkey(struct
vnt_usb_send_context *tx_context,
  u16 payload_len, struct vnt_mic_hdr *mic_hdr)
 {
  struct ieee80211_hdr *hdr = tx_context->hdr;
- struct ieee80211_key_seq seq;
+ u64 pn64;
  u8 *iv = ((u8 *)hdr + ieee80211_get_hdrlen_from_skb(skb));

  /* strip header and icv len from payload */
@@ -752,9 +752,13 @@ static void vnt_fill_txkey(struct
vnt_usb_send_context *tx_context,
  mic_hdr->payload_len = cpu_to_be16(payload_len);
  ether_addr_copy(mic_hdr->mic_addr2, hdr->addr2);

- ieee80211_get_key_tx_seq(tx_key, );
-
- memcpy(mic_hdr->ccmp_pn, seq.ccmp.pn, IEEE80211_CCMP_PN_LEN);
+ pn64 = atomic64_read(_key->tx_pn);
+ mic_hdr->ccmp_pn[5] = pn64;
+ mic_hdr->ccmp_pn[4] = pn64 >> 8;
+ mic_hdr->ccmp_pn[3] = pn64 >> 16;
+ mic_hdr->ccmp_pn[2] = pn64 >> 24;
+ mic_hdr->ccmp_pn[1] = pn64 >> 32;
+ mic_hdr->ccmp_pn[0] = pn64 >> 40;

  if (ieee80211_has_a4(hdr->frame_control))
  mic_hdr->hlen = cpu_to_be16(28);


Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 05/15] net: wireless: ti: Return flow can be simplified for wl1271_cmd_interrogate

[Eliad Peller]

On Wed, Oct 21, 2015 at 10:07 PM, Punit Vara  wrote:
> Remove int ret suggested by kbuild test robot
>
> This patch is to the wlcore/acx.c file that fixes up warning
> reported by coccicheck:
>
> WARNING: end returns can be simplified if negative or 0 value
>
> Prefer direct return value instead of writing 2-3 more sentence.
>
> Signed-off-by: Punit Vara 
> ---
>  drivers/net/wireless/ti/wlcore/acx.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/acx.c 
> b/drivers/net/wireless/ti/wlcore/acx.c
> index f28fa3b..6b566d9 100644
> --- a/drivers/net/wireless/ti/wlcore/acx.c
> +++ b/drivers/net/wireless/ti/wlcore/acx.c
> @@ -158,16 +158,11 @@ out:
>  int wl1271_acx_mem_map(struct wl1271 *wl, struct acx_header *mem_map,
>size_t len)
>  {
> -   int ret;
>
> wl1271_debug(DEBUG_ACX, "acx mem map");
>
> -   ret = wl1271_cmd_interrogate(wl, ACX_MEM_MAP, mem_map,
> +   return wl1271_cmd_interrogate(wl, ACX_MEM_MAP, mem_map,
>  sizeof(struct acx_header), len);
> -   if (ret < 0)
> -   return ret;
> -
> -   return 0;
>  }
>
this changes the return value in case of positive values.
have you verified it can't happen / won't affect the code flow?
i'm not sure you really want to blindly patch it...

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new regdb file format

[Eliad Peller]

On Mon, Oct 19, 2015 at 2:31 PM, Johannes Berg
<johan...@sipsolutions.net> wrote:
> On Mon, 2015-10-19 at 14:28 +0300, Eliad Peller wrote:
>
>> while at it - is there any way to indicate exclusion of some
>> channels?
>> e.g. channels 38/42 in US (the current rule is "(5170 - 5250 @ 40)",
>> which doesn't seem to forbid them)
>>
>
> Hm? Why would you want to do that, if you are allowed to use that band?
>
The spec seems to indicate the allowed channel set for each operating
class, and some channels are allowed only in some countries (tables
E-1 vs. E-2 in 802.11-2012 Annex E).

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new regdb file format

[Eliad Peller]

On Mon, Oct 19, 2015 at 2:53 PM, Johannes Berg
<johan...@sipsolutions.net> wrote:
> On Mon, 2015-10-19 at 14:52 +0300, Eliad Peller wrote:
>>
>> > Hm? Why would you want to do that, if you are allowed to use that
>> > band?
>> >
>> The spec seems to indicate the allowed channel set for each operating
>> class, and some channels are allowed only in some countries (tables
>> E-1 vs. E-2 in 802.11-2012 Annex E).
>>
>
> But that's a different problem in a way - the regulatory database only
> tries to encode the legal restrictions, not the spec restrictions.
>
that's a good point :)

thanks,
Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: new regdb file format

[Eliad Peller]

On Thu, Oct 15, 2015 at 12:01 AM, Johannes Berg
 wrote:
> Err. Let's try that again.
>
> I spent a bit of time thinking about a file format that would be more
> extensible, yet still be loadable into the kernel without having to
> parse it into new data structures in the kernel, i.e. be easy enough to
> read when needed.
>
> My considerations
>  * must be extensible in some way
>  * should be relatively dense/small to not use too much kernel memory
>  * should still be reasonably easy to parse/read
>
> I came up with a file format that's similar to the existing
> regulatory.bin format, but with the following changes:
>  * put the DFS region into a reg rule collection
>  * put the frequency range and power rules directly into each reg rule
>(i.e. don't try to normalize them)
>  * have a length field in the collection and rule structures so that we
>can extend them with new fields
>  * use more compact pointers, i.e. u16 offsets, by aligning everything
>to 4 bytes and shifting the offsets by 2 bits, this allows for
>256KiB database files which seems large enough
>
> More documentation is here:
> https://wireless.wiki.kernel.org/en/developers/todo-list/regdb-file
> -format
>
while at it - is there any way to indicate exclusion of some channels?
e.g. channels 38/42 in US (the current rule is "(5170 - 5250 @ 40)",
which doesn't seem to forbid them)

Eliad.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Association race when acting as AP?

[Eliad Peller]

On Thu, Jul 2, 2015 at 1:39 PM, Michal Kazior michal.kaz...@tieto.com wrote:
 On 2 July 2015 at 10:43, Eliad Peller el...@wizery.com wrote:
 On Thu, Jul 2, 2015 at 11:38 AM, Johannes Berg johan...@sipsolutions.net
 wrote:

 [please try to send w/o html if you're CC'ing the linux-wireless list]

  To me this looks like a race in hostapd. The station should be
  installed to driver _before_ sending Assoc Resp frame, not after. My
  quick-n-dirty hack seems to help:
 
 [...]
  Is anyone aware of this problem already? Anyone working on it? Any
  gotchas I should be aware of before I go into fixing this in a proper
  way? Or am I missing something and this isn't actually a problem?

 The TI folks had a similar patch that broke open networks, not sure
 what was wrong there.

 there was some implementation error. it was fixed later on.

 also, take a look at this thread:
 http://thread.gmane.org/gmane.linux.kernel.wireless.general/88421

 Thanks! Looks like you guys hit this with EAPOL frames. I'll look into it 
 more.

 Is there any particular reason why these TI-OpenLink patches weren't
 submitted/merged to hostap?

nothing particular, AFAIR.
they needed further review/cleanup before upstream, and we just didn't
get to it.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/11] mac80211: add TX fastpath

[Eliad Peller]

On Mon, Apr 20, 2015 at 11:47 AM, Johannes Berg
johan...@sipsolutions.net wrote:
 Hey, somebody is reviewing my patches :-)

i didn't delve into them too much, but generally they look good :)

  +   build.key = rcu_access_pointer(sta-ptk[sta-ptk_idx]);
  +   if (!build.key)
  +   build.key = rcu_access_pointer(sdata-default_unicast_key);
 don't you need rcu_dereference here? (and you don't seem to be inside
 rcu section here)

 It's a bit complicated.

 I used to think I don't need it, but perhaps I do to avoid accessing bad
 memory in this function.

 The thing is that this function is going to be called immediately
 whenever those pointers change, so that the RCU handling of the fast_tx
 struct itself should prevent the TX path from accessing a bad key
 pointer.

 However, it seems possible that we go into this function on another CPU
 for unrelated reasons, and if that CPU then stalls after getting the key
 pointer but before assigning the fast_tx pointer, then it might
 overwrite the assignment or clearing from the CPU processing the key
 change.

 So indeed it looks like this isn't safe as is right now.

 To fix that, I think I can hold the lock longer, so that the lifetime of
 the key and the fast_tx pointer are more closely correlated. If I
 acquire the spinlock before checking for the key, then the CPU that
 invalidates the key pointer cannot race in this way with another caller,
 since the key pointer would (for this purpose) be protected by the lock.
 Then either the CPU that deleted the key will have to wait (while the
 key is still pretty much valid) and then will overwrite the fast_tx w/o
 the key, or the other CPU will have to wait and will find the key
 pointer changed/NULL already.

 Right? what do you think?

sounds correct.
i guess taking rcu_lock is a valid option as well (for about the same
reasons). so either one of them should be good.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 01/11] mac80211: add TX fastpath

[Eliad Peller]

On Fri, Apr 17, 2015 at 6:15 PM, Johannes Berg
johan...@sipsolutions.net wrote:
 From: Johannes Berg johannes.b...@intel.com

 In order to speed up mac80211's TX path, add the fast-xmit cache
 that will cache the data frame 802.11 header and other data to be
 able to build the frame more quickly. This cache is rebuilt when
 external triggers imply changes, but a lot of the checks done per
 packet today are simplified away to the check for the cache.

 There's also a more detailed description in the code.

 Signed-off-by: Johannes Berg johannes.b...@intel.com
 ---
[...]

 +   build.key = rcu_access_pointer(sta-ptk[sta-ptk_idx]);
 +   if (!build.key)
 +   build.key = rcu_access_pointer(sdata-default_unicast_key);
don't you need rcu_dereference here? (and you don't seem to be inside
rcu section here)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 0/6] wlcore: add device-tree support

[Eliad Peller]

hi Nikita,

On Tue, Mar 24, 2015 at 1:37 PM, Nikita Kiryanov nik...@compulab.co.il wrote:
 Hi Eliad,

 On 03/18/2015 06:38 PM, Eliad Peller wrote:

 Add device-tree support to the wlcore (wl12xx/wl18xx)
 driver.

 Update the current users to use the bindings instead
 of pdata-quirks.

 Finally, remove the deprecated wl12xx_platform_data
 struct (along with the da850 board file code that
 still uses it)


 Tested-by: Nikita Kiryanov nik...@compulab.co.il
 Tested on am437x-gp-evm with WL1835MODCOM8B

thanks for testing it!

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

On Mon, Mar 23, 2015 at 10:21 AM, Sekhar Nori nsek...@ti.com wrote:
 On Wednesday 18 March 2015 10:08 PM, Eliad Peller wrote:
 Now that we have wlcore device-tree bindings in place
 (for both wl12xx and wl18xx), remove the legacy
 wl12xx_platform_data struct, and move its members
 into the platform device data (that is passed to wlcore)

 Davinci 850 is the only platform that still set
 the platform data in the legacy way (and doesn't
 have DT bindings), so remove the relevant
 code/Kconfig option from the board file (as suggested
 by Sekhar Nori)

 Since no one currently uses wlcore_spi, simply remove its
 platform data support (DT bindings will have to be added
 if someone actually needs it)

 Signed-off-by: Luciano Coelho l...@coelho.fi
 Signed-off-by: Eliad Peller el...@wizery.com
 ---
 v7:
 * fix spi compilation (Tony)
 * remove irq/irq_trigger from wlcore_platdev_data (they are
   being passed separately)

  arch/arm/mach-davinci/Kconfig  |  11 ---
  arch/arm/mach-davinci/board-da850-evm.c| 113 
 -
  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
  drivers/net/wireless/ti/wlcore/sdio.c  |  76 +
  drivers/net/wireless/ti/wlcore/spi.c   |   6 +-
  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   6 +-
  include/linux/wl12xx.h |  25 --
  10 files changed, 35 insertions(+), 251 deletions(-)

 The patch looks good to me, but it will be nice to know to which base it
 applies cleanly. I tried applying to v4.0-rc1 and linux-next and both
 failed.

 The patchset was rebased on top of v4.0-rc4.
 (Note that you'll have to apply the whole series, as this patch relies
 on some intermediate changes done by the previous patches in the
 patchset)

 I was applying the whole series, but over v4.0-rc1 :) Its best to
 mention the baseline in cover-letter itself.

check out again the cover-letter. you probably overlooked it :)

 The DA850 related changes in the patch look good to me.

 Acked-by: Sekhar Nori nsek...@ti.com

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v7 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

hi Sekhar,

On Mon, Mar 23, 2015 at 9:51 AM, Sekhar Nori nsek...@ti.com wrote:
 + Ido

 On Wednesday 18 March 2015 10:08 PM, Eliad Peller wrote:
 Now that we have wlcore device-tree bindings in place
 (for both wl12xx and wl18xx), remove the legacy
 wl12xx_platform_data struct, and move its members
 into the platform device data (that is passed to wlcore)

 Davinci 850 is the only platform that still set
 the platform data in the legacy way (and doesn't
 have DT bindings), so remove the relevant
 code/Kconfig option from the board file (as suggested
 by Sekhar Nori)

 Since no one currently uses wlcore_spi, simply remove its
 platform data support (DT bindings will have to be added
 if someone actually needs it)

 Signed-off-by: Luciano Coelho l...@coelho.fi
 Signed-off-by: Eliad Peller el...@wizery.com
 ---
 v7:
 * fix spi compilation (Tony)
 * remove irq/irq_trigger from wlcore_platdev_data (they are
   being passed separately)

  arch/arm/mach-davinci/Kconfig  |  11 ---
  arch/arm/mach-davinci/board-da850-evm.c| 113 
 -
  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
  drivers/net/wireless/ti/wlcore/sdio.c  |  76 +
  drivers/net/wireless/ti/wlcore/spi.c   |   6 +-
  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   6 +-
  include/linux/wl12xx.h |  25 --
  10 files changed, 35 insertions(+), 251 deletions(-)

 The patch looks good to me, but it will be nice to know to which base it
 applies cleanly. I tried applying to v4.0-rc1 and linux-next and both
 failed.

The patchset was rebased on top of v4.0-rc4.
(Note that you'll have to apply the whole series, as this patch relies
on some intermediate changes done by the previous patches in the
patchset)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: stop scan before connection

[Eliad Peller]

On Tue, Mar 17, 2015 at 7:58 PM, Emmanuel Grumbach
emmanuel.grumb...@intel.com wrote:
 From: David Spinadel david.spina...@intel.com

 Stop scan before authentication or association to make sure
 that nothing interferes with connection flow.

this makes sense

 Currently mac80211 defers RX auth and assoc packets (among other ones)
 until after the scan is complete, so auth during scan is likely to fail
 if scan took too much time.

but i don't think deferring the frame handling makes sense in case of
hw_scan (there was a similar case with BA request handling).
i should have such (one-liner) patch pending somewhere...

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: stop scan before connection

[Eliad Peller]

On Wed, Mar 18, 2015 at 11:46 AM, Johannes Berg
johan...@sipsolutions.net wrote:
 On Wed, 2015-03-18 at 11:36 +0200, Eliad Peller wrote:
 On Tue, Mar 17, 2015 at 7:58 PM, Emmanuel Grumbach
 emmanuel.grumb...@intel.com wrote:
  From: David Spinadel david.spina...@intel.com
 
  Stop scan before authentication or association to make sure
  that nothing interferes with connection flow.
 
 this makes sense

  Currently mac80211 defers RX auth and assoc packets (among other ones)
  until after the scan is complete, so auth during scan is likely to fail
  if scan took too much time.
 
 but i don't think deferring the frame handling makes sense in case of
 hw_scan (there was a similar case with BA request handling).
 i should have such (one-liner) patch pending somewhere...

 We did consider that, but ultimately I think it's not desirable.

 The aggregation case is different, but during auth/assoc the relevant
 frames cannot be buffered by the AP. So unless you have a hardware
 mechanism that makes the device not continue the scan for say 30-50ms
 after the auth/assoc req frame went out, the connection process will be
 very unreliable.

i'm not sure. the AP will probably have some retransmissions, so the
station should have good chances to get the frames (assuming the
hardware will give this interface some airtime during the scan).

 So in a sense you could say deferring the handling doesn't make sense,
 but I'd still argue you shouldn't start this process while you're in the
 middle of scanning, hence this patch.

i agree the patch makes sense anyway, i just noted that mac80211
behavior seems wrong.
you should avoid scanning while connecting in first place, not defer
the handling.

btw, note that both this patch and ieee80211_iface_work() don't count
for the sched scan case, which is basically the same.

 We may have to do more exclusions (e.g. don't start a scan while
 authenticating or associating) here though, and ultimately not
 *processing* the frames will be irrelevant as they shouldn't be coming
 in anyway.
that's true for auth/assoc frames. but some other frames (e.g. deauth)
can come anytime, and i don't see why we should defer processing in
this case.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 2/6] wl12xx: use frequency instead of enumerations for pdata clocks

[Eliad Peller]

From: Luciano Coelho l...@coelho.fi

Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead.  Also add a
boolean to specify whether the clock is XTAL or not.

Change all board files to reflect this.

Signed-off-by: Luciano Coelho l...@coelho.fi
[Eliad - small fixes, update board file changes]
Signed-off-by: Eliad Peller el...@wizery.com
---
v7: rebase

 arch/arm/mach-davinci/board-da850-evm.c |  3 +-
 arch/arm/mach-omap2/pdata-quirks.c  | 29 
 drivers/net/wireless/ti/wl12xx/main.c   | 60 ++---
 drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +++
 include/linux/wl12xx.h  | 27 ++-
 5 files changed, 103 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 916589c..853b941 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1386,7 +1386,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.irq_trigger= IRQ_TYPE_EDGE_RISING,
-   .board_ref_clock= WL12XX_REFCLOCK_38,
+   .ref_clock_freq = 3840,
+   .ref_clock_xtal = false,
 };
 
 static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index e86fb0d..cebdf8d 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -39,14 +39,14 @@ static struct twl4030_gpio_platform_data twl_gpio_auxdata;
 
 static struct wl12xx_platform_data wl12xx __initdata;
 
-static void __init __used legacy_init_wl12xx(unsigned ref_clock,
-unsigned tcxo_clock,
+static void __init __used legacy_init_wl12xx(u32 ref_clock_freq,
+u32 tcxo_clock_freq,
 int gpio)
 {
int res;
 
-   wl12xx.board_ref_clock = ref_clock;
-   wl12xx.board_tcxo_clock = tcxo_clock;
+   wl12xx.ref_clock_freq = ref_clock_freq;
+   wl12xx.tcxo_clock_freq = tcxo_clock_freq;
wl12xx.irq = gpio_to_irq(gpio);
wl12xx.irq_trigger = IRQ_TYPE_LEVEL_HIGH;
 
@@ -57,8 +57,8 @@ static void __init __used legacy_init_wl12xx(unsigned 
ref_clock,
}
 }
 #else
-static inline void legacy_init_wl12xx(unsigned ref_clock,
- unsigned tcxo_clock,
+static inline void legacy_init_wl12xx(u32 ref_clock_freq,
+ u32 tcxo_clock_freq,
  int gpio)
 {
 }
@@ -130,7 +130,7 @@ static void __init omap3_sbc_t3730_twl_init(void)
 static void __init omap3_sbc_t3730_legacy_init(void)
 {
omap3_sbc_t3x_usb_hub_init(167, sb-t35 usb hub);
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 136);
+   legacy_init_wl12xx(3840, 0, 136);
 }
 
 static void __init omap3_sbc_t3530_legacy_init(void)
@@ -175,12 +175,12 @@ static void __init omap3_igep0030_rev_g_legacy_init(void)
 static void __init omap3_evm_legacy_init(void)
 {
hsmmc2_internal_input_clk();
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
+   legacy_init_wl12xx(3840, 0, 149);
 }
 
 static void __init omap3_zoom_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
+   legacy_init_wl12xx(2600, 0, 162);
 }
 
 static void am35xx_enable_emac_int(void)
@@ -247,7 +247,7 @@ static void __init omap3_sbc_t3517_legacy_init(void)
am35xx_emac_reset();
hsmmc2_internal_input_clk();
omap3_sbc_t3517_wifi_init();
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 145);
+   legacy_init_wl12xx(3840, 0, 145);
 }
 
 static void __init am3517_evm_legacy_init(void)
@@ -292,18 +292,17 @@ static void __init omap3_tao3530_legacy_init(void)
 #ifdef CONFIG_ARCH_OMAP4
 static void __init omap4_sdp_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_26,
-  WL12XX_TCXOCLOCK_26, 53);
+   legacy_init_wl12xx(2600, 2600, 53);
 }
 
 static void __init omap4_panda_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
+   legacy_init_wl12xx(3840, 0, 53);
 }
 
 static void __init var_som_om44_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 41);
+   legacy_init_wl12xx(3840, 0, 41);
 }
 #endif
 
@@ -318,7 +317,7 @@ static struct iommu_platform_data omap4_iommu_pdata = {
 #ifdef CONFIG_SOC_AM33XX
 static void __init am335x_evmsk_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 31);
+   legacy_init_wl12xx(3840, 0, 31);
 }
 #endif
 
diff --git a/drivers/net/wireless/ti/wl12xx/main.c 
b/drivers/net/wireless/ti/wl12xx/main.c
index 144d1f8..b3f751f 100644
--- a/drivers/net

[PATCH v7 4/6] wlcore: add device-tree support

[Eliad Peller]

When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.

Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
Tested-by: Sébastien Szymanski sebastien.szyman...@armadeus.com
---
 drivers/net/wireless/ti/wlcore/sdio.c | 93 ---
 1 file changed, 87 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 2bce00a..b55dc0e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
 #include linux/wl12xx.h
 #include linux/pm_runtime.h
 #include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
 
 #include wlcore.h
 #include wl12xx_80211.h
@@ -214,6 +216,82 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+   { .compatible = ti,wl1271 },
+   { .compatible = ti,wl1273 },
+   { .compatible = ti,wl1281 },
+   { .compatible = ti,wl1283 },
+   { .compatible = ti,wl1801 },
+   { .compatible = ti,wl1805 },
+   { .compatible = ti,wl1807 },
+   { .compatible = ti,wl1831 },
+   { .compatible = ti,wl1835 },
+   { .compatible = ti,wl1837 },
+   { }
+};
+
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct wl12xx_platform_data *pdata;
+
+   if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
+   return NULL;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-irq = irq_of_parse_and_map(np, 0);
+   if (!pdata-irq) {
+   dev_err(dev, No irq in platform data\n);
+   kfree(pdata);
+   return NULL;
+   }
+
+   pdata-irq_trigger =
+   irqd_get_trigger_type(irq_get_irq_data(pdata-irq));
+
+   /* optional clock frequency params */
+   of_property_read_u32(np, ref-clock-frequency,
+pdata-ref_clock_freq);
+   of_property_read_u32(np, tcxo-clock-frequency,
+pdata-tcxo_clock_freq);
+
+   return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+   struct wl12xx_platform_data *pdata;
+
+   /* first, look for DT data */
+   pdata = wlcore_probe_of(dev);
+   if (pdata)
+   return pdata;
+
+   /* if not found - fallback to static platform data */
+   pdata = wl12xx_get_platform_data();
+   if (!IS_ERR(pdata))
+   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+   dev_err(dev, No platform data set\n);
+   return NULL;
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+   kfree(pdata);
+}
+
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
@@ -245,12 +323,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   pdev_data.pdata = wl12xx_get_platform_data();
-   if (IS_ERR(pdev_data.pdata)) {
-   ret = PTR_ERR(pdev_data.pdata);
-   dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+   pdev_data.pdata = wlcore_get_platform_data(func-dev);
+   if (!pdev_data.pdata)
goto out_free_glue;
-   }
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +354,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out_free_pdata;
}
 
glue-core-dev.parent = func-dev;
@@ -313,6 +388,9 @@ static int wl1271_probe(struct sdio_func *func,
 out_dev_put:
platform_device_put(glue-core);
 
+out_free_pdata:
+   wlcore_del_platform_data(pdev_data.pdata);
+
 out_free_glue:
kfree(glue);
 
@@ -323,11 +401,14 @@ out:
 static void wl1271_remove(struct sdio_func *func)
 {
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+   struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
+   struct wl12xx_platform_data *pdata = pdev_data-pdata;
 
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
 
platform_device_unregister(glue-core);
+   wlcore_del_platform_data(pdata);
kfree(glue

[PATCH v7 3/6] dt: bindings: add TI's wilink wireless device

[Eliad Peller]

Add device tree binding documentation for TI's wilink
(wl12xx and wl18xx) wlan chip.

Signed-off-by: Eliad Peller el...@wizery.com
---
 .../devicetree/bindings/net/wireless/ti,wlcore.txt | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
new file mode 100644
index 000..2a3d90d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
@@ -0,0 +1,47 @@
+TI Wilink 6/7/8 (wl12xx/wl18xx) SDIO devices
+
+This node provides properties for controlling the wilink wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+ - compatible: should be one of the following:
+* ti,wl1271
+* ti,wl1273
+* ti,wl1281
+* ti,wl1283
+* ti,wl1801
+* ti,wl1805
+* ti,wl1807
+* ti,wl1831
+* ti,wl1835
+* ti,wl1837
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Optional properties:
+ - interrupt-parent : the phandle for the interrupt controller to which the
+   device interrupts are connected.
+ - ref-clock-frequency : ref clock frequency in Hz
+ - tcxo-clock-frequency : tcxo clock frequency in Hz
+
+Note: the *-clock-frequency properties assume internal clocks. In case of 
external
+clock, new bindings (for parsing the clock nodes) have to be added.
+
+Example:
+
+mmc3 {
+   status = okay;
+   vmmc-supply = wlan_en_reg;
+   bus-width = 4;
+   cap-power-off-card;
+   keep-power-in-suspend;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio0;
+   interrupts = 19 IRQ_TYPE_LEVEL_HIGH;
+   };
+};
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v7 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

Now that we have wlcore device-tree bindings in place
(for both wl12xx and wl18xx), remove the legacy
wl12xx_platform_data struct, and move its members
into the platform device data (that is passed to wlcore)

Davinci 850 is the only platform that still set
the platform data in the legacy way (and doesn't
have DT bindings), so remove the relevant
code/Kconfig option from the board file (as suggested
by Sekhar Nori)

Since no one currently uses wlcore_spi, simply remove its
platform data support (DT bindings will have to be added
if someone actually needs it)

Signed-off-by: Luciano Coelho l...@coelho.fi
Signed-off-by: Eliad Peller el...@wizery.com
---
v7:
* fix spi compilation (Tony)
* remove irq/irq_trigger from wlcore_platdev_data (they are
  being passed separately)

 arch/arm/mach-davinci/Kconfig  |  11 ---
 arch/arm/mach-davinci/board-da850-evm.c| 113 -
 drivers/net/wireless/ti/wilink_platform_data.c |  25 --
 drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
 drivers/net/wireless/ti/wlcore/boot.c  |   1 -
 drivers/net/wireless/ti/wlcore/main.c  |   4 +-
 drivers/net/wireless/ti/wlcore/sdio.c  |  76 +
 drivers/net/wireless/ti/wlcore/spi.c   |   6 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h  |   6 +-
 include/linux/wl12xx.h |  25 --
 10 files changed, 35 insertions(+), 251 deletions(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index cd30f6f..dd8f531 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -200,17 +200,6 @@ config DA850_UI_SD_VIDEO_PORT
 
 endchoice
 
-config DA850_WL12XX
-   bool AM18x wl1271 daughter board
-   depends on MACH_DAVINCI_DA850_EVM
-   help
- The wl1271 daughter card for AM18x EVMs is a combo wireless
- connectivity add-on card, based on the LS Research TiWi module with
- Texas Instruments' wl1271 solution.
- Say Y if you want to use a wl1271 expansion card connected to the
- AM18x EVM.
-
-
 config MACH_MITYOMAPL138
bool Critical Link MityDSP-L138/MityARM-1808 SoM
depends on ARCH_DAVINCI_DA850
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 853b941..1ed545c 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,7 +38,6 @@
 #include linux/regulator/fixed.h
 #include linux/spi/spi.h
 #include linux/spi/flash.h
-#include linux/wl12xx.h
 
 #include mach/common.h
 #include mach/cp_intc.h
@@ -60,9 +59,6 @@
 #define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
 #define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1)
 
-#define DA850_WLAN_EN  GPIO_TO_PIN(6, 9)
-#define DA850_WLAN_IRQ GPIO_TO_PIN(6, 10)
-
 #define DA850_MII_MDIO_CLKEN_PIN   GPIO_TO_PIN(2, 6)
 
 static struct mtd_partition da850evm_spiflash_part[] = {
@@ -1343,110 +1339,6 @@ static __init void da850_vpif_init(void)
 static __init void da850_vpif_init(void) {}
 #endif
 
-#ifdef CONFIG_DA850_WL12XX
-
-static void wl12xx_set_power(int index, bool power_on)
-{
-   static bool power_state;
-
-   pr_debug(Powering %s wl12xx, power_on ? on : off);
-
-   if (power_on == power_state)
-   return;
-   power_state = power_on;
-
-   if (power_on) {
-   /* Power up sequence required for wl127x devices */
-   gpio_set_value(DA850_WLAN_EN, 1);
-   usleep_range(15000, 15000);
-   gpio_set_value(DA850_WLAN_EN, 0);
-   usleep_range(1000, 1000);
-   gpio_set_value(DA850_WLAN_EN, 1);
-   msleep(70);
-   } else {
-   gpio_set_value(DA850_WLAN_EN, 0);
-   }
-}
-
-static struct davinci_mmc_config da850_wl12xx_mmc_config = {
-   .set_power  = wl12xx_set_power,
-   .wires  = 4,
-   .max_freq   = 2500,
-   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_NONREMOVABLE |
- MMC_CAP_POWER_OFF_CARD,
-};
-
-static const short da850_wl12xx_pins[] __initconst = {
-   DA850_MMCSD1_DAT_0, DA850_MMCSD1_DAT_1, DA850_MMCSD1_DAT_2,
-   DA850_MMCSD1_DAT_3, DA850_MMCSD1_CLK, DA850_MMCSD1_CMD,
-   DA850_GPIO6_9, DA850_GPIO6_10,
-   -1
-};
-
-static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
-   .irq= -1,
-   .irq_trigger= IRQ_TYPE_EDGE_RISING,
-   .ref_clock_freq = 3840,
-   .ref_clock_xtal = false,
-};
-
-static __init int da850_wl12xx_init(void)
-{
-   int ret;
-
-   ret = davinci_cfg_reg_list(da850_wl12xx_pins);
-   if (ret) {
-   pr_err(wl12xx/mmc mux setup failed: %d\n, ret);
-   goto exit;
-   }
-
-   ret = da850_register_mmcsd1(da850_wl12xx_mmc_config);
-   if (ret) {
-   pr_err(wl12xx/mmc

Re: [PATCH v6 2/6] wl12xx: use frequency instead of enumerations for pdata clocks

[Eliad Peller]

+Kalle

On Fri, Mar 13, 2015 at 5:00 PM, Tony Lindgren t...@atomide.com wrote:
 * Eliad Peller el...@wizery.com [150312 05:09]:
 From: Luciano Coelho l...@coelho.fi

 Instead of defining an enumeration with the FW specific values for the
 different clock rates, use the actual frequency instead.  Also add a
 boolean to specify whether the clock is XTAL or not.

 Thanks for doing this. Just one comment on how we're going to get this
 all merged. Chances are this will cause merge conflicts between the
 wireless tree and the omap tree for the platform data and dts changes.

 Can you please separate the wireless changes in this series so we can
 do this in the following sets:

 1. Add support for new things to wireless driver

 2. Switch platform code to use the new support

 3. Remove support for platform data with a follow-up patch

the series will still be dependent on each other (e.g. (3) must come
only after (2) was applied), so i'm not sure that will be very
helpful?

 The other option would be to have the whole series in a immutable
 branch against v3.0-rc1 that can be merged into both wirelss tree
 and omap tree.

i think that could be easier.

or maybe you can just take them all through the omap tree? the wlcore
tree is not under active development, so i don't expect conflicts
there.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

On Fri, Mar 13, 2015 at 5:13 PM, Tony Lindgren t...@atomide.com wrote:
 * Eliad Peller el...@wizery.com [150312 05:10]:
 Now that we have wlcore device-tree bindings in place
 (for both wl12xx and wl18xx), remove the legacy
 wl12xx_platform_data struct, and move its members
 into the platform device data (that is passed to wlcore)

 Davinci 850 is the only platform that still set
 the platform data in the legacy way (and doesn't
 have DT bindings), so remove the relevant
 code/Kconfig option from the board file (as suggested
 by Sekhar Nori)

 Signed-off-by: Luciano Coelho l...@coelho.fi
 Signed-off-by: Eliad Peller el...@wizery.com
 ---
  arch/arm/mach-davinci/Kconfig  |  11 ---
  arch/arm/mach-davinci/board-da850-evm.c| 113 
 -
  drivers/net/wireless/ti/wilink_platform_data.c |  25 --
  drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
  drivers/net/wireless/ti/wlcore/boot.c  |   1 -
  drivers/net/wireless/ti/wlcore/main.c  |   4 +-
  drivers/net/wireless/ti/wlcore/sdio.c  |  75 +---
  drivers/net/wireless/ti/wlcore/wlcore_i.h  |   8 +-
  include/linux/wl12xx.h |  25 --
  9 files changed, 36 insertions(+), 245 deletions(-)

 I got a build error related to the SPI driver with this series, probably
 need to update this patch:

 drivers/net/wireless/ti/wlcore/spi.c: In function ‘wl1271_probe’:
 drivers/net/wireless/ti/wlcore/spi.c:334:11: error: ‘struct 
 wlcore_platdev_data’ has no member named ‘pdata’
   pdev_data.pdata = dev_get_platdata(spi-dev);
^
 drivers/net/wireless/ti/wlcore/spi.c:335:16: error: ‘struct 
 wlcore_platdev_data’ has no member named ‘pdata’
   if (!pdev_data.pdata) {

yeah, i missed it :/

looks like there's no platform that defines platform data for it.
i'll replace the dev_get_platdata() with a function that only parses
the clock-frequency properties (the irq is taken in this case from the
spi_device).
(or maybe i should just drop it, as no one actually uses it?)

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wl18xx: Bad format for rx_frames_per_rates in debugfs?

[Eliad Peller]

On Thu, Mar 12, 2015 at 2:39 PM, Nicolas Iooss
nicolas.iooss_li...@m4x.org wrote:
 Hello,

 While adding __printf attributes to several functions in the kernel, I
 got a surprising gcc warning in drivers/net/wireless/ti/wl18xx/debugfs.c
 about format '%u' expects argument of type 'unsigned int', but argument
 5 has type 'u32 *'.

 Indeed it seems that commit c5d94169e818 (wl18xx: use new fw stats
 structures) [1] introduced an array field u32 rx_frames_per_rates[50]
 in struct wl18xx_acx_rx_rate_stat but is using
 WL18XX_DEBUGFS_FWSTATS_FILE(rx_rate, rx_frames_per_rates, %u); instead
 of something like WL18XX_DEBUGFS_FWSTATS_FILE_ARRAY(rx_rate,
 rx_frames_per_rates, 50); for displaying this value.  So I believe that
 currently the rx_rate entry in debugfs contains a kernel pointer instead
 of the actual data.  As I don't have the hardware to test I can't be
 sure of it.

 Is this a real bug which needs to be fixed or something weird I haven't
 understood yet?

yes, seems like a bug.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 4/6] wlcore: add device-tree support

[Eliad Peller]

When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.

Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
v6: parse frequency properties, add wl12xx compatible strings

 drivers/net/wireless/ti/wlcore/sdio.c | 93 ---
 1 file changed, 87 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 2bce00a..b55dc0e 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
 #include linux/wl12xx.h
 #include linux/pm_runtime.h
 #include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
 
 #include wlcore.h
 #include wl12xx_80211.h
@@ -214,6 +216,82 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+   { .compatible = ti,wl1271 },
+   { .compatible = ti,wl1273 },
+   { .compatible = ti,wl1281 },
+   { .compatible = ti,wl1283 },
+   { .compatible = ti,wl1801 },
+   { .compatible = ti,wl1805 },
+   { .compatible = ti,wl1807 },
+   { .compatible = ti,wl1831 },
+   { .compatible = ti,wl1835 },
+   { .compatible = ti,wl1837 },
+   { }
+};
+
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct wl12xx_platform_data *pdata;
+
+   if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
+   return NULL;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-irq = irq_of_parse_and_map(np, 0);
+   if (!pdata-irq) {
+   dev_err(dev, No irq in platform data\n);
+   kfree(pdata);
+   return NULL;
+   }
+
+   pdata-irq_trigger =
+   irqd_get_trigger_type(irq_get_irq_data(pdata-irq));
+
+   /* optional clock frequency params */
+   of_property_read_u32(np, ref-clock-frequency,
+pdata-ref_clock_freq);
+   of_property_read_u32(np, tcxo-clock-frequency,
+pdata-tcxo_clock_freq);
+
+   return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+   struct wl12xx_platform_data *pdata;
+
+   /* first, look for DT data */
+   pdata = wlcore_probe_of(dev);
+   if (pdata)
+   return pdata;
+
+   /* if not found - fallback to static platform data */
+   pdata = wl12xx_get_platform_data();
+   if (!IS_ERR(pdata))
+   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+   dev_err(dev, No platform data set\n);
+   return NULL;
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+   kfree(pdata);
+}
+
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
@@ -245,12 +323,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   pdev_data.pdata = wl12xx_get_platform_data();
-   if (IS_ERR(pdev_data.pdata)) {
-   ret = PTR_ERR(pdev_data.pdata);
-   dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+   pdev_data.pdata = wlcore_get_platform_data(func-dev);
+   if (!pdev_data.pdata)
goto out_free_glue;
-   }
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +354,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out_free_pdata;
}
 
glue-core-dev.parent = func-dev;
@@ -313,6 +388,9 @@ static int wl1271_probe(struct sdio_func *func,
 out_dev_put:
platform_device_put(glue-core);
 
+out_free_pdata:
+   wlcore_del_platform_data(pdev_data.pdata);
+
 out_free_glue:
kfree(glue);
 
@@ -323,11 +401,14 @@ out:
 static void wl1271_remove(struct sdio_func *func)
 {
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+   struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
+   struct wl12xx_platform_data *pdata = pdev_data-pdata;
 
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
 
platform_device_unregister(glue-core);
+   wlcore_del_platform_data(pdata);
kfree(glue

[PATCH v6 6/6] wlcore: remove wl12xx_platform_data

[Eliad Peller]

Now that we have wlcore device-tree bindings in place
(for both wl12xx and wl18xx), remove the legacy
wl12xx_platform_data struct, and move its members
into the platform device data (that is passed to wlcore)

Davinci 850 is the only platform that still set
the platform data in the legacy way (and doesn't
have DT bindings), so remove the relevant
code/Kconfig option from the board file (as suggested
by Sekhar Nori)

Signed-off-by: Luciano Coelho l...@coelho.fi
Signed-off-by: Eliad Peller el...@wizery.com
---
 arch/arm/mach-davinci/Kconfig  |  11 ---
 arch/arm/mach-davinci/board-da850-evm.c| 113 -
 drivers/net/wireless/ti/wilink_platform_data.c |  25 --
 drivers/net/wireless/ti/wl12xx/main.c  |  19 ++---
 drivers/net/wireless/ti/wlcore/boot.c  |   1 -
 drivers/net/wireless/ti/wlcore/main.c  |   4 +-
 drivers/net/wireless/ti/wlcore/sdio.c  |  75 +---
 drivers/net/wireless/ti/wlcore/wlcore_i.h  |   8 +-
 include/linux/wl12xx.h |  25 --
 9 files changed, 36 insertions(+), 245 deletions(-)

diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig
index 584e8d4..6bb1049 100644
--- a/arch/arm/mach-davinci/Kconfig
+++ b/arch/arm/mach-davinci/Kconfig
@@ -198,17 +198,6 @@ config DA850_UI_SD_VIDEO_PORT
 
 endchoice
 
-config DA850_WL12XX
-   bool AM18x wl1271 daughter board
-   depends on MACH_DAVINCI_DA850_EVM
-   help
- The wl1271 daughter card for AM18x EVMs is a combo wireless
- connectivity add-on card, based on the LS Research TiWi module with
- Texas Instruments' wl1271 solution.
- Say Y if you want to use a wl1271 expansion card connected to the
- AM18x EVM.
-
-
 config MACH_MITYOMAPL138
bool Critical Link MityDSP-L138/MityARM-1808 SoM
depends on ARCH_DAVINCI_DA850
diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 853b941..1ed545c 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -38,7 +38,6 @@
 #include linux/regulator/fixed.h
 #include linux/spi/spi.h
 #include linux/spi/flash.h
-#include linux/wl12xx.h
 
 #include mach/common.h
 #include mach/cp_intc.h
@@ -60,9 +59,6 @@
 #define DA850_MMCSD_CD_PIN GPIO_TO_PIN(4, 0)
 #define DA850_MMCSD_WP_PIN GPIO_TO_PIN(4, 1)
 
-#define DA850_WLAN_EN  GPIO_TO_PIN(6, 9)
-#define DA850_WLAN_IRQ GPIO_TO_PIN(6, 10)
-
 #define DA850_MII_MDIO_CLKEN_PIN   GPIO_TO_PIN(2, 6)
 
 static struct mtd_partition da850evm_spiflash_part[] = {
@@ -1343,110 +1339,6 @@ static __init void da850_vpif_init(void)
 static __init void da850_vpif_init(void) {}
 #endif
 
-#ifdef CONFIG_DA850_WL12XX
-
-static void wl12xx_set_power(int index, bool power_on)
-{
-   static bool power_state;
-
-   pr_debug(Powering %s wl12xx, power_on ? on : off);
-
-   if (power_on == power_state)
-   return;
-   power_state = power_on;
-
-   if (power_on) {
-   /* Power up sequence required for wl127x devices */
-   gpio_set_value(DA850_WLAN_EN, 1);
-   usleep_range(15000, 15000);
-   gpio_set_value(DA850_WLAN_EN, 0);
-   usleep_range(1000, 1000);
-   gpio_set_value(DA850_WLAN_EN, 1);
-   msleep(70);
-   } else {
-   gpio_set_value(DA850_WLAN_EN, 0);
-   }
-}
-
-static struct davinci_mmc_config da850_wl12xx_mmc_config = {
-   .set_power  = wl12xx_set_power,
-   .wires  = 4,
-   .max_freq   = 2500,
-   .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_NONREMOVABLE |
- MMC_CAP_POWER_OFF_CARD,
-};
-
-static const short da850_wl12xx_pins[] __initconst = {
-   DA850_MMCSD1_DAT_0, DA850_MMCSD1_DAT_1, DA850_MMCSD1_DAT_2,
-   DA850_MMCSD1_DAT_3, DA850_MMCSD1_CLK, DA850_MMCSD1_CMD,
-   DA850_GPIO6_9, DA850_GPIO6_10,
-   -1
-};
-
-static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
-   .irq= -1,
-   .irq_trigger= IRQ_TYPE_EDGE_RISING,
-   .ref_clock_freq = 3840,
-   .ref_clock_xtal = false,
-};
-
-static __init int da850_wl12xx_init(void)
-{
-   int ret;
-
-   ret = davinci_cfg_reg_list(da850_wl12xx_pins);
-   if (ret) {
-   pr_err(wl12xx/mmc mux setup failed: %d\n, ret);
-   goto exit;
-   }
-
-   ret = da850_register_mmcsd1(da850_wl12xx_mmc_config);
-   if (ret) {
-   pr_err(wl12xx/mmc registration failed: %d\n, ret);
-   goto exit;
-   }
-
-   ret = gpio_request_one(DA850_WLAN_EN, GPIOF_OUT_INIT_LOW, wl12xx_en);
-   if (ret) {
-   pr_err(Could not request wl12xx enable gpio: %d\n, ret);
-   goto exit;
-   }
-
-   ret = gpio_request_one

[PATCH v6 0/6] wlcore: add device-tree support

[Eliad Peller]

Add device-tree support to the wlcore (wl12xx/wl18xx)
driver.

Update the current users to use the bindings instead
of pdata-quirks.

Finally, remove the deprecated wl12xx_platform_data
struct (along with the da850 board file code that
still uses it)

NOTE: all the platform patches were compile-tested
only. I'm looking for some wl12xx card (that i should
have somewhere) to test the wl12xx changes (wrt. clocks),
but haven't found it yet.

v6:
* Add Luca's patches to pass irq_trigger/freq
* Support wl12xx as well
* Update all relevant platforms

Eliad Peller (4):
  dt: bindings: add TI's wilink wireless device
  wlcore: add device-tree support
  ARM: dts: add wl12xx/wl18xx bindings
  wlcore: remove wl12xx_platform_data

Luciano Coelho (2):
  wlcore: set irq_trigger in board files instead of hiding behind a
quirk
  wl12xx: use frequency instead of enumerations for pdata clocks

 .../devicetree/bindings/net/wireless/ti,wlcore.txt |  47 +
 arch/arm/boot/dts/am335x-evmsk.dts |  11 ++
 arch/arm/boot/dts/omap3-cm-t3517.dts   |  10 ++
 arch/arm/boot/dts/omap3-cm-t3730.dts   |  10 ++
 arch/arm/boot/dts/omap3-evm-common.dtsi|  10 ++
 arch/arm/boot/dts/omap3-igep0020-rev-f.dts |   9 ++
 arch/arm/boot/dts/omap3-igep0030-rev-g.dts |   9 ++
 arch/arm/boot/dts/omap3-zoom3.dts  |  10 ++
 arch/arm/boot/dts/omap4-panda-common.dtsi  |  10 ++
 arch/arm/boot/dts/omap4-sdp.dts|  11 ++
 arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi |  10 ++
 arch/arm/mach-davinci/Kconfig  |  11 --
 arch/arm/mach-davinci/board-da850-evm.c| 112 -
 arch/arm/mach-omap2/pdata-quirks.c |  79 ---
 drivers/net/wireless/ti/wilink_platform_data.c |  25 -
 drivers/net/wireless/ti/wl12xx/main.c  |  63 ++--
 drivers/net/wireless/ti/wl12xx/wl12xx.h|  28 ++
 drivers/net/wireless/ti/wlcore/boot.c  |   1 -
 drivers/net/wireless/ti/wlcore/debugfs.c   |   2 +-
 drivers/net/wireless/ti/wlcore/main.c  |  31 +++---
 drivers/net/wireless/ti/wlcore/sdio.c  |  64 ++--
 drivers/net/wireless/ti/wlcore/wlcore.h|   5 +-
 drivers/net/wireless/ti/wlcore/wlcore_i.h  |   8 +-
 include/linux/wl12xx.h |  49 -
 24 files changed, 313 insertions(+), 312 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt

-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6 1/6] wlcore: set irq_trigger in board files instead of hiding behind a quirk

[Eliad Peller]

From: Luciano Coelho l...@coelho.fi

The platform_quirk element in the platform data was used
to change the way the IRQ is triggered.  When set,
the EDGE_IRQ quirk would change the irqflags used
and treat edge trigger differently from the rest.

Instead of hiding this irq flag setting behind the quirk,
have the board files set the irq_trigger explicitly.

This will allow us to use standard irq DT definitions
later on.

Signed-off-by: Luciano Coelho l...@coelho.fi
[Eliad - rebase, add irq_trigger field and pass it,
update board file changes]
Signed-off-by: Eliad Peller el...@wizery.com
---
 arch/arm/mach-davinci/board-da850-evm.c  |  2 +-
 arch/arm/mach-omap2/pdata-quirks.c   |  1 +
 drivers/net/wireless/ti/wlcore/debugfs.c |  2 +-
 drivers/net/wireless/ti/wlcore/main.c| 27 ---
 drivers/net/wireless/ti/wlcore/sdio.c|  2 +-
 drivers/net/wireless/ti/wlcore/wlcore.h  |  5 ++---
 include/linux/wl12xx.h   |  5 +
 7 files changed, 23 insertions(+), 21 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 6b5a97d..916589c 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1385,8 +1385,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
+   .irq_trigger= IRQ_TYPE_EDGE_RISING,
.board_ref_clock= WL12XX_REFCLOCK_38,
-   .platform_quirks= WL12XX_PLATFORM_QUIRK_EDGE_IRQ,
 };
 
 static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 190fa43..4449f4c 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -48,6 +48,7 @@ static void __init __used legacy_init_wl12xx(unsigned 
ref_clock,
wl12xx.board_ref_clock = ref_clock;
wl12xx.board_tcxo_clock = tcxo_clock;
wl12xx.irq = gpio_to_irq(gpio);
+   wl12xx.irq_trigger = IRQ_TYPE_LEVEL_HIGH;
 
res = wl12xx_set_platform_data(wl12xx);
if (res) {
diff --git a/drivers/net/wireless/ti/wlcore/debugfs.c 
b/drivers/net/wireless/ti/wlcore/debugfs.c
index 68f3bf2..eb43f94 100644
--- a/drivers/net/wireless/ti/wlcore/debugfs.c
+++ b/drivers/net/wireless/ti/wlcore/debugfs.c
@@ -502,7 +502,7 @@ static ssize_t driver_state_read(struct file *file, char 
__user *user_buf,
DRIVER_STATE_PRINT_HEX(irq);
/* TODO: ref_clock and tcxo_clock were moved to wl12xx priv */
DRIVER_STATE_PRINT_HEX(hw_pg_ver);
-   DRIVER_STATE_PRINT_HEX(platform_quirks);
+   DRIVER_STATE_PRINT_HEX(irq_flags);
DRIVER_STATE_PRINT_HEX(chip.id);
DRIVER_STATE_PRINT_STR(chip.fw_ver_str);
DRIVER_STATE_PRINT_STR(chip.phy_fw_ver_str);
diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 1e13699..67518f6 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -27,6 +27,7 @@
 #include linux/vmalloc.h
 #include linux/wl12xx.h
 #include linux/interrupt.h
+#include linux/irq.h
 
 #include wlcore.h
 #include debug.h
@@ -538,7 +539,7 @@ static int wlcore_irq_locked(struct wl1271 *wl)
 * In case edge triggered interrupt must be used, we cannot iterate
 * more than once without introducing race conditions with the hardirq.
 */
-   if (wl-platform_quirks  WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
+   if (wl-irq_flags  (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING))
loopcount = 1;
 
wl1271_debug(DEBUG_IRQ, IRQ work);
@@ -6249,7 +6250,6 @@ struct ieee80211_hw *wlcore_alloc_hw(size_t priv_size, 
u32 aggr_buf_size,
wl-ap_ps_map = 0;
wl-ap_fw_ps_map = 0;
wl-quirks = 0;
-   wl-platform_quirks = 0;
wl-system_hlid = WL12XX_SYSTEM_HLID;
wl-active_sta_count = 0;
wl-active_link_count = 0;
@@ -6391,7 +6391,8 @@ static void wlcore_nvs_cb(const struct firmware *fw, void 
*context)
struct platform_device *pdev = wl-pdev;
struct wlcore_platdev_data *pdev_data = dev_get_platdata(pdev-dev);
struct wl12xx_platform_data *pdata = pdev_data-pdata;
-   unsigned long irqflags;
+   struct resource *res;
+
int ret;
irq_handler_t hardirq_fn = NULL;
 
@@ -6418,19 +6419,23 @@ static void wlcore_nvs_cb(const struct firmware *fw, 
void *context)
/* adjust some runtime configuration parameters */
wlcore_adjust_conf(wl);
 
-   wl-irq = platform_get_irq(pdev, 0);
-   wl-platform_quirks = pdata-platform_quirks;
+   res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+   if (!res) {
+   wl1271_error(Could not get IRQ resource);
+   goto out_free_nvs;
+   }
+
+   wl-irq = res-start;
+   wl-irq_flags = res-flags  IRQF_TRIGGER_MASK;
wl

[PATCH v6 2/6] wl12xx: use frequency instead of enumerations for pdata clocks

[Eliad Peller]

From: Luciano Coelho l...@coelho.fi

Instead of defining an enumeration with the FW specific values for the
different clock rates, use the actual frequency instead.  Also add a
boolean to specify whether the clock is XTAL or not.

Change all board files to reflect this.

Signed-off-by: Luciano Coelho l...@coelho.fi
[Eliad - small fixes, update board file changes]
Signed-off-by: Eliad Peller el...@wizery.com
---
 arch/arm/mach-davinci/board-da850-evm.c |  3 +-
 arch/arm/mach-omap2/pdata-quirks.c  | 29 
 drivers/net/wireless/ti/wl12xx/main.c   | 60 ++---
 drivers/net/wireless/ti/wl12xx/wl12xx.h | 28 +++
 include/linux/wl12xx.h  | 27 ++-
 5 files changed, 103 insertions(+), 44 deletions(-)

diff --git a/arch/arm/mach-davinci/board-da850-evm.c 
b/arch/arm/mach-davinci/board-da850-evm.c
index 916589c..853b941 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1386,7 +1386,8 @@ static const short da850_wl12xx_pins[] __initconst = {
 static struct wl12xx_platform_data da850_wl12xx_wlan_data __initdata = {
.irq= -1,
.irq_trigger= IRQ_TYPE_EDGE_RISING,
-   .board_ref_clock= WL12XX_REFCLOCK_38,
+   .ref_clock_freq = 3840,
+   .ref_clock_xtal = false,
 };
 
 static __init int da850_wl12xx_init(void)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 4449f4c..337cc22 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -39,14 +39,14 @@ static struct twl4030_gpio_platform_data twl_gpio_auxdata;
 
 static struct wl12xx_platform_data wl12xx __initdata;
 
-static void __init __used legacy_init_wl12xx(unsigned ref_clock,
-unsigned tcxo_clock,
+static void __init __used legacy_init_wl12xx(u32 ref_clock_freq,
+u32 tcxo_clock_freq,
 int gpio)
 {
int res;
 
-   wl12xx.board_ref_clock = ref_clock;
-   wl12xx.board_tcxo_clock = tcxo_clock;
+   wl12xx.ref_clock_freq = ref_clock_freq;
+   wl12xx.tcxo_clock_freq = tcxo_clock_freq;
wl12xx.irq = gpio_to_irq(gpio);
wl12xx.irq_trigger = IRQ_TYPE_LEVEL_HIGH;
 
@@ -57,8 +57,8 @@ static void __init __used legacy_init_wl12xx(unsigned 
ref_clock,
}
 }
 #else
-static inline void legacy_init_wl12xx(unsigned ref_clock,
- unsigned tcxo_clock,
+static inline void legacy_init_wl12xx(u32 ref_clock_freq,
+ u32 tcxo_clock_freq,
  int gpio)
 {
 }
@@ -130,7 +130,7 @@ static void __init omap3_sbc_t3730_twl_init(void)
 static void __init omap3_sbc_t3730_legacy_init(void)
 {
omap3_sbc_t3x_usb_hub_init(167, sb-t35 usb hub);
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 136);
+   legacy_init_wl12xx(3840, 0, 136);
 }
 
 static void __init omap3_sbc_t3530_legacy_init(void)
@@ -174,12 +174,12 @@ static void __init omap3_igep0030_rev_g_legacy_init(void)
 
 static void __init omap3_evm_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 149);
+   legacy_init_wl12xx(3840, 0, 149);
 }
 
 static void __init omap3_zoom_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_26, 0, 162);
+   legacy_init_wl12xx(2600, 0, 162);
 }
 
 static void am35xx_enable_emac_int(void)
@@ -246,7 +246,7 @@ static void __init omap3_sbc_t3517_legacy_init(void)
am35xx_emac_reset();
hsmmc2_internal_input_clk();
omap3_sbc_t3517_wifi_init();
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 145);
+   legacy_init_wl12xx(3840, 0, 145);
 }
 
 static void __init am3517_evm_legacy_init(void)
@@ -291,18 +291,17 @@ static void __init omap3_tao3530_legacy_init(void)
 #ifdef CONFIG_ARCH_OMAP4
 static void __init omap4_sdp_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_26,
-  WL12XX_TCXOCLOCK_26, 53);
+   legacy_init_wl12xx(2600, 2600, 53);
 }
 
 static void __init omap4_panda_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
+   legacy_init_wl12xx(3840, 0, 53);
 }
 
 static void __init var_som_om44_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 41);
+   legacy_init_wl12xx(3840, 0, 41);
 }
 #endif
 
@@ -317,7 +316,7 @@ static struct iommu_platform_data omap4_iommu_pdata = {
 #ifdef CONFIG_SOC_AM33XX
 static void __init am335x_evmsk_legacy_init(void)
 {
-   legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 31);
+   legacy_init_wl12xx(3840, 0, 31);
 }
 #endif
 
diff --git a/drivers/net/wireless/ti/wl12xx/main.c 
b/drivers/net/wireless/ti/wl12xx/main.c
index 144d1f8..b3f751f 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless

[PATCH v6 5/6] ARM: dts: add wl12xx/wl18xx bindings

[Eliad Peller]

Replace all the pdata-quirks for setting wl12xx/wl18xx
platform data with proper DT definitions.

The patch was compile-tested only.

Signed-off-by: Eliad Peller el...@wizery.com
---
v6: add wl12xx definitions as well

 arch/arm/boot/dts/am335x-evmsk.dts | 11 
 arch/arm/boot/dts/omap3-cm-t3517.dts   | 10 
 arch/arm/boot/dts/omap3-cm-t3730.dts   | 10 
 arch/arm/boot/dts/omap3-evm-common.dtsi| 10 
 arch/arm/boot/dts/omap3-igep0020-rev-f.dts |  9 +++
 arch/arm/boot/dts/omap3-igep0030-rev-g.dts |  9 +++
 arch/arm/boot/dts/omap3-zoom3.dts  | 10 
 arch/arm/boot/dts/omap4-panda-common.dtsi  | 10 
 arch/arm/boot/dts/omap4-sdp.dts| 11 
 arch/arm/boot/dts/omap4-var-som-om44-wlan.dtsi | 10 
 arch/arm/mach-omap2/pdata-quirks.c | 79 --
 11 files changed, 100 insertions(+), 79 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-evmsk.dts 
b/arch/arm/boot/dts/am335x-evmsk.dts
index df5fee6..87fc7a3 100644
--- a/arch/arm/boot/dts/am335x-evmsk.dts
+++ b/arch/arm/boot/dts/am335x-evmsk.dts
@@ -15,6 +15,7 @@
 
 #include am33xx.dtsi
 #include dt-bindings/pwm/pwm.h
+#include dt-bindings/interrupt-controller/irq.h
 
 / {
model = TI AM335x EVM-SK;
@@ -647,6 +648,16 @@
cap-power-off-card;
pinctrl-names = default;
pinctrl-0 = mmc2_pins;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1271;
+   reg = 2;
+   interrupt-parent = gpio1;
+   interrupts = 31 IRQ_TYPE_LEVEL_HIGH; /* gpio 31 */
+   ref-clock-frequency = 3840;
+   };
 };
 
 mcasp1 {
diff --git a/arch/arm/boot/dts/omap3-cm-t3517.dts 
b/arch/arm/boot/dts/omap3-cm-t3517.dts
index 0ab748c..f5b5a1d 100644
--- a/arch/arm/boot/dts/omap3-cm-t3517.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3517.dts
@@ -133,6 +133,16 @@
non-removable;
bus-width = 4;
cap-power-off-card;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1271;
+   reg = 2;
+   interrupt-parent = gpio5;
+   interrupts = 17 IRQ_TYPE_LEVEL_HIGH; /* gpio 145 */
+   ref-clock-frequency = 3840;
+   };
 };
 
 dss {
diff --git a/arch/arm/boot/dts/omap3-cm-t3730.dts 
b/arch/arm/boot/dts/omap3-cm-t3730.dts
index 46eadb2..2294f5b 100644
--- a/arch/arm/boot/dts/omap3-cm-t3730.dts
+++ b/arch/arm/boot/dts/omap3-cm-t3730.dts
@@ -73,6 +73,16 @@
non-removable;
bus-width = 4;
cap-power-off-card;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1271;
+   reg = 2;
+   interrupt-parent = gpio5;
+   interrupts = 8 IRQ_TYPE_LEVEL_HIGH; /* gpio 136 */
+   ref-clock-frequency = 3840;
+   };
 };
 
 dss {
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi 
b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 127f3e7..346552b 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -106,6 +106,16 @@
non-removable;
bus-width = 4;
cap-power-off-card;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1271;
+   reg = 2;
+   interrupt-parent = gpio5;
+   interrupts = 21 IRQ_TYPE_LEVEL_HIGH; /* gpio 149 */
+   ref-clock-frequency = 3840;
+   };
 };
 
 twl_gpio {
diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts 
b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
index cc8bd0c..72f7cdc 100644
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -42,4 +42,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio6;
+   interrupts = 17 IRQ_TYPE_LEVEL_HIGH; /* gpio 177 */
+   };
 };
diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts 
b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
index 9326b28..b899e34 100644
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -64,4 +64,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio5;
+   interrupts = 8 IRQ_TYPE_LEVEL_HIGH; /* gpio 136 */
+   };
 };
diff --git a/arch/arm/boot/dts/omap3-zoom3.dts 
b/arch/arm/boot/dts/omap3-zoom3.dts
index 6644f51..131448d 100644
--- a/arch/arm/boot/dts/omap3

[PATCH v6 3/6] dt: bindings: add TI's wilink wireless device

[Eliad Peller]

Add device tree binding documentation for TI's wilink
(wl12xx and wl18xx) wlan chip.

Signed-off-by: Eliad Peller el...@wizery.com
---
v6: add wl12xx, use IRQ_TYPE_LEVEL_HIGH

 .../devicetree/bindings/net/wireless/ti,wlcore.txt | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
new file mode 100644
index 000..2a3d90d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
@@ -0,0 +1,47 @@
+TI Wilink 6/7/8 (wl12xx/wl18xx) SDIO devices
+
+This node provides properties for controlling the wilink wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+ - compatible: should be one of the following:
+* ti,wl1271
+* ti,wl1273
+* ti,wl1281
+* ti,wl1283
+* ti,wl1801
+* ti,wl1805
+* ti,wl1807
+* ti,wl1831
+* ti,wl1835
+* ti,wl1837
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Optional properties:
+ - interrupt-parent : the phandle for the interrupt controller to which the
+   device interrupts are connected.
+ - ref-clock-frequency : ref clock frequency in Hz
+ - tcxo-clock-frequency : tcxo clock frequency in Hz
+
+Note: the *-clock-frequency properties assume internal clocks. In case of 
external
+clock, new bindings (for parsing the clock nodes) have to be added.
+
+Example:
+
+mmc3 {
+   status = okay;
+   vmmc-supply = wlan_en_reg;
+   bus-width = 4;
+   cap-power-off-card;
+   keep-power-in-suspend;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio0;
+   interrupts = 19 IRQ_TYPE_LEVEL_HIGH;
+   };
+};
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Wed, Mar 11, 2015 at 3:21 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 On Wed, Mar 11, 2015 at 2:17 PM, Arnd Bergmann a...@arndb.de wrote:
 On Wednesday 11 March 2015 14:07:11 Javier Martinez Canillas wrote:

 Right now it seems that all boards in mainline with a WiLink6 part are
 using internal clocks. So as a first step I think that adding an
 optional refclock-frequency and tcxoclock-frequency properties should
 be enough.

 It would be good if the driver supports getting the refclock and
 tcxoclock from an external provider in case a board gets these from
 external clocks but that can be done as a followup if there are boards
 in the future using that design.

 But please bear in mind that I'm not familiar with the clock handling
 in WiLink6 since the WiLink8 part used in the IGEP boards does not
 need these clocks and I only looked at Luciano's previous patches and
 the WiLink today driver today. So it would be good if Eliad can double
 check my assumptions to see if those are correct.

sounds right. that's what i know as well.

 Sounds good. I'd also be fine with not implementing the case for
 external clocks in the code until we need (and can test) it, but
 I think it should be specified in the binding from the start.

 Agreed.

great. so i'll implement the internal clocks case only.

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

hi Javier,

On Wed, Mar 11, 2015 at 2:28 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 Hello Eliad,

 On Mon, Mar 9, 2015 at 4:36 PM, Eliad Peller el...@wizery.com wrote:
 Add wl18xx (wilink8) bindings to omap3-igep0030-rev-g and
 omap3-igep0020-rev-f dts files, instead of defining the
 platform data through the pdata-quirks.

 The patch was compile-tested only.


 You should look at MAINTAINERS or use ./scripts/get_maintainer.pl to
 know who should be cc'ed. Specially for this kind of patches where you
 are not able to test on the actual platform. Added Enric to cc as well
 since he also maintains the IGEP boards an has access to the hw too.

right. sorry about that.
i assumed adding the relevant mailing lists should be enough, but i
guess i should have added the relevant maintainers as well.

  arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 +
  arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 +
  arch/arm/mach-omap2/pdata-quirks.c | 2 --
  3 files changed, 18 insertions(+), 2 deletions(-)

 diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts 
 b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
 index cc8bd0c..8e5b44e 100644
 --- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
 @@ -42,4 +42,13 @@
 vmmc-supply = lbep5clwmc_wlen;
 bus-width = 4;
 non-removable;
 +
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   wlcore: wlcore@2 {
 +   compatible = ti,wl1835;
 +   reg = 2;
 +   interrupt-parent = gpio6;
 +   interrupts = 17 IRQ_TYPE_NONE;

 As Arnd said, it seems this should be IRQ_TYPE_LEVEL_HIGH to match
 what the platform code is currently doing.

will be fixed.

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

hi Javier,

On Wed, Mar 11, 2015 at 3:19 AM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 Hello Eliad,

 On Wed, Mar 11, 2015 at 1:28 AM, Javier Martinez Canillas
 jav...@dowhile0.org wrote:
 On Mon, Mar 9, 2015 at 4:36 PM, Eliad Peller el...@wizery.com wrote:
 --- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
 +++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
 @@ -42,4 +42,13 @@
 vmmc-supply = lbep5clwmc_wlen;

 Something I forgot to mention is that this vmmc-supply is a DT hack
 since the WLAN SDIO chip needs a WL_EN signal to be asserted as a part
 of the chip power sequencing.

 But there wasn't a DT binding to describe that so most boards use the
 same hack which is to define a fake fixed-regulator with an enable
 GPIO just to toggle that pin.

 But now the MMC subsystem has support for power sequence providers and
 the pwrseq-simple driver
 (Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt) has
 support for reset GPIOs so you may want to change that as well.

interesting. i wasn't aware of it.
but that's for a different time i guess :)

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 2/3] wl18xx: add basic device-tree support

[Eliad Peller]

On Wed, Mar 11, 2015 at 11:51 AM, Arnd Bergmann a...@arndb.de wrote:
  +static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
  +{
  +   kfree(pdata);
  +}
  +

 This function seems to be an unnecessary, why not just call kfree() directly?

 Or better, maybe the resource-managed devm_*() functions can be used
 so the data doesn't have to be explicitly freed?

 As I said earlier, I think it would be best not to dynamically allocate 
 anything
 here at all. As Eliad explained, the data is used by two different drivers:
 wl12xx and wl18xx, and only the latter is converted for now, but after the
 conversion, it should not need the platform data structure any more, only
 the irq number that gets passed in from DT.

sure, i'll try taking care of it (probably with additional patch after
the conversion)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Wed, Mar 11, 2015 at 1:34 PM, Javier Martinez Canillas
jav...@dowhile0.org wrote:
 I think that patch [0] should not be needed since for external clocks,
 the IP providing the clocks should have its own clock driver and for
 internal clocks, a property should be used instead as you said.

 If there is no external clock provider for this chip and the clocks
 are provided by the device itself, then all we need is a clock-frequency
 property in the device node.


 Agreed, IIUC Luciano wanted to expose the internal clocks by
 registering in the common clock framework but if those clocks are not
 really accessible from outside the wlan chip, then I also think that a
 device node property should be used instead.

how should i describe multiple clock-frequency properties (there are 2
relevant clocks) in this case?

does something like the following makes sense?

wlcore: wlcore@2 {
...
refclock: refclock {
compatible = fixed-clock;
#clock-cells = 0;
clock-frequency = 3840;
};
}

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
 * Eliad Peller el...@wizery.com [150309 14:03]:
 On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
  On Monday 09 March 2015 17:36:42 Eliad Peller wrote:
  --- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
  +++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
  @@ -64,4 +64,13 @@
  vmmc-supply = lbep5clwmc_wlen;
  bus-width = 4;
  non-removable;
  +
  +   #address-cells = 1;
  +   #size-cells = 0;
  +   wlcore: wlcore@2 {
  +   compatible = ti,wl1835;
  +   reg = 2;
  +   interrupt-parent = gpio5;
  +   interrupts = 8 IRQ_TYPE_NONE;
  +   };
 
 
  Why IRQ_TYPE_NONE?
 
 i simply mirrored the current board file (which only sets the irq number).

  I was expecting you to remove all calls to legacy_init_wl12xx from this 
  file,
  including the ones for wl12xx aside from the wl18xx ones you removed, but
  if that's enough to clean out the platform_data handling from the wlcore
  driver, it's good enough as a start.
 not sure i'm following - can you elaborate?

 i'll summarize the way i see it. please correct me if i'm wrong.

 both wl18xx and wl12xx use the platform data to get the irq number.
 wl12xx (only) also needs some additional clock definitions to be
 passed. there's currently some issue with specifying some the of clock
 sources, so i preferred starting only with (the simpler) wl18xx
 bindings.

 for platforms with wl18xx, we can remove the pdata-quirk, as all the
 data (i.e. irq) can be passed by the new DT bindings.
 however, for platforms with wl12xx, we still need to pass the clock
 definitions (along with the irq), so we have to keep
 legacy_init_wl12xx for the time being (and that's also why we have to
 currently keep the platform_data handling in the wlcore driver)

 do you have something else in mind?

 I think what Arnd is saying is we've now removed all the wl12xx using
 legacy platforms, so all of them can boot with just data from dts.

I don't think that's the case (unless i'm missing something).
e.g. there's still pdata-quirk for compulab,omap3-sbc-t3730 which
initializes wl12xx device.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote:
 On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
 On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
   I was expecting you to remove all calls to legacy_init_wl12xx from this 
   file,
   including the ones for wl12xx aside from the wl18xx ones you removed, 
   but
   if that's enough to clean out the platform_data handling from the wlcore
   driver, it's good enough as a start.
  not sure i'm following - can you elaborate?
 
  i'll summarize the way i see it. please correct me if i'm wrong.
 
  both wl18xx and wl12xx use the platform data to get the irq number.
  wl12xx (only) also needs some additional clock definitions to be
  passed. there's currently some issue with specifying some the of clock
  sources, so i preferred starting only with (the simpler) wl18xx
  bindings.
 
  for platforms with wl18xx, we can remove the pdata-quirk, as all the
  data (i.e. irq) can be passed by the new DT bindings.
  however, for platforms with wl12xx, we still need to pass the clock
  definitions (along with the irq), so we have to keep
  legacy_init_wl12xx for the time being (and that's also why we have to
  currently keep the platform_data handling in the wlcore driver)
 
  do you have something else in mind?
 
  I think what Arnd is saying is we've now removed all the wl12xx using
  legacy platforms, so all of them can boot with just data from dts.

 Right, that was my idea.

 I don't think that's the case (unless i'm missing something).
 e.g. there's still pdata-quirk for compulab,omap3-sbc-t3730 which
 initializes wl12xx device.

 This one is just like the igep0030, as Tony was saying: the board
 boots from device tree already, so now that we have a binding for
 it, we can remove the wl12xx_set_platform_data() for it.

i think the wl12xx_set_platform_data() name created some confusion -
it is used to pass platform data for both wl12xx and wl18xx devices.
(this confusion is all around the wlcore driver as well, due to the
code evolution)

the binding i added is for wl18xx only (there is no wl12xx binding yet).
the remaining boards, AFAICT, have wl12xx (rather than wl18xx) cards.
so i don't see how we can remove these wl12xx_set_platform_data()
calls before we have wl12xx bindings in-place as well.

 Unfortunately, there is still one machine that uses a board file
 in combination with this wl12xx: da850-evm calls
 wl12xx_set_platform_data() from a legacy board file without DT.

ditto.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Tue, Mar 10, 2015 at 6:18 PM, Tony Lindgren t...@atomide.com wrote:
 * Eliad Peller el...@wizery.com [150310 09:11]:
 On Tue, Mar 10, 2015 at 5:52 PM, Arnd Bergmann a...@arndb.de wrote:
  On Tuesday 10 March 2015 16:31:33 Eliad Peller wrote:
  On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote:
   On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
   On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com 
   wrote:
 I was expecting you to remove all calls to legacy_init_wl12xx 
 from this file,
 including the ones for wl12xx aside from the wl18xx ones you 
 removed, but
 if that's enough to clean out the platform_data handling from the 
 wlcore
 driver, it's good enough as a start.
not sure i'm following - can you elaborate?
   
i'll summarize the way i see it. please correct me if i'm wrong.
   
both wl18xx and wl12xx use the platform data to get the irq number.
wl12xx (only) also needs some additional clock definitions to be
passed. there's currently some issue with specifying some the of 
clock
sources, so i preferred starting only with (the simpler) wl18xx
bindings.
   
for platforms with wl18xx, we can remove the pdata-quirk, as all the
data (i.e. irq) can be passed by the new DT bindings.
however, for platforms with wl12xx, we still need to pass the clock
definitions (along with the irq), so we have to keep
legacy_init_wl12xx for the time being (and that's also why we have 
to
currently keep the platform_data handling in the wlcore driver)
   
do you have something else in mind?
   
I think what Arnd is saying is we've now removed all the wl12xx using
legacy platforms, so all of them can boot with just data from dts.
  
   Right, that was my idea.
  
   I don't think that's the case (unless i'm missing something).
   e.g. there's still pdata-quirk for compulab,omap3-sbc-t3730 which
   initializes wl12xx device.
  
   This one is just like the igep0030, as Tony was saying: the board
   boots from device tree already, so now that we have a binding for
   it, we can remove the wl12xx_set_platform_data() for it.
  
  i think the wl12xx_set_platform_data() name created some confusion -
  it is used to pass platform data for both wl12xx and wl18xx devices.
  (this confusion is all around the wlcore driver as well, due to the
  code evolution)
 
  the binding i added is for wl18xx only (there is no wl12xx binding yet).
  the remaining boards, AFAICT, have wl12xx (rather than wl18xx) cards.
  so i don't see how we can remove these wl12xx_set_platform_data()
  calls before we have wl12xx bindings in-place as well.
 
  What is missing for that binding then? I keep getting confused here,
  but I thought that they share the implementation that looks at the
  platform data.
 
 they both get the same wl12xx_platform_data struct, but only wl12xx
 cares about the clocks-related fields.
 the bindings i added parses only the irq.

 (Luca tried previously to upstream wl12xx DT support along with the
 required clock DT changes, but got some rejections, mainly wrt. clock
 stuff.
 e.g. http://thread.gmane.org/gmane.linux.kernel/1520752
 that's why i preferred starting with easier wl18xx bindings only)

 I believe we did not have clock bindings back then, now it's simple
 to get the clock. If it's some internal clock to the wl12xx, then
 that's a different story, it should be just hidden behind a compatible
 flag then.

i'm really not familiar with the common clock framework, but there
still doesn't seem to be a way to determine whether a clock is XTAL or
not (which is what Luca's patch was about). should we use compatible
flag in such case? i'm not sure it sounds right.

anyway, i'd really prefer, if possible, starting with the wl18xx
bindings, and defer the wl12xx complications to later on.
(i also need to find some wl12xx card in order to actually test the
patches once i'll have them...)

we do have to make sure these wl18xx bindings are future-compatible
with the wl12xx ones, but i think the current bindings are pretty much
standard (and are actually a subset of the bindings needed by wl12xx),
so it should be fine.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Tue, Mar 10, 2015 at 5:52 PM, Arnd Bergmann a...@arndb.de wrote:
 On Tuesday 10 March 2015 16:31:33 Eliad Peller wrote:
 On Tue, Mar 10, 2015 at 4:11 PM, Arnd Bergmann a...@arndb.de wrote:
  On Tuesday 10 March 2015 13:00:19 Eliad Peller wrote:
  On Tue, Mar 10, 2015 at 12:49 AM, Tony Lindgren t...@atomide.com wrote:
I was expecting you to remove all calls to legacy_init_wl12xx from 
this file,
including the ones for wl12xx aside from the wl18xx ones you 
removed, but
if that's enough to clean out the platform_data handling from the 
wlcore
driver, it's good enough as a start.
   not sure i'm following - can you elaborate?
  
   i'll summarize the way i see it. please correct me if i'm wrong.
  
   both wl18xx and wl12xx use the platform data to get the irq number.
   wl12xx (only) also needs some additional clock definitions to be
   passed. there's currently some issue with specifying some the of clock
   sources, so i preferred starting only with (the simpler) wl18xx
   bindings.
  
   for platforms with wl18xx, we can remove the pdata-quirk, as all the
   data (i.e. irq) can be passed by the new DT bindings.
   however, for platforms with wl12xx, we still need to pass the clock
   definitions (along with the irq), so we have to keep
   legacy_init_wl12xx for the time being (and that's also why we have to
   currently keep the platform_data handling in the wlcore driver)
  
   do you have something else in mind?
  
   I think what Arnd is saying is we've now removed all the wl12xx using
   legacy platforms, so all of them can boot with just data from dts.
 
  Right, that was my idea.
 
  I don't think that's the case (unless i'm missing something).
  e.g. there's still pdata-quirk for compulab,omap3-sbc-t3730 which
  initializes wl12xx device.
 
  This one is just like the igep0030, as Tony was saying: the board
  boots from device tree already, so now that we have a binding for
  it, we can remove the wl12xx_set_platform_data() for it.
 
 i think the wl12xx_set_platform_data() name created some confusion -
 it is used to pass platform data for both wl12xx and wl18xx devices.
 (this confusion is all around the wlcore driver as well, due to the
 code evolution)

 the binding i added is for wl18xx only (there is no wl12xx binding yet).
 the remaining boards, AFAICT, have wl12xx (rather than wl18xx) cards.
 so i don't see how we can remove these wl12xx_set_platform_data()
 calls before we have wl12xx bindings in-place as well.

 What is missing for that binding then? I keep getting confused here,
 but I thought that they share the implementation that looks at the
 platform data.

they both get the same wl12xx_platform_data struct, but only wl12xx
cares about the clocks-related fields.
the bindings i added parses only the irq.

(Luca tried previously to upstream wl12xx DT support along with the
required clock DT changes, but got some rejections, mainly wrt. clock
stuff.
e.g. http://thread.gmane.org/gmane.linux.kernel/1520752
that's why i preferred starting with easier wl18xx bindings only)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: handle hw roc cancel vs. expiration race

[Eliad Peller]

mac80211 handles roc expirations (indicated by
ieee80211_remain_on_channel_expired()) with a separate
work (hw_roc_done).

If userspace asks to cancel the ongoing roc before
hw_roc_done was scheduled, mac80211 will cancel
the ongoing roc, while leaving the hw_roc_done work
pending.

This might end up in the next roc being cancelled
by the stale work, causing mac80211 and the low-level
driver to go out of sync.

Fix it by cancelling hw_roc_done on roc cancel.
Since hw_roc_done takes local-mtx, temporarily
release it (before re-acquiring it and starting
the next roc if needed).

Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/cfg.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index dd4ff36..a80f7b3 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2782,7 +2782,22 @@ static int ieee80211_cancel_roc(struct ieee80211_local 
*local,
}
 
list_del(found-list);
+   mutex_unlock(local-mtx);
+
+   /*
+* The driver might have already expired the ROC (by
+* calling ieee80211_remain_on_channel_expired()), so
+* cancel the pending roc_done work (otherwise, it might
+* cancel the upcoming roc).
+*/
+   cancel_work_sync(local-hw_roc_done);
 
+   mutex_lock(local-mtx);
+   /*
+* We hold rtnl, so nothing should have been able to
+* manipulate the roc_list during the temporary
+* lock release.
+*/
if (found-started)
ieee80211_start_next_roc(local);
mutex_unlock(local-mtx);
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: handle hw roc cancel vs. expiration race

[Eliad Peller]

On Mon, Mar 9, 2015 at 2:52 PM, Johannes Berg johan...@sipsolutions.net wrote:
 On Mon, 2015-03-09 at 13:53 +0200, Eliad Peller wrote:

 Fix it by cancelling hw_roc_done on roc cancel.
 Since hw_roc_done takes local-mtx, temporarily
 release it (before re-acquiring it and starting
 the next roc if needed).

 I can't say I like this, and I'm not even sure it doesn't leave a race?
 After all, the work will not take the RTNL.

the other way (cancel while hw_roc_done) is protected, since
ieee80211_cancel_roc() looks for a specific roc cookie.

 Also, I think the whole concept is racy because you acquire found
 before the unlock, but use it after the unlock, so if the work actually
 ran (_sync, perhaps it already started) it may have freed the found
 pointer.

hw_roc_done work bails out in case of no started roc, so i think we're
safe here.

 I think the only way to really fix that is to make the driver return the
 roc pointer or so and then we can either queue a work struct per roc
 struct, or at least mark the roc struct as driver-destroyed and
 double-check that in the work function?

that was my initial implementation. but then i thought it will be
nicer to implement it in mac80211 and avoid changing all the drivers
(with the need to save the cookie, etc.)
do you prefer adding such cookie/pointer param?

 Or perhaps we could flush the work before we even take the lock, but
 then it might still race with the driver trying to cancel just after we
 flushed I guess.
right.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] wl18xx: add basic device-tree support

[Eliad Peller]

On Mon, Mar 9, 2015 at 10:50 AM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 09 March 2015 09:18:46 Eliad Peller wrote:
 On Sun, Mar 8, 2015 at 11:53 PM, Arnd Bergmann a...@arndb.de wrote:
  On Sunday 08 March 2015 13:13:13 Eliad Peller wrote:
 
   I've looked up the what boards actually use this data and found that
   all of them already support booting from DT: some omap2 boards using
   arch/arm/mach-omap2/pdata-quirks.c to provide the data, and the
   davinci 850evm. Can you make sure you add the correct data to all
   of these dts files as part of your series and remove the
   wl12xx_platform_data references?
 
  AFAICT, these board files add wl12xx platform data, while the new DT
  support is only for wl18xx.
 
 
  How can you tell the difference? What I see is that omap3pandora
  (and nothing else) calls wl1251_set_platform_data(), while
  da850-evm and all omap3/omap4 boards use wl12xx_set_platform_data().
 
  The latter seems to refer to all wl12xx and wl18xx variants except
  for wl1251, based on my (very limited) understanding of that code.

 right.
 i got mislead because legacy_init_wl12xx() is defined there only for
 CONFIG_WL12XX (and not for CONFIG_WL18XX).
 it looks like only isee,omap3-igep0020-rev-f and
 isee,omap3-igep0020-rev-g have pdata quirks for wl18xx (and thus
 initialize the pdata clocks to 0).

 Ok.

 sorry for the trivial question, but what's the standard way to submit
 such patch? should i simply add a third patch to the patchset which
 removes the pdata quirk and adds the missing dts definition? i don't
 have such board, so i can only compile-test it.

 Yes, I think that would be good. Depending on the complexity of the
 patch, you can do it in multiple ways:

 a) one patch to all the dts files, which also removes the
legacy_init_wl12xx() infrastructure

 b) one patch to add the .dts changes, a second patch to remove the
code from pdata-quirks.c and a third to remove the functionality
in the driver

 c) one patch per board.

 I'm fine with any of these, but the omap maintainers might have a
 preference.

thanks. i'll go with a single patch then (unless the maintainers
prefer otherwise).

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

Add wl18xx (wilink8) bindings to omap3-igep0030-rev-g and
omap3-igep0020-rev-f dts files, instead of defining the
platform data through the pdata-quirks.

The patch was compile-tested only.

Signed-off-by: Eliad Peller el...@wizery.com
---
 arch/arm/boot/dts/omap3-igep0020-rev-f.dts | 9 +
 arch/arm/boot/dts/omap3-igep0030-rev-g.dts | 9 +
 arch/arm/mach-omap2/pdata-quirks.c | 2 --
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts 
b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
index cc8bd0c..8e5b44e 100644
--- a/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
+++ b/arch/arm/boot/dts/omap3-igep0020-rev-f.dts
@@ -42,4 +42,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio6;
+   interrupts = 17 IRQ_TYPE_NONE;
+   };
 };
diff --git a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts 
b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
index 9326b28..02c4eec 100644
--- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
+++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
@@ -64,4 +64,13 @@
vmmc-supply = lbep5clwmc_wlen;
bus-width = 4;
non-removable;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio5;
+   interrupts = 8 IRQ_TYPE_NONE;
+   };
 };
diff --git a/arch/arm/mach-omap2/pdata-quirks.c 
b/arch/arm/mach-omap2/pdata-quirks.c
index 190fa43..abc8a20 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -159,14 +159,12 @@ static struct platform_device btwilink_device = {
 
 static void __init omap3_igep0020_rev_f_legacy_init(void)
 {
-   legacy_init_wl12xx(0, 0, 177);
platform_device_register(wl18xx_device);
platform_device_register(btwilink_device);
 }
 
 static void __init omap3_igep0030_rev_g_legacy_init(void)
 {
-   legacy_init_wl12xx(0, 0, 136);
platform_device_register(wl18xx_device);
platform_device_register(btwilink_device);
 }
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/3] dt: bindings: add wl18xx wireless device

[Eliad Peller]

Add device tree binding documentation for TI's wl18xx
wlan chip.

Signed-off-by: Eliad Peller el...@wizery.com
---
 .../devicetree/bindings/net/wireless/ti,wl18xx.txt | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
new file mode 100644
index 000..9dcf535
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
@@ -0,0 +1,39 @@
+TI Wilink8 (wl18xx) SDIO devices
+
+This node provides properties for controlling the wilink8 wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+ - compatible : Should be ti,wl18xx.
+ - compatible: should be one of the following:
+* ti,wl1801
+* ti,wl1805
+* ti,wl1807
+* ti,wl1831
+* ti,wl1835
+* ti,wl1837
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Optional properties:
+ - interrupt-parent : the phandle for the interrupt controller to which the
+   device interrupts are connected.
+
+Example:
+
+mmc3 {
+   status = okay;
+   vmmc-supply = wlan_en_reg;
+   bus-width = 4;
+   cap-power-off-card;
+   keep-power-in-suspend;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio0;
+   interrupts = 19 IRQ_TYPE_NONE;
+   };
+};
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/3] wl18xx: add basic device-tree support

[Eliad Peller]

When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.

For now, parse only the irq used. Other (optional) properties
can be added later on.

Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wlcore/sdio.c | 80 ---
 1 file changed, 74 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index d3dd7bf..ee556ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
 #include linux/wl12xx.h
 #include linux/pm_runtime.h
 #include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
 
 #include wlcore.h
 #include wl12xx_80211.h
@@ -214,6 +216,69 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+   { .compatible = ti,wl1801 },
+   { .compatible = ti,wl1805 },
+   { .compatible = ti,wl1807 },
+   { .compatible = ti,wl1831 },
+   { .compatible = ti,wl1835 },
+   { .compatible = ti,wl1837 },
+   { }
+};
+
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct wl12xx_platform_data *pdata;
+
+   if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
+   return NULL;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-irq = irq_of_parse_and_map(np, 0);
+   if (!pdata-irq) {
+   dev_err(dev, No irq in platform data\n);
+   kfree(pdata);
+   return NULL;
+   }
+
+   return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+   struct wl12xx_platform_data *pdata;
+
+   /* first, look for DT data */
+   pdata = wlcore_probe_of(dev);
+   if (pdata)
+   return pdata;
+
+   /* if not found - fallback to static platform data */
+   pdata = wl12xx_get_platform_data();
+   if (!IS_ERR(pdata))
+   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+   dev_err(dev, No platform data set\n);
+   return NULL;
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+   kfree(pdata);
+}
+
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
@@ -245,12 +310,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   pdev_data.pdata = wl12xx_get_platform_data();
-   if (IS_ERR(pdev_data.pdata)) {
-   ret = PTR_ERR(pdev_data.pdata);
-   dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+   pdev_data.pdata = wlcore_get_platform_data(func-dev);
+   if (!pdev_data.pdata)
goto out_free_glue;
-   }
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +341,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out_free_pdata;
}
 
glue-core-dev.parent = func-dev;
@@ -313,6 +375,9 @@ static int wl1271_probe(struct sdio_func *func,
 out_dev_put:
platform_device_put(glue-core);
 
+out_free_pdata:
+   wlcore_del_platform_data(pdev_data.pdata);
+
 out_free_glue:
kfree(glue);
 
@@ -323,11 +388,14 @@ out:
 static void wl1271_remove(struct sdio_func *func)
 {
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+   struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
+   struct wl12xx_platform_data *pdata = pdev_data-pdata;
 
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
 
platform_device_unregister(glue-core);
+   wlcore_del_platform_data(pdata);
kfree(glue);
 }
 
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 3/3] ARM: dts: igep00x0: add wl18xx bindings

[Eliad Peller]

On Mon, Mar 9, 2015 at 9:50 PM, Arnd Bergmann a...@arndb.de wrote:
 On Monday 09 March 2015 17:36:42 Eliad Peller wrote:
 --- a/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
 +++ b/arch/arm/boot/dts/omap3-igep0030-rev-g.dts
 @@ -64,4 +64,13 @@
 vmmc-supply = lbep5clwmc_wlen;
 bus-width = 4;
 non-removable;
 +
 +   #address-cells = 1;
 +   #size-cells = 0;
 +   wlcore: wlcore@2 {
 +   compatible = ti,wl1835;
 +   reg = 2;
 +   interrupt-parent = gpio5;
 +   interrupts = 8 IRQ_TYPE_NONE;
 +   };


 Why IRQ_TYPE_NONE?

i simply mirrored the current board file (which only sets the irq number).

 I was expecting you to remove all calls to legacy_init_wl12xx from this file,
 including the ones for wl12xx aside from the wl18xx ones you removed, but
 if that's enough to clean out the platform_data handling from the wlcore
 driver, it's good enough as a start.
not sure i'm following - can you elaborate?

i'll summarize the way i see it. please correct me if i'm wrong.

both wl18xx and wl12xx use the platform data to get the irq number.
wl12xx (only) also needs some additional clock definitions to be
passed. there's currently some issue with specifying some the of clock
sources, so i preferred starting only with (the simpler) wl18xx
bindings.

for platforms with wl18xx, we can remove the pdata-quirk, as all the
data (i.e. irq) can be passed by the new DT bindings.
however, for platforms with wl12xx, we still need to pass the clock
definitions (along with the irq), so we have to keep
legacy_init_wl12xx for the time being (and that's also why we have to
currently keep the platform_data handling in the wlcore driver)

do you have something else in mind?

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] wl18xx: add basic device-tree support

[Eliad Peller]

On Sun, Mar 8, 2015 at 11:53 PM, Arnd Bergmann a...@arndb.de wrote:
 On Sunday 08 March 2015 13:13:13 Eliad Peller wrote:

  I've looked up the what boards actually use this data and found that
  all of them already support booting from DT: some omap2 boards using
  arch/arm/mach-omap2/pdata-quirks.c to provide the data, and the
  davinci 850evm. Can you make sure you add the correct data to all
  of these dts files as part of your series and remove the
  wl12xx_platform_data references?

 AFAICT, these board files add wl12xx platform data, while the new DT
 support is only for wl18xx.


 How can you tell the difference? What I see is that omap3pandora
 (and nothing else) calls wl1251_set_platform_data(), while
 da850-evm and all omap3/omap4 boards use wl12xx_set_platform_data().

 The latter seems to refer to all wl12xx and wl18xx variants except
 for wl1251, based on my (very limited) understanding of that code.

right.
i got mislead because legacy_init_wl12xx() is defined there only for
CONFIG_WL12XX (and not for CONFIG_WL18XX).
it looks like only isee,omap3-igep0020-rev-f and
isee,omap3-igep0020-rev-g have pdata quirks for wl18xx (and thus
initialize the pdata clocks to 0).

sorry for the trivial question, but what's the standard way to submit
such patch? should i simply add a third patch to the patchset which
removes the pdata quirk and adds the missing dts definition? i don't
have such board, so i can only compile-test it.

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/2] wl18xx: add basic device-tree support

[Eliad Peller]

When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.

For now, parse only the irq used. Other (optional) properties
can be added later on.

Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
v4: use specific models, look for DT first (Arnd)

 drivers/net/wireless/ti/wlcore/sdio.c | 80 ---
 1 file changed, 74 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index d3dd7bf..ee556ac 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
 #include linux/wl12xx.h
 #include linux/pm_runtime.h
 #include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
 
 #include wlcore.h
 #include wl12xx_80211.h
@@ -214,6 +216,69 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+   { .compatible = ti,wl1801 },
+   { .compatible = ti,wl1805 },
+   { .compatible = ti,wl1807 },
+   { .compatible = ti,wl1831 },
+   { .compatible = ti,wl1835 },
+   { .compatible = ti,wl1837 },
+   { }
+};
+
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct wl12xx_platform_data *pdata;
+
+   if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
+   return NULL;
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-irq = irq_of_parse_and_map(np, 0);
+   if (!pdata-irq) {
+   dev_err(dev, No irq in platform data\n);
+   kfree(pdata);
+   return NULL;
+   }
+
+   return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+   struct wl12xx_platform_data *pdata;
+
+   /* first, look for DT data */
+   pdata = wlcore_probe_of(dev);
+   if (pdata)
+   return pdata;
+
+   /* if not found - fallback to static platform data */
+   pdata = wl12xx_get_platform_data();
+   if (!IS_ERR(pdata))
+   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+   dev_err(dev, No platform data set\n);
+   return NULL;
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+   kfree(pdata);
+}
+
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
@@ -245,12 +310,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   pdev_data.pdata = wl12xx_get_platform_data();
-   if (IS_ERR(pdev_data.pdata)) {
-   ret = PTR_ERR(pdev_data.pdata);
-   dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+   pdev_data.pdata = wlcore_get_platform_data(func-dev);
+   if (!pdev_data.pdata)
goto out_free_glue;
-   }
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +341,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out_free_pdata;
}
 
glue-core-dev.parent = func-dev;
@@ -313,6 +375,9 @@ static int wl1271_probe(struct sdio_func *func,
 out_dev_put:
platform_device_put(glue-core);
 
+out_free_pdata:
+   wlcore_del_platform_data(pdev_data.pdata);
+
 out_free_glue:
kfree(glue);
 
@@ -323,11 +388,14 @@ out:
 static void wl1271_remove(struct sdio_func *func)
 {
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+   struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
+   struct wl12xx_platform_data *pdata = pdev_data-pdata;
 
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
 
platform_device_unregister(glue-core);
+   wlcore_del_platform_data(pdata);
kfree(glue);
 }
 
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] dt: bindings: add wl18xx wireless device

[Eliad Peller]

Add device tree binding documentation for TI's wl18xx
wlan chip.

Signed-off-by: Eliad Peller el...@wizery.com
---
v4: use specific wl18xx model numbers (Arnd)

 .../devicetree/bindings/net/wireless/ti,wl18xx.txt | 39 ++
 1 file changed, 39 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
new file mode 100644
index 000..9dcf535
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
@@ -0,0 +1,39 @@
+TI Wilink8 (wl18xx) SDIO devices
+
+This node provides properties for controlling the wilink8 wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+ - compatible : Should be ti,wl18xx.
+ - compatible: should be one of the following:
+* ti,wl1801
+* ti,wl1805
+* ti,wl1807
+* ti,wl1831
+* ti,wl1835
+* ti,wl1837
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Optional properties:
+ - interrupt-parent : the phandle for the interrupt controller to which the
+   device interrupts are connected.
+
+Example:
+
+mmc3 {
+   status = okay;
+   vmmc-supply = wlan_en_reg;
+   bus-width = 4;
+   cap-power-off-card;
+   keep-power-in-suspend;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl1835;
+   reg = 2;
+   interrupt-parent = gpio0;
+   interrupts = 19 IRQ_TYPE_NONE;
+   };
+};
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/2] dt: bindings: add wl18xx wireless device

[Eliad Peller]

On Fri, Feb 27, 2015 at 10:14 AM, Arnd Bergmann a...@arndb.de wrote:
 On Thursday 19 February 2015 18:13:20 Eliad Peller wrote:
 +Required properties:
 + - compatible : Should be ti,wl18xx.

 Do not use wildcards in the compatible string, use specific model numbers.

ok. i'll change it to ti,wl1835 and ti,wl1837

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] wlcore: add basic device-tree support

[Eliad Peller]

hi Luca,

On Fri, Feb 27, 2015 at 9:31 AM, Luca Coelho l...@coelho.fi wrote:
 Hi,

 On Sun, 2015-02-15 at 13:09 +0200, Eliad Peller wrote:
 When running with device-tree, we no longer have a board file
 that can set up the platform data for wlcore.
 Allow this data to be passed from DT.

 For now, parse only the irq used. Other (optional) properties
 can be added later on.

 Signed-off-by: Ido Yariv i...@wizery.com
 Signed-off-by: Eliad Peller el...@wizery.com
 ---

 I don't really care much, but why not just finalize the work I did a
 couple of years ago?

 http://mid.gmane.org/1375189476-21557-1-git-send-email-coe...@ti.com
 http://mid.gmane.org/1375215668-29171-1-git-send-email-coe...@ti.com

 IIRC there were just some minor comments there, but I never really got
 to it because I left TI.

I just wanted a small patch to add DT support for wl18xx.
as there were some issues remaining wrt the correct way to specify the
clock data, i preferred taking the simpler route (for now), and only
add the wl18xx part, which doesn't require the clocks definitions.

i guess the patches will still be useful (and used) when wl12xx DT
support will be added.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 2/2] wl18xx: add basic device-tree support

[Eliad Peller]

On Fri, Feb 27, 2015 at 10:26 AM, Arnd Bergmann a...@arndb.de wrote:
 On Thursday 19 February 2015 18:13:21 Eliad Peller wrote:
 +
 +static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
 +{
 +   struct device_node *np = dev-of_node;
 +   struct wl12xx_platform_data *pdata;
 +
 +   if (!np || !of_match_node(wlcore_sdio_of_match_table, np)) {
 +   dev_err(dev, No platform data set\n);
 +   return NULL;
 +   }
 +
 +   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
 +   if (!pdata)
 +   return NULL;
 +
 +   pdata-irq = irq_of_parse_and_map(np, 0);
 +   if (!pdata-irq) {
 +   dev_err(dev, No irq in platform data\n);
 +   kfree(pdata);
 +   return NULL;
 +   }
 +
 +   return pdata;
 +}
 +#else
 +static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
 +{
 +   return NULL;
 +}
 +#endif
 +
 +static struct wl12xx_platform_data *
 +wlcore_get_platform_data(struct device *dev)
 +{
 +   struct wl12xx_platform_data *pdata;
 +
 +   pdata = wl12xx_get_platform_data();
 +   if (!IS_ERR(pdata))
 +   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
 +
 +   return wlcore_probe_of(dev);
 +}

 I think the probe_of needs to come first here, otherwise you cannot
 override the pdata quirk with actual DT data.

makes sense. i'll change it.

 I've looked up the what boards actually use this data and found that
 all of them already support booting from DT: some omap2 boards using
 arch/arm/mach-omap2/pdata-quirks.c to provide the data, and the
 davinci 850evm. Can you make sure you add the correct data to all
 of these dts files as part of your series and remove the
 wl12xx_platform_data references?

AFAICT, these board files add wl12xx platform data, while the new DT
support is only for wl18xx.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 2/2] wl18xx: add basic device-tree support

[Eliad Peller]

When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.

For now, parse only the irq used. Other (optional) properties
can be added later on.

Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wlcore/sdio.c | 70 ---
 1 file changed, 64 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index d3dd7bf..c3bc178 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
 #include linux/wl12xx.h
 #include linux/pm_runtime.h
 #include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
 
 #include wlcore.h
 #include wl12xx_80211.h
@@ -214,6 +216,59 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
 };
 
+#ifdef CONFIG_OF
+static const struct of_device_id wlcore_sdio_of_match_table[] = {
+   { .compatible = ti,wl18xx },
+   { }
+};
+
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct wl12xx_platform_data *pdata;
+
+   if (!np || !of_match_node(wlcore_sdio_of_match_table, np)) {
+   dev_err(dev, No platform data set\n);
+   return NULL;
+   }
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-irq = irq_of_parse_and_map(np, 0);
+   if (!pdata-irq) {
+   dev_err(dev, No irq in platform data\n);
+   kfree(pdata);
+   return NULL;
+   }
+
+   return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+   struct wl12xx_platform_data *pdata;
+
+   pdata = wl12xx_get_platform_data();
+   if (!IS_ERR(pdata))
+   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+   return wlcore_probe_of(dev);
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+   kfree(pdata);
+}
+
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
@@ -245,12 +300,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   pdev_data.pdata = wl12xx_get_platform_data();
-   if (IS_ERR(pdev_data.pdata)) {
-   ret = PTR_ERR(pdev_data.pdata);
-   dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+   pdev_data.pdata = wlcore_get_platform_data(func-dev);
+   if (!pdev_data.pdata)
goto out_free_glue;
-   }
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +331,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out_free_pdata;
}
 
glue-core-dev.parent = func-dev;
@@ -313,6 +365,9 @@ static int wl1271_probe(struct sdio_func *func,
 out_dev_put:
platform_device_put(glue-core);
 
+out_free_pdata:
+   wlcore_del_platform_data(pdev_data.pdata);
+
 out_free_glue:
kfree(glue);
 
@@ -323,11 +378,14 @@ out:
 static void wl1271_remove(struct sdio_func *func)
 {
struct wl12xx_sdio_glue *glue = sdio_get_drvdata(func);
+   struct wlcore_platdev_data *pdev_data = glue-core-dev.platform_data;
+   struct wl12xx_platform_data *pdata = pdev_data-pdata;
 
/* Undo decrement done above in wl1271_probe */
pm_runtime_get_noresume(func-dev);
 
platform_device_unregister(glue-core);
+   wlcore_del_platform_data(pdata);
kfree(glue);
 }
 
-- 
1.8.5.1.109.g3d252a9

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 1/2] dt: bindings: add wl18xx wireless device

[Eliad Peller]

Add device tree binding documentation for TI's wl18xx
wlan chip.

Signed-off-by: Eliad Peller el...@wizery.com
---
v3:
 * make the bindings device-specific (wl18xx) (Arnd, Mark)
 * split bindings and driver changes (Arnd)
 * make interrupt-parent optional (Arnd)
 * make unit-address same as reg (Mark)

 .../devicetree/bindings/net/wireless/ti,wl18xx.txt | 32 ++
 1 file changed, 32 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
new file mode 100644
index 000..8120a81
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl18xx.txt
@@ -0,0 +1,32 @@
+TI Wilink8 (wl18xx) SDIO devices
+
+This node provides properties for controlling the wilink8 wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+ - compatible : Should be ti,wl18xx.
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Optional properties:
+ - interrupt-parent : the phandle for the interrupt controller to which the
+   device interrupts are connected.
+
+Example:
+
+mmc3 {
+   status = okay;
+   vmmc-supply = wlan_en_reg;
+   bus-width = 4;
+   cap-power-off-card;
+   keep-power-in-suspend;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@2 {
+   compatible = ti,wl18xx;
+   reg = 2;
+   interrupt-parent = gpio0;
+   interrupts = 19 IRQ_TYPE_NONE;
+   };
+};
-- 
1.8.5.1.109.g3d252a9

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] wlcore: add basic device-tree support

[Eliad Peller]

On Tue, Feb 17, 2015 at 5:45 PM, Mark Rutland mark.rutl...@arm.com wrote:
 On Tue, Feb 17, 2015 at 03:39:03PM +, Eliad Peller wrote:
 On Mon, Feb 16, 2015 at 12:06 PM, Arnd Bergmann a...@arndb.de wrote:
  On Sunday 15 February 2015 13:09:10 Eliad Peller wrote:
  s
  +
  +This node provides properties for controlling the wilink wireless 
  device. The
  +node is expected to be specified as a child node to the SDIO controller 
  that
  +connects the device to the system.
  +
  +Required properties:
  +
  + - compatible : Should be ti,wlcore.
 
  I think you should use the specific model number here. If I understand
  correctly, wlcore is the name of the driver that is used for multiple
  device implementation.
 
 right, wlcore is the common driver part of wl12xx and wl18xx device drivers.
 these DT properties are common for both.
 can't we use a common binding as well in this case?

 Just have a string for each; the driver can easily match them all and
 handle them identically for now until we decide/realise we need to
 handle them differently later.

 Regardless, the compatible string should match some real part number
 and/or standard rather than the Linux driver name.

ok, makes sense.

  +mmc3 {
  + status = okay;
  + vmmc-supply = wlan_en_reg;
  + bus-width = 4;
  + cap-power-off-card;
  + keep-power-in-suspend;
  +
  + #address-cells = 1;
  + #size-cells = 0;
  + wlcore: wlcore@0 {
  + compatible = ti,wlcore;
  + reg = 2;
  + interrupt-parent = gpio0;
  + interrupts = 19 IRQ_TYPE_NONE;
  + };
  +};
 
  It could make sense to specify a few extra properties here:
 
  - The platform data lists two clocks. How about adding them
here as optional clocks so we don't need to change the binding
again.
 
 There were some very long threads previously regarding the correct way
 to describe these clocks.
 I prefer starting a working basic implementation and add the
 controversial parts later on, as needed.

 This could be problematic. Elsewhere we've later added properties that
 should have been mandatory from the start but were masked by some
 platform data somewhere. It would be very good to avoid that.

that's a good argument.
in this case, i'll start with submitting a binding only for wl18xx,
which doesn't need the clock bindings (they are needed only for
wl12xx).

 What is problematic about describing the clock inputs to this block? Is
 the problem specific to this block or to the specific clock
 controller(s) it happens to be wired to?
i'm referring to patches like this one:
http://thread.gmane.org/gmane.linux.kernel/1520752

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] wlcore: add basic device-tree support

[Eliad Peller]

On Mon, Feb 16, 2015 at 12:06 PM, Arnd Bergmann a...@arndb.de wrote:
 On Sunday 15 February 2015 13:09:10 Eliad Peller wrote:
 s
 +
 +This node provides properties for controlling the wilink wireless device. 
 The
 +node is expected to be specified as a child node to the SDIO controller that
 +connects the device to the system.
 +
 +Required properties:
 +
 + - compatible : Should be ti,wlcore.

 I think you should use the specific model number here. If I understand
 correctly, wlcore is the name of the driver that is used for multiple
 device implementation.

right, wlcore is the common driver part of wl12xx and wl18xx device drivers.
these DT properties are common for both.
can't we use a common binding as well in this case?

 + - interrupt-parent : the phandle for the interrupt controller to which the
 + device interrupts are connected.

 interrupt-parent should not be required

sure. i'll make it optional.

 +mmc3 {
 + status = okay;
 + vmmc-supply = wlan_en_reg;
 + bus-width = 4;
 + cap-power-off-card;
 + keep-power-in-suspend;
 +
 + #address-cells = 1;
 + #size-cells = 0;
 + wlcore: wlcore@0 {
 + compatible = ti,wlcore;
 + reg = 2;
 + interrupt-parent = gpio0;
 + interrupts = 19 IRQ_TYPE_NONE;
 + };
 +};

 It could make sense to specify a few extra properties here:

 - The platform data lists two clocks. How about adding them
   here as optional clocks so we don't need to change the binding
   again.

There were some very long threads previously regarding the correct way
to describe these clocks.
I prefer starting a working basic implementation and add the
controversial parts later on, as needed.

 diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
 b/drivers/net/wireless/ti/wlcore/sdio.c
 index d3dd7bf..317796b 100644
 --- a/drivers/net/wireless/ti/wlcore/sdio.c
 +++ b/drivers/net/wireless/ti/wlcore/sdio.c

 Please make this a two-patch series and keep the dt binding in a separate
 patch from the driver change.

sure.

 +#ifdef CONFIG_OF
 +static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
 +{
 + struct device_node *np = dev-of_node;
 + struct wl12xx_platform_data *pdata;
 +
 + if (!np || !of_device_is_compatible(np, ti,wlcore)) {
 + dev_err(dev, No platform data set\n);
 + return NULL;
 + }
 +
 + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
 + if (!pdata)
 + return NULL;

 Your method seems overly complicated. While a lot of drivers do the same
 thing, allocating a platform_data structure at probe time is really
 just extra work compared to making the platform_data optional and
 adding the required fields into the driver-private structure.
i see your point here.
however, the driver already holds (and uses) a pointer describing the
platform_data (in the non-dt case), so this patch simply takes
leverage of the current behavior (and returns a similar pointer).

thanks for the review!

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] wlcore: add basic device-tree support

[Eliad Peller]

When running with device-tree, we no longer have a board file
that can set up the platform data for wlcore.
Allow this data to be passed from DT.

For now, parse only the irq used. Other (optional) properties
can be added later on.

Signed-off-by: Ido Yariv i...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
previous submission of this patch got lost somewhere.

this patch follows the expected way to pass SDIO function DT
information, as was recently added by this patchset:
http://www.spinics.net/lists/linux-mmc/msg27353.html

 .../devicetree/bindings/net/wireless/ti,wlcore.txt | 31 +++
 drivers/net/wireless/ti/wlcore/sdio.c  | 65 --
 2 files changed, 90 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
new file mode 100644
index 000..df9af48
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore.txt
@@ -0,0 +1,31 @@
+TI Wilink (wlcore) SDIO devices
+
+This node provides properties for controlling the wilink wireless device. The
+node is expected to be specified as a child node to the SDIO controller that
+connects the device to the system.
+
+Required properties:
+
+ - compatible : Should be ti,wlcore.
+ - interrupt-parent : the phandle for the interrupt controller to which the
+   device interrupts are connected.
+ - interrupts : specifies attributes for the out-of-band interrupt.
+
+Example:
+
+mmc3 {
+   status = okay;
+   vmmc-supply = wlan_en_reg;
+   bus-width = 4;
+   cap-power-off-card;
+   keep-power-in-suspend;
+
+   #address-cells = 1;
+   #size-cells = 0;
+   wlcore: wlcore@0 {
+   compatible = ti,wlcore;
+   reg = 2;
+   interrupt-parent = gpio0;
+   interrupts = 19 IRQ_TYPE_NONE;
+   };
+};
diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index d3dd7bf..317796b 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -34,6 +34,8 @@
 #include linux/wl12xx.h
 #include linux/pm_runtime.h
 #include linux/printk.h
+#include linux/of.h
+#include linux/of_irq.h
 
 #include wlcore.h
 #include wl12xx_80211.h
@@ -214,6 +216,54 @@ static struct wl1271_if_operations sdio_ops = {
.set_block_size = wl1271_sdio_set_block_size,
 };
 
+#ifdef CONFIG_OF
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   struct device_node *np = dev-of_node;
+   struct wl12xx_platform_data *pdata;
+
+   if (!np || !of_device_is_compatible(np, ti,wlcore)) {
+   dev_err(dev, No platform data set\n);
+   return NULL;
+   }
+
+   pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
+   if (!pdata)
+   return NULL;
+
+   pdata-irq = irq_of_parse_and_map(np, 0);
+   if (!pdata-irq) {
+   dev_err(dev, No irq in platform data\n);
+   kfree(pdata);
+   return NULL;
+   }
+
+   return pdata;
+}
+#else
+static struct wl12xx_platform_data *wlcore_probe_of(struct device *dev)
+{
+   return NULL;
+}
+#endif
+
+static struct wl12xx_platform_data *
+wlcore_get_platform_data(struct device *dev)
+{
+   struct wl12xx_platform_data *pdata;
+
+   pdata = wl12xx_get_platform_data();
+   if (!IS_ERR(pdata))
+   return kmemdup(pdata, sizeof(*pdata), GFP_KERNEL);
+
+   return wlcore_probe_of(dev);
+}
+
+static void wlcore_del_platform_data(struct wl12xx_platform_data *pdata)
+{
+   kfree(pdata);
+}
+
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
@@ -245,12 +295,9 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func-card-quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   pdev_data.pdata = wl12xx_get_platform_data();
-   if (IS_ERR(pdev_data.pdata)) {
-   ret = PTR_ERR(pdev_data.pdata);
-   dev_err(glue-dev, missing wlan platform data: %d\n, ret);
+   pdev_data.pdata = wlcore_get_platform_data(func-dev);
+   if (!pdev_data.pdata)
goto out_free_glue;
-   }
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
@@ -279,7 +326,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue-core) {
dev_err(glue-dev, can't allocate platform_device);
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out_free_pdata;
}
 
glue-core-dev.parent = func-dev;
@@ -313,6 +360,9 @@ static int wl1271_probe(struct sdio_func *func,
 out_dev_put:
platform_device_put(glue-core);
 
+out_free_pdata

Re: [PATCH v2 3/3] mac80211: don't defer scans in case of radar detection

[Eliad Peller]

On Sun, Feb 8, 2015 at 5:56 PM, Jouni Malinen j...@w1.fi wrote:
 I don't see why returning EBUSY is wrong, though.
 Actually, it just make the test fail immediately, instead of waiting
 indefinitely until a timeout occurs (i guess, didn't actually test it
 with the reverted patch).
 This was exactly the intended behavior, and i think it makes much more sense.

 I have no issues with EBUSY being returned for a case where an
 offchannel operation would be required while on a channel that require
 constant monitoring for radars. I guess it would be fine to run a
 single-channel scan on that same channel in such a state, but I'm not
 sure whether this code prevents that or not. (Or whether there is really
 that much of a real use case for such an operation.)

See my answers to Janusz.
The current code blocks any scan (including on-channel one).
I guess an exception for on-channel scan can be added if needed.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: clear sdata-radar_required

[Eliad Peller]

If ieee80211_vif_use_channel() fails, we have to clear
sdata-radar_required (which we might have just set).

Failing to do it results in stale radar_required field
which prevents starting new scan requests.

Reported-by: Jouni Malinen j...@w1.fi
Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/chan.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 35b11e1..f3a8708 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -1508,6 +1508,8 @@ static void __ieee80211_vif_release_channel(struct 
ieee80211_sub_if_data *sdata)
if (ieee80211_chanctx_refcount(local, ctx) == 0)
ieee80211_free_chanctx(local, ctx);
 
+   sdata-radar_required = 0;
+
/* Unreserving may ready an in-place reservation. */
if (use_reserved_switch)
ieee80211_vif_use_reserved_switch(local);
@@ -1566,6 +1568,9 @@ int ieee80211_vif_use_channel(struct 
ieee80211_sub_if_data *sdata,
ieee80211_recalc_smps_chanctx(local, ctx);
ieee80211_recalc_radar_chanctx(local, ctx);
  out:
+   if (ret)
+   sdata-radar_required = 0;
+
mutex_unlock(local-chanctx_mtx);
return ret;
 }
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] mac80211: don't defer scans in case of radar detection

[Eliad Peller]

On Sun, Feb 8, 2015 at 3:17 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
 On 8 February 2015 at 11:57, Eliad Peller el...@wizery.com wrote:
 On Sat, Feb 7, 2015 at 9:17 PM, Janusz Dziedzic
 janusz.dzied...@tieto.com wrote:
 BTW, what in case we will start AP on first interface (DFS channel),
 on second one we will try to connect to other AP. As I understand this
 correctly, second iface (STA iface) will not allow to scan (connect)
 ...?

 right.
 The rationale behind it that you must listen constantly to detect
 radar events, which prevents scanning off-channel.
 (i guess an exception for on-channel scanning can be added if needed, though)

 Still I can image hw with hw_scan() support that could have dedicated
 hw part for scanning.
 So, driver should made this decision (allow or not) base on hw features.

this will probably require additional radio...

anyway, i don't have any objection here :)
just explained the original logic (and my patch only changed the
behavior from blocking indefinitely to returning error immediately)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] mac80211: don't defer scans in case of radar detection

[Eliad Peller]

Hi Jouni,

On Sat, Feb 7, 2015 at 1:57 PM, Jouni Malinen j...@w1.fi wrote:
 On Wed, Jan 07, 2015 at 05:50:11PM +0200, Eliad Peller wrote:
 Radar detection can last indefinite time. There is no
 point in deferring a scan request in this case - simply
 return -EBUSY.

 diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
 @@ -505,7 +505,7 @@ static int __ieee80211_start_scan(struct 
 ieee80211_sub_if_data *sdata,
 - if (local-scan_req)
 + if (local-scan_req || ieee80211_is_radar_required(local))
   return -EBUSY;

 This seems to be breaking a hwsim test case sequence of ap_vht80plus80
 followed by ap_vht80. In such a case, all the HT40 scans for ap_vht80
 fail due to this added condition resulting in -EBUSY being returned
 every time. It looks like this happens even if I change ap_vht80 to use
 the same country code (US) as ap_vht80plus80, so the change in the
 country code does not explain this either.

 I'm not sure what is causing the issue here, but it looks like something
 in ap_vht80plus80 (i.e., an attempt to enable a channel combination that
 would require DFS on one of the 80 MHz segments) leaves behind state
 that makes ieee80211_is_radar_required(local) return true even when it
 shouldn't. DFS for 80+80 is not yet supported, so I'd assume this is
 somehow related to that. Anyway, I don't think mac80211 should behave in
 this way.

Thanks for the detailed report.
There was indeed stale state. I've just sent a patch to fix it.

I don't see why returning EBUSY is wrong, though.
Actually, it just make the test fail immediately, instead of waiting
indefinitely until a timeout occurs (i guess, didn't actually test it
with the reverted patch).
This was exactly the intended behavior, and i think it makes much more sense.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] mac80211: don't defer scans in case of radar detection

[Eliad Peller]

On Sat, Feb 7, 2015 at 9:17 PM, Janusz Dziedzic
janusz.dzied...@tieto.com wrote:
 BTW, what in case we will start AP on first interface (DFS channel),
 on second one we will try to connect to other AP. As I understand this
 correctly, second iface (STA iface) will not allow to scan (connect)
 ...?

right.
The rationale behind it that you must listen constantly to detect
radar events, which prevents scanning off-channel.
(i guess an exception for on-channel scanning can be added if needed, though)

 Other case, what if we start DFS AP and allow to scan in AP mode (eg
 for ACS purpose, allow to choose better channel and do CSA ...)?
ditto. you just have to make sure you keep listening on the operating channel.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] wlcore: unlock on error in wl1271_op_suspend()

[Eliad Peller]

On Thu, Jan 15, 2015 at 1:43 PM, Dan Carpenter dan.carpen...@oracle.com wrote:
 We recently introduced a new error path which needs an unlock.

 Fixes: 6d5a748d4836 ('wlcore: add ability to reduce FW interrupts during 
 suspend')
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
 ---
 Static checker fix.  It's possible that wl1271_ps_elp_wakeup() unlocks
 on error but I didn't see it, and that would be an ugly API.

 diff --git a/drivers/net/wireless/ti/wlcore/main.c 
 b/drivers/net/wireless/ti/wlcore/main.c
 index e90fb78..02f0e86 100644
 --- a/drivers/net/wireless/ti/wlcore/main.c
 +++ b/drivers/net/wireless/ti/wlcore/main.c
 @@ -1785,8 +1785,10 @@ static int wl1271_op_suspend(struct ieee80211_hw *hw,
 mutex_lock(wl-mutex);

 ret = wl1271_ps_elp_wakeup(wl);
 -   if (ret  0)
 +   if (ret  0) {
 +   mutex_unlock(wl-mutex);
 return ret;
 +   }

The patch is correct, thanks.
If you'll take a look at other functions in the file, you'll usually
see goto out_unlock (or something similar) in this case.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND 2/2] wlcore: align member-assigns in a structure-copy block

[Eliad Peller]

On Fri, Jan 9, 2015 at 7:03 PM, Kalle Valo kv...@codeaurora.org wrote:
 Giel van Schijndel m...@mortis.eu writes:

 This highlights the differences (e.g. the bug fixed in the previous
 commit).

 Signed-off-by: Giel van Schijndel m...@mortis.eu
 ---
  drivers/net/wireless/ti/wlcore/acx.c | 22 +++---
  1 file changed, 11 insertions(+), 11 deletions(-)

 diff --git a/drivers/net/wireless/ti/wlcore/acx.c 
 b/drivers/net/wireless/ti/wlcore/acx.c
 index f28fa3b..93a2fa8 100644
 --- a/drivers/net/wireless/ti/wlcore/acx.c
 +++ b/drivers/net/wireless/ti/wlcore/acx.c
 @@ -1715,17 +1715,17 @@ int wl12xx_acx_config_hangover(struct wl1271 *wl)
   goto out;
   }

 - acx-recover_time = cpu_to_le32(conf-recover_time);
 - acx-hangover_period = conf-hangover_period;
 - acx-dynamic_mode = conf-dynamic_mode;
 - acx-early_termination_mode = conf-early_termination_mode;
 - acx-max_period = conf-max_period;
 - acx-min_period = conf-min_period;
 - acx-increase_delta = conf-increase_delta;
 - acx-decrease_delta = conf-decrease_delta;
 - acx-quiet_time = conf-quiet_time;
 - acx-increase_time = conf-increase_time;
 - acx-window_size = conf-window_size;
 + acx-recover_time   = cpu_to_le32(conf-recover_time);
 + acx-hangover_period= conf-hangover_period;
 + acx-dynamic_mode   = conf-dynamic_mode;
 + acx-early_termination_mode = conf-early_termination_mode;
 + acx-max_period = conf-max_period;
 + acx-min_period = conf-min_period;
 + acx-increase_delta = conf-increase_delta;
 + acx-decrease_delta = conf-decrease_delta;
 + acx-quiet_time = conf-quiet_time;
 + acx-increase_time  = conf-increase_time;
 + acx-window_size= conf-window_size;

 I would like to get an ACK from one of the wlcore developers if I should
 apply this (or not).

I don't have a strong opinion here.
However, it looks pretty much redundant to take a random blob (which
was just fixed by a correct patch) and re-indent it.
The rest of the file doesn't follow this style, so i don't see a good
reason to apply it here.

I agree such indentation have some benefit, but it won't help with the
more common use case (of copy-paste error) of copying the wrong field
(i.e. D-a = S-b instead of D-a = S-a).
For these cases the macros suggested by Arend and Johannes will do the
trick. However i usually dislike such macros, as they tend to break
some IDE features (e.g. auto completion).
Maybe we can come up with some nice spatch to catch these cases.

Just my 2c.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 3/3] mac80211: don't defer scans in case of radar detection

[Eliad Peller]

Radar detection can last indefinite time. There is no
point in deferring a scan request in this case - simply
return -EBUSY.

Signed-off-by: Eliad Peller el...@wizery.com
---
v1-v2: use the newly introduced funcion

 net/mac80211/scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index cdd8258..4bee1f97 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -505,7 +505,7 @@ static int __ieee80211_start_scan(struct 
ieee80211_sub_if_data *sdata,
 
lockdep_assert_held(local-mtx);
 
-   if (local-scan_req)
+   if (local-scan_req || ieee80211_is_radar_required(local))
return -EBUSY;
 
if (!ieee80211_can_scan(local, sdata)) {
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/3] mac80211: remove local-radar_detect_enabled

[Eliad Peller]

local-radar_detect_enabled should tell whether
radar_detect is enabled on any interface belonging
to local.

However, it's not getting updated correctly
in many cases (actually, when testing with hwsim
it's never been set, even when the dfs master
is beaconing).

Instead of handling all the corner cases
(e.g. channel switch), simply check whether
radar detection is enabled only when needed,
instead of caching the result.

Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/cfg.c | 2 +-
 net/mac80211/chan.c| 5 ++---
 net/mac80211/ieee80211_i.h | 3 +--
 net/mac80211/scan.c| 2 +-
 4 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1696658..3c53fa3 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2557,7 +2557,7 @@ static int ieee80211_start_roc_work(struct 
ieee80211_local *local,
 
/* if there's one pending or we're scanning, queue this one */
if (!list_empty(local-roc_list) ||
-   local-scanning || local-radar_detect_enabled)
+   local-scanning || ieee80211_is_radar_required(local))
goto out_check_combine;
 
/* if not HW assist, just queue  schedule work */
diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 5d6dae9..f5d08d5 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -388,7 +388,7 @@ ieee80211_find_chanctx(struct ieee80211_local *local,
return NULL;
 }
 
-static bool ieee80211_is_radar_required(struct ieee80211_local *local)
+bool ieee80211_is_radar_required(struct ieee80211_local *local)
 {
struct ieee80211_sub_if_data *sdata;
 
@@ -567,7 +567,7 @@ static void ieee80211_recalc_radar_chanctx(struct 
ieee80211_local *local,
bool radar_enabled;
 
lockdep_assert_held(local-chanctx_mtx);
-   /* for setting local-radar_detect_enabled */
+   /* for ieee80211_is_radar_required */
lockdep_assert_held(local-mtx);
 
radar_enabled = ieee80211_is_radar_required(local);
@@ -576,7 +576,6 @@ static void ieee80211_recalc_radar_chanctx(struct 
ieee80211_local *local,
return;
 
chanctx-conf.radar_enabled = radar_enabled;
-   local-radar_detect_enabled = chanctx-conf.radar_enabled;
 
if (!local-use_chanctx) {
local-hw.conf.radar_enabled = chanctx-conf.radar_enabled;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 4f45cab..9cdd94a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1168,8 +1168,6 @@ struct ieee80211_local {
/* wowlan is enabled -- don't reconfig on resume */
bool wowlan;
 
-   /* DFS/radar detection is enabled */
-   bool radar_detect_enabled;
struct work_struct radar_detected_work;
 
/* number of RX chains the hardware has */
@@ -1982,6 +1980,7 @@ void ieee80211_recalc_smps_chanctx(struct ieee80211_local 
*local,
   struct ieee80211_chanctx *chanctx);
 void ieee80211_recalc_chanctx_min_def(struct ieee80211_local *local,
  struct ieee80211_chanctx *ctx);
+bool ieee80211_is_radar_required(struct ieee80211_local *local);
 
 void ieee80211_dfs_cac_timer(unsigned long data);
 void ieee80211_dfs_cac_timer_work(struct work_struct *work);
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index ae84267..cdd8258 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -432,7 +432,7 @@ static int ieee80211_start_sw_scan(struct ieee80211_local 
*local,
 static bool ieee80211_can_scan(struct ieee80211_local *local,
   struct ieee80211_sub_if_data *sdata)
 {
-   if (local-radar_detect_enabled)
+   if (ieee80211_is_radar_required(local))
return false;
 
if (!list_empty(local-roc_list))
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 2/3] mac80211: consider only relevant vifs for radar_required calculation

[Eliad Peller]

ctx-conf.radar_enabled should reflect whether radar
detection is enabled for the channel context.

When calculating it, make it consider only the vifs
that have this context assigned (instead of all the
vifs).

Signed-off-by: Eliad Peller el...@wizery.com
---
v1-v2: 
* add a new function (instead of replacing existing one)
* init ctx-conf.radar_enabled to false

 net/mac80211/chan.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index f5d08d5..28da444 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -406,6 +406,34 @@ bool ieee80211_is_radar_required(struct ieee80211_local 
*local)
return false;
 }
 
+static bool
+ieee80211_chanctx_radar_required(struct ieee80211_local *local,
+struct ieee80211_chanctx *ctx)
+{
+   struct ieee80211_chanctx_conf *conf = ctx-conf;
+   struct ieee80211_sub_if_data *sdata;
+   bool required = false;
+
+   lockdep_assert_held(local-chanctx_mtx);
+   lockdep_assert_held(local-mtx);
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(sdata, local-interfaces, list) {
+   if (!ieee80211_sdata_running(sdata))
+   continue;
+   if (rcu_access_pointer(sdata-vif.chanctx_conf) != conf)
+   continue;
+   if (!sdata-radar_required)
+   continue;
+
+   required = true;
+   break;
+   }
+   rcu_read_unlock();
+
+   return required;
+}
+
 static struct ieee80211_chanctx *
 ieee80211_alloc_chanctx(struct ieee80211_local *local,
const struct cfg80211_chan_def *chandef,
@@ -425,7 +453,7 @@ ieee80211_alloc_chanctx(struct ieee80211_local *local,
ctx-conf.rx_chains_static = 1;
ctx-conf.rx_chains_dynamic = 1;
ctx-mode = mode;
-   ctx-conf.radar_enabled = ieee80211_is_radar_required(local);
+   ctx-conf.radar_enabled = false;
ieee80211_recalc_chanctx_min_def(local, ctx);
 
return ctx;
@@ -570,7 +598,7 @@ static void ieee80211_recalc_radar_chanctx(struct 
ieee80211_local *local,
/* for ieee80211_is_radar_required */
lockdep_assert_held(local-mtx);
 
-   radar_enabled = ieee80211_is_radar_required(local);
+   radar_enabled = ieee80211_chanctx_radar_required(local, chanctx);
 
if (radar_enabled == chanctx-conf.radar_enabled)
return;
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mac80211: consider only relevant vifs for radar_required calculation

[Eliad Peller]

On Tue, Jan 6, 2015 at 9:36 PM, Eliad Peller el...@wizery.com wrote:
 On Tue, Jan 6, 2015 at 9:02 PM, Johannes Berg johan...@sipsolutions.net 
 wrote:
 On Tue, 2015-01-06 at 20:57 +0200, Eliad Peller wrote:
 On Tue, Jan 6, 2015 at 4:14 PM, Johannes Berg johan...@sipsolutions.net 
 wrote:
  On Tue, 2015-01-06 at 15:05 +0100, Johannes Berg wrote:
  On Tue, 2015-01-06 at 12:04 +0100, Johannes Berg wrote:
   all three applied.
 
  Nope, dropped patch 2 again
 
  And dropped the other two also - with them the sequence of two tests I
  was looking at never completes.
 
 err... sorry about that.
 i'll look into it.

 I think there's probably two bugs - the test suite should wait for all
 the DFS stuff to finish.

 But the fact that it never completes now is strange, maybe somehow radar
 detection doesn't get turned off properly after your patches?

 it's probably local-radar_detect_enabled doesn't get cleared.
 patch (3) fixes a similar issue, but there seems to be another one.
 (it seems that patch (1) exposed these issues, so i should probably
 reorder the patches and make it the last one)

ok, sent a new patchset.

there were some missing updates of local-radar_detect_enabled, so i
preferred to simply remove it altogether and check for radar detection
directly when needed (i.e. on scan/roc).

ap_ht_40mhz_intolerant_ap still seems to fail here, but it fails even
when running only this test, without any of my patches applied.
now i get the same error with my patches applied (Exception: AP did
not move to 40 MHz channel) instead of the EBUSY one.

i'll try debugging this issue as well.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mac80211: consider only relevant vifs for radar_required calculation

[Eliad Peller]

On Wed, Jan 7, 2015 at 6:32 PM, Johannes Berg johan...@sipsolutions.net wrote:
 On Wed, 2015-01-07 at 17:58 +0200, Eliad Peller wrote:
 ap_ht_40mhz_intolerant_ap still seems to fail here, but it fails even
 when running only this test, without any of my patches applied.
 now i get the same error with my patches applied (Exception: AP did
 not move to 40 MHz channel) instead of the EBUSY one.

 i'll try debugging this issue as well.

 Well, if you want to :)
 It's not related to your patches I think, and I saw it passing w/o your
 patches applied.

thanks.
looks like something bad in my setup.
i recompiled hostapd and it seems to pass now :)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mac80211: consider only relevant vifs for radar_required calculation

[Eliad Peller]

On Tue, Jan 6, 2015 at 9:02 PM, Johannes Berg johan...@sipsolutions.net wrote:
 On Tue, 2015-01-06 at 20:57 +0200, Eliad Peller wrote:
 On Tue, Jan 6, 2015 at 4:14 PM, Johannes Berg johan...@sipsolutions.net 
 wrote:
  On Tue, 2015-01-06 at 15:05 +0100, Johannes Berg wrote:
  On Tue, 2015-01-06 at 12:04 +0100, Johannes Berg wrote:
   all three applied.
 
  Nope, dropped patch 2 again
 
  And dropped the other two also - with them the sequence of two tests I
  was looking at never completes.
 
 err... sorry about that.
 i'll look into it.

 I think there's probably two bugs - the test suite should wait for all
 the DFS stuff to finish.

 But the fact that it never completes now is strange, maybe somehow radar
 detection doesn't get turned off properly after your patches?

it's probably local-radar_detect_enabled doesn't get cleared.
patch (3) fixes a similar issue, but there seems to be another one.
(it seems that patch (1) exposed these issues, so i should probably
reorder the patches and make it the last one)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/3] mac80211: consider only relevant vifs for radar_required calculation

[Eliad Peller]

On Tue, Jan 6, 2015 at 4:14 PM, Johannes Berg johan...@sipsolutions.net wrote:
 On Tue, 2015-01-06 at 15:05 +0100, Johannes Berg wrote:
 On Tue, 2015-01-06 at 12:04 +0100, Johannes Berg wrote:
  all three applied.

 Nope, dropped patch 2 again

 And dropped the other two also - with them the sequence of two tests I
 was looking at never completes.

err... sorry about that.
i'll look into it.

thanks,
Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] mac80211: consider only relevant vifs for radar_required calculation

[Eliad Peller]

no need to consider all the vifs, but only the ones
that have this context assigned.

Signed-off-by: Eliad Peller el...@wizery.com
---
This patch was already sent previously as part of a different patchset
(in which the other patch was later dropped).
However, i don't see it in patchwork, so resend it.

 net/mac80211/chan.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 5d6dae9..7f83451 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -388,22 +388,31 @@ ieee80211_find_chanctx(struct ieee80211_local *local,
return NULL;
 }
 
-static bool ieee80211_is_radar_required(struct ieee80211_local *local)
+static bool ieee80211_is_radar_required(struct ieee80211_local *local,
+   struct ieee80211_chanctx *ctx)
 {
+   struct ieee80211_chanctx_conf *conf = ctx-conf;
struct ieee80211_sub_if_data *sdata;
+   bool required = false;
 
+   lockdep_assert_held(local-chanctx_mtx);
lockdep_assert_held(local-mtx);
 
rcu_read_lock();
list_for_each_entry_rcu(sdata, local-interfaces, list) {
-   if (sdata-radar_required) {
-   rcu_read_unlock();
-   return true;
-   }
+   if (!ieee80211_sdata_running(sdata))
+   continue;
+   if (rcu_access_pointer(sdata-vif.chanctx_conf) != conf)
+   continue;
+   if (!sdata-radar_required)
+   continue;
+
+   required = true;
+   break;
}
rcu_read_unlock();
 
-   return false;
+   return required;
 }
 
 static struct ieee80211_chanctx *
@@ -425,7 +434,7 @@ ieee80211_alloc_chanctx(struct ieee80211_local *local,
ctx-conf.rx_chains_static = 1;
ctx-conf.rx_chains_dynamic = 1;
ctx-mode = mode;
-   ctx-conf.radar_enabled = ieee80211_is_radar_required(local);
+   ctx-conf.radar_enabled = ieee80211_is_radar_required(local, ctx);
ieee80211_recalc_chanctx_min_def(local, ctx);
 
return ctx;
@@ -570,7 +579,7 @@ static void ieee80211_recalc_radar_chanctx(struct 
ieee80211_local *local,
/* for setting local-radar_detect_enabled */
lockdep_assert_held(local-mtx);
 
-   radar_enabled = ieee80211_is_radar_required(local);
+   radar_enabled = ieee80211_is_radar_required(local, chanctx);
 
if (radar_enabled == chanctx-conf.radar_enabled)
return;
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] mac80211: don't defer scans in case of radar detection

[Eliad Peller]

Radar detection can last indefinite time. There is no
point in deferring a scan request in this case - simply
return -EBUSY.

Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/scan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index ae84267..4525623 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -505,7 +505,7 @@ static int __ieee80211_start_scan(struct 
ieee80211_sub_if_data *sdata,
 
lockdep_assert_held(local-mtx);
 
-   if (local-scan_req)
+   if (local-scan_req || local-radar_detect_enabled)
return -EBUSY;
 
if (!ieee80211_can_scan(local, sdata)) {
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] mac80211: always recalc_radar on chanctx changes

[Eliad Peller]

ieee80211_recalc_radar_chanctx() changes the global
local-radar_detect_enabled in case of a change
from the current chanctx radar_enabled state.

Thus, we need to make sure it will be called
even if the current chanctx is going to be
freed (so local-radar_detect_enabled will
be cleared if needed).

Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/chan.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 7f83451..9261cc0 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -629,10 +629,12 @@ out:
 
sdata-vif.bss_conf.idle = !conf;
 
+   if (curr_ctx)
+   ieee80211_recalc_radar_chanctx(local, curr_ctx);
+
if (curr_ctx  ieee80211_chanctx_num_assigned(local, curr_ctx)  0) {
ieee80211_recalc_chanctx_chantype(local, curr_ctx);
ieee80211_recalc_smps_chanctx(local, curr_ctx);
-   ieee80211_recalc_radar_chanctx(local, curr_ctx);
ieee80211_recalc_chanctx_min_def(local, curr_ctx);
}
 
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 09/13] wlcore: add support for ap csa

[Eliad Peller]

Support ap csa support by implementing the channel_switch_beacon()
mac80211 op.

Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wl18xx/cmd.c   | 11 +++--
 drivers/net/wireless/ti/wlcore/event.c | 10 +++--
 drivers/net/wireless/ti/wlcore/main.c  | 81 +-
 3 files changed, 95 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/ti/wl18xx/cmd.c 
b/drivers/net/wireless/ti/wl18xx/cmd.c
index 68e12e5..5731950 100644
--- a/drivers/net/wireless/ti/wl18xx/cmd.c
+++ b/drivers/net/wireless/ti/wl18xx/cmd.c
@@ -33,7 +33,8 @@ int wl18xx_cmd_channel_switch(struct wl1271 *wl,
u32 supported_rates;
int ret;
 
-   wl1271_debug(DEBUG_ACX, cmd channel switch);
+   wl1271_debug(DEBUG_ACX, cmd channel switch (count=%d),
+ch_switch-count);
 
cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
if (!cmd) {
@@ -60,8 +61,12 @@ int wl18xx_cmd_channel_switch(struct wl1271 *wl,
goto out_free;
}
 
-   supported_rates = CONF_TX_ENABLED_RATES | CONF_TX_MCS_RATES |
- wlcore_hw_sta_get_ap_rate_mask(wl, wlvif);
+   supported_rates = CONF_TX_ENABLED_RATES | CONF_TX_MCS_RATES;
+   if (wlvif-bss_type == BSS_TYPE_STA_BSS)
+   supported_rates |= wlcore_hw_sta_get_ap_rate_mask(wl, wlvif);
+   else
+   supported_rates |=
+   wlcore_hw_ap_get_mimo_wide_rate_mask(wl, wlvif);
if (wlvif-p2p)
supported_rates = ~CONF_TX_CCK_RATES;
cmd-local_supported_rates = cpu_to_le32(supported_rates);
diff --git a/drivers/net/wireless/ti/wlcore/event.c 
b/drivers/net/wireless/ti/wlcore/event.c
index 5153640..69a2661 100644
--- a/drivers/net/wireless/ti/wlcore/event.c
+++ b/drivers/net/wireless/ti/wlcore/event.c
@@ -139,7 +139,7 @@ void wlcore_event_channel_switch(struct wl1271 *wl,
wl1271_debug(DEBUG_EVENT, %s: roles=0x%lx success=%d,
 __func__, roles_bitmap, success);
 
-   wl12xx_for_each_wlvif_sta(wl, wlvif) {
+   wl12xx_for_each_wlvif(wl, wlvif) {
if (wlvif-role_id == WL12XX_INVALID_ROLE_ID ||
!test_bit(wlvif-role_id , roles_bitmap))
continue;
@@ -150,8 +150,12 @@ void wlcore_event_channel_switch(struct wl1271 *wl,
 
vif = wl12xx_wlvif_to_vif(wlvif);
 
-   ieee80211_chswitch_done(vif, success);
-   cancel_delayed_work(wlvif-channel_switch_work);
+   if (wlvif-bss_type == BSS_TYPE_STA_BSS) {
+   ieee80211_chswitch_done(vif, success);
+   cancel_delayed_work(wlvif-channel_switch_work);
+   } else {
+   ieee80211_csa_finish(vif);
+   }
}
 }
 EXPORT_SYMBOL_GPL(wlcore_event_channel_switch);
diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 673bfc4..9a35f30 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -5434,6 +5434,83 @@ out:
mutex_unlock(wl-mutex);
 }
 
+static const void *wlcore_get_beacon_ie(struct wl1271 *wl,
+   struct wl12xx_vif *wlvif,
+   u8 eid)
+{
+   int ieoffset = offsetof(struct ieee80211_mgmt, u.beacon.variable);
+   struct sk_buff *beacon =
+   ieee80211_beacon_get(wl-hw, wl12xx_wlvif_to_vif(wlvif));
+
+   if (!beacon)
+   return NULL;
+
+   return cfg80211_find_ie(eid,
+   beacon-data + ieoffset,
+   beacon-len - ieoffset);
+}
+
+static int wlcore_get_csa_count(struct wl1271 *wl, struct wl12xx_vif *wlvif,
+   u8 *csa_count)
+{
+   const u8 *ie;
+   const struct ieee80211_channel_sw_ie *ie_csa;
+
+   ie = wlcore_get_beacon_ie(wl, wlvif, WLAN_EID_CHANNEL_SWITCH);
+   if (!ie)
+   return -EINVAL;
+
+   ie_csa = (struct ieee80211_channel_sw_ie *)ie[2];
+   *csa_count = ie_csa-count;
+
+   return 0;
+}
+
+static void wlcore_op_channel_switch_beacon(struct ieee80211_hw *hw,
+   struct ieee80211_vif *vif,
+   struct cfg80211_chan_def *chandef)
+{
+   struct wl1271 *wl = hw-priv;
+   struct wl12xx_vif *wlvif = wl12xx_vif_to_data(vif);
+   struct ieee80211_channel_switch ch_switch = {
+   .block_tx = true,
+   .chandef = *chandef,
+   };
+   int ret;
+
+   wl1271_debug(DEBUG_MAC80211,
+mac80211 channel switch beacon (role %d),
+wlvif-role_id);
+
+   ret = wlcore_get_csa_count(wl, wlvif, ch_switch.count);
+   if (ret  0) {
+   wl1271_error(error getting beacon (for CSA counter));
+   return;
+   }
+
+   mutex_lock(wl-mutex

[PATCH 06/13] wlcore: enable sleep during AP mode operation

[Eliad Peller]

From: Kobi L kobi.lev...@gmail.com

Enable ELP authorization in AP mode and enable the use
of the wakeup bit in the ELP register.

Introduce AP role sleep configuration which is disabled
by default. When configured, it allows the AP to sleep
when ELP is authorized for it.

Signed-off-by: Kobi Leibovitch kobi.lev...@gmail.com
Signed-off-by: Arik Nemtsov a...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wl12xx/main.c   |  1 +
 drivers/net/wireless/ti/wl18xx/acx.c| 32 
 drivers/net/wireless/ti/wl18xx/acx.h| 25 +++--
 drivers/net/wireless/ti/wl18xx/conf.h   | 23 ++-
 drivers/net/wireless/ti/wl18xx/main.c   |  7 +++
 drivers/net/wireless/ti/wlcore/hw_ops.h |  9 +
 drivers/net/wireless/ti/wlcore/init.c   |  8 ++--
 drivers/net/wireless/ti/wlcore/ps.c |  6 --
 drivers/net/wireless/ti/wlcore/wlcore.h |  1 +
 9 files changed, 101 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ti/wl12xx/main.c 
b/drivers/net/wireless/ti/wl12xx/main.c
index b457069..42264e5 100644
--- a/drivers/net/wireless/ti/wl12xx/main.c
+++ b/drivers/net/wireless/ti/wl12xx/main.c
@@ -1731,6 +1731,7 @@ static struct wlcore_ops wl12xx_ops = {
.lnk_low_prio   = wl12xx_lnk_low_prio,
.interrupt_notify   = NULL,
.rx_ba_filter   = NULL,
+   .ap_sleep   = NULL,
 };
 
 static struct ieee80211_sta_ht_cap wl12xx_ht_cap = {
diff --git a/drivers/net/wireless/ti/wl18xx/acx.c 
b/drivers/net/wireless/ti/wl18xx/acx.c
index 9d4b9aa..67f2a0e 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.c
+++ b/drivers/net/wireless/ti/wl18xx/acx.c
@@ -24,6 +24,7 @@
 #include ../wlcore/acx.h
 
 #include acx.h
+#include wl18xx.h
 
 int wl18xx_acx_host_if_cfg_bitmap(struct wl1271 *wl, u32 host_cfg_bitmap,
  u32 sdio_blk_size, u32 extra_mem_blks,
@@ -250,3 +251,34 @@ out:
kfree(acx);
return ret;
 }
+
+int wl18xx_acx_ap_sleep(struct wl1271 *wl)
+{
+   struct wl18xx_priv *priv = wl-priv;
+   struct acx_ap_sleep_cfg *acx;
+   struct conf_ap_sleep_settings *conf = priv-conf.ap_sleep;
+   int ret;
+
+   wl1271_debug(DEBUG_ACX, acx config ap sleep);
+
+   acx = kzalloc(sizeof(*acx), GFP_KERNEL);
+   if (!acx) {
+   ret = -ENOMEM;
+   goto out;
+   }
+
+   acx-idle_duty_cycle = conf-idle_duty_cycle;
+   acx-connected_duty_cycle = conf-connected_duty_cycle;
+   acx-max_stations_thresh = conf-max_stations_thresh;
+   acx-idle_conn_thresh = conf-idle_conn_thresh;
+
+   ret = wl1271_cmd_configure(wl, ACX_AP_SLEEP_CFG, acx, sizeof(*acx));
+   if (ret  0) {
+   wl1271_warning(acx config ap-sleep failed: %d, ret);
+   goto out;
+   }
+
+out:
+   kfree(acx);
+   return ret;
+}
diff --git a/drivers/net/wireless/ti/wl18xx/acx.h 
b/drivers/net/wireless/ti/wl18xx/acx.h
index 1234bdc..4afccd4 100644
--- a/drivers/net/wireless/ti/wl18xx/acx.h
+++ b/drivers/net/wireless/ti/wl18xx/acx.h
@@ -34,8 +34,8 @@ enum {
ACX_AUTO_RX_STREAMING= 0x0055,
ACX_PEER_CAP = 0x0056,
ACX_INTERRUPT_NOTIFY = 0x0057,
-   ACX_RX_BA_FILTER = 0x0058
-
+   ACX_RX_BA_FILTER = 0x0058,
+   ACX_AP_SLEEP_CFG = 0x0059
 };
 
 /* numbers of bits the length field takes (add 1 for the actual number) */
@@ -347,6 +347,26 @@ struct wl18xx_acx_rx_ba_filter {
u32 enable;
 };
 
+struct acx_ap_sleep_cfg {
+   struct acx_header header;
+   /* Duty Cycle (20-80% of staying Awake) for IDLE AP
+* (0: disable)
+*/
+   u8 idle_duty_cycle;
+   /* Duty Cycle (20-80% of staying Awake) for Connected AP
+* (0: disable)
+*/
+   u8 connected_duty_cycle;
+   /* Maximum stations that are allowed to be connected to AP
+*  (255: no limit)
+*/
+   u8 max_stations_thresh;
+   /* Timeout till enabling the Sleep Mechanism after data stops
+* [unit: 100 msec]
+*/
+   u8 idle_conn_thresh;
+} __packed;
+
 int wl18xx_acx_host_if_cfg_bitmap(struct wl1271 *wl, u32 host_cfg_bitmap,
  u32 sdio_blk_size, u32 extra_mem_blks,
  u32 len_field_size);
@@ -359,5 +379,6 @@ int wl18xx_acx_set_peer_cap(struct wl1271 *wl,
u32 rate_set, u8 hlid);
 int wl18xx_acx_interrupt_notify_config(struct wl1271 *wl, bool action);
 int wl18xx_acx_rx_ba_filter(struct wl1271 *wl, bool action);
+int wl18xx_acx_ap_sleep(struct wl1271 *wl);
 
 #endif /* __WL18XX_ACX_H__ */
diff --git a/drivers/net/wireless/ti/wl18xx/conf.h 
b/drivers/net/wireless/ti/wl18xx/conf.h
index e34302e..71f1ec4 100644
--- a/drivers/net/wireless/ti/wl18xx/conf.h
+++ b/drivers/net/wireless/ti/wl18xx/conf.h
@@ -23,7 +23,7

[PATCH 07/13] wl18xx: add radar detection implementation

[Eliad Peller]

Add support for CAC start/stop commands, and pass
radar detection events from the fw to mac80211.

Bump fw name (to wl18xx-fw-4.bin) and min fw version
(to 8.9.*.*.11), and align event mailbox accordingly.

Signed-off-by: Guy Mishol g...@ti.com
Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wl18xx/cmd.c  |  31 ++
 drivers/net/wireless/ti/wl18xx/cmd.h  |  11 +++
 drivers/net/wireless/ti/wl18xx/event.c|  21 
 drivers/net/wireless/ti/wl18xx/event.h|  14 ++-
 drivers/net/wireless/ti/wl18xx/main.c |   4 +-
 drivers/net/wireless/ti/wl18xx/wl18xx.h   |   4 +-
 drivers/net/wireless/ti/wlcore/cmd.c  |   3 +-
 drivers/net/wireless/ti/wlcore/cmd.h  |   6 ++
 drivers/net/wireless/ti/wlcore/hw_ops.h   |   9 ++
 drivers/net/wireless/ti/wlcore/main.c | 159 +-
 drivers/net/wireless/ti/wlcore/wlcore.h   |   2 +
 drivers/net/wireless/ti/wlcore/wlcore_i.h |   2 +
 12 files changed, 257 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ti/wl18xx/cmd.c 
b/drivers/net/wireless/ti/wl18xx/cmd.c
index 44f0b20..10f9d1c 100644
--- a/drivers/net/wireless/ti/wl18xx/cmd.c
+++ b/drivers/net/wireless/ti/wl18xx/cmd.c
@@ -167,3 +167,34 @@ out_free:
 out:
return ret;
 }
+
+int wl18xx_cmd_set_cac(struct wl1271 *wl, struct wl12xx_vif *wlvif, bool start)
+{
+   struct wlcore_cmd_cac_start *cmd;
+   int ret = 0;
+
+   wl1271_debug(DEBUG_CMD, cmd cac (channel %d) %s,
+wlvif-channel, start ? start : stop);
+
+   cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
+   if (!cmd)
+   return -ENOMEM;
+
+   cmd-role_id = wlvif-role_id;
+   cmd-channel = wlvif-channel;
+   if (wlvif-band == IEEE80211_BAND_5GHZ)
+   cmd-band = WLCORE_BAND_5GHZ;
+   cmd-bandwidth = wlcore_get_native_channel_type(wlvif-channel_type);
+
+   ret = wl1271_cmd_send(wl,
+ start ? CMD_CAC_START : CMD_CAC_STOP,
+ cmd, sizeof(*cmd), 0);
+   if (ret  0) {
+   wl1271_error(failed to send cac command);
+   goto out_free;
+   }
+
+out_free:
+   kfree(cmd);
+   return ret;
+}
diff --git a/drivers/net/wireless/ti/wl18xx/cmd.h 
b/drivers/net/wireless/ti/wl18xx/cmd.h
index 92499e2..91b3e2f 100644
--- a/drivers/net/wireless/ti/wl18xx/cmd.h
+++ b/drivers/net/wireless/ti/wl18xx/cmd.h
@@ -59,6 +59,16 @@ struct wl18xx_cmd_smart_config_set_group_key {
u8 key[16];
 } __packed;
 
+/* cac_start and cac_stop share the same params */
+struct wlcore_cmd_cac_start {
+   struct wl1271_cmd_header header;
+
+   u8 role_id;
+   u8 channel;
+   u8 band;
+   u8 bandwidth;
+} __packed;
+
 int wl18xx_cmd_channel_switch(struct wl1271 *wl,
  struct wl12xx_vif *wlvif,
  struct ieee80211_channel_switch *ch_switch);
@@ -66,4 +76,5 @@ int wl18xx_cmd_smart_config_start(struct wl1271 *wl, u32 
group_bitmap);
 int wl18xx_cmd_smart_config_stop(struct wl1271 *wl);
 int wl18xx_cmd_smart_config_set_group_key(struct wl1271 *wl, u16 group_id,
  u8 key_len, u8 *key);
+int wl18xx_cmd_set_cac(struct wl1271 *wl, struct wl12xx_vif *wlvif, bool 
start);
 #endif
diff --git a/drivers/net/wireless/ti/wl18xx/event.c 
b/drivers/net/wireless/ti/wl18xx/event.c
index eb1848e..c28f068 100644
--- a/drivers/net/wireless/ti/wl18xx/event.c
+++ b/drivers/net/wireless/ti/wl18xx/event.c
@@ -47,6 +47,19 @@ int wl18xx_wait_for_event(struct wl1271 *wl, enum 
wlcore_wait_event event,
return wlcore_cmd_wait_for_event_or_timeout(wl, local_event, timeout);
 }
 
+static const char *wl18xx_radar_type_decode(u8 radar_type)
+{
+   switch (radar_type) {
+   case RADAR_TYPE_REGULAR:
+   return REGULAR;
+   case RADAR_TYPE_CHIRP:
+   return CHIRP;
+   case RADAR_TYPE_NONE:
+   default:
+   return N/A;
+   }
+}
+
 static int wlcore_smart_config_sync_event(struct wl1271 *wl, u8 sync_channel,
  u8 sync_band)
 {
@@ -115,6 +128,14 @@ int wl18xx_process_mailbox_events(struct wl1271 *wl)
wl18xx_scan_completed(wl, wl-scan_wlvif);
}
 
+   if (vector  RADAR_DETECTED_EVENT_ID) {
+   wl1271_info(radar event: channel %d type %s,
+   mbox-radar_channel,
+   wl18xx_radar_type_decode(mbox-radar_type));
+
+   ieee80211_radar_detected(wl-hw);
+   }
+
if (vector  PERIODIC_SCAN_REPORT_EVENT_ID) {
wl1271_debug(DEBUG_EVENT,
 PERIODIC_SCAN_REPORT_EVENT (results %d),
diff --git a/drivers/net/wireless/ti/wl18xx/event.h 
b/drivers/net/wireless/ti/wl18xx/event.h
index 0680312..266ee87 100644
--- a/drivers/net/wireless/ti/wl18xx/event.h
+++ b/drivers/net/wireless/ti/wl18xx/event.h
@@ -42,6 +42,12 @@ enum

[PATCH 01/13] wlcore: fix WLCORE_VENDOR_ATTR_GROUP_KEY policy

[Eliad Peller]

The attribute type is binary data (with max length).

Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wlcore/vendor_cmd.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ti/wlcore/vendor_cmd.c 
b/drivers/net/wireless/ti/wlcore/vendor_cmd.c
index ad86a48..fd4e9ba 100644
--- a/drivers/net/wireless/ti/wlcore/vendor_cmd.c
+++ b/drivers/net/wireless/ti/wlcore/vendor_cmd.c
@@ -21,7 +21,7 @@ static const
 struct nla_policy wlcore_vendor_attr_policy[NUM_WLCORE_VENDOR_ATTR] = {
[WLCORE_VENDOR_ATTR_FREQ]   = { .type = NLA_U32 },
[WLCORE_VENDOR_ATTR_GROUP_ID]   = { .type = NLA_U32 },
-   [WLCORE_VENDOR_ATTR_GROUP_KEY]  = { .type = NLA_U32,
+   [WLCORE_VENDOR_ATTR_GROUP_KEY]  = { .type = NLA_BINARY,
.len = WLAN_MAX_KEY_LEN },
 };
 
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 05/13] wlcore: enable AP wowlan

[Eliad Peller]

configure wowlan when host is suspended in AP mode,
since the FW can now wake the host up on Rx.

Signed-off-by: Kobi Leibovitch kobi.lev...@gmail.com
Signed-off-by: Arik Nemtsov a...@wizery.com
Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wlcore/main.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index aaa836b..0d67e39 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -1707,7 +1707,8 @@ out:
 }
 
 static int wl1271_configure_suspend_ap(struct wl1271 *wl,
-  struct wl12xx_vif *wlvif)
+   struct wl12xx_vif *wlvif,
+   struct cfg80211_wowlan *wow)
 {
int ret = 0;
 
@@ -1715,6 +1716,12 @@ static int wl1271_configure_suspend_ap(struct wl1271 *wl,
goto out;
 
ret = wl1271_acx_beacon_filter_opt(wl, wlvif, true);
+   if (ret  0)
+   goto out;
+
+   ret = wl1271_configure_wowlan(wl, wow);
+   if (ret  0)
+   goto out;
 
 out:
return ret;
@@ -1728,7 +1735,7 @@ static int wl1271_configure_suspend(struct wl1271 *wl,
if (wlvif-bss_type == BSS_TYPE_STA_BSS)
return wl1271_configure_suspend_sta(wl, wlvif, wow);
if (wlvif-bss_type == BSS_TYPE_AP_BSS)
-   return wl1271_configure_suspend_ap(wl, wlvif);
+   return wl1271_configure_suspend_ap(wl, wlvif, wow);
return 0;
 }
 
@@ -1741,12 +1748,13 @@ static void wl1271_configure_resume(struct wl1271 *wl, 
struct wl12xx_vif *wlvif)
if ((!is_ap)  (!is_sta))
return;
 
-   if (is_sta  !test_bit(WLVIF_FLAG_STA_ASSOCIATED, wlvif-flags))
+   if ((is_sta  !test_bit(WLVIF_FLAG_STA_ASSOCIATED, wlvif-flags)) ||
+   (is_ap  !test_bit(WLVIF_FLAG_AP_STARTED, wlvif-flags)))
return;
 
-   if (is_sta) {
-   wl1271_configure_wowlan(wl, NULL);
+   wl1271_configure_wowlan(wl, NULL);
 
+   if (is_sta) {
if ((wl-conf.conn.suspend_wake_up_event ==
 wl-conf.conn.wake_up_event) 
(wl-conf.conn.suspend_listen_interval ==
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 03/13] wlcore/wl18xx: handle rc updates in a separate work

[Eliad Peller]

sta_rc_update runs in atomic context. thus, a new work
should be scheduled in order to configure the fw
with the required configuration.

Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wl18xx/main.c | 18 
 drivers/net/wireless/ti/wlcore/hw_ops.h   |  5 ++---
 drivers/net/wireless/ti/wlcore/main.c | 35 +--
 drivers/net/wireless/ti/wlcore/wlcore.h   |  3 +--
 drivers/net/wireless/ti/wlcore/wlcore_i.h |  4 
 5 files changed, 44 insertions(+), 21 deletions(-)

diff --git a/drivers/net/wireless/ti/wl18xx/main.c 
b/drivers/net/wireless/ti/wl18xx/main.c
index 7af1936..6946d18 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -1559,26 +1559,19 @@ static u32 wl18xx_pre_pkt_send(struct wl1271 *wl,
 }
 
 static void wl18xx_sta_rc_update(struct wl1271 *wl,
-struct wl12xx_vif *wlvif,
-struct ieee80211_sta *sta,
-u32 changed)
+struct wl12xx_vif *wlvif)
 {
-   bool wide = sta-bandwidth = IEEE80211_STA_RX_BW_40;
+   bool wide = wlvif-rc_update_bw = IEEE80211_STA_RX_BW_40;
 
wl1271_debug(DEBUG_MAC80211, mac80211 sta_rc_update wide %d, wide);
 
-   if (!(changed  IEEE80211_RC_BW_CHANGED))
-   return;
-
-   mutex_lock(wl-mutex);
-
/* sanity */
if (WARN_ON(wlvif-bss_type != BSS_TYPE_STA_BSS))
-   goto out;
+   return;
 
/* ignore the change before association */
if (!test_bit(WLVIF_FLAG_STA_ASSOCIATED, wlvif-flags))
-   goto out;
+   return;
 
/*
 * If we started out as wide, we can change the operation mode. If we
@@ -1589,9 +1582,6 @@ static void wl18xx_sta_rc_update(struct wl1271 *wl,
wl18xx_acx_peer_ht_operation_mode(wl, wlvif-sta.hlid, wide);
else
ieee80211_connection_loss(wl12xx_wlvif_to_vif(wlvif));
-
-out:
-   mutex_unlock(wl-mutex);
 }
 
 static int wl18xx_set_peer_cap(struct wl1271 *wl,
diff --git a/drivers/net/wireless/ti/wlcore/hw_ops.h 
b/drivers/net/wireless/ti/wlcore/hw_ops.h
index aa9f82c..29ce55f 100644
--- a/drivers/net/wireless/ti/wlcore/hw_ops.h
+++ b/drivers/net/wireless/ti/wlcore/hw_ops.h
@@ -211,11 +211,10 @@ wlcore_hw_pre_pkt_send(struct wl1271 *wl, u32 buf_offset, 
u32 last_len)
 }
 
 static inline void
-wlcore_hw_sta_rc_update(struct wl1271 *wl, struct wl12xx_vif *wlvif,
-   struct ieee80211_sta *sta, u32 changed)
+wlcore_hw_sta_rc_update(struct wl1271 *wl, struct wl12xx_vif *wlvif)
 {
if (wl-ops-sta_rc_update)
-   wl-ops-sta_rc_update(wl, wlvif, sta, changed);
+   wl-ops-sta_rc_update(wl, wlvif);
 }
 
 static inline int
diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 2a99456..f6e37d5 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -226,6 +226,29 @@ void wl12xx_rearm_tx_watchdog_locked(struct wl1271 *wl)
msecs_to_jiffies(wl-conf.tx.tx_watchdog_timeout));
 }
 
+static void wlcore_rc_update_work(struct work_struct *work)
+{
+   int ret;
+   struct wl12xx_vif *wlvif = container_of(work, struct wl12xx_vif,
+   rc_update_work);
+   struct wl1271 *wl = wlvif-wl;
+
+   mutex_lock(wl-mutex);
+
+   if (unlikely(wl-state != WLCORE_STATE_ON))
+   goto out;
+
+   ret = wl1271_ps_elp_wakeup(wl);
+   if (ret  0)
+   goto out;
+
+   wlcore_hw_sta_rc_update(wl, wlvif);
+
+   wl1271_ps_elp_sleep(wl);
+out:
+   mutex_unlock(wl-mutex);
+}
+
 static void wl12xx_tx_watchdog_work(struct work_struct *work)
 {
struct delayed_work *dwork;
@@ -2279,6 +2302,7 @@ static int wl12xx_init_vif_data(struct wl1271 *wl, struct 
ieee80211_vif *vif)
  wl1271_rx_streaming_enable_work);
INIT_WORK(wlvif-rx_streaming_disable_work,
  wl1271_rx_streaming_disable_work);
+   INIT_WORK(wlvif-rc_update_work, wlcore_rc_update_work);
INIT_DELAYED_WORK(wlvif-channel_switch_work,
  wlcore_channel_switch_work);
INIT_DELAYED_WORK(wlvif-connection_loss_work,
@@ -2724,6 +2748,7 @@ unlock:
del_timer_sync(wlvif-rx_streaming_timer);
cancel_work_sync(wlvif-rx_streaming_enable_work);
cancel_work_sync(wlvif-rx_streaming_disable_work);
+   cancel_work_sync(wlvif-rc_update_work);
cancel_delayed_work_sync(wlvif-connection_loss_work);
cancel_delayed_work_sync(wlvif-channel_switch_work);
cancel_delayed_work_sync(wlvif-pending_auth_complete_work);
@@ -5371,9 +5396,15 @@ static void wlcore_op_sta_rc_update(struct ieee80211_hw 
*hw,
u32 changed)
 {
struct wl12xx_vif *wlvif

[PATCH 13/13] wl18xx: declare radar_detect_widths support for ap interfaces

[Eliad Peller]

After having all the dfs infrastructure in place, declare
radar_detect_widths support for the ap interfaces combination.

Signed-off-by: Eliad Peller el...@wizery.com
---
 drivers/net/wireless/ti/wl18xx/main.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/ti/wl18xx/main.c 
b/drivers/net/wireless/ti/wl18xx/main.c
index 604de24..e5bc557 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -1799,6 +1799,10 @@ wl18xx_iface_combinations[] = {
.limits = wl18xx_iface_ap_limits,
.n_limits = ARRAY_SIZE(wl18xx_iface_ap_limits),
.num_different_channels = 1,
+   .radar_detect_widths =  BIT(NL80211_CHAN_NO_HT) |
+   BIT(NL80211_CHAN_HT20) |
+   BIT(NL80211_CHAN_HT40MINUS) |
+   BIT(NL80211_CHAN_HT40PLUS),
}
 };
 
-- 
1.8.5.2.229.g4448466.dirty

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: fix dot11MulticastTransmittedFrameCount tested address

[Eliad Peller]

dot11MulticastTransmittedFrameCount should be updated according
to the DA, which might be different from hdr1.

(Checking hdr1 results in the counter being 0 in case of station,
as TODS data frames use hdr1 for the bssid address)

Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/status.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index d64037c..7d4e930 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -862,7 +862,7 @@ void ieee80211_tx_status(struct ieee80211_hw *hw, struct 
sk_buff *skb)
(info-flags  IEEE80211_TX_STAT_NOACK_TRANSMITTED)) {
if (ieee80211_is_first_frag(hdr-seq_ctrl)) {
local-dot11TransmittedFrameCount++;
-   if (is_multicast_ether_addr(hdr-addr1))
+   if (is_multicast_ether_addr(ieee80211_get_DA(hdr)))
local-dot11MulticastTransmittedFrameCount++;
if (retry_count  0)
local-dot11RetryCount++;
-- 
1.8.5.1.109.g3d252a9

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: fix dot11MulticastTransmittedFrameCount tested address

[Eliad Peller]

On Sun, Dec 21, 2014 at 4:19 PM, Fred Chou fred.chou...@gmail.com wrote:
 On 21/12/2014 9:25 PM, Eliad Peller wrote:
 dot11MulticastTransmittedFrameCount should be updated according
 to the DA, which might be different from hdr1.

 Shouldn't address 1 be used to determine whether the MPDU is multicast?
 From Std-2012 definition of multicast: When applied to a MAC protocol
 data unit (MPDU), it is an MPDU with a group address in the Address 1
 field.

good point. i guess it depends on the meaning of
dot11MulticastTransmittedFrameCount -
multicast frames sent by sta are not multicast frames per se (as they
are sent directly to the AP), but they are destined to multicast
group.

i tried understanding the meaning of this MIB from here (as i couldn't
find clear definition in the spec):
http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=entranslate=TranslateobjectInput=dot11MulticastTransmittedFrameCount

where it seems to be similar (IIUC) to the way i interpreted it, but i
might got it wrong :)

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] mac80211: consider only relevant vifs for radar_required calculation

[Eliad Peller]

no need to consider all the vifs, but only the ones
that have this context assigned.

Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/chan.c | 25 +
 1 file changed, 17 insertions(+), 8 deletions(-)

diff --git a/net/mac80211/chan.c b/net/mac80211/chan.c
index 5d6dae9..7f83451 100644
--- a/net/mac80211/chan.c
+++ b/net/mac80211/chan.c
@@ -388,22 +388,31 @@ ieee80211_find_chanctx(struct ieee80211_local *local,
return NULL;
 }
 
-static bool ieee80211_is_radar_required(struct ieee80211_local *local)
+static bool ieee80211_is_radar_required(struct ieee80211_local *local,
+   struct ieee80211_chanctx *ctx)
 {
+   struct ieee80211_chanctx_conf *conf = ctx-conf;
struct ieee80211_sub_if_data *sdata;
+   bool required = false;
 
+   lockdep_assert_held(local-chanctx_mtx);
lockdep_assert_held(local-mtx);
 
rcu_read_lock();
list_for_each_entry_rcu(sdata, local-interfaces, list) {
-   if (sdata-radar_required) {
-   rcu_read_unlock();
-   return true;
-   }
+   if (!ieee80211_sdata_running(sdata))
+   continue;
+   if (rcu_access_pointer(sdata-vif.chanctx_conf) != conf)
+   continue;
+   if (!sdata-radar_required)
+   continue;
+
+   required = true;
+   break;
}
rcu_read_unlock();
 
-   return false;
+   return required;
 }
 
 static struct ieee80211_chanctx *
@@ -425,7 +434,7 @@ ieee80211_alloc_chanctx(struct ieee80211_local *local,
ctx-conf.rx_chains_static = 1;
ctx-conf.rx_chains_dynamic = 1;
ctx-mode = mode;
-   ctx-conf.radar_enabled = ieee80211_is_radar_required(local);
+   ctx-conf.radar_enabled = ieee80211_is_radar_required(local, ctx);
ieee80211_recalc_chanctx_min_def(local, ctx);
 
return ctx;
@@ -570,7 +579,7 @@ static void ieee80211_recalc_radar_chanctx(struct 
ieee80211_local *local,
/* for setting local-radar_detect_enabled */
lockdep_assert_held(local-mtx);
 
-   radar_enabled = ieee80211_is_radar_required(local);
+   radar_enabled = ieee80211_is_radar_required(local, chanctx);
 
if (radar_enabled == chanctx-conf.radar_enabled)
return;
-- 
1.8.5.1.109.g3d252a9

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] mac80211: allow some multi-channel combinations with DFS master

[Eliad Peller]

Allow some multi-channel interface combinations along with
DFS master support, if there is only a single AP/GO.

Allowing other interface types at the same time is fine
(as long as the device supports them), and doesn't require
additional code.

Update ieee80211_dfs_radar_detected_work() to consider
this case, and look specifically for the chanctx with
radar_enabled.

Signed-off-by: Eliad Peller el...@wizery.com
---
 net/mac80211/main.c | 11 ---
 net/mac80211/util.c |  3 +++
 net/wireless/core.c | 23 +--
 3 files changed, 20 insertions(+), 17 deletions(-)

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index d9ce336..78d8c6d 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -792,17 +792,6 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 */
if (local-hw.wiphy-interface_modes  BIT(NL80211_IFTYPE_WDS))
return -EINVAL;
-
-   /* DFS is not supported with multi-channel combinations yet */
-   for (i = 0; i  local-hw.wiphy-n_iface_combinations; i++) {
-   const struct ieee80211_iface_combination *comb;
-
-   comb = local-hw.wiphy-iface_combinations[i];
-
-   if (comb-radar_detect_widths 
-   comb-num_different_channels  1)
-   return -EINVAL;
-   }
}
 
/* Only HW csum features are currently compatible with mac80211 */
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 974ebe7..61affe6 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2625,6 +2625,9 @@ void ieee80211_dfs_radar_detected_work(struct work_struct 
*work)
if (ctx-replace_state == IEEE80211_CHANCTX_REPLACES_OTHER)
continue;
 
+   if (!ctx-conf.radar_enabled)
+   continue;
+
num_chanctx++;
chandef = ctx-conf.def;
}
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 4910758..8bcadd9 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -453,7 +453,7 @@ static int wiphy_verify_combinations(struct wiphy *wiphy)
int i, j;
 
for (i = 0; i  wiphy-n_iface_combinations; i++) {
-   u32 cnt = 0;
+   u32 cnt = 0, dfs_cnt = 0;
u16 all_iftypes = 0;
 
c = wiphy-iface_combinations[i];
@@ -477,11 +477,6 @@ static int wiphy_verify_combinations(struct wiphy *wiphy)
CFG80211_MAX_NUM_DIFFERENT_CHANNELS))
return -EINVAL;
 
-   /* DFS only works on one channel. */
-   if (WARN_ON(c-radar_detect_widths 
-   (c-num_different_channels  1)))
-   return -EINVAL;
-
if (WARN_ON(!c-n_limits))
return -EINVAL;
 
@@ -505,6 +500,22 @@ static int wiphy_verify_combinations(struct wiphy *wiphy)
c-limits[j].max  1))
return -EINVAL;
 
+   if (types  (BIT(NL80211_IFTYPE_AP) |
+BIT(NL80211_IFTYPE_P2P_GO) |
+BIT(NL80211_IFTYPE_ADHOC) |
+BIT(NL80211_IFTYPE_MESH_POINT))) {
+   dfs_cnt += c-limits[j].max;
+
+   /*
+* Multiple DFS masters on multiple channels
+* are not supported yet.
+*/
+   if (WARN_ON(c-radar_detect_widths 
+   c-num_different_channels  1 
+   dfs_cnt  1))
+   return -EINVAL;
+   }
+
cnt += c-limits[j].max;
/*
 * Don't advertise an unsupported type
-- 
1.8.5.1.109.g3d252a9

--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mac80211: fix dot11MulticastTransmittedFrameCount tested address

[Eliad Peller]

On Sun, Dec 21, 2014 at 6:25 PM, Johannes Berg
johan...@sipsolutions.net wrote:
 On Sun, 2014-12-21 at 17:27 +0200, Eliad Peller wrote:
 On Sun, Dec 21, 2014 at 4:19 PM, Fred Chou fred.chou...@gmail.com wrote:
  On 21/12/2014 9:25 PM, Eliad Peller wrote:
  dot11MulticastTransmittedFrameCount should be updated according
  to the DA, which might be different from hdr1.
 
  Shouldn't address 1 be used to determine whether the MPDU is multicast?
  From Std-2012 definition of multicast: When applied to a MAC protocol
  data unit (MPDU), it is an MPDU with a group address in the Address 1
  field.
 
 good point. i guess it depends on the meaning of
 dot11MulticastTransmittedFrameCount -
 multicast frames sent by sta are not multicast frames per se (as they
 are sent directly to the AP), but they are destined to multicast
 group.

 i tried understanding the meaning of this MIB from here (as i couldn't
 find clear definition in the spec):
 http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=entranslate=TranslateobjectInput=dot11MulticastTransmittedFrameCount

 Yeah I can't find a good reference in the spec either - anyone want to
 dig through the flow charts? :)

 Btw, since this is ancient code from devicescape, it is possible that
 they only cared about AP mode then - and there there's no difference
 between the addresses.

makes sense.

 where it seems to be similar (IIUC) to the way i interpreted it, but i
 might got it wrong :)

 I think you're probably right - however I wonder if we can stick the
 code elsewhere (like subif xmit?) instead of introducing more
 conditionals here?

well, we look for the tx status, so i think it makes sense to leave it here.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] cfg80211: Add feature flag for 4-way handshake offload

[Eliad Peller]

hi,

On Thu, Dec 18, 2014 at 2:51 PM, Arend van Spriel ar...@broadcom.com wrote:
 From: Gautam Kumar Shukla gaut...@broadcom.com

 The new feature flag allows the driver to indicate that it can
 offload the 4-way handshake for WPA/RSN-PSK. With the
 wiphy::features flag being used up this patch adds a new
 field wiphy::ext_features. Considering extensibility this
 new field is declared as a byte array.

 Signed-off-by: Gautam (Gautam Kumar) Shukla gaut...@broadcom.com
 Signed-off-by: Arend van Spriel ar...@broadcom.com
 ---
 Hi Johannes,

 Here the proposed way to deal with new feature flags. Let
 me know if this is suitable.

 Regards,
 Arend
 ---

 @@ -3122,6 +3124,7 @@ struct wiphy {
 u16 max_acl_mac_addrs;

 u32 flags, regulatory_flags, features;
 +   u8 ext_features[1];

i think it would be nicer to use unsigned long (instead of u8) along
with BITS_TO_LONGS


  /**
 + * enum nl80211_ext_feature_index - bit index of extended features.
 + *
 + * @NL80211_EXT_FEATURE_4WAY_HANDSHAKE: the device supports 4way handshake
 + */
 +enum nl80211_ext_feature_index {
 +   NL80211_EXT_FEATURE_4WAY_HANDSHAKE,
 +};

just add the standard LAST/MAX defines here, and the bitmap size will
be allocated automatically.


 +void cfg80211_ext_feature_set(struct wiphy *wiphy,
 + enum nl80211_ext_feature_index ftidx)
 +{
 +   u8 *ft_byte;
 +
 +   ft_byte = wiphy-ext_features[ftidx / 8];
 +   *ft_byte |= BIT(ftidx % 8);
 +}
 +EXPORT_SYMBOL(cfg80211_ext_feature_set);
 +
 +bool cfg80211_ext_feature_isset(struct wiphy *wiphy,
 +   enum nl80211_ext_feature_index ftidx)
 +{
 +   u8 ft_byte;
 +
 +   ft_byte = wiphy-ext_features[ftidx / 8];
 +   return (ft_byte  BIT(ftidx % 8)) != 0;
 +}
 +EXPORT_SYMBOL(cfg80211_ext_feature_isset);

and these (or only the implementations) could be replaced by set_bit/test_bit.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] cfg80211: Add feature flag for 4-way handshake offload

[Eliad Peller]

hi Arend,

On Thu, Dec 18, 2014 at 5:21 PM, Arend van Spriel ar...@broadcom.com wrote:
 On 12/18/14 14:44, Eliad Peller wrote:
 On Thu, Dec 18, 2014 at 2:51 PM, Arend van Sprielar...@broadcom.com
 wrote:

 From: Gautam Kumar Shuklagaut...@broadcom.com

 The new feature flag allows the driver to indicate that it can
 offload the 4-way handshake for WPA/RSN-PSK. With the
 wiphy::features flag being used up this patch adds a new
 field wiphy::ext_features. Considering extensibility this
 new field is declared as a byte array.

 Signed-off-by: Gautam (Gautam Kumar) Shuklagaut...@broadcom.com
 Signed-off-by: Arend van Sprielar...@broadcom.com
 ---
 Hi Johannes,

 Here the proposed way to deal with new feature flags. Let
 me know if this is suitable.

 Regards,
 Arend
 ---


 @@ -3122,6 +3124,7 @@ struct wiphy {
  u16 max_acl_mac_addrs;

  u32 flags, regulatory_flags, features;
 +   u8 ext_features[1];

 i think it would be nicer to use unsigned long (instead of u8) along
 with BITS_TO_LONGS


 Thanks, Eliad

 I considered that, but decided against it. The main reason for me was the
 fact that this is passed in nl80211 attribute and using u8 seemed more
 straightforward to me. That said I think I will need to describe in nl80211
 how the bits are ordered in the byte-array.

usually bitmaps are implemented by unsigned long array, but i didn't
consider that in this case the array is passed to userspace as well
(as you and Johannes pointed out).
adding a conversion function to nl80211 can do the trick, but i guess
simply using u8 instead in this case makes sense :)


   /**
 + * enum nl80211_ext_feature_index - bit index of extended features.
 + *
 + * @NL80211_EXT_FEATURE_4WAY_HANDSHAKE: the device supports 4way
 handshake
 + */
 +enum nl80211_ext_feature_index {
 +   NL80211_EXT_FEATURE_4WAY_HANDSHAKE,
 +};


 just add the standard LAST/MAX defines here, and the bitmap size will
 be allocated automatically.


 I thought that was only for attribute enumerations. This is a bit index
 within a attribute.

it's usually not needed, but in this case it will allow defining
ext_features with proper length automatically.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: Warn once for delayed scan completion

[Eliad Peller]

On Tue, Oct 21, 2014 at 9:42 AM, Johannes Berg
johan...@sipsolutions.net wrote:
 On Tue, 2014-10-21 at 09:26 +0530, Sujith Manoharan wrote:
 Johannes Berg wrote:
  Maybe we need something like this:
 
  diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
  index af0d094b2f2f..45b74ab1c59d 100644
  --- a/net/mac80211/scan.c
  +++ b/net/mac80211/scan.c
  @@ -985,7 +985,6 @@ void ieee80211_scan_cancel(struct ieee80211_local 
  *local)
  drv_cancel_hw_scan(local,
  rcu_dereference_protected(local-scan_sdata,
  lockdep_is_held(local-mtx)));
  -   goto out;
  }

 Is the big comment at the beginning of ieee80211_scan_cancel()
 outdated ? It does seem valid to me, at least the point about
 not cancelling scan_work for HW scan.

 Yeah you're right.

 However, when the interface is deleted, the driver must still also
 remove the scan and definitely schedule the work, so most drivers will
 really always do so in cancel_hw_scan()? We could change the API and
 require that to be synchronous, like in the interface removal case, but
 maybe we don't want to.

 How about this then?

 diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
 index e469b3390f2a..6f1b90eb568c 100644
 --- a/net/mac80211/iface.c
 +++ b/net/mac80211/iface.c
 @@ -766,10 +766,12 @@ static void ieee80211_do_stop(struct 
 ieee80211_sub_if_data *sdata,
 int i, flushed;
 struct ps_data *ps;
 struct cfg80211_chan_def chandef;
 +   bool cancel_scan;

 clear_bit(SDATA_STATE_RUNNING, sdata-state);

 -   if (rcu_access_pointer(local-scan_sdata) == sdata)
 +   cancel_scan = rcu_access_pointer(local-scan_sdata) == sdata;
 +   if (cancel_scan)
 ieee80211_scan_cancel(local);

 /*
 @@ -993,6 +995,9 @@ static void ieee80211_do_stop(struct 
 ieee80211_sub_if_data *sdata,

 ieee80211_recalc_ps(local, -1);

 +   if (cancel_scan)
 +   flush_delayed_work(local-scan_work);
 +
 if (local-open_count == 0) {
 ieee80211_stop_device(local);

This patch actually solves a kernel panic that can be reproduced
easily by increasing the delay in ieee80211_scan_completed() and
removing the driver right after initiating a scan - the delayed
scan_work never gets flushed, resulting in invalid memory access, etc.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SMPS for AP mode confoguration

[Eliad Peller]

hi,

On Sun, Oct 19, 2014 at 2:50 PM, Krishna Chaitanya
chaitanya.m...@gmail.com wrote:
 We are testing SMPS functionality for AP mode. The driver conveys its
 capabilities through setting the HT capability which can be set to 0-3.

 I wanted to convey support for both Dynamic and Static Powersave
 and then control the config through hostapd.conf file. Currently this is
 not possible.From driver i can only advertize support for static (or) dynamic
 not both (HW_SUPPORTS_* is a different thing which is used in
 doing checks at debugfs level).

 So if i wanted to configure different modes from hostapd.conf, i
 have to change the driver settings as well.

 Shouldn't it be the other way around, based on driver's _HW_ flags
 we should convey the capabilities to user-space  (currently we use
 ht_cap for this) and it will configure the mode from the configuration
 file.  I think the design of SMPS configuration should be changed.

this was recently changed. take a look at this patchset:
http://www.spinics.net/lists/linux-wireless/msg126749.html

we also have a matching supplicant patchset that will probably be
upstreamed soon.

Eliad.
--
To unsubscribe from this list: send the line unsubscribe linux-wireless in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html