* Re: [PATCH] mac80211: add per-chain signal information to radiotap
From: Johannes Berg @ 2013-07-08 8:56 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1372851242-25474-1-git-send-email-johannes@sipsolutions.net>
On Wed, 2013-07-03 at 13:34 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> When per-chain signal information is available, don't add
> the antenna field once but instead add a radiotap namespace
> for each chain containing the chain/antenna number and the
> signal strength on that chain.
Applied.
johannes
^ permalink raw reply
* Re: [PATCH V2] vlan priority handling in WMM
From: Johannes Berg @ 2013-07-08 8:51 UTC (permalink / raw)
To: voncken; +Cc: linux-wireless
In-Reply-To: <002b01ce798d$865cee70$9316cb50$@acksys.fr>
On Fri, 2013-07-05 at 16:39 +0200, voncken wrote:
> > >+ vlan_priority = (skb->vlan_tci & VLAN_PRIO_MASK) >>
> VLAN_PRIO_SHIFT;
> > >+ if (vlan_priority > 0)
> >> + return vlan_priority;
>
> > Is this really correct? For once, checking vlan_priority for
> non-zero seems
> > weird since that ought to be a valid value -- is there no other way
> to
> > determine that the value is valid?
> The vlan Tag contain three bit for priority. The value 0 indicate no
> priority (on this case the VLAN tag contain only VID). The vlan_tci
> field is set to zero if the frame do not contain the vlan tag. So if
> we have not a vlan tag or no priority in VLAN tag the priority value
> is always 0.
Yes but don't we know that the vlan_tci field is valid?
I don't think you're correct in that 0 means "no priority present", it
actually means "best effort" as far as I can tell. Ignoring the VLAN tag
when the field is 0 would mean we could use a higher priority from the
contents of the frame, which would not be desired?
> >Also, this gives you a 2-bit value, while the return value should be
> a 3-bit value, maybe you need to shift this up by one to spread into
> the correct buckets?
> Sorry but I don't understand. The vlan_tci field it is a __u16 value
> (defined in include/linux/skbuff.h), the VLAN_PRIO_MASK is set to
> 0xE000 and VLAN_PRIO_SHIFT is set to 13 (defined in
> include/linux/if_vlan.h), the vlan_priority is an unsigned char. For
> me the vlan_priority contain a 3-bit value (0xE000 >>13 = 0x0003), why
> 2 ?
Umm? No? Think again about what hweight(0x0003) is.
johannes
^ permalink raw reply
* [PATCH] mac80211: fix ethtool stats for non-station interfaces
From: Johannes Berg @ 2013-07-08 8:46 UTC (permalink / raw)
To: linux-wireless; +Cc: greearb
As reported in https://bugzilla.kernel.org/show_bug.cgi?id=60514,
the station loop never initialises 'sinfo' and therefore adds up
a stack values, leaking stack information (the number of times it
adds values is easily obtained another way.)
Fix this by initialising the sinfo for each station to add.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/cfg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 8184d12..43dd752 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -666,6 +666,8 @@ static void ieee80211_get_et_stats(struct wiphy *wiphy,
if (sta->sdata->dev != dev)
continue;
+ sinfo.filled = 0;
+ sta_set_sinfo(sta, &sinfo);
i = 0;
ADD_STA_STATS(sta);
}
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] rtlwifi: Fix Kconfig for some corner cases
From: Larry Finger @ 2013-07-07 18:13 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linville, linux-wireless, netdev, Fengguang Wu
In-Reply-To: <1373190151.3428.13.camel@deadeye.wl.decadent.org.uk>
On 07/07/2013 04:42 AM, Ben Hutchings wrote:
> On Sat, 2013-07-06 at 21:47 -0500, Larry Finger wrote:
>>
>> Although I could not duplicate this result on my machine, it seemed likely
>> that it was due to the unusual configuration where rtlwifi was being built,
>> but none of its dependent drivers were selected.
>
> I think it just requires:
>
> CONFIG_USB=m
> CONFIG_RTLWIFI=y
>
>> The fix is to select rtlwifi only when it is needed.
>
> I don't think so. Consider this configuration:
>
> CONFIG_PCI=y
> CONFIG_USB=m
> CONFIG_RTL_CARDS=y
> CONFIG_RTL8192CE=y
> CONFIG_RTL8192CU=m
> CONFIG_RTLWIFI=y # maximum of RTL8192CE=y and RTL8192CU=m
>
> The same breakage occurs.
Ben,
Thanks for your comments. I certainly do not claim to understand very much about
the whole Kbuild process.
After setting up the above configuration manually, I ran 'make oldconfig' and
got back
CONFIG_RTL_CARDS=m
CONFIG_RTL8192CE=m
CONFIG_RTL8192SE=m
CONFIG_RTL8192DE=m
CONFIG_RTL8723AE=m
CONFIG_RTL8188EE=m
CONFIG_RTL8192CU=m
CONFIG_RTLWIFI=m
CONFIG_RTLWIFI_DEBUG=y
CONFIG_RTL8192C_COMMON=m
That set of configuration parameters built normally.
>> While making this
>> change, I simplified the configuration so that variable RTLWIFI is never seen
>> by the user.
> [...]
>
> This will break existing configurations as RTL_CARDS defaults to n.
I added a 'default y' to the RTL_CARDS stanza. I now get the following:
finger@larrylap:~/staging> make
scripts/kconfig/conf --silentoldconfig Kconfig
*
* Restart config...
*
*
* Realtek rtlwifi family of devices
*
Realtek rtlwifi family of devices (RTL_CARDS) [M/n/?] (NEW)
That should prevent breakage of existing configurations. It defaults to "m"
because mac80211 is built as a module in my configuration.
> Perhaps you should introduce separate modules for the common PCI and USB
> support code, similarly to how the rt2x00 modules are organised.
That would not be very difficult, but it would involve converting the single
module rtlwifi into 3 separate entities. Does that make sense to you? I'm not sure.
Thanks again for your comments.
Larry
^ permalink raw reply
* RE: [PATCH] mwifiex: don't ignore SDIO interrupts during shutdown
From: Amitkumar Karwar @ 2013-07-07 16:15 UTC (permalink / raw)
To: 'Daniel Drake'
Cc: Bing Zhao, 'linux-wireless@vger.kernel.org',
'linville@tuxdriver.com'
In-Reply-To: <5FF020A1CFFEEC49BD1E09530C4FF5951035636354@SC-VEXCH1.marvell.com>
[-- Attachment #1: Type: text/plain, Size: 364 bytes --]
Hi Daniel,
>We didn't test the behavior of sdio_read/sdio_write API's when hardware is >not present. But they should just return an error.
I ran some tests which confirmed that there is no harm in calling these API's when hardware is removed. They returned ENOMEDIUM error.
Can you please review and verify attached patch?
Thanks,
Amitkumar Karwar
[-- Attachment #2: 0001-mwifiex-disable-SDIO-interrupts-in-remove-handler.patch --]
[-- Type: application/octet-stream, Size: 5178 bytes --]
From d1b063d2097d30fd445b31a985c024765a9c14e1 Mon Sep 17 00:00:00 2001
From: Amitkumar Karwar <akarwar@marvell.com>
Date: Mon, 8 Jul 2013 21:16:08 +0530
Subject: [PATCH] mwifiex: disable SDIO interrupts in remove handler
Our mwifiex_sdio_remove() handler sets surprised_removed
flag. This causes SDIO_interrupt handler to ignore all
further interrupts without acking them. This may lead to
an interrupt storm causing problem for bluetooth driver
which operates same wifi card.
The problem is fixed by disabling interrupts in remove
handler. If there is an interrupt in process, the logic
to wait until it gets completed is already there
(mwifiex_shutdown_drv() call).
Some code is moved in this patch to prevent forward
declarations.
Inspired by a patch sent by Daniel Drake <dsd@laptop.org>
Reported-by: Daniel Drake <dsd@laptop.org>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
---
drivers/net/wireless/mwifiex/sdio.c | 121 +++++++++++++++++------------------
1 files changed, 58 insertions(+), 63 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index 14ac51f..f79800b 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -111,6 +111,61 @@ mwifiex_sdio_probe(struct sdio_func *func, const struct sdio_device_id *id)
return ret;
}
+/* This function reads data from SDIO card register. */
+static int
+mwifiex_read_reg(struct mwifiex_adapter *adapter, u32 reg, u8 *data)
+{
+ struct sdio_mmc_card *card = adapter->card;
+ int ret = -1;
+ u8 val;
+
+ sdio_claim_host(card->func);
+ val = sdio_readb(card->func, reg, &ret);
+ sdio_release_host(card->func);
+
+ *data = val;
+
+ return ret;
+}
+
+/* This function writes data into SDIO card register. */
+static int
+mwifiex_write_reg(struct mwifiex_adapter *adapter, u32 reg, u8 data)
+{
+ struct sdio_mmc_card *card = adapter->card;
+ int ret = -1;
+
+ sdio_claim_host(card->func);
+ sdio_writeb(card->func, data, reg, &ret);
+ sdio_release_host(card->func);
+
+ return ret;
+}
+
+/* This function disables the host interrupt.
+ *
+ * The host interrupt mask is read, the disable bit is reset and
+ * written back to the card host interrupt mask register.
+ */
+static int mwifiex_sdio_disable_host_int(struct mwifiex_adapter *adapter)
+{
+ u8 host_int_mask, host_int_disable = HOST_INT_DISABLE;
+
+ /* Read back the host_int_mask register */
+ if (mwifiex_read_reg(adapter, HOST_INT_MASK_REG, &host_int_mask))
+ return -1;
+
+ /* Update with the mask and write back to the register */
+ host_int_mask &= ~host_int_disable;
+
+ if (mwifiex_write_reg(adapter, HOST_INT_MASK_REG, host_int_mask)) {
+ dev_err(adapter->dev, "disable host interrupt failed\n");
+ return -1;
+ }
+
+ return 0;
+}
+
/*
* SDIO remove.
*
@@ -152,6 +207,9 @@ mwifiex_sdio_remove(struct sdio_func *func)
mwifiex_init_shutdown_fw(priv, MWIFIEX_FUNC_SHUTDOWN);
}
+ /* Disable host interrupt mask register for SDIO */
+ mwifiex_sdio_disable_host_int(adapter);
+
mwifiex_remove_card(card->adapter, &add_remove_card_sem);
kfree(card);
}
@@ -297,41 +355,6 @@ static struct sdio_driver mwifiex_sdio = {
};
/*
- * This function writes data into SDIO card register.
- */
-static int
-mwifiex_write_reg(struct mwifiex_adapter *adapter, u32 reg, u8 data)
-{
- struct sdio_mmc_card *card = adapter->card;
- int ret = -1;
-
- sdio_claim_host(card->func);
- sdio_writeb(card->func, data, reg, &ret);
- sdio_release_host(card->func);
-
- return ret;
-}
-
-/*
- * This function reads data from SDIO card register.
- */
-static int
-mwifiex_read_reg(struct mwifiex_adapter *adapter, u32 reg, u8 *data)
-{
- struct sdio_mmc_card *card = adapter->card;
- int ret = -1;
- u8 val;
-
- sdio_claim_host(card->func);
- val = sdio_readb(card->func, reg, &ret);
- sdio_release_host(card->func);
-
- *data = val;
-
- return ret;
-}
-
-/*
* This function writes multiple data into SDIO card memory.
*
* This does not work in suspended mode.
@@ -680,31 +703,6 @@ mwifiex_sdio_read_fw_status(struct mwifiex_adapter *adapter, u16 *dat)
}
/*
- * This function disables the host interrupt.
- *
- * The host interrupt mask is read, the disable bit is reset and
- * written back to the card host interrupt mask register.
- */
-static int mwifiex_sdio_disable_host_int(struct mwifiex_adapter *adapter)
-{
- u8 host_int_mask, host_int_disable = HOST_INT_DISABLE;
-
- /* Read back the host_int_mask register */
- if (mwifiex_read_reg(adapter, HOST_INT_MASK_REG, &host_int_mask))
- return -1;
-
- /* Update with the mask and write back to the register */
- host_int_mask &= ~host_int_disable;
-
- if (mwifiex_write_reg(adapter, HOST_INT_MASK_REG, host_int_mask)) {
- dev_err(adapter->dev, "disable host interrupt failed\n");
- return -1;
- }
-
- return 0;
-}
-
-/*
* This function enables the host interrupt.
*
* The host interrupt enable mask is written to the card
@@ -997,9 +995,6 @@ mwifiex_sdio_interrupt(struct sdio_func *func)
}
adapter = card->adapter;
- if (adapter->surprise_removed)
- return;
-
if (!adapter->pps_uapsd_mode && adapter->ps_state == PS_STATE_SLEEP)
adapter->ps_state = PS_STATE_AWAKE;
--
1.7.3.4
^ permalink raw reply related
* Re: [rt2x00-users] [PATCH v2 00/20] rt2x00: add experimental support for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:42 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-1-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:39AM +0200, Gabor Juhos wrote:
> This patch-set implements experiemental support for the
> RT3593 chipset. The patches are tested on the Linksys
> AE3000 USB device only, however other USB devices which
> are using the RT3573 chips might work as well.
Good work Gabor!
Thanks
Stanislaw
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 20/20] rt2x00: rt2800usb: add USB device ID for Linksys AE3000
From: Stanislaw Gruszka @ 2013-07-07 14:41 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-21-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:59AM +0200, Gabor Juhos wrote:
> The Linksys AE3000 device is based on the RT3573
> chipset. The support for this chipset is available
> already, and the AE3000 device works with the driver.
>
> Only managed mode works correctly at the moment,
> for AP mode additional changes are needed in the
> driver.
>
> Also add a new RT2800USB_RT3573 Kconfig option and
> only enable support for RT3573 based devices if
> that is enabled.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 19/20] rt2x00: rt2800usb: use correct [RT]XWI size for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:41 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-20-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:58AM +0200, Gabor Juhos wrote:
> The RT3593 chipset requires different [RT]XWI size
> values. Modify the driver to use the correct values.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 18/20] rt2x00: rt2800lib: enable RT3593 support
From: Stanislaw Gruszka @ 2013-07-07 14:40 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-19-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:57AM +0200, Gabor Juhos wrote:
> Support for the RT3593 has been implemented in
> the previous changes, so it is safe to mark it
> supported in the driver.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 17/20] rt2x00: rt2800lib: enable RF3053 support
From: Stanislaw Gruszka @ 2013-07-07 14:40 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-18-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:56AM +0200, Gabor Juhos wrote:
> Support for the RF3053 has been implemented in
> the previous changes, so it is safe to mark it
> supported in the driver.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 16/20] rt2x00: rt2800lib: enable VCO recalibration for RF3053
From: Stanislaw Gruszka @ 2013-07-07 14:40 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-17-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:55AM +0200, Gabor Juhos wrote:
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
> case RF3290:
> + case RF3053:
> case RF5360:
Nit: sort order.
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 15/20] rt2x00: rt2800lib: add channel configuration for RF3053
From: Stanislaw Gruszka @ 2013-07-07 14:39 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-16-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:54AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> RT3593_ChipSwitchChannel in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 14/20] rt2x00: rt2800lib: add rf_vals for RF3053
From: Stanislaw Gruszka @ 2013-07-07 14:26 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-15-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:53AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> FreqItems3053 in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 13/20] rt2x00: rt2800lib: add default_power3 field for three-chain devices
From: Stanislaw Gruszka @ 2013-07-07 14:23 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-14-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:52AM +0200, Gabor Juhos wrote:
> The actual code uses two default TX power values.
> This is enough for 1T and for 2T devices however
> on 3T devices another value is needed for the third
> chain.
>
> Add a new field to struct channel_info and initialize
> it from the 'rt2800_probe_hw_mode' function. Also modify
> the 'rt2800_config_channel' to handle the new field as
> well.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 12/20] rt2x00: rt2x00lib: fix LNA_A[12] gain values for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:23 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-13-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:51AM +0200, Gabor Juhos wrote:
> The LNA_A[12] gain values are stored at a different
> offset in the EEPROM on RT3593 based devices. However
> the current code unconditionally reads those values
> from the location used by other chipsets.
>
> Fix the code to use the correct EEPROM offset.
>
> Based on the DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> RT3593_EEPROM_RSSI2_OFFSET_ALNAGAIN1_24G_READ in include/chip/rt3593.h
> RT3593_EEPROM_RSSI2_OFFSET_ALNAGAIN2_5G_READ in include/chip/rt3593.h
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 09/20] rt2x00: rt2800lib: fix default TX power values for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:20 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-10-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:48AM +0200, Gabor Juhos wrote:
> The TX power values in the EEPROM are using
> a different format for the RT3593 chip. The
> default TX power value uses bits 0..4 only.
> Bits 5..8 contains value for fine grained
> power control. Additionally, the lower and
> upper limits of the TX power values are the
> same for both bands.
>
> Improve the rt2800_txpower_to_dev function,
> in order to compute the correct default power
> values for the RT3593 chip as well.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 08/20] rt2x00: rt2800lib: add rt2800_txpower_to_dev helper
From: Stanislaw Gruszka @ 2013-07-07 14:18 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-9-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:47AM +0200, Gabor Juhos wrote:
> Introduce a new helper function for converting
> the default TX power values from EEPROM into
> mac80211 values.
>
> The change improves the readability and it makes
> it easier to add support for other chipsets.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 07/20] rt2x00: rt2800lib: fix antenna configuration for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:16 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-8-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:46AM +0200, Gabor Juhos wrote:
> On the RT3593 chipset, BBP register 86 must be
> configured by different values based on the RX
> antenna numbers.
>
> Configure this register from the 'rt2800_config_ant'
> function.
>
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> RT3593_CONFIG_SET_BY_ANTENNA in include/chip/rt3593.h
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 06/20] rt2x00: rt2800lib: fix BBP1_TX_ANTENNA field configuration for 3T devices
From: Stanislaw Gruszka @ 2013-07-07 14:16 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-7-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:45AM +0200, Gabor Juhos wrote:
> The field must be set to 2 instead of 0 for
> devices with three TX chains.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 11/20] rt2x00: rt2800lib: hardcode TX mixer gain values for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:15 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-12-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:50AM +0200, Gabor Juhos wrote:
> The reference code uses hardcoded zero TX mixer gain value
> for RT3593. Do the same in the rt2x00 driver.
>
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> NICReadEEPROMParameters in common/rtmp_init.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 10/20] rt2x00: rt2800lib: introduce rt2800_get_txmixer_gain_{24, 5}g helpers
From: Stanislaw Gruszka @ 2013-07-07 14:15 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-11-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:49AM +0200, Gabor Juhos wrote:
> Move the TX mixer gain reading code into separate
> helper functions in preparation for RT3593 support.
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 05/20] rt2x00: rt2800lib: add TX power configuration for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:14 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-6-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:44AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> RTMPReadTxPwrPerRateExt in chips/rt3593.c
> RT3593_AsicGetTxPowerOffset in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 04/20] rt2x00: rt2800lib: add BBP post initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:10 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-5-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:43AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> Reference:
> RT3593_PostBBPInitialization in chips/rt3553.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 03/20] rt2x00: rt2800lib: add RFCSR register initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:10 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-4-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:42AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> NICInitRT3593RFRegisters in chips/rt3593.c
> RT3593LoadRFNormalModeSetup in chips/rt3593.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
> case RT3390:
> rt2800_init_rfcsr_3390(rt2x00dev);
> break;
> + case RT3593:
> + rt2800_init_rfcsr_3593(rt2x00dev);
> + break;
> case RT3572:
> rt2800_init_rfcsr_3572(rt2x00dev);
> break;
Nit: RT3572 should be before RT3593.
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2 02/20] rt2x00: rt2800lib: add BBP register initialization for RT3593
From: Stanislaw Gruszka @ 2013-07-07 14:07 UTC (permalink / raw)
To: Gabor Juhos; +Cc: John Linville, linux-wireless, users
In-Reply-To: <1372664879-18474-3-git-send-email-juhosg@openwrt.org>
On Mon, Jul 01, 2013 at 09:47:41AM +0200, Gabor Juhos wrote:
> Based on the Ralink DPO_RT5572_LinuxSTA_2.6.0.1_20120629
> driver.
>
> References:
> NICInitRT3593BbpRegisters in chips/rt3593.c
> NICInitBBP in common/rtmp_init.c
> NICInitAsicFromEEPROM in common/rtmp_init.c
>
> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
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