* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Johannes Berg @ 2013-07-31 6:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Ben Greear, Paul Stewart, Felix Fietkau,
Jouni Malinen
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On Tue, 2013-07-30 at 17:53 -0700, Luis R. Rodriguez wrote:
> Folks,
>
> Back in 2009 Intel had put out a wifi-test tree [0] but that seems
> deprecated now. The git tree at least is gone. Can someone confirm if
> that's dead?
It is indeed dead.
> We later had Google present at the 2010 San Francisco
> wireless summit [1] their test infrastructure using autotest. Last I
> checked that stuff was not merged back upstream to autotest.
I don't think that's upstream, but it's certainly available as open
source from chromium.
> Can
> someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
> internal testing infrastructures that obviously are not open.
hwsim is really orthogonal here - it's a test driver to allow testing in
e.g. virtual machine environments as opposed to a real
testbed/screenroom, but it obviously doesn't provide any test
infrastructure.
johannes
^ permalink raw reply
* Re: [PATCH v2] ath10k: implement get_survey()
From: Kalle Valo @ 2013-07-31 6:24 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1375081712-9697-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This implements a limited subset of what can be
> reported in the survey dump.
>
> This can be used for assessing approximate channel
> load, e.g. for automatic channel selection.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> @@ -374,6 +375,11 @@ struct ath10k {
>
> struct work_struct restart_work;
>
> + /* cycle count is reported twice for each visited channel during scan */
> + u32 survey_last_rx_clear_count;
> + u32 survey_last_cycle_count;
> + struct survey_info survey[ATH10K_NUM_CHANS];
Please document the locking. Apparently survey is protected with
data_lock?
[...]
> static void ath10k_wmi_event_chan_info(struct ath10k *ar, struct sk_buff *skb)
> {
> - ath10k_dbg(ATH10K_DBG_WMI, "WMI_CHAN_INFO_EVENTID\n");
> + struct wmi_chan_info_event *ev;
> + int idx;
> +
> + spin_lock_bh(&ar->data_lock);
> +
> + ev = (struct wmi_chan_info_event *)skb->data;
> + ath10k_dbg(ATH10K_DBG_WMI,
> + "chan info: err_code:%d freq:%d cmd_flags:%d noise_floor:%d rx_clear_count:%d cycle_count:%d\n",
> + __le32_to_cpu(ev->err_code),
> + __le32_to_cpu(ev->freq),
> + __le32_to_cpu(ev->cmd_flags),
> + __le32_to_cpu(ev->noise_floor),
> + __le32_to_cpu(ev->rx_clear_count),
> + __le32_to_cpu(ev->cycle_count));
"wmi event chan info err_code %d freq %d cmd_flags %d noise_floor %d rx_clear_count %d cycle_count %d\n"
> + if (!ar->scan.in_progress) {
> + ath10k_warn("chan info event without a scan request?\n");
> + goto exit;
> + }
> +
> + if (__le32_to_cpu(ev->cmd_flags) & WMI_CHAN_INFO_FLAG_COMPLETE) {
> + idx = freq_to_idx(ar, __le32_to_cpu(ev->freq));
> + if (idx >= ARRAY_SIZE(ar->survey)) {
> + ath10k_warn("chan info: invalid frequency %d (idx %d out of bounds)\n",
> + __le32_to_cpu(ev->freq), idx);
I think we should just bail out if this happens.
> + } else {
> + /* During scanning chan info is reported twice for each
> + * visited channel. The reported cycle count is global
> + * and per-channel cycle count must be calculated */
> +
> + ar->survey[idx].channel_time = WMI_CHAN_INFO_MSEC(
> + __le32_to_cpu(ev->cycle_count) -
> + ar->survey_last_cycle_count);
> + ar->survey[idx].channel_time_rx = WMI_CHAN_INFO_MSEC(
> + __le32_to_cpu(ev->rx_clear_count) -
> + ar->survey_last_rx_clear_count);
> + ar->survey[idx].noise = __le32_to_cpu(ev->noise_floor);
> + ar->survey[idx].filled = SURVEY_INFO_CHANNEL_TIME |
> + SURVEY_INFO_CHANNEL_TIME_RX |
> + SURVEY_INFO_NOISE_DBM;
> + }
...and then there's no reason to use else branch here. Also you can add
temporary variables time and time_rx to make clean up the indentation.
> + }
> +
> + ar->survey_last_rx_clear_count = __le32_to_cpu(ev->rx_clear_count);
> + ar->survey_last_cycle_count = __le32_to_cpu(ev->cycle_count);
> +
> +exit:
> + spin_unlock_bh(&ar->data_lock);
> }
>
> static void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index da3b2bc..4acff47 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -2931,6 +2931,9 @@ struct wmi_chan_info_event {
> __le32 cycle_count;
> } __packed;
>
> +#define WMI_CHAN_INFO_FLAG_COMPLETE BIT(0)
> +#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595) /* XXX: empirically extrapolated */
Use "FIXME:" and comment on a separate line:
/* FIXME: empirically extrapolated */
#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595)
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: detect the number of spatial streams supported by hw
From: Kalle Valo @ 2013-07-31 6:06 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374662206-19198-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Until now ath10k assumed 3 spatial streams.
> However some devices support only 2 spatial
> streams.
>
> This patch improves performance on devices that
> don't support 3 spatial streams.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: improve tx throughput on slow machines
From: Kalle Valo @ 2013-07-31 6:06 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374495928-29514-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> It is more efficient to move just the 802.11
> header instead of the whole payload in most cases.
>
> This has no measurable effect on modern hardware.
> It should improve performance by a few percent on
> hardware such as an Access Point that have a slow
> CPU compared to a typical desktop CPU.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Applied, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: move irq setup
From: Michal Kazior @ 2013-07-31 5:50 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87d2pzuc90.fsf@kamboji.qca.qualcomm.com>
On 30 July 2013 20:35, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> There was a slight race during PCI shutdown. Since
>> interrupts weren't really stopped (only Copy
>> Engine interrupts were disabled through device hw
>> registers) it was possible for a firmware
>> indication (crash) interrupt to come in after
>> tasklets were synced/killed. This would cause
>> memory corruption and a panic in most cases. It
>> was also possible for interrupt to come before CE
>> was initialized during device probing.
>>
>> Interrupts are required for BMI phase so they are enabled as soon as
>> power_up() is called but are freed upon both power_down() and stop()
>> so there's asymmetry here. As by design stop() cannot be followed by
>> start() it is okay. Both power_down() and stop() should be merged
>> later on to avoid confusion.
>
> Why are the interrupts freed both in power_down() and stop()? I don't
> get that.
>
> What if we call disable_irq() in power_down() instead?
power_down() must call free_irq(), because power_up() calls
request_irq() (if you want the symmetry). If anything, the stop()
should call disable_irq(), but wouldn't that mean start() should call
enable_irq()? But than, irqs are needed before start()..
I did think about disable_irq() but AFAIR you need to enable_irq()
later on (so either way you need to keep track of the irq state or
you'll get a ton of WARN_ONs from the system). I'll double check that
and report back later
>> Before this can be really properly fixed var/hw
>> init code split is necessary.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>> ---
>>
>> Please note: this is based on my (still under
>> review at the time of posting) previous patchests:
>> device setup refactor and recovery.
>>
>> I'm posting this before those patchsets are merged
>> so anyone interested in testing this fix (I can't
>> reproduce the problem on my setup) can give it a
>> try.
>
> This was reported by Ben, right? So this sould have a Reported-by line
> attributing him.
Yes. I'll fix that, provided we get through the review with the patch :)
>> @@ -1783,16 +1792,24 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> return 0;
>>
>> err_ce:
>> + /* XXX: Until var/hw init is split it's impossible to fix the ordering
>> + * here so we must call stop_intr() here too to prevent interrupts after
>> + * CE is teared down. It's okay to double call the stop_intr()
>> */
>
> "FIXME:"
Ok.
>> exit:
>> + ar_pci->intr_started = ret == 0;
>
> A bit too clever for the sake of readibility for my taste, but I guess
> it's ok.
>
>> --- a/drivers/net/wireless/ath/ath10k/pci.h
>> +++ b/drivers/net/wireless/ath/ath10k/pci.h
>> @@ -198,6 +198,7 @@ struct ath10k_pci {
>> * interrupts.
>> */
>> int num_msi_intrs;
>> + bool intr_started;
>
> Adding a new state variable makes me worried. I really would prefer a
> solution which would not require that.
I know that. That's why I mentioned in the commit log that it is more
of a workaround than a real fix. Me, I don't like this either but a
real fix requires a lot of rework from what I can tell.
This bug can be triggered more easily now apparently after recovery
patches went in. I'm not experiencing it but I get reports of rare
panics when a machine is left idle for a very long time with
interfaces brought down.
> Also if we call request_irq() in ath10k_pci_probe() we should also call
> free_irq() in ath10k_pci_remove() for symmetry. Just doing a temporary
> hack will most likely stay forever :)
With the patch interrupts are temporarily enabled&disabled for
probe_fw() during pci_probe() and are then not requested until
mac80211 start().
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: change email of TI WiLink drivers' maintainer
From: Luciano Coelho @ 2013-07-31 5:22 UTC (permalink / raw)
To: linville; +Cc: balbi, linux-wireless, luca
In-Reply-To: <1375206341-26211-1-git-send-email-coelho@ti.com>
Hi John,
Could you queue this for 3.11?
I don't currently have anything else for 3.11, so it would just be an
overhead to send you a pull request for this tiny change. ;)
--
Cheers,
Luca.
On Tue, 2013-07-30 at 20:45 +0300, Luciano Coelho wrote:
> Soon the coelho@ti.com email will not be valid anymore, so change it
> to my private one.
>
> Cc: Luciano Coelho <luca@coelho.fi>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c6dc128..77be3f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8278,7 +8278,7 @@ S: Maintained
> F: sound/soc/codecs/twl4030*
>
> TI WILINK WIRELESS DRIVERS
> -M: Luciano Coelho <coelho@ti.com>
> +M: Luciano Coelho <luca@coelho.fi>
> L: linux-wireless@vger.kernel.org
> W: http://wireless.kernel.org/en/users/Drivers/wl12xx
> W: http://wireless.kernel.org/en/users/Drivers/wl1251
^ permalink raw reply
* [PATCH v2] Bluetooth: btmrvl: add calibration data download support
From: Bing Zhao @ 2013-07-31 1:05 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-wireless,
Bing Zhao, Amitkumar Karwar
From: Amitkumar Karwar <akarwar@marvell.com>
A text file containing calibration data in hex format can
be provided at following path:
/lib/firmware/mrvl/sd8797_caldata.conf
The data will be downloaded to firmware during initialization.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
v2: Remove module parameter. The calibration data will be downloaded
only when the device speicific data file is provided.
(Marcel Holtmann)
drivers/bluetooth/btmrvl_drv.h | 10 ++-
drivers/bluetooth/btmrvl_main.c | 140 +++++++++++++++++++++++++++++++++++++++-
drivers/bluetooth/btmrvl_sdio.c | 9 ++-
drivers/bluetooth/btmrvl_sdio.h | 2 +
4 files changed, 157 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index 27068d1..5ef5e84 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -23,6 +23,8 @@
#include <linux/bitops.h>
#include <linux/slab.h>
#include <net/bluetooth/bluetooth.h>
+#include <linux/ctype.h>
+#include <linux/firmware.h>
#define BTM_HEADER_LEN 4
#define BTM_UPLD_SIZE 2312
@@ -41,6 +43,8 @@ struct btmrvl_thread {
struct btmrvl_device {
void *card;
struct hci_dev *hcidev;
+ struct device *dev;
+ const char *cal_data;
u8 dev_type;
@@ -91,6 +95,7 @@ struct btmrvl_private {
#define BT_CMD_HOST_SLEEP_CONFIG 0x59
#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
#define BT_CMD_MODULE_CFG_REQ 0x5B
+#define BT_CMD_LOAD_CONFIG_DATA 0x61
/* Sub-commands: Module Bringup/Shutdown Request/Response */
#define MODULE_BRINGUP_REQ 0xF1
@@ -116,10 +121,13 @@ struct btmrvl_private {
#define PS_SLEEP 0x01
#define PS_AWAKE 0x00
+#define BT_CMD_DATA_SIZE 32
+#define BT_CAL_DATA_SIZE 28
+
struct btmrvl_cmd {
__le16 ocf_ogf;
u8 length;
- u8 data[4];
+ u8 data[BT_CMD_DATA_SIZE];
} __packed;
struct btmrvl_event {
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 9a9f518..9487684 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -57,8 +57,9 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
ocf = hci_opcode_ocf(opcode);
ogf = hci_opcode_ogf(opcode);
- if (ocf == BT_CMD_MODULE_CFG_REQ &&
- priv->btmrvl_dev.sendcmdflag) {
+ if ((ocf == BT_CMD_MODULE_CFG_REQ ||
+ ocf == BT_CMD_LOAD_CONFIG_DATA) &&
+ priv->btmrvl_dev.sendcmdflag) {
priv->btmrvl_dev.sendcmdflag = false;
priv->adapter->cmd_complete = true;
wake_up_interruptible(&priv->adapter->cmd_wait_q);
@@ -552,6 +553,132 @@ static int btmrvl_service_main_thread(void *data)
return 0;
}
+static int btmrvl_parse_cal_cfg(const u8 *src, u32 len, u8 *dst, u32 dst_size)
+{
+ const u8 *s = src;
+ u8 *d = dst;
+ int ret;
+ u8 tmp[3];
+
+ while ((s - src) < len) {
+ if (*s && (isspace(*s) || *s == '\t')) {
+ s++;
+ continue;
+ }
+
+ if (isxdigit(*s)) {
+ if ((d - dst) >= dst_size) {
+ BT_ERR("calibration data file too big!!!");
+ return -EINVAL;
+ }
+
+ memcpy(tmp, s, 2);
+ tmp[2] = '\0';
+
+ ret = kstrtol(tmp, 16, (long *)d++);
+ if (ret < 0)
+ return ret;
+
+ s += 2;
+ } else {
+ s++;
+ }
+ }
+ if (d == dst)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int btmrvl_load_cal_data(struct btmrvl_private *priv,
+ u8 *config_data)
+{
+ struct sk_buff *skb;
+ struct btmrvl_cmd *cmd;
+ int i;
+
+ skb = bt_skb_alloc(sizeof(*cmd), GFP_ATOMIC);
+ if (!skb)
+ return -ENOMEM;
+
+ cmd = (struct btmrvl_cmd *)skb->data;
+ cmd->ocf_ogf =
+ cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA));
+ cmd->length = BT_CMD_DATA_SIZE;
+ cmd->data[0] = 0x00;
+ cmd->data[1] = 0x00;
+ cmd->data[2] = 0x00;
+ cmd->data[3] = BT_CMD_DATA_SIZE - 4;
+
+ /* swap cal-data bytes */
+ for (i = 4; i < BT_CMD_DATA_SIZE; i++)
+ cmd->data[i] = config_data[(i/4)*8 - 1 - i];
+
+ bt_cb(skb)->pkt_type = MRVL_VENDOR_PKT;
+ skb_put(skb, sizeof(*cmd));
+ skb->dev = (void *)priv->btmrvl_dev.hcidev;
+ skb_queue_head(&priv->adapter->tx_queue, skb);
+ priv->btmrvl_dev.sendcmdflag = true;
+ priv->adapter->cmd_complete = false;
+
+ print_hex_dump_bytes("Calibration data: ",
+ DUMP_PREFIX_OFFSET, cmd->data, BT_CMD_DATA_SIZE);
+
+ wake_up_interruptible(&priv->main_thread.wait_q);
+ if (!wait_event_interruptible_timeout(priv->adapter->cmd_wait_q,
+ priv->adapter->cmd_complete,
+ msecs_to_jiffies(WAIT_UNTIL_CMD_RESP))) {
+ BT_ERR("Timeout while loading calibration data");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int
+btmrvl_process_cal_cfg(struct btmrvl_private *priv, u8 *data, u32 size)
+{
+ u8 cal_data[BT_CAL_DATA_SIZE];
+ int ret;
+
+ ret = btmrvl_parse_cal_cfg(data, size, cal_data, sizeof(cal_data));
+ if (ret)
+ return ret;
+
+ ret = btmrvl_load_cal_data(priv, cal_data);
+ if (ret) {
+ BT_ERR("Fail to load calibrate data");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int btmrvl_cal_data_config(struct btmrvl_private *priv)
+{
+ const struct firmware *cfg;
+ int ret;
+ const char *cal_data = priv->btmrvl_dev.cal_data;
+
+ if (!cal_data)
+ return 0;
+
+ ret = request_firmware(&cfg, cal_data, priv->btmrvl_dev.dev);
+ if (ret < 0) {
+ BT_DBG("Failed to get %s file, skipping cal data download",
+ cal_data);
+ ret = 0;
+ goto done;
+ }
+
+ ret = btmrvl_process_cal_cfg(priv, (u8 *)cfg->data, cfg->size);
+done:
+ if (cfg)
+ release_firmware(cfg);
+
+ return ret;
+}
+
int btmrvl_register_hdev(struct btmrvl_private *priv)
{
struct hci_dev *hdev = NULL;
@@ -583,12 +710,21 @@ int btmrvl_register_hdev(struct btmrvl_private *priv)
goto err_hci_register_dev;
}
+ ret = btmrvl_cal_data_config(priv);
+ if (ret) {
+ BT_ERR("Set cal data failed");
+ goto err_cal_data_config;
+ }
+
#ifdef CONFIG_DEBUG_FS
btmrvl_debugfs_init(hdev);
#endif
return 0;
+err_cal_data_config:
+ hci_unregister_dev(hdev);
+
err_hci_register_dev:
hci_free_dev(hdev);
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 75c2626..292fd92 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -18,7 +18,6 @@
* this warranty disclaimer.
**/
-#include <linux/firmware.h>
#include <linux/slab.h>
#include <linux/mmc/sdio_ids.h>
@@ -102,6 +101,7 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_88xx = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
.helper = "mrvl/sd8688_helper.bin",
.firmware = "mrvl/sd8688.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -109,6 +109,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
.helper = NULL,
.firmware = "mrvl/sd8787_uapsta.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -116,6 +117,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
.helper = NULL,
.firmware = "mrvl/sd8797_uapsta.bin",
+ .cal_data = "mrvl/sd8797_caldata.conf",
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -123,6 +125,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8897 = {
.helper = NULL,
.firmware = "mrvl/sd8897_uapsta.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_88xx,
.sd_blksz_fw_dl = 256,
};
@@ -1006,6 +1009,7 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
struct btmrvl_sdio_device *data = (void *) id->driver_data;
card->helper = data->helper;
card->firmware = data->firmware;
+ card->cal_data = data->cal_data;
card->reg = data->reg;
card->sd_blksz_fw_dl = data->sd_blksz_fw_dl;
}
@@ -1034,6 +1038,8 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
}
card->priv = priv;
+ priv->btmrvl_dev.dev = &card->func->dev;
+ priv->btmrvl_dev.cal_data = card->cal_data;
/* Initialize the interface specific function pointers */
priv->hw_host_to_card = btmrvl_sdio_host_to_card;
@@ -1222,4 +1228,5 @@ MODULE_FIRMWARE("mrvl/sd8688_helper.bin");
MODULE_FIRMWARE("mrvl/sd8688.bin");
MODULE_FIRMWARE("mrvl/sd8787_uapsta.bin");
MODULE_FIRMWARE("mrvl/sd8797_uapsta.bin");
+MODULE_FIRMWARE("mrvl/sd8797_caldata.conf");
MODULE_FIRMWARE("mrvl/sd8897_uapsta.bin");
diff --git a/drivers/bluetooth/btmrvl_sdio.h b/drivers/bluetooth/btmrvl_sdio.h
index 43d35a6..6872d9e 100644
--- a/drivers/bluetooth/btmrvl_sdio.h
+++ b/drivers/bluetooth/btmrvl_sdio.h
@@ -85,6 +85,7 @@ struct btmrvl_sdio_card {
u32 ioport;
const char *helper;
const char *firmware;
+ const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
u8 rx_unit;
@@ -94,6 +95,7 @@ struct btmrvl_sdio_card {
struct btmrvl_sdio_device {
const char *helper;
const char *firmware;
+ const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
};
--
1.8.0
^ permalink raw reply related
* 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Luis R. Rodriguez @ 2013-07-31 0:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, Paul Stewart, Felix Fietkau, Jouni Malinen
Folks,
Back in 2009 Intel had put out a wifi-test tree [0] but that seems
deprecated now. The git tree at least is gone. Can someone confirm if
that's dead? We later had Google present at the 2010 San Francisco
wireless summit [1] their test infrastructure using autotest. Last I
checked that stuff was not merged back upstream to autotest. Can
someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
internal testing infrastructures that obviously are not open.
If we are to embark on a new journey towards an open testing
infrastructure what should be used? Ben, you have some stuff, and I
know you also report some interesting bugs with insane amount of
stations. Is any of it open?
AFAICT mac80211_hwism should and likely already is used for a slew of
core API changes / tests. Addressing testing using that shoud
hopefully address tons of testings and find a lot of issues. We'd then
just need vendors to replicate behaviour on top of their drivers. The
core test stuff though still needs to be available.
What do we have, anyone have any lofty plans?
[0] http://wireless.kernel.org/en/developers/Testing/wifi-test
[1] http://wireless.kernel.org/en/developers/Summits/SanFranciscoBayArea-2010
[2] http://wireless.kernel.org/en/users/Drivers/mac80211_hwsim
Luis
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-31 0:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings
In-Reply-To: <20130730235508.GA25319@kroah.com>
On Tue, Jul 30, 2013 at 04:55:08PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 30, 2013 at 03:48:09PM -0700, Luis R. Rodriguez wrote:
> > > We are planning to take one extra step and split this into a
> > > mini-driver approach similar to what has been done for usbnet, but we
> > > are not there yet.
> >
> > Neat. Perhaps we need something that we can share with 802.11 or other
> > hardare I highly doubt we're the only ones patching ROM. Don't we even
> > patch up core CPUs? I'm wondering if firmware_class could be expanded to
> > support serialized ROM patching. The biggest hurdle I see with splititng
> > ROM patching from a single firmware is serializing that, addressing
> > revision dependencies and of course kernel dependencies.
>
> What does the firmware_class need to do here that it doesn't do today?
It will depend on the requirements for ROM patches and if or not
firmware can be split up into patches rather than getting a full
firmware.fw update for any single patch update. If ROM patches
get split up then how I can imagine driver code firmware getting
to become a pain in the ass to maintain and nasty. It'd seem
better to build relationships between these and possible patch
depdendencies on ROM and let firmware_class do the management
of that.
> > > However the ROM patching drivers need to be in the kernel since
> > > otherwise they will race with the core init sequence.
> >
> > Sure and depending on the architecture -- if this is kicked off to
> > userspace helpers or not then we may need to consider dbus in
> > kernel thing to help with speed / races, dependenecies / async
> > loading, -EPROBE_DEFER, etc.
>
> How would dbus in the kernel change anything here?
> The kernel directly loads firmware from the filesystem now, no userspace
> helpers are involved, so no need for udev, libusb, etc. And as such, no
> need for any "dbus" in the kernel to do this either.
> I don't understand how it could, please explain.
Yeah nevermind :D too much coffee today made my brain fart.
> Also note, for those not knowing, we have been working on dbus in the
> kernel (google "kdbus" for the github repo), but it is all
> outward-facing (i.e. userspace using the kdbus code to interact with
> other processes with a dbus-like protocol, not for in-kernel dbus
> things, although adding it wouldn't be that hard, just really strange.
Thanks!
Luis
^ permalink raw reply
* [PATCH] mwifiex: populate rates in probe request using cfg80211_scan_request
From: Bing Zhao @ 2013-07-31 0:18 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Avinash Patil, Amitkumar Karwar,
Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Avinash Patil <patila@marvell.com>
Whenever available, use cfg80211_scan_request to populates rates
in outgoing probe request. This will help to advertise band specific
rates and fix an issue where 11b rates were advertised in probe
request going out on 11a band.
This will also ensure that we do not advertise 11b rates while P2P
scan is going on.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/cfp.c | 42 ++++++++++++++++++++++---
drivers/net/wireless/mwifiex/main.h | 2 ++
drivers/net/wireless/mwifiex/scan.c | 63 +++++++++++++++++++++++++++----------
3 files changed, 85 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfp.c b/drivers/net/wireless/mwifiex/cfp.c
index 5178c46..9eefacb 100644
--- a/drivers/net/wireless/mwifiex/cfp.c
+++ b/drivers/net/wireless/mwifiex/cfp.c
@@ -404,11 +404,43 @@ mwifiex_is_rate_auto(struct mwifiex_private *priv)
return false;
}
-/*
- * This function gets the supported data rates.
- *
- * The function works in both Ad-Hoc and infra mode by printing the
- * band and returning the data rates.
+/* This function gets the supported data rates from bitmask inside
+ * cfg80211_scan_request.
+ */
+u32 mwifiex_get_rates_from_cfg80211(struct mwifiex_private *priv,
+ u8 *rates, u8 radio_type)
+{
+ struct wiphy *wiphy = priv->adapter->wiphy;
+ struct cfg80211_scan_request *request = priv->scan_request;
+ u32 num_rates, rate_mask;
+ struct ieee80211_supported_band *sband;
+ int i;
+
+ if (radio_type) {
+ sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+ if (WARN_ON_ONCE(!sband))
+ return 0;
+ rate_mask = request->rates[IEEE80211_BAND_5GHZ];
+ } else {
+ sband = wiphy->bands[IEEE80211_BAND_2GHZ];
+ if (WARN_ON_ONCE(!sband))
+ return 0;
+ rate_mask = request->rates[IEEE80211_BAND_2GHZ];
+ }
+
+ num_rates = 0;
+ for (i = 0; i < sband->n_bitrates; i++) {
+ if ((BIT(i) & rate_mask) == 0)
+ continue; /* skip rate */
+ rates[num_rates++] = (u8)(sband->bitrates[i].bitrate / 5);
+ }
+
+ return num_rates;
+}
+
+/* This function gets the supported data rates. The function works in
+ * both Ad-Hoc and infra mode by printing the band and returning the
+ * data rates.
*/
u32 mwifiex_get_supported_rates(struct mwifiex_private *priv, u8 *rates)
{
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 48685e7..cf961d9 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -903,6 +903,8 @@ int mwifiex_cmd_append_vsie_tlv(struct mwifiex_private *priv, u16 vsie_mask,
u32 mwifiex_get_active_data_rates(struct mwifiex_private *priv,
u8 *rates);
u32 mwifiex_get_supported_rates(struct mwifiex_private *priv, u8 *rates);
+u32 mwifiex_get_rates_from_cfg80211(struct mwifiex_private *priv,
+ u8 *rates, u8 radio_type);
u8 mwifiex_is_rate_auto(struct mwifiex_private *priv);
extern u16 region_code_index[MWIFIEX_MAX_REGION_CODE];
void mwifiex_save_curr_bcn(struct mwifiex_private *priv);
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index c447d9b..8cf7d50 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -543,6 +543,37 @@ mwifiex_scan_create_channel_list(struct mwifiex_private *priv,
return chan_idx;
}
+/* This function appends rate TLV to scan config command. */
+static int
+mwifiex_append_rate_tlv(struct mwifiex_private *priv,
+ struct mwifiex_scan_cmd_config *scan_cfg_out,
+ u8 radio)
+{
+ struct mwifiex_ie_types_rates_param_set *rates_tlv;
+ u8 rates[MWIFIEX_SUPPORTED_RATES], *tlv_pos;
+ u32 rates_size;
+
+ memset(rates, 0, sizeof(rates));
+
+ tlv_pos = (u8 *)scan_cfg_out->tlv_buf + scan_cfg_out->tlv_buf_len;
+
+ if (priv->scan_request)
+ rates_size = mwifiex_get_rates_from_cfg80211(priv, rates,
+ radio);
+ else
+ rates_size = mwifiex_get_supported_rates(priv, rates);
+
+ dev_dbg(priv->adapter->dev, "info: SCAN_CMD: Rates size = %d\n",
+ rates_size);
+ rates_tlv = (struct mwifiex_ie_types_rates_param_set *)tlv_pos;
+ rates_tlv->header.type = cpu_to_le16(WLAN_EID_SUPP_RATES);
+ rates_tlv->header.len = cpu_to_le16((u16) rates_size);
+ memcpy(rates_tlv->rates, rates, rates_size);
+ scan_cfg_out->tlv_buf_len += sizeof(rates_tlv->header) + rates_size;
+
+ return rates_size;
+}
+
/*
* This function constructs and sends multiple scan config commands to
* the firmware.
@@ -564,9 +595,10 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
struct mwifiex_chan_scan_param_set *tmp_chan_list;
struct mwifiex_chan_scan_param_set *start_chan;
- u32 tlv_idx;
+ u32 tlv_idx, rates_size;
u32 total_scan_time;
u32 done_early;
+ u8 radio_type;
if (!scan_cfg_out || !chan_tlv_out || !scan_chan_list) {
dev_dbg(priv->adapter->dev,
@@ -591,6 +623,7 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
tlv_idx = 0;
total_scan_time = 0;
+ radio_type = 0;
chan_tlv_out->header.len = 0;
start_chan = tmp_chan_list;
done_early = false;
@@ -612,6 +645,7 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
continue;
}
+ radio_type = tmp_chan_list->radio_type;
dev_dbg(priv->adapter->dev,
"info: Scan: Chan(%3d), Radio(%d),"
" Mode(%d, %d), Dur(%d)\n",
@@ -692,6 +726,9 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
break;
}
+ rates_size = mwifiex_append_rate_tlv(priv, scan_cfg_out,
+ radio_type);
+
priv->adapter->scan_channels = start_chan;
/* Send the scan command to the firmware with the specified
@@ -699,6 +736,14 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
ret = mwifiex_send_cmd_async(priv, HostCmd_CMD_802_11_SCAN,
HostCmd_ACT_GEN_SET, 0,
scan_cfg_out);
+
+ /* rate IE is updated per scan command but same starting
+ * pointer is used each time so that rate IE from earlier
+ * scan_cfg_out->buf is overwritten with new one.
+ */
+ scan_cfg_out->tlv_buf_len -=
+ sizeof(struct mwifiex_ie_types_header) + rates_size;
+
if (ret)
break;
}
@@ -741,7 +786,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
struct mwifiex_adapter *adapter = priv->adapter;
struct mwifiex_ie_types_num_probes *num_probes_tlv;
struct mwifiex_ie_types_wildcard_ssid_params *wildcard_ssid_tlv;
- struct mwifiex_ie_types_rates_param_set *rates_tlv;
u8 *tlv_pos;
u32 num_probes;
u32 ssid_len;
@@ -753,8 +797,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
u8 radio_type;
int i;
u8 ssid_filter;
- u8 rates[MWIFIEX_SUPPORTED_RATES];
- u32 rates_size;
struct mwifiex_ie_types_htcap *ht_cap;
/* The tlv_buf_len is calculated for each scan command. The TLVs added
@@ -889,19 +931,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
}
- /* Append rates tlv */
- memset(rates, 0, sizeof(rates));
-
- rates_size = mwifiex_get_supported_rates(priv, rates);
-
- rates_tlv = (struct mwifiex_ie_types_rates_param_set *) tlv_pos;
- rates_tlv->header.type = cpu_to_le16(WLAN_EID_SUPP_RATES);
- rates_tlv->header.len = cpu_to_le16((u16) rates_size);
- memcpy(rates_tlv->rates, rates, rates_size);
- tlv_pos += sizeof(rates_tlv->header) + rates_size;
-
- dev_dbg(adapter->dev, "info: SCAN_CMD: Rates size = %d\n", rates_size);
-
if (ISSUPP_11NENABLED(priv->adapter->fw_cap_info) &&
(priv->adapter->config_bands & BAND_GN ||
priv->adapter->config_bands & BAND_AN)) {
--
1.8.2.3
^ permalink raw reply related
* [PATCH] mwifiex: fix adapter pointer dereference issue
From: Bing Zhao @ 2013-07-31 0:18 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Dan Carpenter, Amitkumar Karwar, Avinash Patil,
Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Amitkumar Karwar <akarwar@marvell.com>
It has introduced by recent commit 6b41f941d7cd: "mwifiex:
handle driver initialization error paths" which adds error
path handling for mwifiex_fw_dpc().
release_firmware(adapter->*) is called for success as well
as failure paths. In failure paths, adapter is already freed
at this point.
The issue is fixed by moving mwifiex_free_adapter() call.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/main.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/main.c b/drivers/net/wireless/mwifiex/main.c
index 5644c7f..3402bff 100644
--- a/drivers/net/wireless/mwifiex/main.c
+++ b/drivers/net/wireless/mwifiex/main.c
@@ -414,6 +414,8 @@ static void mwifiex_fw_dpc(const struct firmware *firmware, void *context)
struct mwifiex_private *priv;
struct mwifiex_adapter *adapter = context;
struct mwifiex_fw_image fw;
+ struct semaphore *sem = adapter->card_sem;
+ bool init_failed = false;
if (!firmware) {
dev_err(adapter->dev,
@@ -528,15 +530,20 @@ err_dnld_fw:
}
adapter->surprise_removed = true;
mwifiex_terminate_workqueue(adapter);
- mwifiex_free_adapter(adapter);
+ init_failed = true;
done:
if (adapter->cal_data) {
release_firmware(adapter->cal_data);
adapter->cal_data = NULL;
}
- release_firmware(adapter->firmware);
+ if (adapter->firmware) {
+ release_firmware(adapter->firmware);
+ adapter->firmware = NULL;
+ }
complete(&adapter->fw_load);
- up(adapter->card_sem);
+ if (init_failed)
+ mwifiex_free_adapter(adapter);
+ up(sem);
return;
}
--
1.8.2.3
^ permalink raw reply related
* [GIT] [NFC] 3.11 fixes
From: Samuel Ortiz @ 2013-07-30 23:59 UTC (permalink / raw)
To: John W. Linville; +Cc: Linux Wireless, Linux NFC
Hi John,
This is the second NFC fixes pull request for 3.11.
We have:
1) A build failure fix for the NCI SPI transport layer due to a
missing CRC_CCITT Kconfig dependency.
2) A netlink command rename: CMD_FW_UPLOAD was merged during the 3.11
merge window but the typical terminology for loading a firmware to a
target is firmware download rather than upload. In order to avoid any
confusion in a file exported to userspace, we rename this command to
CMD_FW_DOWNLOAD.
I realize 2) might not meet the net.git criteria for what fixes are. If
you don't want to take it then I'll have to push it through the
3.12 merge window. If that's the case, and you only want to take 1) then
please use tags/nfc-3.11-1 instead of tags/nfc-3.11-2 in your pull URL.
The following changes since commit 64b6f46f1141ad938e354f37af62e28da972e8eb:
ath9k_hw: Fix multicast search for AR9002 family (2013-07-18 16:22:00 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-fixes.git tags/nfc-fixes-3.11-2
for you to fetch changes up to 9ea7187c53f63e31f2d1b2b1e474e31808565009:
NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD (2013-07-31 01:19:43 +0200)
----------------------------------------------------------------
Frederic Danis (1):
NFC: Fix NCI over SPI build
Samuel Ortiz (1):
NFC: netlink: Rename CMD_FW_UPLOAD to CMD_FW_DOWNLOAD
include/net/nfc/hci.h | 2 +-
include/net/nfc/nfc.h | 4 ++--
include/uapi/linux/nfc.h | 6 +++---
net/nfc/core.c | 20 ++++++++++----------
net/nfc/hci/core.c | 8 ++++----
net/nfc/nci/Kconfig | 1 +
net/nfc/netlink.c | 12 ++++++------
net/nfc/nfc.h | 6 +++---
8 files changed, 30 insertions(+), 29 deletions(-)
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Greg Kroah-Hartman @ 2013-07-30 23:55 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings
In-Reply-To: <20130730224809.GN17130@pogo>
On Tue, Jul 30, 2013 at 03:48:09PM -0700, Luis R. Rodriguez wrote:
> > We are planning to take one extra step and split this into a
> > mini-driver approach similar to what has been done for usbnet, but we
> > are not there yet.
>
> Neat. Perhaps we need something that we can share with 802.11 or other
> hardare I highly doubt we're the only ones patching ROM. Don't we even
> patch up core CPUs? I'm wondering if firmware_class could be expanded to
> support serialized ROM patching. The biggest hurdle I see with splititng
> ROM patching from a single firmware is serializing that, addressing
> revision dependencies and of course kernel dependencies.
What does the firmware_class need to do here that it doesn't do today?
> > However the ROM patching drivers need to be in the kernel since
> > otherwise they will race with the core init sequence.
>
> Sure and depending on the architecture -- if this is kicked off to
> userspace helpers or not then we may need to consider dbus in
> kernel thing to help with speed / races, dependenecies / async
> loading, -EPROBE_DEFER, etc.
How would dbus in the kernel change anything here?
> > There are also just firmware download drivers that do nothing else
> > than just loading the firmware. And here it can be done via userspace
> > or kernel space. In the Bluetooth world we have seen both, but
> > generally the kernel ones stayed around while the userspace ones had a
> > hard time to work with udev, libusb, libusb1 etc.
>
> Ah I see. Perhaps we can address this once we get some form of dbus in
> kernel.
The kernel directly loads firmware from the filesystem now, no userspace
helpers are involved, so no need for udev, libusb, etc. And as such, no
need for any "dbus" in the kernel to do this either.
> > For UART based drivers it is a little bit different since we had to
> > bring up the line discipline from userspace anyway and configure all
> > the UART parameters. For these drivers the firmware download or ROM
> > patching has been done normally via userspace since there is full
> > exclusive access before the Bluetooth subsystem knows about the
> > device.
>
> Is this something that dbus in kernel can help clean up a bit?
I don't understand how it could, please explain.
Also note, for those not knowing, we have been working on dbus in the
kernel (google "kdbus" for the github repo), but it is all
outward-facing (i.e. userspace using the kdbus code to interact with
other processes with a dbus-like protocol, not for in-kernel dbus
things, although adding it wouldn't be that hard, just really strange.
thanks,
greg k-h
^ permalink raw reply
* Re: [GIT] [3.11] NFC fixes
From: Samuel Ortiz @ 2013-07-30 23:48 UTC (permalink / raw)
To: John W. Linville; +Cc: Linux NFC, Linux Wireless
In-Reply-To: <20130730130843.GA28677@zurbaran>
Hi John,
On Tue, Jul 30, 2013 at 03:08:43PM +0200, Samuel Ortiz wrote:
> Hi John,
>
> This is the first NFC fixes pull request for 3.11.
Forget about this one, I'm going to send another pull request.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
From: Luciano Coelho @ 2013-07-30 23:04 UTC (permalink / raw)
To: Mike Turquette
Cc: linux-wireless, tony, nsekhar, mark.rutland, balbi, grant.likely,
rob.herring, devicetree-discuss, linux-doc, linux-kernel,
linux-omap, linux-arm-kernel, nm, martinez.javier
In-Reply-To: <20130730223535.5270.39864@quantum>
On Tue, 2013-07-30 at 15:35 -0700, Mike Turquette wrote:
> Quoting Luciano Coelho (2013-07-30 06:04:34)
> > +static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
> > + { .compatible = "ti,wilink-clock" },
> > +};
> > +
> > static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> > {
> > struct wl12xx_platform_data *pdata;
> > struct device_node *np = dev->of_node;
> > + struct device_node *clock_node;
> >
> > if (!np) {
> > np = of_find_matching_node(NULL, dev->driver->of_match_table);
> > @@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> > goto out_free;
> > }
> >
> > + for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
> > + of_fixed_clk_setup(clock_node);
>
> Hi Luciano,
Hi Mike,
> Any reason for establishing your own compatible string if you just plan
> to use the fixed rate clock? You could just use "fixed-clock" compatible
> in your DTS.
The reason is that I can't call of_clk_init(), because this function is
not exported and my module can't use it. I would have to link with the
clk code to be able to call it.
Also, I reckoned that, since these clock cannot be used by anyone else
than the WiLink module itself, it would make sense to have a different
compatible string.
> I will be posting patches this week which makes the fixed-rate clock a
> proper driver and matches that compatible string to instantiate those
> clocks. That means that your driver could probably remove the clock
> setup code completely.
Okay, if this is done, then I could probably use "fixed-clock" directly,
since the driver itself will take care of going through the DT and
initializing all the fixed-clocks.
--
Luca.
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-30 22:48 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Hector Palacios, linux-wireless, linux-bluetooth@vger.kernel.org,
gustavo@padovan.org, johan.hedberg@gmail.com, mcgrof,
linux-kernel@vger.kernel.org, surajs@qca.qualcomm.com, jjohnson,
Adrian Chadd, ddahlby, Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <2C94C740-76BA-4058-B0D7-C37D44875CA1@holtmann.org>
CC'ing linux-wireless as ROM patching is mentioned and in so far as
802.11 mobile is concerned this is a pretty frequent practice there
as well so figured we'd tie in the conversations.
On Tue, Jul 30, 2013 at 03:05:18PM -0700, Marcel Holtmann wrote:
> Hi Luis,
>
> >> This brings an interesting question: shouldn't the firmware download
> >> part be isolated from the USB driver? After all, I want to
> >> communicate with a UART bluetooth chip.
> >
> > There are a few BT firmware upload modules (last I checked at least 2),
> > I believe it should be possible to stuff all that code a shared
> > module or even as FreeBSD does it -- treat fw uploading in userspace,
> > however just keep in mind for quirks [0]. So patches welcomed.
>
> it really depends on what kind of patching or firmware download has to be done.
>
> For all the ROM patching via HCI commands, we explicitly added support
> for setup stage
This stage is what is I was referring to.
> and exposed a standard way of getting in front of
> Bluetooth core init sequence.
Nice.
> An example here would be the Intel
> Bluetooth devices that require ROM patching. This can be useful for
> many Bluetooth devices that are generally USB transport standard
> compliant, but need a few extra commands of vendor setup.
Interesting. I believe for 802.11 we just throw in a bunch of ROM
patching onto the 802.11 driver_firwmare.fw file and then assume
the driver can do the right thing. I however haven't worked on that so I
am curious if someone more familiar with this can provide details of
how that happens. I do know that the 802.11 mobile drivers get tons of
firmware updates because of this exact architectural choice and do
wonder how we can easily keep up with the firmware updates in meaninful
way to linux-firwmare.
How often do the ROM patches get updated? And do the HCI commands
trigger a userspace event?
> We are planning to take one extra step and split this into a
> mini-driver approach similar to what has been done for usbnet, but we
> are not there yet.
Neat. Perhaps we need something that we can share with 802.11 or other
hardare I highly doubt we're the only ones patching ROM. Don't we even
patch up core CPUs? I'm wondering if firmware_class could be expanded to
support serialized ROM patching. The biggest hurdle I see with splititng
ROM patching from a single firmware is serializing that, addressing
revision dependencies and of course kernel dependencies.
I've thrown this on the list of topics for the next wireless summit
at New Orleans.
> However the ROM patching drivers need to be in the kernel since
> otherwise they will race with the core init sequence.
Sure and depending on the architecture -- if this is kicked off to
userspace helpers or not then we may need to consider dbus in
kernel thing to help with speed / races, dependenecies / async
loading, -EPROBE_DEFER, etc.
> There are also just firmware download drivers that do nothing else
> than just loading the firmware. And here it can be done via userspace
> or kernel space. In the Bluetooth world we have seen both, but
> generally the kernel ones stayed around while the userspace ones had a
> hard time to work with udev, libusb, libusb1 etc.
Ah I see. Perhaps we can address this once we get some form of dbus in
kernel.
> For UART based drivers it is a little bit different since we had to
> bring up the line discipline from userspace anyway and configure all
> the UART parameters. For these drivers the firmware download or ROM
> patching has been done normally via userspace since there is full
> exclusive access before the Bluetooth subsystem knows about the
> device.
Is this something that dbus in kernel can help clean up a bit?
> With the newly introduced setup stage, the drivers could actually
> share the setup handling for UART and USB based devices. Not sure if
> any vendor is going for this approach.
Interesting... Is the architecture documented somewhere? Is this
upstream already?
Luis
^ permalink raw reply
* Re: [PATCH v4 6/8] wlcore: sdio: add wilink clock providers
From: Mike Turquette @ 2013-07-30 22:35 UTC (permalink / raw)
To: Luciano Coelho, linux-wireless, tony, nsekhar
Cc: coelho, luca, mark.rutland, balbi, grant.likely, rob.herring,
devicetree-discuss, linux-doc, linux-kernel, linux-omap,
linux-arm-kernel, nm, martinez.javier
In-Reply-To: <1375189476-21557-7-git-send-email-coelho@ti.com>
Quoting Luciano Coelho (2013-07-30 06:04:34)
> +static const struct of_device_id wlcore_sdio_of_clk_match_table[] = {
> + { .compatible = "ti,wilink-clock" },
> +};
> +
> static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> {
> struct wl12xx_platform_data *pdata;
> struct device_node *np = dev->of_node;
> + struct device_node *clock_node;
>
> if (!np) {
> np = of_find_matching_node(NULL, dev->driver->of_match_table);
> @@ -241,6 +247,9 @@ static struct wl12xx_platform_data *wlcore_get_pdata_from_of(struct device *dev)
> goto out_free;
> }
>
> + for_each_matching_node(clock_node, wlcore_sdio_of_clk_match_table)
> + of_fixed_clk_setup(clock_node);
Hi Luciano,
Any reason for establishing your own compatible string if you just plan
to use the fixed rate clock? You could just use "fixed-clock" compatible
in your DTS.
I will be posting patches this week which makes the fixed-rate clock a
proper driver and matches that compatible string to instantiate those
clocks. That means that your driver could probably remove the clock
setup code completely.
Regards,
Mike
> +
> goto out;
>
> out_free:
> --
> 1.8.3.2
^ permalink raw reply
* Re: [PATCH 15/30] iwlwifi: mvm: reprobe device on firmware error during restart
From: Eliad Peller @ 2013-07-30 21:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1374827327-3464-16-git-send-email-johannes@sipsolutions.net>
On Fri, Jul 26, 2013 at 11:28 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> If we get a firmware error during restart, we currently abandon any
> hope and simply fail, getting stuck until the driver is reloaded.
> Unfortunately, there isn't really much else we can do since restart
> will likely continue to fail, and asking mac80211 for disconnection
> just causes more error.
>
> To allow the user to at least set up the device again completely
> from scratch, reprobe the device and in doing so completely destroy
> any mac80211/driver state.
>
> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
[...]
> + /*
> + * get a module reference to avoid doing this while unloading
> + * anyway and to avoid scheduling a work with code that's
> + * being removed.
> + */
> + if (!try_module_get(THIS_MODULE)) {
> + IWL_ERR(mvm, "Module is being unloaded - abort\n");
> + return;
> + }
> +
> + reprobe = kzalloc(sizeof(*reprobe), GFP_ATOMIC);
> + if (!reprobe)
> + return;
missing module_put() :)
Eliad.
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 7951b4e..3845615 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -140,6 +140,16 @@
"DMic", "Digital Mic",
"Digital Mic", "Digital Mic1 Bias";
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio2 22 0>; /* gpio line 54 */
+ startup-delay-us = <70000>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -166,6 +176,7 @@
&mcbsp2_pins
&dss_hdmi_pins
&tpd12s015_pins
+ &wilink_pins
>;
uart2_pins: pinmux_uart2_pins {
@@ -295,6 +306,19 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x7c 0x3 /* gpio_54 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -420,8 +444,13 @@
};
&mmc5 {
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 4/4] arm: dts: omap4-sdp: add WiLink7 device tree node
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add appropriate device tree node for Blaze's WiLink7 module. It uses
a GPIO as interrupt, so configure the gpio2 node as interrupt parent
and assign the corresponding GPIO. Additionally, add the clock
frequencies used by the module.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 3845615..63f1af1 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -7,6 +7,7 @@
*/
/dts-v1/;
+#include <dt-bindings/interrupt-controller/irq.h>
#include "omap443x.dtsi"
#include "elpida_ecb240abacn.dtsi"
@@ -150,6 +151,26 @@
startup-delay-us = <70000>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink7";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock &tcxoclock>;
+ clock-names = "refclock tcxoclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ tcxoclock: tcxoclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+ };
};
&omap4_pmx_wkup {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 1/4] ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add regulator, pin muxing and MMC5 configuration to be used by the
on-board WiLink6 module.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..b3f6e1f 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -107,6 +107,16 @@
*/
clock-frequency = <19200000>;
};
+
+ wilink_wl_en: fixedregulator@1 {
+ compatible = "regulator-fixed";
+ regulator-name = "wilink_wl_en";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio2 11 0>; /* gpio line 43 */
+ startup-delay-us = <70000>;
+ enable-active-high;
+ };
};
&omap4_pmx_wkup {
@@ -132,6 +142,7 @@
&dss_hdmi_pins
&tpd12s015_pins
&hsusbb1_pins
+ &wilink_pins
>;
twl6030_pins: pinmux_twl6030_pins {
@@ -235,6 +246,19 @@
0x1c (PIN_OUTPUT | MUX_MODE3) /* gpio_wk8 */
>;
};
+
+ wilink_pins: pinmux_wilink_pins {
+ pinctrl-single,pins = <
+ 0x7a 0x103 /* gpio_53 INPUT | MODE3 */
+ 0x66 0x3 /* gpio_43 OUTPUT | MODE3 */
+ 0x148 0x118 /* clk INPUT PULLUP | MODE0 */
+ 0x14a 0x118 /* cmd INPUT PULLUP | MODE0 */
+ 0x14c 0x118 /* dat0 INPUT PULLUP | MODE0 */
+ 0x14e 0x118 /* dat1 INPUT PULLUP | MODE0 */
+ 0x150 0x118 /* dat2 INPUT PULLUP | MODE0 */
+ 0x152 0x118 /* dat3 INPUT PULLUP | MODE0 */
+ >;
+ };
};
&i2c1 {
@@ -314,8 +338,13 @@
};
&mmc5 {
- ti,non-removable;
+ status = "okay";
+ vmmc-supply = <&wilink_wl_en>;
bus-width = <4>;
+ cap-power-off-card;
+ keep-power-in-suspend;
+ ti,non-removable;
+ ti,needs-special-hs-handling;
};
&emif1 {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 2/4] arm: dts: omap4-panda-common: add WiLink6 device tree nodes
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
In-Reply-To: <1375218923-29876-1-git-send-email-coelho@ti.com>
Add the WiLink device tree nodes. On omap4-panda, a WiLink6 module is
connected on MMC5 and a GPIO interrupt is used. The refclock
frequency is 38.4MHz.
Signed-off-by: Luciano Coelho <coelho@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index b3f6e1f..59a797d 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -5,6 +5,7 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
+#include <dt-bindings/interrupt-controller/irq.h>
#include "elpida_ecb240abacn.dtsi"
/ {
@@ -117,6 +118,20 @@
startup-delay-us = <70000>;
enable-active-high;
};
+
+ wlan {
+ compatible = "ti,wilink6";
+ interrupt-parent = <&gpio2>;
+ interrupts = <21 IRQ_TYPE_LEVEL_HIGH>; /* gpio line 53 */
+ clocks = <&refclock>;
+ clock-names = "refclock";
+
+ refclock: refclock {
+ compatible = "ti,wilink-clock";
+ #clock-cells = <0>;
+ clock-frequency = <38400000>;
+ };
+ };
};
&omap4_pmx_wkup {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp
From: Luciano Coelho @ 2013-07-30 21:15 UTC (permalink / raw)
To: tony, linux-omap
Cc: devicetree, linux-arm-kernel, linux-wireless, coelho, luca, balbi,
laurent.pinchart
Hi,
In v2: use IRQ_TYPE_LEVEL_HIGH when defining the interrupts, as
suggested by Laurent.
These patches add the necessary DT configuration to use the WLAN part
of WiLink on OMAP4 Pandaboard and on OMAP4-SDP (including Blaze).
I've tested these changes on Panda and it works fine. But I couldn't
test the OMAP4 SDP changes properly on 3.11-rc3 because I'm having
problems with clocks and SDIO stuff. So it's pretty much just
compiled tested. I've tried this (without the new clock definition
stuff) on Blaze with 3.10 and it was working, though.
Please take a look and let me know what you think.
Luca.
Luciano Coelho (4):
ARM: dts: omap4-panda: add MMC5 (WiLink WLAN) configuration
arm: dts: omap4-panda-common: add WiLink6 device tree nodes
ARM: dts: omap4-sdp: add MMC5 (WiLink WLAN) configuration
arm: dts: omap4-sdp: add WiLink7 device tree node
arch/arm/boot/dts/omap4-panda-common.dtsi | 46 +++++++++++++++++++++++++++-
arch/arm/boot/dts/omap4-sdp.dts | 50 +++++++++++++++++++++++++++++++
2 files changed, 95 insertions(+), 1 deletion(-)
--
1.8.3.2
^ permalink raw reply
* Re: Oops in nl80211_set_reg, Linux 3.10.3
From: Johannes Berg @ 2013-07-30 20:38 UTC (permalink / raw)
To: Ben Hutchings; +Cc: linux-wireless
In-Reply-To: <1375214899.8176.4.camel@jlt4.sipsolutions.net>
On Tue, 2013-07-30 at 22:08 +0200, Johannes Berg wrote:
> I don't see a similar issue with the other code that uses
> nl80211_fam.attrbuf
That's just because I'm blind -- it *looks* correct but isn't.. patch
coming.
johannes
^ permalink raw reply
* [PATCH 3.11] nl80211: fix another nl80211_fam.attrbuf race
From: Johannes Berg @ 2013-07-30 20:38 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Hutchings, Johannes Berg
In-Reply-To: <1375211931.2664.21.camel@deadeye.wl.decadent.org.uk>
From: Johannes Berg <johannes.berg@intel.com>
This is similar to the race Linus had reported, but in this case
it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy
index in cb->args[0] as it is and thus parses the message over
and over again instead of just once because 0 is the first valid
wiphy index. Similar code in nl80211_testmode_dump() correctly
offsets the wiphy_index by 1, do that here as well.
Cc: stable@vger.kernel.org
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 25d217d..3fcba69 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -441,10 +441,12 @@ static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
goto out_unlock;
}
*rdev = wiphy_to_dev((*wdev)->wiphy);
- cb->args[0] = (*rdev)->wiphy_idx;
+ /* 0 is the first index - add 1 to parse only once */
+ cb->args[0] = (*rdev)->wiphy_idx + 1;
cb->args[1] = (*wdev)->identifier;
} else {
- struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0]);
+ /* subtract the 1 again here */
+ struct wiphy *wiphy = wiphy_idx_to_wiphy(cb->args[0] - 1);
struct wireless_dev *tmp;
if (!wiphy) {
--
1.8.0
^ 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