* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Mark Rutland @ 2013-06-28 10:33 UTC (permalink / raw)
To: Luciano Coelho
Cc: linux-doc@vger.kernel.org, devicetree-discuss@lists.ozlabs.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
rob.herring@calxeda.com, grant.likely@linaro.org,
linux-omap@vger.kernel.org, "mturquette
In-Reply-To: <1372413215.21065.41.camel@cumari.coelho.fi>
[resending with the correct address for Mike Turquette]
On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > +Optional properties:
> > > +--------------------
> > > +
> > > +- refclock: the internal WLAN reference clock frequency (required for
> > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > > + following:
> > > + 0 = 19.2 MHz
> > > + 1 = 26.0 MHz
> > > + 2 = 38.4 MHz
> > > + 3 = 52.0 MHz
> > > + 4 = 38.4 MHz, XTAL
> > > + 5 = 26.0 MHz, XTAL
> > > +
> > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > > + following:
> > > + 0 = 19.200 MHz
> > > + 1 = 26.000 MHz
> > > + 2 = 38.400 MHz
> > > + 3 = 52.000 MHz
> > > + 4 = 16.368 MHz
> > > + 5 = 32.736 MHz
> > > + 6 = 16.800 MHz
> > > + 7 = 33.600 MHz
> >
> > This looks suspiciously like what we have the common clock bindings for:
> >
> > refclk {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <19200000>;
> > }
> >
> > wilink {
> > compatible = "ti,wilink7";
> > interrupt-parent = <&some_interrupt_controller>;
> > interrupts = <0 1 1>;
> > clocks = <&refclk>, <&refclk>;
> > clock-names = "refclk", "txoclk";
> > };
> >
> > Could you not use them?
>
> Hmmm... this actually does look good. But these are internal clocks in
> the modules, they cannot be accessed from outside. Does it make sense
> to register them with the clock framework?
Given we already have a common way of describing clocks, I think it
makes sense to use it -- people already understand the common bindings,
and it's less code to add add to the kernel. I don't think the fact
these clocks are internal should prevent us from describing them as we
would an external clock.
Perhaps Mike Turquette [Cc'd] has an opinion on the matter.
Thanks,
Mark.
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Luciano Coelho @ 2013-06-28 10:31 UTC (permalink / raw)
To: Mark Rutland, mturquette
Cc: grant.likely@linaro.org, rob.herring@calxeda.com,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-arm@vger.kernel.org
In-Reply-To: <20130628102145.GB2139@e106331-lin.cambridge.arm.com>
(fixed Mike's address)
On Fri, 2013-06-28 at 11:21 +0100, Mark Rutland wrote:
> On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> > On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > > +Optional properties:
> > > > +--------------------
> > > > +
> > > > +- refclock: the internal WLAN reference clock frequency (required for
> > > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > > > + following:
> > > > + 0 = 19.2 MHz
> > > > + 1 = 26.0 MHz
> > > > + 2 = 38.4 MHz
> > > > + 3 = 52.0 MHz
> > > > + 4 = 38.4 MHz, XTAL
> > > > + 5 = 26.0 MHz, XTAL
> > > > +
> > > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > > > + following:
> > > > + 0 = 19.200 MHz
> > > > + 1 = 26.000 MHz
> > > > + 2 = 38.400 MHz
> > > > + 3 = 52.000 MHz
> > > > + 4 = 16.368 MHz
> > > > + 5 = 32.736 MHz
> > > > + 6 = 16.800 MHz
> > > > + 7 = 33.600 MHz
> > >
> > > This looks suspiciously like what we have the common clock bindings for:
> > >
> > > refclk {
> > > compatible = "fixed-clock";
> > > #clock-cells = <0>;
> > > clock-frequency = <19200000>;
> > > }
> > >
> > > wilink {
> > > compatible = "ti,wilink7";
> > > interrupt-parent = <&some_interrupt_controller>;
> > > interrupts = <0 1 1>;
> > > clocks = <&refclk>, <&refclk>;
> > > clock-names = "refclk", "txoclk";
> > > };
> > >
> > > Could you not use them?
> >
> > Hmmm... this actually does look good. But these are internal clocks in
> > the modules, they cannot be accessed from outside. Does it make sense
> > to register them with the clock framework?
>
> Given we already have a common way of describing clocks, I think it
> makes sense to use it -- people already understand the common bindings,
> and it's less code to add add to the kernel. I don't think the fact
> these clocks are internal should prevent us from describing them as we
> would an external clock.
Yes, I agree with you. Thanks for the suggestion! I think it will look
much better. And now that I dug a bit more into the code, I can see
that there are only structs being populated, so there shouldn't be any
other side-effects.
> Perhaps Mike Turquette [Cc'd] has an opinion on the matter.
Experts' opinions are appreciated. :)
--
Luca.
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Mark Rutland @ 2013-06-28 10:21 UTC (permalink / raw)
To: Luciano Coelho
Cc: grant.likely@linaro.org, rob.herring@calxeda.com,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-arm@vger.kernel.org,
mturquette
In-Reply-To: <1372413215.21065.41.camel@cumari.coelho.fi>
On Fri, Jun 28, 2013 at 10:53:35AM +0100, Luciano Coelho wrote:
> On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> > On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > > +Optional properties:
> > > +--------------------
> > > +
> > > +- refclock: the internal WLAN reference clock frequency (required for
> > > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > > + following:
> > > + 0 = 19.2 MHz
> > > + 1 = 26.0 MHz
> > > + 2 = 38.4 MHz
> > > + 3 = 52.0 MHz
> > > + 4 = 38.4 MHz, XTAL
> > > + 5 = 26.0 MHz, XTAL
> > > +
> > > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > > + following:
> > > + 0 = 19.200 MHz
> > > + 1 = 26.000 MHz
> > > + 2 = 38.400 MHz
> > > + 3 = 52.000 MHz
> > > + 4 = 16.368 MHz
> > > + 5 = 32.736 MHz
> > > + 6 = 16.800 MHz
> > > + 7 = 33.600 MHz
> >
> > This looks suspiciously like what we have the common clock bindings for:
> >
> > refclk {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <19200000>;
> > }
> >
> > wilink {
> > compatible = "ti,wilink7";
> > interrupt-parent = <&some_interrupt_controller>;
> > interrupts = <0 1 1>;
> > clocks = <&refclk>, <&refclk>;
> > clock-names = "refclk", "txoclk";
> > };
> >
> > Could you not use them?
>
> Hmmm... this actually does look good. But these are internal clocks in
> the modules, they cannot be accessed from outside. Does it make sense
> to register them with the clock framework?
Given we already have a common way of describing clocks, I think it
makes sense to use it -- people already understand the common bindings,
and it's less code to add add to the kernel. I don't think the fact
these clocks are internal should prevent us from describing them as we
would an external clock.
Perhaps Mike Turquette [Cc'd] has an opinion on the matter.
Thanks,
Mark.
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Luciano Coelho @ 2013-06-28 9:53 UTC (permalink / raw)
To: Mark Rutland
Cc: grant.likely@linaro.org, rob.herring@calxeda.com,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-arm@vger.kernel.org
In-Reply-To: <20130628093848.GA2139@e106331-lin.cambridge.arm.com>
On Fri, 2013-06-28 at 10:38 +0100, Mark Rutland wrote:
> On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> > +Optional properties:
> > +--------------------
> > +
> > +- refclock: the internal WLAN reference clock frequency (required for
> > + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> > + following:
> > + 0 = 19.2 MHz
> > + 1 = 26.0 MHz
> > + 2 = 38.4 MHz
> > + 3 = 52.0 MHz
> > + 4 = 38.4 MHz, XTAL
> > + 5 = 26.0 MHz, XTAL
> > +
> > +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> > + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> > + following:
> > + 0 = 19.200 MHz
> > + 1 = 26.000 MHz
> > + 2 = 38.400 MHz
> > + 3 = 52.000 MHz
> > + 4 = 16.368 MHz
> > + 5 = 32.736 MHz
> > + 6 = 16.800 MHz
> > + 7 = 33.600 MHz
>
> This looks suspiciously like what we have the common clock bindings for:
>
> refclk {
> compatible = "fixed-clock";
> #clock-cells = <0>;
> clock-frequency = <19200000>;
> }
>
> wilink {
> compatible = "ti,wilink7";
> interrupt-parent = <&some_interrupt_controller>;
> interrupts = <0 1 1>;
> clocks = <&refclk>, <&refclk>;
> clock-names = "refclk", "txoclk";
> };
>
> Could you not use them?
Hmmm... this actually does look good. But these are internal clocks in
the modules, they cannot be accessed from outside. Does it make sense
to register them with the clock framework?
--
Luca.
^ permalink raw reply
* [PATCH] cfg80211: fix bugs in new SME implementation
From: Johannes Berg @ 2013-06-28 9:41 UTC (permalink / raw)
To: linux-wireless
When splitting the SME implementation from the MLME code,
I introduced a few bugs:
* association failures no longer sent a connect-failure event
* getting disassociated from the AP caused deauth to be sent
but state wasn't cleaned up, leading to warnings
* authentication failures weren't cleaned up properly, causing
new connection attempts to warn and fail
Fix these bugs.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/wireless/sme.c | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 1d3cfb1..81c8a10 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -34,8 +34,10 @@ struct cfg80211_conn {
CFG80211_CONN_SCAN_AGAIN,
CFG80211_CONN_AUTHENTICATE_NEXT,
CFG80211_CONN_AUTHENTICATING,
+ CFG80211_CONN_AUTH_FAILED,
CFG80211_CONN_ASSOCIATE_NEXT,
CFG80211_CONN_ASSOCIATING,
+ CFG80211_CONN_ASSOC_FAILED,
CFG80211_CONN_DEAUTH,
CFG80211_CONN_CONNECTED,
} state;
@@ -164,6 +166,8 @@ static int cfg80211_conn_do_work(struct wireless_dev *wdev)
NULL, 0,
params->key, params->key_len,
params->key_idx, NULL, 0);
+ case CFG80211_CONN_AUTH_FAILED:
+ return -ENOTCONN;
case CFG80211_CONN_ASSOCIATE_NEXT:
BUG_ON(!rdev->ops->assoc);
wdev->conn->state = CFG80211_CONN_ASSOCIATING;
@@ -188,10 +192,17 @@ static int cfg80211_conn_do_work(struct wireless_dev *wdev)
WLAN_REASON_DEAUTH_LEAVING,
false);
return err;
+ case CFG80211_CONN_ASSOC_FAILED:
+ cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid,
+ NULL, 0,
+ WLAN_REASON_DEAUTH_LEAVING, false);
+ return -ENOTCONN;
case CFG80211_CONN_DEAUTH:
cfg80211_mlme_deauth(rdev, wdev->netdev, params->bssid,
NULL, 0,
WLAN_REASON_DEAUTH_LEAVING, false);
+ /* free directly, disconnected event already sent */
+ cfg80211_sme_free(wdev);
return 0;
default:
return 0;
@@ -371,7 +382,7 @@ bool cfg80211_sme_rx_assoc_resp(struct wireless_dev *wdev, u16 status)
return true;
}
- wdev->conn->state = CFG80211_CONN_DEAUTH;
+ wdev->conn->state = CFG80211_CONN_ASSOC_FAILED;
schedule_work(&rdev->conn_work);
return false;
}
@@ -383,7 +394,13 @@ void cfg80211_sme_deauth(struct wireless_dev *wdev)
void cfg80211_sme_auth_timeout(struct wireless_dev *wdev)
{
- cfg80211_sme_free(wdev);
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+
+ if (!wdev->conn)
+ return;
+
+ wdev->conn->state = CFG80211_CONN_AUTH_FAILED;
+ schedule_work(&rdev->conn_work);
}
void cfg80211_sme_disassoc(struct wireless_dev *wdev)
@@ -399,7 +416,13 @@ void cfg80211_sme_disassoc(struct wireless_dev *wdev)
void cfg80211_sme_assoc_timeout(struct wireless_dev *wdev)
{
- cfg80211_sme_disassoc(wdev);
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wdev->wiphy);
+
+ if (!wdev->conn)
+ return;
+
+ wdev->conn->state = CFG80211_CONN_ASSOC_FAILED;
+ schedule_work(&rdev->conn_work);
}
static int cfg80211_sme_connect(struct wireless_dev *wdev,
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Mark Rutland @ 2013-06-28 9:38 UTC (permalink / raw)
To: Luciano Coelho
Cc: grant.likely@linaro.org, rob.herring@calxeda.com,
devicetree-discuss@lists.ozlabs.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-arm@vger.kernel.org
In-Reply-To: <1372149330-24335-1-git-send-email-coelho@ti.com>
On Tue, Jun 25, 2013 at 09:35:30AM +0100, Luciano Coelho wrote:
> Add device tree bindings documentation for the TI WiLink modules.
> Currently only the WLAN part of the WiLink6, WiLink7 and WiLink8
> modules is supported.
>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
>
> I created a new directory under net to contain wireless bindings documentation.
>
> The actual implementation in the driver will follow separately.
>
> .../devicetree/bindings/net/wireless/ti-wilink.txt | 46 ++++++++++++++++++++
> 1 file changed, 46 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> new file mode 100644
> index 0000000..d8e8bfbb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/wireless/ti-wilink.txt
> @@ -0,0 +1,46 @@
> +TI WiLink Wireless Modules Device Tree Bindings
> +===============================================
> +
> +The WiLink modules provide wireless connectivity, such as WLAN,
> +Bluetooth, FM and NFC.
> +
> +There are several different modules available, which can be grouped by
> +their generation: WiLink6, WiLink7 and WiLink8. WiLink4 is not
> +currently supported with device tree.
> +
> +Currently, only the WLAN portion of the modules is supported with
> +device tree.
> +
> +Required properties:
> +--------------------
> +
> +- compatible: should be "ti,wilink6", "ti,wilink7" or "ti,wilink8"
> +- interrupt-parent: the interrupt controller
> +- interrupts: out-of-band WLAN interrupt
> + See the interrupt controller's bindings documentation for
> + detailed definition.
> +
> +Optional properties:
> +--------------------
> +
> +- refclock: the internal WLAN reference clock frequency (required for
> + WiLink6 and WiLink7; not used for WiLink8). Must be one of the
> + following:
> + 0 = 19.2 MHz
> + 1 = 26.0 MHz
> + 2 = 38.4 MHz
> + 3 = 52.0 MHz
> + 4 = 38.4 MHz, XTAL
> + 5 = 26.0 MHz, XTAL
> +
> +- tcxoclock: the internal WLAN TCXO clock frequency (required for
> + WiLink7 not used for WiLink6 and WiLink8). Must be one of the
> + following:
> + 0 = 19.200 MHz
> + 1 = 26.000 MHz
> + 2 = 38.400 MHz
> + 3 = 52.000 MHz
> + 4 = 16.368 MHz
> + 5 = 32.736 MHz
> + 6 = 16.800 MHz
> + 7 = 33.600 MHz
This looks suspiciously like what we have the common clock bindings for:
refclk {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <19200000>;
}
wilink {
compatible = "ti,wilink7";
interrupt-parent = <&some_interrupt_controller>;
interrupts = <0 1 1>;
clocks = <&refclk>, <&refclk>;
clock-names = "refclk", "txoclk";
};
Could you not use them?
Thanks,
Mark.
^ permalink raw reply
* Re: rtl8192cu: slow path warning
From: Richard GENOUD @ 2013-06-28 8:58 UTC (permalink / raw)
To: Larry Finger
Cc: Chaoming Li, John W. Linville, linux-wireless, linux-kernel,
Maxime Ripard
In-Reply-To: <51CC8284.9070301@lwfinger.net>
On [jeu., 27.06.2013 13:20:52], Larry Finger wrote:
> On 06/27/2013 02:33 AM, Richard Genoud wrote:
> >Yes, of course, you can add my
> >Reported-by: Richard Genoud <richard.genoud@gmail.com>
> >
> >But the patch doesn't compile on my platform ( since I'm on ARM, I
> >haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) :
> >
> >ERROR: "rtl_lps_change_work_callback"
> >[drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined!
> >
> >
> >Best regards,
> >Richard.
> >
> >PS: duckducking the warning, I found this automated report also :
> >https://retrace.fedoraproject.org/faf/reports/142038/
>
> A revised patch for the warning is attached. The fix relatively
> simple and the only difference between this one and the earlier
> version is that routine rtl_lps_change_work_callback() was moved
> from pci.c to ps.c. As a result, it will be available for ARM and
> other architectures without a PCI bus.
>
> Larry
>
>
> Index: wireless-testing-save/drivers/net/wireless/rtlwifi/pci.c
> ===================================================================
> --- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/pci.c
> +++ wireless-testing-save/drivers/net/wireless/rtlwifi/pci.c
> @@ -1008,19 +1008,6 @@ static void _rtl_pci_prepare_bcn_tasklet
> return;
> }
>
> -static void rtl_lps_change_work_callback(struct work_struct *work)
> -{
> - struct rtl_works *rtlworks =
> - container_of(work, struct rtl_works, lps_change_work);
> - struct ieee80211_hw *hw = rtlworks->hw;
> - struct rtl_priv *rtlpriv = rtl_priv(hw);
> -
> - if (rtlpriv->enter_ps)
> - rtl_lps_enter(hw);
> - else
> - rtl_lps_leave(hw);
> -}
> -
> static void _rtl_pci_init_trx_var(struct ieee80211_hw *hw)
> {
> struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
> Index: wireless-testing-save/drivers/net/wireless/rtlwifi/ps.h
> ===================================================================
> --- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/ps.h
> +++ wireless-testing-save/drivers/net/wireless/rtlwifi/ps.h
> @@ -49,5 +49,6 @@ void rtl_swlps_rf_awake(struct ieee80211
> void rtl_swlps_rf_sleep(struct ieee80211_hw *hw);
> void rtl_p2p_ps_cmd(struct ieee80211_hw *hw, u8 p2p_ps_state);
> void rtl_p2p_info(struct ieee80211_hw *hw, void *data, unsigned int len);
> +void rtl_lps_change_work_callback(struct work_struct *work);
>
> #endif
> Index: wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
> ===================================================================
> --- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/usb.c
> +++ wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
> @@ -1070,6 +1070,8 @@ int rtl_usb_probe(struct usb_interface *
> spin_lock_init(&rtlpriv->locks.usb_lock);
> INIT_WORK(&rtlpriv->works.fill_h2c_cmd,
> rtl_fill_h2c_cmd_work_callback);
> + INIT_WORK(&rtlpriv->works.lps_change_work,
> + rtl_lps_change_work_callback);
>
> rtlpriv->usb_data_index = 0;
> init_completion(&rtlpriv->firmware_loading_complete);
> Index: wireless-testing-save/drivers/net/wireless/rtlwifi/ps.c
> ===================================================================
> --- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/ps.c
> +++ wireless-testing-save/drivers/net/wireless/rtlwifi/ps.c
> @@ -611,6 +611,18 @@ void rtl_swlps_rf_sleep(struct ieee80211
> MSECS(sleep_intv * mac->vif->bss_conf.beacon_int - 40));
> }
>
> +void rtl_lps_change_work_callback(struct work_struct *work)
> +{
> + struct rtl_works *rtlworks =
> + container_of(work, struct rtl_works, lps_change_work);
> + struct ieee80211_hw *hw = rtlworks->hw;
> + struct rtl_priv *rtlpriv = rtl_priv(hw);
> +
> + if (rtlpriv->enter_ps)
> + rtl_lps_enter(hw);
> + else
> + rtl_lps_leave(hw);
> +}
>
> void rtl_swlps_wq_callback(void *data)
> {
Tested the patch on 3.10-rc7, ARM at91sam9g35, usb key TP-link
TL-WN725N.
I haven't seen the WARNING any more.
Tests done: (DHCP request)
client with no security
client WEP
client WPA
AP with no security
AP WEP
AP+WAP test failed (bust it was like that before the patch also)
Tested-by: Richard Genoud <richard.genoud@gmail.com>
^ permalink raw reply
* [PATCH 1/2] nl80211: enable HT overrides for ibss
From: Simon Wunderlich @ 2013-06-28 8:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 13 +++++++++++++
2 files changed, 18 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7b0730a..836b7e2 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1592,6 +1592,9 @@ struct cfg80211_disassoc_request {
* user space. Otherwise, port is marked authorized by default.
* @basic_rates: bitmap of basic rates to use when creating the IBSS
* @mcast_rate: per-band multicast rate index + 1 (0: disabled)
+ * @ht_capa: HT Capabilities over-rides. Values set in ht_capa_mask
+ * will be used in ht_capa. Un-supported values will be ignored.
+ * @ht_capa_mask: The bits of ht_capa which are to be used.
*/
struct cfg80211_ibss_params {
u8 *ssid;
@@ -1605,6 +1608,8 @@ struct cfg80211_ibss_params {
bool privacy;
bool control_port;
int mcast_rate[IEEE80211_NUM_BANDS];
+ struct ieee80211_ht_cap ht_capa;
+ struct ieee80211_ht_cap ht_capa_mask;
};
/**
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7dc3343..d74230c 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6344,6 +6344,19 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
return err;
}
+ if (info->attrs[NL80211_ATTR_HT_CAPABILITY_MASK])
+ memcpy(&ibss.ht_capa_mask,
+ nla_data(info->attrs[NL80211_ATTR_HT_CAPABILITY_MASK]),
+ sizeof(ibss.ht_capa_mask));
+
+ if (info->attrs[NL80211_ATTR_HT_CAPABILITY]) {
+ if (!info->attrs[NL80211_ATTR_HT_CAPABILITY_MASK])
+ return -EINVAL;
+ memcpy(&ibss.ht_capa,
+ nla_data(info->attrs[NL80211_ATTR_HT_CAPABILITY]),
+ sizeof(ibss.ht_capa));
+ }
+
if (info->attrs[NL80211_ATTR_MCAST_RATE] &&
!nl80211_parse_mcast_rate(rdev, ibss.mcast_rate,
nla_get_u32(info->attrs[NL80211_ATTR_MCAST_RATE])))
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/2] mac80211: enable HT overrides for ibss
From: Simon Wunderlich @ 2013-06-28 8:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372408799-25651-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/mac80211/ht.c | 53 +++++++++++++++++++++++++++++++-------------
net/mac80211/ibss.c | 18 +++++++++++++--
net/mac80211/ieee80211_i.h | 3 +++
3 files changed, 57 insertions(+), 17 deletions(-)
diff --git a/net/mac80211/ht.c b/net/mac80211/ht.c
index f83534f..529bf58 100644
--- a/net/mac80211/ht.c
+++ b/net/mac80211/ht.c
@@ -19,13 +19,14 @@
#include "ieee80211_i.h"
#include "rate.h"
-static void __check_htcap_disable(struct ieee80211_sub_if_data *sdata,
+static void __check_htcap_disable(struct ieee80211_ht_cap *ht_capa,
+ struct ieee80211_ht_cap *ht_capa_mask,
struct ieee80211_sta_ht_cap *ht_cap,
u16 flag)
{
__le16 le_flag = cpu_to_le16(flag);
- if (sdata->u.mgd.ht_capa_mask.cap_info & le_flag) {
- if (!(sdata->u.mgd.ht_capa.cap_info & le_flag))
+ if (ht_capa_mask->cap_info & le_flag) {
+ if (!(ht_capa->cap_info & le_flag))
ht_cap->cap &= ~flag;
}
}
@@ -33,13 +34,30 @@ static void __check_htcap_disable(struct ieee80211_sub_if_data *sdata,
void ieee80211_apply_htcap_overrides(struct ieee80211_sub_if_data *sdata,
struct ieee80211_sta_ht_cap *ht_cap)
{
- u8 *scaps = (u8 *)(&sdata->u.mgd.ht_capa.mcs.rx_mask);
- u8 *smask = (u8 *)(&sdata->u.mgd.ht_capa_mask.mcs.rx_mask);
+ struct ieee80211_ht_cap *ht_capa, *ht_capa_mask;
+ u8 *scaps, *smask;
int i;
if (!ht_cap->ht_supported)
return;
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_STATION:
+ ht_capa = &sdata->u.mgd.ht_capa;
+ ht_capa_mask = &sdata->u.mgd.ht_capa_mask;
+ break;
+ case NL80211_IFTYPE_ADHOC:
+ ht_capa = &sdata->u.ibss.ht_capa;
+ ht_capa_mask = &sdata->u.ibss.ht_capa_mask;
+ break;
+ default:
+ WARN_ON_ONCE(1);
+ return;
+ }
+
+ scaps = (u8 *)(&ht_capa->mcs.rx_mask);
+ smask = (u8 *)(&ht_capa_mask->mcs.rx_mask);
+
/* NOTE: If you add more over-rides here, update register_hw
* ht_capa_mod_msk logic in main.c as well.
* And, if this method can ever change ht_cap.ht_supported, fix
@@ -55,28 +73,32 @@ void ieee80211_apply_htcap_overrides(struct ieee80211_sub_if_data *sdata,
}
/* Force removal of HT-40 capabilities? */
- __check_htcap_disable(sdata, ht_cap, IEEE80211_HT_CAP_SUP_WIDTH_20_40);
- __check_htcap_disable(sdata, ht_cap, IEEE80211_HT_CAP_SGI_40);
+ __check_htcap_disable(ht_capa, ht_capa_mask, ht_cap,
+ IEEE80211_HT_CAP_SUP_WIDTH_20_40);
+ __check_htcap_disable(ht_capa, ht_capa_mask, ht_cap,
+ IEEE80211_HT_CAP_SGI_40);
/* Allow user to disable SGI-20 (SGI-40 is handled above) */
- __check_htcap_disable(sdata, ht_cap, IEEE80211_HT_CAP_SGI_20);
+ __check_htcap_disable(ht_capa, ht_capa_mask, ht_cap,
+ IEEE80211_HT_CAP_SGI_20);
/* Allow user to disable the max-AMSDU bit. */
- __check_htcap_disable(sdata, ht_cap, IEEE80211_HT_CAP_MAX_AMSDU);
+ __check_htcap_disable(ht_capa, ht_capa_mask, ht_cap,
+ IEEE80211_HT_CAP_MAX_AMSDU);
/* Allow user to decrease AMPDU factor */
- if (sdata->u.mgd.ht_capa_mask.ampdu_params_info &
+ if (ht_capa_mask->ampdu_params_info &
IEEE80211_HT_AMPDU_PARM_FACTOR) {
- u8 n = sdata->u.mgd.ht_capa.ampdu_params_info
- & IEEE80211_HT_AMPDU_PARM_FACTOR;
+ u8 n = ht_capa->ampdu_params_info &
+ IEEE80211_HT_AMPDU_PARM_FACTOR;
if (n < ht_cap->ampdu_factor)
ht_cap->ampdu_factor = n;
}
/* Allow the user to increase AMPDU density. */
- if (sdata->u.mgd.ht_capa_mask.ampdu_params_info &
+ if (ht_capa_mask->ampdu_params_info &
IEEE80211_HT_AMPDU_PARM_DENSITY) {
- u8 n = (sdata->u.mgd.ht_capa.ampdu_params_info &
+ u8 n = (ht_capa->ampdu_params_info &
IEEE80211_HT_AMPDU_PARM_DENSITY)
>> IEEE80211_HT_AMPDU_PARM_DENSITY_SHIFT;
if (n > ht_cap->ampdu_density)
@@ -112,7 +134,8 @@ bool ieee80211_ht_cap_ie_to_sta_ht_cap(struct ieee80211_sub_if_data *sdata,
* we advertised a restricted capability set to. Override
* our own capabilities and then use those below.
*/
- if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+ if ((sdata->vif.type == NL80211_IFTYPE_STATION ||
+ sdata->vif.type == NL80211_IFTYPE_ADHOC) &&
!test_sta_flag(sta, WLAN_STA_TDLS_PEER))
ieee80211_apply_htcap_overrides(sdata, &own_cap);
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index ea7b9c2..25e6998 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -179,8 +179,12 @@ static void __ieee80211_sta_join_ibss(struct ieee80211_sub_if_data *sdata,
chandef.width != NL80211_CHAN_WIDTH_5 &&
chandef.width != NL80211_CHAN_WIDTH_10 &&
sband->ht_cap.ht_supported) {
- pos = ieee80211_ie_build_ht_cap(pos, &sband->ht_cap,
- sband->ht_cap.cap);
+ struct ieee80211_sta_ht_cap ht_cap;
+
+ memcpy(&ht_cap, &sband->ht_cap, sizeof(ht_cap));
+ ieee80211_apply_htcap_overrides(sdata, &ht_cap);
+
+ pos = ieee80211_ie_build_ht_cap(pos, &ht_cap, ht_cap.cap);
/*
* Note: According to 802.11n-2009 9.13.3.1, HT Protection
* field and RIFS Mode are reserved in IBSS mode, therefore
@@ -1051,6 +1055,11 @@ int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
memcpy(sdata->u.ibss.ssid, params->ssid, params->ssid_len);
sdata->u.ibss.ssid_len = params->ssid_len;
+ memcpy(&sdata->u.ibss.ht_capa, ¶ms->ht_capa,
+ sizeof(sdata->u.ibss.ht_capa));
+ memcpy(&sdata->u.ibss.ht_capa_mask, ¶ms->ht_capa_mask,
+ sizeof(sdata->u.ibss.ht_capa_mask));
+
/*
* 802.11n-2009 9.13.3.1: In an IBSS, the HT Protection field is
* reserved, but an HT STA shall protect HT transmissions as though
@@ -1131,6 +1140,11 @@ int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata)
presp = rcu_dereference_protected(ifibss->presp,
lockdep_is_held(&sdata->wdev.mtx));
RCU_INIT_POINTER(sdata->u.ibss.presp, NULL);
+
+ /* on the next assoc, re-program HT parameters */
+ memset(&ifibss->ht_capa, 0, sizeof(ifibss->ht_capa));
+ memset(&ifibss->ht_capa_mask, 0, sizeof(ifibss->ht_capa_mask));
+
sdata->vif.bss_conf.ibss_joined = false;
sdata->vif.bss_conf.ibss_creator = false;
sdata->vif.bss_conf.enable_beacon = false;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 8412a30..683751a 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -509,6 +509,9 @@ struct ieee80211_if_ibss {
/* probe response/beacon for IBSS */
struct beacon_data __rcu *presp;
+ struct ieee80211_ht_cap ht_capa; /* configured ht-cap over-rides */
+ struct ieee80211_ht_cap ht_capa_mask; /* Valid parts of ht_capa */
+
spinlock_t incomplete_lock;
struct list_head incomplete_stations;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] ath10k: minimally handle new channel width enumeration values
From: Kalle Valo @ 2013-06-28 7:10 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1372355538-19284-1-git-send-email-linville@tuxdriver.com>
"John W. Linville" <linville@tuxdriver.com> writes:
> From: "John W. Linville" <linville@tuxdriver.com>
>
> CC drivers/net/wireless/ath/ath10k/mac.o
> drivers/net/wireless/ath/ath10k/mac.c: In function ‘chan_to_phymode’:
> drivers/net/wireless/ath/ath10k/mac.c:229:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_5’ not handled in switch [-Wswitch]
> drivers/net/wireless/ath/ath10k/mac.c:229:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_10’ not handled in switch [-Wswitch]
> drivers/net/wireless/ath/ath10k/mac.c:247:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_5’ not handled in switch [-Wswitch]
> drivers/net/wireless/ath/ath10k/mac.c:247:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_10’ not handled in switch [-Wswitch]
>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
Looks good, thanks for fixing this while I'm on vacation. Strangely
enough we even had few warm days here in Finland! :)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Nishanth Menon @ 2013-06-27 19:56 UTC (permalink / raw)
To: Luciano Coelho
Cc: grant.likely, rob.herring, devicetree-discuss, linux-doc, lkml,
linux-wireless, Tony Lindgren, linux-omap,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1372362418.21065.25.camel@cumari.coelho.fi>
On 06/27/2013 02:46 PM, Luciano Coelho wrote:
> On Thu, 2013-06-27 at 14:12 -0500, Nishanth Menon wrote:
[...]
>> Indexes to another entity is always a maintenance burden in the longer
>> run and needs judicious control. If it is possible to avoid it by
>> selecting the right parameters, I am a hard advocate for the same.
>
> I tend to agree. But you need a balance. In theory you're right. But
> I think if you take the real world example, it is over-engineering.
>
> Anyway, if you *really* think this needs to be changed, I think we're in
> a deadlock here and I'd like to hear other people's opinions. I don't
> mind making the change, but I'm still not convinced it is worth it,
> since it just adds complexity.
>
> And hey, this is too much bikeshedding for such a small detail.
Lol :)
Alrite, if no one else is complaining, I am not going to block it either.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Luciano Coelho @ 2013-06-27 19:46 UTC (permalink / raw)
To: Nishanth Menon
Cc: grant.likely, rob.herring, devicetree-discuss, linux-doc, lkml,
linux-wireless, Tony Lindgren, linux-omap,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <51CC8E80.5030206@ti.com>
On Thu, 2013-06-27 at 14:12 -0500, Nishanth Menon wrote:
> On 06/27/2013 01:51 PM, Luciano Coelho wrote:
> > On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
> >> On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho <coelho@ti.com> wrote:
> >>> On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
> >>>> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
> >>>>> On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> >>>>>> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho <coelho@ti.com> wrote:
> >>>>>>> For the actual DTS files, I could add a wilink.dtsi with enumerations
> >>>>>>> for these values so they could be used in the node definitions. But I'm
> >>>>>>> not sure it's going to be that valuable in the end.
> >>>>>> The way GPIO HIGH was defined might help to provide guidance I think :)
> >>>>>
> >>>>> Where? As far as I can see, the GPIO flags are defined in a bitmap.
> >>>>
> >>>> include/dt-bindings/gpio/gpio.h
> >>>
> >>> Thanks! I don't see these macros used anywhere, though.
> >> umm... I'd think you have'nt looked deep enough / lists :)
> >
> > If you mean mailing lists, you're right, I didn't. I just did a git
> > grep for the macros and didn't find any users.
> git grep "GPIO_ACTIVE_[HIGH|LOW]" arch/arm/boot/dts/|wc -l
> 344
> on next-20130626. anyways, besides the point.
>
>
> >>> This seems to be a completely different thing. This is the header that
> >>> contains the helper functions to get GPIO-related device tree nodes,
> >>> isn't it?
> >> That is true, but it also contains the flag for level which needs to
> >> be in sync with the gpio.h dts header.
> >>>> just a hint. not saying frequencies were defined in header. for systems
> >>>> that define frequencies - example cpufreq OPPs, clock node usage, we do
> >>>> not use indexing to frequency, instead, that is the responsibility of
> >>>> driver to convert frequency back to required index.
> >>>> git grep frequency Documentation/devicetree/bindings gives you how the
> >>>> precedence looks like.
> >>>>
> >>>> Personally, if given a choice, I'd go with actual frequencies rather
> >>>> than indexes.
> >>>
> >>> If I do that, I need to add also a separate flag to define whether the
> >>> XTAL clock is used or not. For instance, we have 26MHz and 26MHz
> >>> crystal; and 38.4MHz and 38.4MHz crystal...
> >> Yes, you would have to. at the same time, it is easy for module maker
> >> to provide dtsi corresponding to exact h/w representation on his
> >> module using wilink chip without being worried about weird index value
> >> whose meaning is hidden in binding
> >
> > The module makers need to know about the bindings and read the document
> > before they specify the node in DTS. I think for clarity, a comment in
> > the DTS file stating the actual frequency is good enough. Simpler and
> > more efficient (in terms of DT binary size and module code size) than
> > adding the actual frequencies.
> >
> >
> >> On the flip side, It also allows driver to reject frequencies /
> >> configurations that are not supported by the corresponding chip.
> >
> > It's actually much easier to reject frequencies that are not valid with
> > the enumeration. "if (refclock > 5) { bail_out(); }". If I need to
> > check every frequency, I need to add an array of valid frequencies and
> > so on. Waste of code, IMHO.
> >
> >
> >> As I said, just my 2 cents. Personally, I'd like dts files to be as
> >> readable as c files without having to dig through bindings document.
> >
> > As I said before, for readability, adding a comment with the frequency
> > is good enough. This is what I did for PandaES's DTS (not sent out
> > yet):
> >
> > wlan {
> > compatible = "ti,wilink6";
> > interrupt-parent = <&gpio2>;
> > interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > refclock = <2>; /* 38.4 MHz */
> > };
> >
> > Looks more readable to me than:
> >
> > wlan {
> > compatible = "ti,wilink6";
> > interrupt-parent = <&gpio2>;
> > interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> > refclock = <38400>;
> > refclock_xtal = <0>;
> > };
> >
> > The macro idea sounds better to me, but in this case this code is so
> > simple that I don't think it's really worth it.
> >
> > And, from another point of view, I see this as only a specification of
> > the module's details. The frequency value is not really used anywhere
> > outside the module, so we don't see it. I don't think there's a good
> > reason to expose the actual frequency to the kernel (and parse it back
> > to the values the firmware needs), since nothing else inside the kernel
> > will care about it.
> Overview: we are adding bindings for
> Documentation/devicetree/bindings/net/wireless/ti-wilink.txt Which I
> believe is intended to be generic.
>
> Current frequencies supported for tcxoclock is the following for WiLink7
> + 0 = 19.200 MHz
> + 1 = 26.000 MHz
> + 2 = 38.400 MHz
> + 3 = 52.000 MHz
> + 4 = 16.368 MHz
> + 5 = 32.736 MHz
> + 6 = 16.800 MHz
> + 7 = 33.600 MHz
> Say wilink9 comes along and redefines this map OR introduces support for
> 20MHz support making the map 0-8, you'd no longer be able to support
> this map. or say a new update of firmware magically changes this mapping
> or something unexpected.
No problem with adding 20MHz support. Look at 6 = 16.800 MHz. That's
already out of order, so why would 20MHz have to change the mapping?
It is true that stupid changes happen in the firmware from time to time.
But if it happens, the translation could still be done in the driver.
> If the translation and validation is done in the driver, it is trivial
> to handle without redefining the binding and breaking older dtbs (if
> relevant)
The validation can still be done in the driver. I don't think anything
has to break here. The bindings document is the de-facto specifications
of this stuff. If something in the lower layers (ie. firmware) breaks,
the driver can do the translation without having to change anything in
the DTS.
> Indexes to another entity is always a maintenance burden in the longer
> run and needs judicious control. If it is possible to avoid it by
> selecting the right parameters, I am a hard advocate for the same.
I tend to agree. But you need a balance. In theory you're right. But
I think if you take the real world example, it is over-engineering.
Anyway, if you *really* think this needs to be changed, I think we're in
a deadlock here and I'd like to hear other people's opinions. I don't
mind making the change, but I'm still not convinced it is worth it,
since it just adds complexity.
And hey, this is too much bikeshedding for such a small detail.
--
Luca.
^ permalink raw reply
* Re: Fwd: Re: TP-Link 8200ND - rtl8192cu module not loading / working
From: Xose Vazquez Perez @ 2013-06-27 19:45 UTC (permalink / raw)
To: Larry Finger; +Cc: shiki.biomernok, linux-wireless
In-Reply-To: <51CC5541.8010003@lwfinger.net>
On 06/27/2013 05:07 PM, Larry Finger wrote:
> On 06/27/2013 08:34 AM, Xose Vazquez Perez wrote:
>> But it looks like rtl8192cu wasn't tested enough with 2T2R(RTL8192CUS)
>> devices.
> The code in wireless-testing works fine on my Edimax EW-7811Un, which reports as an RTL8192CUS.
But Edimax EW-7811Un is a 1T1R device.
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Nishanth Menon @ 2013-06-27 19:12 UTC (permalink / raw)
To: Luciano Coelho
Cc: grant.likely, rob.herring, devicetree-discuss, linux-doc, lkml,
linux-wireless, Tony Lindgren, linux-omap,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <1372359090.21065.12.camel@cumari.coelho.fi>
On 06/27/2013 01:51 PM, Luciano Coelho wrote:
> On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
>> On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho <coelho@ti.com> wrote:
>>> On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
>>>> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
>>>>> On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
>>>>>> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho <coelho@ti.com> wrote:
>>>>>>> For the actual DTS files, I could add a wilink.dtsi with enumerations
>>>>>>> for these values so they could be used in the node definitions. But I'm
>>>>>>> not sure it's going to be that valuable in the end.
>>>>>> The way GPIO HIGH was defined might help to provide guidance I think :)
>>>>>
>>>>> Where? As far as I can see, the GPIO flags are defined in a bitmap.
>>>>
>>>> include/dt-bindings/gpio/gpio.h
>>>
>>> Thanks! I don't see these macros used anywhere, though.
>> umm... I'd think you have'nt looked deep enough / lists :)
>
> If you mean mailing lists, you're right, I didn't. I just did a git
> grep for the macros and didn't find any users.
git grep "GPIO_ACTIVE_[HIGH|LOW]" arch/arm/boot/dts/|wc -l
344
on next-20130626. anyways, besides the point.
>>> This seems to be a completely different thing. This is the header that
>>> contains the helper functions to get GPIO-related device tree nodes,
>>> isn't it?
>> That is true, but it also contains the flag for level which needs to
>> be in sync with the gpio.h dts header.
>>>> just a hint. not saying frequencies were defined in header. for systems
>>>> that define frequencies - example cpufreq OPPs, clock node usage, we do
>>>> not use indexing to frequency, instead, that is the responsibility of
>>>> driver to convert frequency back to required index.
>>>> git grep frequency Documentation/devicetree/bindings gives you how the
>>>> precedence looks like.
>>>>
>>>> Personally, if given a choice, I'd go with actual frequencies rather
>>>> than indexes.
>>>
>>> If I do that, I need to add also a separate flag to define whether the
>>> XTAL clock is used or not. For instance, we have 26MHz and 26MHz
>>> crystal; and 38.4MHz and 38.4MHz crystal...
>> Yes, you would have to. at the same time, it is easy for module maker
>> to provide dtsi corresponding to exact h/w representation on his
>> module using wilink chip without being worried about weird index value
>> whose meaning is hidden in binding
>
> The module makers need to know about the bindings and read the document
> before they specify the node in DTS. I think for clarity, a comment in
> the DTS file stating the actual frequency is good enough. Simpler and
> more efficient (in terms of DT binary size and module code size) than
> adding the actual frequencies.
>
>
>> On the flip side, It also allows driver to reject frequencies /
>> configurations that are not supported by the corresponding chip.
>
> It's actually much easier to reject frequencies that are not valid with
> the enumeration. "if (refclock > 5) { bail_out(); }". If I need to
> check every frequency, I need to add an array of valid frequencies and
> so on. Waste of code, IMHO.
>
>
>> As I said, just my 2 cents. Personally, I'd like dts files to be as
>> readable as c files without having to dig through bindings document.
>
> As I said before, for readability, adding a comment with the frequency
> is good enough. This is what I did for PandaES's DTS (not sent out
> yet):
>
> wlan {
> compatible = "ti,wilink6";
> interrupt-parent = <&gpio2>;
> interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> refclock = <2>; /* 38.4 MHz */
> };
>
> Looks more readable to me than:
>
> wlan {
> compatible = "ti,wilink6";
> interrupt-parent = <&gpio2>;
> interrupts = <21 0x4>; /* gpio line 53, high level triggered */
> refclock = <38400>;
> refclock_xtal = <0>;
> };
>
> The macro idea sounds better to me, but in this case this code is so
> simple that I don't think it's really worth it.
>
> And, from another point of view, I see this as only a specification of
> the module's details. The frequency value is not really used anywhere
> outside the module, so we don't see it. I don't think there's a good
> reason to expose the actual frequency to the kernel (and parse it back
> to the values the firmware needs), since nothing else inside the kernel
> will care about it.
Overview: we are adding bindings for
Documentation/devicetree/bindings/net/wireless/ti-wilink.txt Which I
believe is intended to be generic.
Current frequencies supported for tcxoclock is the following for WiLink7
+ 0 = 19.200 MHz
+ 1 = 26.000 MHz
+ 2 = 38.400 MHz
+ 3 = 52.000 MHz
+ 4 = 16.368 MHz
+ 5 = 32.736 MHz
+ 6 = 16.800 MHz
+ 7 = 33.600 MHz
Say wilink9 comes along and redefines this map OR introduces support for
20MHz support making the map 0-8, you'd no longer be able to support
this map. or say a new update of firmware magically changes this mapping
or something unexpected.
If the translation and validation is done in the driver, it is trivial
to handle without redefining the binding and breaking older dtbs (if
relevant)
Indexes to another entity is always a maintenance burden in the longer
run and needs judicious control. If it is possible to avoid it by
selecting the right parameters, I am a hard advocate for the same.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] Documentation: dt: bindings: TI WiLink modules
From: Luciano Coelho @ 2013-06-27 18:51 UTC (permalink / raw)
To: Nishanth Menon
Cc: grant.likely, rob.herring, devicetree-discuss, linux-doc, lkml,
linux-wireless, Tony Lindgren, linux-omap,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAGo_u6pWZX9gbHgBae=gcWk8i6-TnhxH1TdM9QdEDLTow6Pn5A@mail.gmail.com>
On Thu, 2013-06-27 at 08:39 -0500, Nishanth Menon wrote:
> On Thu, Jun 27, 2013 at 8:30 AM, Luciano Coelho <coelho@ti.com> wrote:
> > On Thu, 2013-06-27 at 08:23 -0500, Nishanth Menon wrote:
> >> On 06/27/2013 08:19 AM, Luciano Coelho wrote:
> >> > On Thu, 2013-06-27 at 08:15 -0500, Nishanth Menon wrote:
> >> >> On Thu, Jun 27, 2013 at 7:58 AM, Luciano Coelho <coelho@ti.com> wrote:
> >> >>> For the actual DTS files, I could add a wilink.dtsi with enumerations
> >> >>> for these values so they could be used in the node definitions. But I'm
> >> >>> not sure it's going to be that valuable in the end.
> >> >> The way GPIO HIGH was defined might help to provide guidance I think :)
> >> >
> >> > Where? As far as I can see, the GPIO flags are defined in a bitmap.
> >>
> >> include/dt-bindings/gpio/gpio.h
> >
> > Thanks! I don't see these macros used anywhere, though.
> umm... I'd think you have'nt looked deep enough / lists :)
If you mean mailing lists, you're right, I didn't. I just did a git
grep for the macros and didn't find any users.
> >> And corresponding kernel header:
> >> include/linux/of_gpio.h
> >
> > This seems to be a completely different thing. This is the header that
> > contains the helper functions to get GPIO-related device tree nodes,
> > isn't it?
> That is true, but it also contains the flag for level which needs to
> be in sync with the gpio.h dts header.
> >> just a hint. not saying frequencies were defined in header. for systems
> >> that define frequencies - example cpufreq OPPs, clock node usage, we do
> >> not use indexing to frequency, instead, that is the responsibility of
> >> driver to convert frequency back to required index.
> >> git grep frequency Documentation/devicetree/bindings gives you how the
> >> precedence looks like.
> >>
> >> Personally, if given a choice, I'd go with actual frequencies rather
> >> than indexes.
> >
> > If I do that, I need to add also a separate flag to define whether the
> > XTAL clock is used or not. For instance, we have 26MHz and 26MHz
> > crystal; and 38.4MHz and 38.4MHz crystal...
> Yes, you would have to. at the same time, it is easy for module maker
> to provide dtsi corresponding to exact h/w representation on his
> module using wilink chip without being worried about weird index value
> whose meaning is hidden in binding
The module makers need to know about the bindings and read the document
before they specify the node in DTS. I think for clarity, a comment in
the DTS file stating the actual frequency is good enough. Simpler and
more efficient (in terms of DT binary size and module code size) than
adding the actual frequencies.
> On the flip side, It also allows driver to reject frequencies /
> configurations that are not supported by the corresponding chip.
It's actually much easier to reject frequencies that are not valid with
the enumeration. "if (refclock > 5) { bail_out(); }". If I need to
check every frequency, I need to add an array of valid frequencies and
so on. Waste of code, IMHO.
> As I said, just my 2 cents. Personally, I'd like dts files to be as
> readable as c files without having to dig through bindings document.
As I said before, for readability, adding a comment with the frequency
is good enough. This is what I did for PandaES's DTS (not sent out
yet):
wlan {
compatible = "ti,wilink6";
interrupt-parent = <&gpio2>;
interrupts = <21 0x4>; /* gpio line 53, high level triggered */
refclock = <2>; /* 38.4 MHz */
};
Looks more readable to me than:
wlan {
compatible = "ti,wilink6";
interrupt-parent = <&gpio2>;
interrupts = <21 0x4>; /* gpio line 53, high level triggered */
refclock = <38400>;
refclock_xtal = <0>;
};
The macro idea sounds better to me, but in this case this code is so
simple that I don't think it's really worth it.
And, from another point of view, I see this as only a specification of
the module's details. The frequency value is not really used anywhere
outside the module, so we don't see it. I don't think there's a good
reason to expose the actual frequency to the kernel (and parse it back
to the values the firmware needs), since nothing else inside the kernel
will care about it.
--
Luca.
^ permalink raw reply
* Re: rtl8192cu: slow path warning
From: Larry Finger @ 2013-06-27 18:20 UTC (permalink / raw)
To: Richard Genoud
Cc: Chaoming Li, John W. Linville, linux-wireless, linux-kernel,
Maxime Ripard
In-Reply-To: <CACQ1gAh+WjQZHo+_afZpzcwt1=KPM8VMBOe=YCHN_LEZu+jPNQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
On 06/27/2013 02:33 AM, Richard Genoud wrote:
> Yes, of course, you can add my
> Reported-by: Richard Genoud <richard.genoud@gmail.com>
>
> But the patch doesn't compile on my platform ( since I'm on ARM, I
> haven't got a PCI bus, so rtlwifi/pci.c is not compiled ) :
>
> ERROR: "rtl_lps_change_work_callback"
> [drivers/net/wireless/rtlwifi/rtlwifi.ko] undefined!
>
>
> Best regards,
> Richard.
>
> PS: duckducking the warning, I found this automated report also :
> https://retrace.fedoraproject.org/faf/reports/142038/
A revised patch for the warning is attached. The fix relatively simple and the
only difference between this one and the earlier version is that routine
rtl_lps_change_work_callback() was moved from pci.c to ps.c. As a result, it
will be available for ARM and other architectures without a PCI bus.
Larry
[-- Attachment #2: rtl8192cu_init_work --]
[-- Type: text/plain, Size: 2732 bytes --]
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/pci.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/pci.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/pci.c
@@ -1008,19 +1008,6 @@ static void _rtl_pci_prepare_bcn_tasklet
return;
}
-static void rtl_lps_change_work_callback(struct work_struct *work)
-{
- struct rtl_works *rtlworks =
- container_of(work, struct rtl_works, lps_change_work);
- struct ieee80211_hw *hw = rtlworks->hw;
- struct rtl_priv *rtlpriv = rtl_priv(hw);
-
- if (rtlpriv->enter_ps)
- rtl_lps_enter(hw);
- else
- rtl_lps_leave(hw);
-}
-
static void _rtl_pci_init_trx_var(struct ieee80211_hw *hw)
{
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/ps.h
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/ps.h
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/ps.h
@@ -49,5 +49,6 @@ void rtl_swlps_rf_awake(struct ieee80211
void rtl_swlps_rf_sleep(struct ieee80211_hw *hw);
void rtl_p2p_ps_cmd(struct ieee80211_hw *hw, u8 p2p_ps_state);
void rtl_p2p_info(struct ieee80211_hw *hw, void *data, unsigned int len);
+void rtl_lps_change_work_callback(struct work_struct *work);
#endif
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/usb.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/usb.c
@@ -1070,6 +1070,8 @@ int rtl_usb_probe(struct usb_interface *
spin_lock_init(&rtlpriv->locks.usb_lock);
INIT_WORK(&rtlpriv->works.fill_h2c_cmd,
rtl_fill_h2c_cmd_work_callback);
+ INIT_WORK(&rtlpriv->works.lps_change_work,
+ rtl_lps_change_work_callback);
rtlpriv->usb_data_index = 0;
init_completion(&rtlpriv->firmware_loading_complete);
Index: wireless-testing-save/drivers/net/wireless/rtlwifi/ps.c
===================================================================
--- wireless-testing-save.orig/drivers/net/wireless/rtlwifi/ps.c
+++ wireless-testing-save/drivers/net/wireless/rtlwifi/ps.c
@@ -611,6 +611,18 @@ void rtl_swlps_rf_sleep(struct ieee80211
MSECS(sleep_intv * mac->vif->bss_conf.beacon_int - 40));
}
+void rtl_lps_change_work_callback(struct work_struct *work)
+{
+ struct rtl_works *rtlworks =
+ container_of(work, struct rtl_works, lps_change_work);
+ struct ieee80211_hw *hw = rtlworks->hw;
+ struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+ if (rtlpriv->enter_ps)
+ rtl_lps_enter(hw);
+ else
+ rtl_lps_leave(hw);
+}
void rtl_swlps_wq_callback(void *data)
{
^ permalink raw reply
* [PATCH] ath10k: minimally handle new channel width enumeration values
From: John W. Linville @ 2013-06-27 17:52 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo, John W. Linville
From: "John W. Linville" <linville@tuxdriver.com>
CC drivers/net/wireless/ath/ath10k/mac.o
drivers/net/wireless/ath/ath10k/mac.c: In function ‘chan_to_phymode’:
drivers/net/wireless/ath/ath10k/mac.c:229:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_5’ not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:229:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_10’ not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:247:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_5’ not handled in switch [-Wswitch]
drivers/net/wireless/ath/ath10k/mac.c:247:3: warning: enumeration value ‘NL80211_CHAN_WIDTH_10’ not handled in switch [-Wswitch]
Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 95e306e..da5c333 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -236,6 +236,8 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
case NL80211_CHAN_WIDTH_40:
phymode = MODE_11NG_HT40;
break;
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
case NL80211_CHAN_WIDTH_80:
case NL80211_CHAN_WIDTH_80P80:
case NL80211_CHAN_WIDTH_160:
@@ -257,6 +259,8 @@ chan_to_phymode(const struct cfg80211_chan_def *chandef)
case NL80211_CHAN_WIDTH_80:
phymode = MODE_11AC_VHT80;
break;
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
case NL80211_CHAN_WIDTH_80P80:
case NL80211_CHAN_WIDTH_160:
phymode = MODE_UNKNOWN;
--
1.8.1.4
^ permalink raw reply related
* [PATCHv5 17/18] ath5k: set 5/10 MHz supported channels and fix duration
From: Simon Wunderlich @ 2013-06-27 16:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath5k/base.c | 24 ++++++++++++++++--------
drivers/net/wireless/ath/ath5k/pcu.c | 2 ++
drivers/net/wireless/ath/ath5k/qcu.c | 25 ++++++++++++++++++++++++-
3 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 260a6fc..7c298af 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -165,28 +165,36 @@ static const struct ieee80211_rate ath5k_rates[] = {
.flags = IEEE80211_RATE_SHORT_PREAMBLE },
{ .bitrate = 60,
.hw_value = ATH5K_RATE_CODE_6M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
{ .bitrate = 90,
.hw_value = ATH5K_RATE_CODE_9M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
{ .bitrate = 120,
.hw_value = ATH5K_RATE_CODE_12M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
{ .bitrate = 180,
.hw_value = ATH5K_RATE_CODE_18M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
{ .bitrate = 240,
.hw_value = ATH5K_RATE_CODE_24M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
{ .bitrate = 360,
.hw_value = ATH5K_RATE_CODE_36M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
{ .bitrate = 480,
.hw_value = ATH5K_RATE_CODE_48M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
{ .bitrate = 540,
.hw_value = ATH5K_RATE_CODE_54M,
- .flags = 0 },
+ .flags = IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ },
};
static inline u64 ath5k_extend_tsf(struct ath5k_hw *ah, u32 rstamp)
diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c
index 1f16b42..c60d36a 100644
--- a/drivers/net/wireless/ath/ath5k/pcu.c
+++ b/drivers/net/wireless/ath/ath5k/pcu.c
@@ -144,11 +144,13 @@ ath5k_hw_get_frame_duration(struct ath5k_hw *ah, enum ieee80211_band band,
sifs = AR5K_INIT_SIFS_HALF_RATE;
preamble *= 2;
sym_time *= 2;
+ bitrate = DIV_ROUND_UP(bitrate, 2);
break;
case AR5K_BWMODE_5MHZ:
sifs = AR5K_INIT_SIFS_QUARTER_RATE;
preamble *= 4;
sym_time *= 4;
+ bitrate = DIV_ROUND_UP(bitrate, 4);
break;
default:
sifs = AR5K_INIT_SIFS_DEFAULT_BG;
diff --git a/drivers/net/wireless/ath/ath5k/qcu.c b/drivers/net/wireless/ath/ath5k/qcu.c
index 65fe929..0583c69 100644
--- a/drivers/net/wireless/ath/ath5k/qcu.c
+++ b/drivers/net/wireless/ath/ath5k/qcu.c
@@ -566,9 +566,11 @@ int ath5k_hw_set_ifs_intervals(struct ath5k_hw *ah, unsigned int slot_time)
{
struct ieee80211_channel *channel = ah->ah_current_channel;
enum ieee80211_band band;
+ struct ieee80211_supported_band *sband;
struct ieee80211_rate *rate;
u32 ack_tx_time, eifs, eifs_clock, sifs, sifs_clock;
u32 slot_time_clock = ath5k_hw_htoclock(ah, slot_time);
+ u32 rate_flags, i;
if (slot_time < 6 || slot_time_clock > AR5K_SLOT_TIME_MAX)
return -EINVAL;
@@ -605,7 +607,28 @@ int ath5k_hw_set_ifs_intervals(struct ath5k_hw *ah, unsigned int slot_time)
else
band = IEEE80211_BAND_2GHZ;
- rate = &ah->sbands[band].bitrates[0];
+ switch (ah->ah_bwmode) {
+ case AR5K_BWMODE_5MHZ:
+ rate_flags = IEEE80211_RATE_SUPPORTS_5MHZ;
+ break;
+ case AR5K_BWMODE_10MHZ:
+ rate_flags = IEEE80211_RATE_SUPPORTS_10MHZ;
+ break;
+ default:
+ rate_flags = 0;
+ break;
+ }
+ sband = &ah->sbands[band];
+ rate = NULL;
+ for (i = 0; i < sband->n_bitrates; i++) {
+ if ((rate_flags & sband->bitrates[i].flags) != rate_flags)
+ continue;
+ rate = &sband->bitrates[i];
+ break;
+ }
+ if (WARN_ON(!rate))
+ return -EINVAL;
+
ack_tx_time = ath5k_hw_get_frame_duration(ah, band, 10, rate, false);
/* ack_tx_time includes an SIFS already */
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 18/18] ath5k: enable support for 5 MHz and 10 MHz channels
From: Simon Wunderlich @ 2013-06-27 16:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath5k/ath5k.h | 1 +
drivers/net/wireless/ath/ath5k/base.c | 25 ++++++++++++++++++++++---
drivers/net/wireless/ath/ath5k/base.h | 2 +-
drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
4 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/ath5k.h b/drivers/net/wireless/ath/ath5k/ath5k.h
index 2d691b8..74bd54d 100644
--- a/drivers/net/wireless/ath/ath5k/ath5k.h
+++ b/drivers/net/wireless/ath/ath5k/ath5k.h
@@ -29,6 +29,7 @@
#include <linux/average.h>
#include <linux/leds.h>
#include <net/mac80211.h>
+#include <net/cfg80211.h>
/* RX/TX descriptor hw structs
* TODO: Driver part should only see sw structs */
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 7c298af..48161ed 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -56,6 +56,7 @@
#include <linux/etherdevice.h>
#include <linux/nl80211.h>
+#include <net/cfg80211.h>
#include <net/ieee80211_radiotap.h>
#include <asm/unaligned.h>
@@ -443,11 +444,27 @@ ath5k_setup_bands(struct ieee80211_hw *hw)
* Called with ah->lock.
*/
int
-ath5k_chan_set(struct ath5k_hw *ah, struct ieee80211_channel *chan)
+ath5k_chan_set(struct ath5k_hw *ah, struct cfg80211_chan_def *chandef)
{
ATH5K_DBG(ah, ATH5K_DEBUG_RESET,
"channel set, resetting (%u -> %u MHz)\n",
- ah->curchan->center_freq, chan->center_freq);
+ ah->curchan->center_freq, chandef->chan->center_freq);
+
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ ah->ah_bwmode = AR5K_BWMODE_DEFAULT;
+ break;
+ case NL80211_CHAN_WIDTH_5:
+ ah->ah_bwmode = AR5K_BWMODE_5MHZ;
+ break;
+ case NL80211_CHAN_WIDTH_10:
+ ah->ah_bwmode = AR5K_BWMODE_10MHZ;
+ break;
+ default:
+ WARN_ON(1);
+ return -EINVAL;
+ }
/*
* To switch channels clear any pending DMA operations;
@@ -455,7 +472,7 @@ ath5k_chan_set(struct ath5k_hw *ah, struct ieee80211_channel *chan)
* hardware at the new frequency, and then re-enable
* the relevant bits of the h/w.
*/
- return ath5k_reset(ah, chan, true);
+ return ath5k_reset(ah, chandef->chan, true);
}
void ath5k_vif_iter(void *data, u8 *mac, struct ieee80211_vif *vif)
@@ -2525,6 +2542,8 @@ ath5k_init_ah(struct ath5k_hw *ah, const struct ath_bus_ops *bus_ops)
/* SW support for IBSS_RSN is provided by mac80211 */
hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
+ hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_5_10_MHZ;
+
/* both antennas can be configured as RX or TX */
hw->wiphy->available_antennas_tx = 0x3;
hw->wiphy->available_antennas_rx = 0x3;
diff --git a/drivers/net/wireless/ath/ath5k/base.h b/drivers/net/wireless/ath/ath5k/base.h
index ca9a83c..97469d0 100644
--- a/drivers/net/wireless/ath/ath5k/base.h
+++ b/drivers/net/wireless/ath/ath5k/base.h
@@ -101,7 +101,7 @@ void ath5k_set_beacon_filter(struct ieee80211_hw *hw, bool enable);
void ath5k_update_bssid_mask_and_opmode(struct ath5k_hw *ah,
struct ieee80211_vif *vif);
-int ath5k_chan_set(struct ath5k_hw *ah, struct ieee80211_channel *chan);
+int ath5k_chan_set(struct ath5k_hw *ah, struct cfg80211_chan_def *chandef);
void ath5k_txbuf_free_skb(struct ath5k_hw *ah, struct ath5k_buf *bf);
void ath5k_rxbuf_free_skb(struct ath5k_hw *ah, struct ath5k_buf *bf);
void ath5k_tx_queue(struct ieee80211_hw *hw, struct sk_buff *skb,
diff --git a/drivers/net/wireless/ath/ath5k/mac80211-ops.c b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
index 81b686c..aa9d976 100644
--- a/drivers/net/wireless/ath/ath5k/mac80211-ops.c
+++ b/drivers/net/wireless/ath/ath5k/mac80211-ops.c
@@ -202,7 +202,7 @@ ath5k_config(struct ieee80211_hw *hw, u32 changed)
mutex_lock(&ah->lock);
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
- ret = ath5k_chan_set(ah, conf->chandef.chan);
+ ret = ath5k_chan_set(ah, &conf->chandef);
if (ret < 0)
goto unlock;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 14/18] ath9k: set 5/10 MHz supported channels and fix bitrate
From: Simon Wunderlich @ 2013-06-27 16:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
Changes to PATCHv4:
* remove unused divisor line in the rate control
---
drivers/net/wireless/ath/ath9k/init.c | 24 ++++++++++++++++--------
drivers/net/wireless/ath/ath9k/rc.c | 5 +++++
2 files changed, 21 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index d0d3d2a..96b0d29 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -146,14 +146,22 @@ static struct ieee80211_rate ath9k_legacy_rates[] = {
RATE(20, 0x1a, IEEE80211_RATE_SHORT_PREAMBLE),
RATE(55, 0x19, IEEE80211_RATE_SHORT_PREAMBLE),
RATE(110, 0x18, IEEE80211_RATE_SHORT_PREAMBLE),
- RATE(60, 0x0b, 0),
- RATE(90, 0x0f, 0),
- RATE(120, 0x0a, 0),
- RATE(180, 0x0e, 0),
- RATE(240, 0x09, 0),
- RATE(360, 0x0d, 0),
- RATE(480, 0x08, 0),
- RATE(540, 0x0c, 0),
+ RATE(60, 0x0b, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
+ RATE(90, 0x0f, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
+ RATE(120, 0x0a, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
+ RATE(180, 0x0e, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
+ RATE(240, 0x09, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
+ RATE(360, 0x0d, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
+ RATE(480, 0x08, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
+ RATE(540, 0x0c, (IEEE80211_RATE_SUPPORTS_5MHZ |
+ IEEE80211_RATE_SUPPORTS_10MHZ)),
};
#ifdef CONFIG_MAC80211_LEDS
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index e41f563..5a69d9b 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -1282,9 +1282,14 @@ static void ath_rate_init(void *priv, struct ieee80211_supported_band *sband,
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ath_rate_priv *ath_rc_priv = priv_sta;
int i, j = 0;
+ u32 rate_flags = ieee80211_chandef_rate_flags(&sc->hw->conf.chandef);
for (i = 0; i < sband->n_bitrates; i++) {
if (sta->supp_rates[sband->band] & BIT(i)) {
+ if ((rate_flags & sband->bitrates[i].flags)
+ != rate_flags)
+ continue;
+
ath_rc_priv->neg_rates.rs_rates[j]
= (sband->bitrates[i].bitrate * 2) / 10;
j++;
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 10/18] nl80211: allow 5 and 10 MHz channels for IBSS
From: Simon Wunderlich @ 2013-06-27 16:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Whether the wiphy supports it or not is already checked, so what is left
is to enable these channel types.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
net/wireless/nl80211.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ebd889d..10755dc 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6300,6 +6300,8 @@ static int nl80211_join_ibss(struct sk_buff *skb, struct genl_info *info)
return -EINVAL;
switch (ibss.chandef.width) {
+ case NL80211_CHAN_WIDTH_5:
+ case NL80211_CHAN_WIDTH_10:
case NL80211_CHAN_WIDTH_20_NOHT:
break;
case NL80211_CHAN_WIDTH_20:
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 12/18] ath9k: use chandef instead of channel_type
From: Simon Wunderlich @ 2013-06-27 16:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
To enable support for 5/10 MHz, some internal functions must be
converted from using the (old) channel_type to chandef. This is a good
chance to change all remaining occurences.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath9k/common.c | 67 +++++++++++++++----------
drivers/net/wireless/ath/ath9k/common.h | 3 +-
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
drivers/net/wireless/ath/ath9k/init.c | 4 +-
drivers/net/wireless/ath/ath9k/main.c | 8 ++-
drivers/net/wireless/ath/ath9k/rc.c | 4 +-
6 files changed, 51 insertions(+), 40 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
index 344fdde..d3063c2 100644
--- a/drivers/net/wireless/ath/ath9k/common.c
+++ b/drivers/net/wireless/ath/ath9k/common.c
@@ -49,37 +49,40 @@ int ath9k_cmn_get_hw_crypto_keytype(struct sk_buff *skb)
}
EXPORT_SYMBOL(ath9k_cmn_get_hw_crypto_keytype);
-static u32 ath9k_get_extchanmode(struct ieee80211_channel *chan,
- enum nl80211_channel_type channel_type)
+static u32 ath9k_get_extchanmode(struct cfg80211_chan_def *chandef)
{
u32 chanmode = 0;
- switch (chan->band) {
+ switch (chandef->chan->band) {
case IEEE80211_BAND_2GHZ:
- switch (channel_type) {
- case NL80211_CHAN_NO_HT:
- case NL80211_CHAN_HT20:
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
chanmode = CHANNEL_G_HT20;
break;
- case NL80211_CHAN_HT40PLUS:
- chanmode = CHANNEL_G_HT40PLUS;
+ case NL80211_CHAN_WIDTH_40:
+ if (chandef->center_freq1 > chandef->chan->center_freq)
+ chanmode = CHANNEL_G_HT40PLUS;
+ else
+ chanmode = CHANNEL_G_HT40MINUS;
break;
- case NL80211_CHAN_HT40MINUS:
- chanmode = CHANNEL_G_HT40MINUS;
+ default:
break;
}
break;
case IEEE80211_BAND_5GHZ:
- switch (channel_type) {
- case NL80211_CHAN_NO_HT:
- case NL80211_CHAN_HT20:
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ case NL80211_CHAN_WIDTH_20:
chanmode = CHANNEL_A_HT20;
break;
- case NL80211_CHAN_HT40PLUS:
- chanmode = CHANNEL_A_HT40PLUS;
+ case NL80211_CHAN_WIDTH_40:
+ if (chandef->center_freq1 > chandef->chan->center_freq)
+ chanmode = CHANNEL_A_HT40PLUS;
+ else
+ chanmode = CHANNEL_A_HT40MINUS;
break;
- case NL80211_CHAN_HT40MINUS:
- chanmode = CHANNEL_A_HT40MINUS;
+ default:
break;
}
break;
@@ -94,13 +97,12 @@ static u32 ath9k_get_extchanmode(struct ieee80211_channel *chan,
* Update internal channel flags.
*/
void ath9k_cmn_update_ichannel(struct ath9k_channel *ichan,
- struct ieee80211_channel *chan,
- enum nl80211_channel_type channel_type)
+ struct cfg80211_chan_def *chandef)
{
- ichan->channel = chan->center_freq;
- ichan->chan = chan;
+ ichan->channel = chandef->chan->center_freq;
+ ichan->chan = chandef->chan;
- if (chan->band == IEEE80211_BAND_2GHZ) {
+ if (chandef->chan->band == IEEE80211_BAND_2GHZ) {
ichan->chanmode = CHANNEL_G;
ichan->channelFlags = CHANNEL_2GHZ | CHANNEL_OFDM;
} else {
@@ -108,8 +110,22 @@ void ath9k_cmn_update_ichannel(struct ath9k_channel *ichan,
ichan->channelFlags = CHANNEL_5GHZ | CHANNEL_OFDM;
}
- if (channel_type != NL80211_CHAN_NO_HT)
- ichan->chanmode = ath9k_get_extchanmode(chan, channel_type);
+ switch (chandef->width) {
+ case NL80211_CHAN_WIDTH_5:
+ ichan->channelFlags |= CHANNEL_QUARTER;
+ break;
+ case NL80211_CHAN_WIDTH_10:
+ ichan->channelFlags |= CHANNEL_HALF;
+ break;
+ case NL80211_CHAN_WIDTH_20_NOHT:
+ break;
+ case NL80211_CHAN_WIDTH_20:
+ case NL80211_CHAN_WIDTH_40:
+ ichan->chanmode = ath9k_get_extchanmode(chandef);
+ break;
+ default:
+ WARN_ON(1);
+ }
}
EXPORT_SYMBOL(ath9k_cmn_update_ichannel);
@@ -125,8 +141,7 @@ struct ath9k_channel *ath9k_cmn_get_curchannel(struct ieee80211_hw *hw,
chan_idx = curchan->hw_value;
channel = &ah->channels[chan_idx];
- ath9k_cmn_update_ichannel(channel, curchan,
- cfg80211_get_chandef_type(&hw->conf.chandef));
+ ath9k_cmn_update_ichannel(channel, &hw->conf.chandef);
return channel;
}
diff --git a/drivers/net/wireless/ath/ath9k/common.h b/drivers/net/wireless/ath/ath9k/common.h
index 207d069..e039bcb 100644
--- a/drivers/net/wireless/ath/ath9k/common.h
+++ b/drivers/net/wireless/ath/ath9k/common.h
@@ -44,8 +44,7 @@
int ath9k_cmn_get_hw_crypto_keytype(struct sk_buff *skb);
void ath9k_cmn_update_ichannel(struct ath9k_channel *ichan,
- struct ieee80211_channel *chan,
- enum nl80211_channel_type channel_type);
+ struct cfg80211_chan_def *chandef);
struct ath9k_channel *ath9k_cmn_get_curchannel(struct ieee80211_hw *hw,
struct ath_hw *ah);
int ath9k_cmn_count_streams(unsigned int chainmask, int max);
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index fba6ea7..87b3429 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1203,16 +1203,13 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
if ((changed & IEEE80211_CONF_CHANGE_CHANNEL) || chip_reset) {
struct ieee80211_channel *curchan = hw->conf.chandef.chan;
- enum nl80211_channel_type channel_type =
- cfg80211_get_chandef_type(&hw->conf.chandef);
int pos = curchan->hw_value;
ath_dbg(common, CONFIG, "Set channel: %d MHz\n",
curchan->center_freq);
ath9k_cmn_update_ichannel(&priv->ah->channels[pos],
- hw->conf.chandef.chan,
- channel_type);
+ &hw->conf.chandef);
if (ath9k_htc_set_channel(priv, hw, &priv->ah->channels[pos]) < 0) {
ath_err(common, "Unable to set channel\n");
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 1e555d8..d0d3d2a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -710,13 +710,15 @@ static void ath9k_init_band_txpower(struct ath_softc *sc, int band)
struct ieee80211_supported_band *sband;
struct ieee80211_channel *chan;
struct ath_hw *ah = sc->sc_ah;
+ struct cfg80211_chan_def chandef;
int i;
sband = &sc->sbands[band];
for (i = 0; i < sband->n_channels; i++) {
chan = &sband->channels[i];
ah->curchan = &ah->channels[chan->hw_value];
- ath9k_cmn_update_ichannel(ah->curchan, chan, NL80211_CHAN_HT20);
+ cfg80211_chandef_create(&chandef, chan, NL80211_CHAN_HT20);
+ ath9k_cmn_update_ichannel(ah->curchan, &chandef);
ath9k_hw_set_txpowerlimit(ah, MAX_RATE_POWER, true);
}
}
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 1737a3e..ff91f4a 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1193,8 +1193,6 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
if ((changed & IEEE80211_CONF_CHANGE_CHANNEL) || reset_channel) {
struct ieee80211_channel *curchan = hw->conf.chandef.chan;
- enum nl80211_channel_type channel_type =
- cfg80211_get_chandef_type(&conf->chandef);
int pos = curchan->hw_value;
int old_pos = -1;
unsigned long flags;
@@ -1202,8 +1200,8 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
if (ah->curchan)
old_pos = ah->curchan - &ah->channels[0];
- ath_dbg(common, CONFIG, "Set channel: %d MHz type: %d\n",
- curchan->center_freq, channel_type);
+ ath_dbg(common, CONFIG, "Set channel: %d MHz width: %d\n",
+ curchan->center_freq, hw->conf.chandef.width);
/* update survey stats for the old channel before switching */
spin_lock_irqsave(&common->cc_lock, flags);
@@ -1211,7 +1209,7 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
spin_unlock_irqrestore(&common->cc_lock, flags);
ath9k_cmn_update_ichannel(&sc->sc_ah->channels[pos],
- curchan, channel_type);
+ &conf->chandef);
/*
* If the operating channel changes, change the survey in-use flags
diff --git a/drivers/net/wireless/ath/ath9k/rc.c b/drivers/net/wireless/ath/ath9k/rc.c
index a3c4ca0..e41f563 100644
--- a/drivers/net/wireless/ath/ath9k/rc.c
+++ b/drivers/net/wireless/ath/ath9k/rc.c
@@ -1326,8 +1326,8 @@ static void ath_rate_update(void *priv, struct ieee80211_supported_band *sband,
ath_rc_init(sc, priv_sta);
ath_dbg(ath9k_hw_common(sc->sc_ah), CONFIG,
- "Operating HT Bandwidth changed to: %d\n",
- cfg80211_get_chandef_type(&sc->hw->conf.chandef));
+ "Operating Bandwidth changed to: %d\n",
+ &sc->hw->conf.chandef->width);
}
}
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 16/18] ath5k: report 5/10 MHz channels
From: Simon Wunderlich @ 2013-06-27 16:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath5k/base.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index ce67ab7..260a6fc 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1400,6 +1400,16 @@ ath5k_receive_frame(struct ath5k_hw *ah, struct sk_buff *skb,
rxs->rate_idx = ath5k_hw_to_driver_rix(ah, rs->rs_rate);
rxs->flag |= ath5k_rx_decrypted(ah, skb, rs);
+ switch (ah->ah_bwmode) {
+ case AR5K_BWMODE_5MHZ:
+ rxs->flag |= RX_FLAG_5MHZ;
+ break;
+ case AR5K_BWMODE_10MHZ:
+ rxs->flag |= RX_FLAG_10MHZ;
+ break;
+ default:
+ break;
+ }
if (rxs->rate_idx >= 0 && rs->rs_rate ==
ah->sbands[ah->curchan->band].bitrates[rxs->rate_idx].hw_value_short)
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 15/18] ath9k: announce that ath9k supports 5/10 MHz
From: Simon Wunderlich @ 2013-06-27 16:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
drivers/net/wireless/ath/ath9k/init.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index 96b0d29..f6ae49f 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -844,6 +844,7 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_TDLS;
hw->wiphy->flags |= WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
+ hw->wiphy->flags |= WIPHY_FLAG_SUPPORTS_5_10_MHZ;
#ifdef CONFIG_PM_SLEEP
if ((ah->caps.hw_caps & ATH9K_HW_WOW_DEVICE_CAPABLE) &&
--
1.7.10.4
^ permalink raw reply related
* [PATCHv5 05/18] cfg80211/mac80211: get mandatory rates based on rate flags
From: Simon Wunderlich @ 2013-06-27 16:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Mathias Kretschmer, Simon Wunderlich
In-Reply-To: <1372352340-20663-1-git-send-email-siwu@hrz.tu-chemnitz.de>
Mandatory rates for 5 and 10 MHz are different from the rates used for
20 MHz in 2.4 GHz mode, as they use OFDM only.
Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
---
Changes to PATCHv4:
* it is now based on scan_width instead of rate flags
---
include/net/cfg80211.h | 4 +++-
net/mac80211/ibss.c | 19 +++++++++++++++----
net/wireless/mesh.c | 5 ++++-
net/wireless/util.c | 14 ++++++++++----
4 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 820cce5..83d52dc 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3069,11 +3069,13 @@ ieee80211_get_response_rate(struct ieee80211_supported_band *sband,
/**
* ieee80211_mandatory_rates - get mandatory rates for a given band
* @sband: the band to look for rates in
+ * @scan_width: width of the control channel
*
* This function returns a bitmap of the mandatory rates for the given
* band, bits are set according to the rate position in the bitrates array.
*/
-u32 ieee80211_mandatory_rates(struct ieee80211_supported_band *sband);
+u32 ieee80211_mandatory_rates(struct ieee80211_supported_band *sband,
+ enum nl80211_bss_scan_width scan_width);
/*
* Radiotap parsing functions -- for controlled injection support
diff --git a/net/mac80211/ibss.c b/net/mac80211/ibss.c
index fa91df8..d0c27dc 100644
--- a/net/mac80211/ibss.c
+++ b/net/mac80211/ibss.c
@@ -376,6 +376,7 @@ ieee80211_ibss_add_sta(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta;
struct ieee80211_chanctx_conf *chanctx_conf;
struct ieee80211_supported_band *sband;
+ enum nl80211_bss_scan_width scan_width;
int band;
/*
@@ -404,6 +405,7 @@ ieee80211_ibss_add_sta(struct ieee80211_sub_if_data *sdata,
if (WARN_ON_ONCE(!chanctx_conf))
return NULL;
band = chanctx_conf->def.chan->band;
+ scan_width = cfg80211_chandef_to_scan_width(&chanctx_conf->def);
rcu_read_unlock();
sta = sta_info_alloc(sdata, addr, GFP_KERNEL);
@@ -417,7 +419,7 @@ ieee80211_ibss_add_sta(struct ieee80211_sub_if_data *sdata,
/* make sure mandatory rates are always added */
sband = local->hw.wiphy->bands[band];
sta->sta.supp_rates[band] = supp_rates |
- ieee80211_mandatory_rates(sband);
+ ieee80211_mandatory_rates(sband, scan_width);
return ieee80211_ibss_finish_sta(sta, auth);
}
@@ -499,6 +501,7 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
u64 beacon_timestamp, rx_timestamp;
u32 supp_rates = 0;
enum ieee80211_band band = rx_status->band;
+ enum nl80211_bss_scan_width scan_width;
struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band];
bool rates_updated = false;
@@ -527,9 +530,15 @@ static void ieee80211_rx_bss_info(struct ieee80211_sub_if_data *sdata,
prev_rates = sta->sta.supp_rates[band];
/* make sure mandatory rates are always added */
+ scan_width = NL80211_BSS_CHAN_WIDTH_20;
+ if (rx_status->flag & RX_FLAG_5MHZ)
+ scan_width = NL80211_BSS_CHAN_WIDTH_5;
+ if (rx_status->flag & RX_FLAG_10MHZ)
+ scan_width = NL80211_BSS_CHAN_WIDTH_10;
+
sta->sta.supp_rates[band] = supp_rates |
- ieee80211_mandatory_rates(sband);
-
+ ieee80211_mandatory_rates(sband,
+ scan_width);
if (sta->sta.supp_rates[band] != prev_rates) {
ibss_dbg(sdata,
"updated supp_rates set for %pM based on beacon/probe_resp (0x%x -> 0x%x)\n",
@@ -663,6 +672,7 @@ void ieee80211_ibss_rx_no_sta(struct ieee80211_sub_if_data *sdata,
struct sta_info *sta;
struct ieee80211_chanctx_conf *chanctx_conf;
struct ieee80211_supported_band *sband;
+ enum nl80211_bss_scan_width scan_width;
int band;
/*
@@ -688,6 +698,7 @@ void ieee80211_ibss_rx_no_sta(struct ieee80211_sub_if_data *sdata,
return;
}
band = chanctx_conf->def.chan->band;
+ scan_width = cfg80211_chandef_to_scan_width(&chanctx_conf->def);
rcu_read_unlock();
sta = sta_info_alloc(sdata, addr, GFP_ATOMIC);
@@ -699,7 +710,7 @@ void ieee80211_ibss_rx_no_sta(struct ieee80211_sub_if_data *sdata,
/* make sure mandatory rates are always added */
sband = local->hw.wiphy->bands[band];
sta->sta.supp_rates[band] = supp_rates |
- ieee80211_mandatory_rates(sband);
+ ieee80211_mandatory_rates(sband, scan_width);
spin_lock(&ifibss->incomplete_lock);
list_add(&sta->list, &ifibss->incomplete_stations);
diff --git a/net/wireless/mesh.c b/net/wireless/mesh.c
index 30c4920..0553fd4 100644
--- a/net/wireless/mesh.c
+++ b/net/wireless/mesh.c
@@ -167,9 +167,12 @@ int __cfg80211_join_mesh(struct cfg80211_registered_device *rdev,
* basic rates
*/
if (!setup->basic_rates) {
+ enum nl80211_bss_scan_width scan_width;
struct ieee80211_supported_band *sband =
rdev->wiphy.bands[setup->chandef.chan->band];
- setup->basic_rates = ieee80211_mandatory_rates(sband);
+ scan_width = cfg80211_chandef_to_scan_width(&setup->chandef);
+ setup->basic_rates = ieee80211_mandatory_rates(sband,
+ scan_width);
}
if (!cfg80211_reg_can_beacon(&rdev->wiphy, &setup->chandef))
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 74458b7..ce090c1 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -33,7 +33,8 @@ ieee80211_get_response_rate(struct ieee80211_supported_band *sband,
}
EXPORT_SYMBOL(ieee80211_get_response_rate);
-u32 ieee80211_mandatory_rates(struct ieee80211_supported_band *sband)
+u32 ieee80211_mandatory_rates(struct ieee80211_supported_band *sband,
+ enum nl80211_bss_scan_width scan_width)
{
struct ieee80211_rate *bitrates;
u32 mandatory_rates = 0;
@@ -43,10 +44,15 @@ u32 ieee80211_mandatory_rates(struct ieee80211_supported_band *sband)
if (WARN_ON(!sband))
return 1;
- if (sband->band == IEEE80211_BAND_2GHZ)
- mandatory_flag = IEEE80211_RATE_MANDATORY_B;
- else
+ if (sband->band == IEEE80211_BAND_2GHZ) {
+ if (scan_width == NL80211_BSS_CHAN_WIDTH_5 ||
+ scan_width == NL80211_BSS_CHAN_WIDTH_10)
+ mandatory_flag = IEEE80211_RATE_MANDATORY_G;
+ else
+ mandatory_flag = IEEE80211_RATE_MANDATORY_B;
+ } else {
mandatory_flag = IEEE80211_RATE_MANDATORY_A;
+ }
bitrates = sband->bitrates;
for (i = 0; i < sband->n_bitrates; i++)
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox