* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Mark Brown @ 2013-10-28 19:23 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Alexander Shiyan, Luciano Coelho, Mark Rutland, devicetree,
Russell King, Pawel Moll, Ian Campbell, Tony Lindgren,
Greg Kroah-Hartman, Stephen Warren, linux-doc, John W. Linville,
Rob Herring, linux-kernel@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CANOLnONKcC1i19ypb4rh2Rff3WsVhhuUhNvZvYwDV2-ZNtjVxQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]
On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote:
> When wl12xx family of chips is connected through SDIO, we already have
> that pin set up as a regulator controlled with the help of mmc
> subsystem. When time comes to communicate with the chip, mmc subsystem
> sees this as yet another SD card and looks for associated regulator
> for it, and the board file has that set up as a fixed regulator
> controlling that pin (see pandora_vmmc3 in
> arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
> first SDIO communications are over, pm_runtime calls are used in
> drivers/net/wireless/ti/wl1251/sdio.c .
Is this actually controlling VMMC though, or is it some other control?
If it's not controlling VMMC then it shouldn't say that it is.
> I don't know if something similar can be done done in SPI case, but
> I'm sure this is not the first your-so-called regulator misuse.
It's not the first but that doesn't make controlling something other
than a regulator through the regulator API any less broken.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: iwlegacy (4965) - what would 0x8000 as the completed TX rate indicate?
From: Adrian Chadd @ 2013-10-28 19:24 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1382968966.17956.15.camel@jlt4.sipsolutions.net>
Hi!
On 28 October 2013 07:02, Johannes Berg <johannes@sipsolutions.net> wrote:
[snip]
>> The status indicates things are transmitting and completing fine.
>>
>> So, any ideas what that 0x8000 rate in the rate completion means?
>
> I think that just means it used the other antenna and rate 0, since the
> bits 0x1c000 contain the antenna bitmap that was used (up to three can
> be used for each transmission)
Well, what's rate=0 mean?
And 0x8000 is bit 11 set, which is HT40. I definitely don't have HT40 enabled.
-a
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Krishna Chaitanya @ 2013-10-28 19:27 UTC (permalink / raw)
To: Felipe Contreras
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CAMP44s0087jYz5AiEaEzwt7GqH9ed8PWE1CmvMPr4Dqn3yE6rA@mail.gmail.com>
On Tue, Oct 29, 2013 at 12:13 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 12:28 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> On Mon, Oct 28, 2013 at 11:30 PM, Felipe Contreras
>> <felipe.contreras@gmail.com> wrote:
>>
>>> The authentication response does come back in both cases though, it's
>>> just the acknowledgement that is missing. Unfortunately I cannot
>>> figure out for which message it's the ack.
>>>
>>> Also, I notice the sequence number received from the router doesn't
>>> seem to change. All the authentication requests received have the same
>>> number (256). Another peculiar thing is that in the failed case the SN
>>> we send starts with 0.
>>>
>>> I suppose since the authentication ack never arrives, the next steps
>>> are never completed.
>>>
>>> Does that help?
>> From the supplicant logs we have successfully received the
>> authentication response
>> and sent out the association request. So are you referring to not receiving ACK
>> for association request??
>
> No, from the capture there's no association request in the bad case,
> only in the good one.
>
>> It would be nice to get the capture without any filters?
>
> http://people.freedesktop.org/~felipec/wpa/wpa-bad.pcapng
> http://people.freedesktop.org/~felipec/wpa/wpa-good.pcapng
>
>From the logs we can see that we have received authentication response,
so the association request is getting dropped somewhere? We might
need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
Another side porint? Also all the beacons from that AP are malformed
but probe responses are fine, weird??
^ permalink raw reply
* Re: [PATCH 4/4] wl1251: spi: add device tree support
From: Kumar Gala @ 2013-10-28 19:30 UTC (permalink / raw)
To: Grazvydas Ignotas
Cc: Sebastian Reichel, Mark Rutland, linux-doc, Tony Lindgren,
Russell King, Sachin Kamat, Ian Campbell, Sebastian Reichel,
Luciano Coelho, devicetree, Pawel Moll, Stephen Warren,
John W. Linville, Rob Herring, Bill Pemberton,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
Greg Kroah-Hartman, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, Felipe Balbi, Rob Landley, netdev
In-Reply-To: <CANOLnOP=antQDwQLxWhuB8+-kZh9x-JJXrXmOz3FH67fM2Lang@mail.gmail.com>
On Oct 28, 2013, at 12:15 PM, Grazvydas Ignotas wrote:
> On Mon, Oct 28, 2013 at 8:37 AM, Kumar Gala <galak@codeaurora.org> wrote:
>> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
>>> +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
>>> @@ -0,0 +1,36 @@
>>> +* Texas Instruments wl1251 controller
>>> +
>>> +The wl1251 chip can be connected via SPI or via SDIO. The linux
>>> +kernel currently only supports device tree for the SPI variant.
>>> +
>>
>> From the binding I have no idea what this chip actually does, also we don't normally reference linux kernel support in bindings specs (so please remove it).
>>
>> However, what would expect the SDIO binding to look like? Or more specifically, how would you distinguish the SPI vs SDIO binding/connection? I'm wondering if the compatible should be something like "ti,wl1251-spi" and than the sdio can be "ti,wl1251-sdio"
>
> When connected to SDIO, it doesn't act as standard SDIO device and
> can't be probed (standard SDIO registers missing), so information has
> to come some other way. That used to partially come through
> platform_data and partially through a callback from mmc subsystem (see
> pandora_wl1251_init_card() in
> arch/arm/mach-omap2/board-omap3pandora.c). I don't know much about DT,
> but maybe the information that comes from SDIO registers on "normal"
> SDIO devices should come through DT in this case too? I don't really
> know how that should be integrated with mmc subsystem though..
Ok, my point is still valid that we can use a different compatible for the SDIO case even if its no standard SDIO vs the SPI case.
>
>>> +Required properties:
>>> +- compatible : Should be "ti,wl1251"
>>
>> reg is not listed as a required prop.
>>
>>> +- interrupts : Should contain interrupt line
>>> +- interrupt-parent : Should be the phandle for the interrupt
>>> + controller that services interrupts for this device
>>> +- vio-supply : phandle to regulator providing VIO
>>> +- power-gpio : GPIO connected to chip's PMEN pin
>>
>> should be vendor prefixed: ti,power-gpio
>>
>>> +- For additional required properties on SPI, please consult
>>> + Documentation/devicetree/bindings/spi/spi-bus.txt
>>> +
>>> +Optional properties:
>>> +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>>
>> can you be a bit more specific on what cfg will be loaded. Also, is this property a boolean, if so how do I know which eeprom the cfg is loaded from (is it one that is directly connected to the wl1251?
>
> wl1251 is a wifi chip that can have an optional eeprom connected to it
> to store things like calibration stuff and MAC address, and that
> eeprom is usually inside a single module with some additional radio
> related chips. If the eeprom is connected (like the module on pandora
> board has), the driver can issue command to the firmware running on
> chip to load that data on it's startup, alternatively the driver can
> load calibration from other storage (like it happens on N900).
So sounds like a boolean. I think just adding that its a boolean and maybe something like "configuration (calibration data, MAC addr, etc..)"
- k
>
>
> Gražvydas
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 20:06 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CABPxzYLwwyFCFw1pEt0v9Xw4kcue1C_RZx0RbTbMrUw=+MWvgQ@mail.gmail.com>
On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Tue, Oct 29, 2013 at 12:13 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Oct 28, 2013 at 12:28 PM, Krishna Chaitanya
>> <chaitanya.mgit@gmail.com> wrote:
>>> On Mon, Oct 28, 2013 at 11:30 PM, Felipe Contreras
>>> <felipe.contreras@gmail.com> wrote:
>>>
>>>> The authentication response does come back in both cases though, it's
>>>> just the acknowledgement that is missing. Unfortunately I cannot
>>>> figure out for which message it's the ack.
>>>>
>>>> Also, I notice the sequence number received from the router doesn't
>>>> seem to change. All the authentication requests received have the same
>>>> number (256). Another peculiar thing is that in the failed case the SN
>>>> we send starts with 0.
>>>>
>>>> I suppose since the authentication ack never arrives, the next steps
>>>> are never completed.
>>>>
>>>> Does that help?
>>> From the supplicant logs we have successfully received the
>>> authentication response
>>> and sent out the association request. So are you referring to not receiving ACK
>>> for association request??
>>
>> No, from the capture there's no association request in the bad case,
>> only in the good one.
>>
>>> It would be nice to get the capture without any filters?
>>
>> http://people.freedesktop.org/~felipec/wpa/wpa-bad.pcapng
>> http://people.freedesktop.org/~felipec/wpa/wpa-good.pcapng
>>
>
> From the logs we can see that we have received authentication response,
> so the association request is getting dropped somewhere? We might
> need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
>
> http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
There you go:
http://people.freedesktop.org/~felipec/wpa/trace.dat.xz
--
Felipe Contreras
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 20:37 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CABPxzYLwwyFCFw1pEt0v9Xw4kcue1C_RZx0RbTbMrUw=+MWvgQ@mail.gmail.com>
On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> Another side porint? Also all the beacons from that AP are malformed
> but probe responses are fine, weird??
Also, here's a message I get some times. I don't think it's related to
the issue at hands, but who knows:
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: fail to flush all
tx fifo queues Q 11
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Current SW read_ptr
137 write_ptr 154
Oct 28 14:28:47 nysa kernel: iwl data: 00000000: 00 fe ff 01 00 00 00
00 00 00 00 00 00 00 00 00 ................
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(0) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(1) = 0xc010b098
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(2) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(3) = 0x803000e3
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(4) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(5) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(6) = 0x00000000
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: FH TRBs(7) = 0x00709041
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 0 is active and
mapped to fifo 3 ra_tid 0x0000 [228,228]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 1 is active and
mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 2 is active and
mapped to fifo 1 ra_tid 0x0000 [105,105]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 3 is active and
mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 4 is active and
mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 5 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 6 is active and
mapped to fifo 2 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 7 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 8 is active and
mapped to fifo 4 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 9 is active and
mapped to fifo 7 ra_tid 0x0000 [66,66]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 10 is active and
mapped to fifo 5 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 11 is active and
mapped to fifo 1 ra_tid 0x0000 [137,154]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 12 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 13 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 14 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 15 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 16 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 17 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 18 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
Oct 28 14:28:47 nysa kernel: iwlwifi 0000:02:00.0: Q 19 is inactive
and mapped to fifo 0 ra_tid 0x0000 [0,0]
--
Felipe Contreras
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Krishna Chaitanya @ 2013-10-28 20:44 UTC (permalink / raw)
To: Felipe Contreras
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CAMP44s0svc2MRKCrZXS5ZYRZNPoomQkcKHdC2m2BGy7di+TCyA@mail.gmail.com>
On Tue, Oct 29, 2013 at 1:36 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
> <chaitanya.mgit@gmail.com> wrote:
>> From the logs we can see that we have received authentication response,
>> so the association request is getting dropped somewhere? We might
>> need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
>>
>> http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
>
> There you go:
> http://people.freedesktop.org/~felipec/wpa/trace.dat.xz
>
Hmm.."trace-cmd report -i trace.dat" returned lots of errors, i have even
tried with the trace-cmd from git (ubuntu). Did it worked fro you?
===
# trace-cmd report -i trace.dat
version = 6
trace-cmd: No such file or directory ??????????????
function scsi_trace_parse_cdb not defined
function scsi_trace_parse_cdb not defined
function scsi_trace_parse_cdb not defined
function scsi_trace_parse_cdb not defined
function is_writable_pte not defined
function __le16_to_cpup not defined
function __le16_to_cpup not defined
function __le16_to_cpup not defined
CPU 0 is empty
CPU 1 is empty
CPU 2 is empty
CPU 3 is empty
cpus=4
--
Thanks,
Regards,
Chaitanya T K.
Mobile:+91-9963910010.
^ permalink raw reply
* Re: [PATCH] cfg80211/nl80211: Add support to report unsafe frequency ranges(s)
From: Jeffrey Johnson @ 2013-10-28 21:11 UTC (permalink / raw)
To: Dan Williams
Cc: Chauhan, Rajesh, Rodriguez, Luis, Johannes Berg,
linux-wireless@vger.kernel.org, Malinen, Jouni, Bahini, Henri,
Chang, Leo, Luo, Xun
In-Reply-To: <1382986906.7298.10.camel@dcbw.foobar.com>
On 10/28/2013 12:01 PM, Dan Williams wrote:
> On Mon, 2013-10-28 at 18:08 +0000, Chauhan, Rajesh wrote:
>> Hi Luis,
>>
>> For "enough information for proper usage" - how about if I add an attribute for the source of interference (say, for example, "cellular") for each of those frequency range?
> When you say "cellular" here, do mean a WWAN card in the same machine,
> sharing the antenna (or using a very very nearby antenna) with the WiFi
> card? Or do you mean a close-by phone, or a tower itself? How is this
> different from BT coexistence or WiMAX coexistence?
>
One use case would be a colocated WWAN card sharing an antenna or using
a very very nearby antenna. There could be other use cases. I would say
this is complimentary to coexistence. The idea is to tell userspace
which frequencies have know sources of interference so that they can be
avoided, and hence coexistence would not be required. If userspace
chooses to use an "unsafe" frequency, the the driver's coexistence logic
would then be utilized, but the user experience could suffer compared to
if a "safe" frequency had been selected.
The issue that has been debated internally is whether or not userspace
needs to know the source of the interference. In other words, if we
have an enumerated set of interference sources, would userspace behave
differently based upon the source?
This is, after all, just meant to be a hint to userspace to give it more
information to use when selected a channel to be used in a master mode
of operation.
^ permalink raw reply
* Linksys AE3000 iw tool issues
From: Richard Wang @ 2013-10-28 21:28 UTC (permalink / raw)
To: linux-wireless
Hi,
I currently have a Linksys AE3000 Wifi USB dongle, which has the
RalinkRT3573 chipset.
I am able currently able to connect to surrounding APs by installing
Ralink proprietary drivers as outlined here
(http://geekniggle.blogspot.com/2012/07/cisco-linksys-ae3000-wifi-usb-dongle.html).
Ifconfig and iwconfig both recognize the device using the interface ra0.
Unfortunately, the "iw" tool is having some issues. One machine running
Lucid Ubuntu 10.04 with the following command "iw dev ra0 info" returns
"command failed: No such device (-19)". Another machine machine with
xubuntu on command "iw list" returns "nl80211 not found."
From what I have read so far, it appears that the current driver may
not support iw operations. As a result, I looked into installing
rt2800usb driver that a few other threads appear to have working
successfully. As stated on wikidevi
(http://wikidevi.com/wiki/Linksys_AE3000), one of the more recent
patches appears to support the RT3573 chipset. I tried to install the
latest developmental release. After rebooting and loading the rt2800usb
driver, "modprobe rt2800usb", I get dmesg errors like "rt2x00lib:
disagrees about version of... ieee80211....".
Any suggestions to get the "iw" tool working would be much appreciated.
Thanks!
^ permalink raw reply
* Re: [OPW kernel] [Patch v3 1/3] net: wireless: replace printk with pr_warn in adm8211.c
From: Greg KH @ 2013-10-28 21:30 UTC (permalink / raw)
To: Georgiana Rodica Chelu; +Cc: opw-kernel, linux-wireless
In-Reply-To: <20131026192053.GA10494@fireworks>
On Sat, Oct 26, 2013 at 10:20:53PM +0300, Georgiana Rodica Chelu wrote:
> WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then pr_warn(...
> to printk(KERN_WARNING ...
>
> Signed-off-by: Georgiana Rodica Chelu <georgiana.chelu93@gmail.com>
> ---
> drivers/net/wireless/adm8211.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Like Sarah said, we can't take these as they are not against the staging
tree.
And even if they were:
> diff --git a/drivers/net/wireless/adm8211.c b/drivers/net/wireless/adm8211.c
> index f9a24e5..e36d54d 100644
> --- a/drivers/net/wireless/adm8211.c
> +++ b/drivers/net/wireless/adm8211.c
> @@ -151,7 +151,7 @@ static int adm8211_read_eeprom(struct ieee80211_hw *dev)
> else
> priv->rf_type = ADM8211_TYPE_AIROHA;
>
> - printk(KERN_WARNING "%s (adm8211): Unknown RFtype %d\n",
> + pr_warn("%s (adm8211): Unknown RFtype %d\n",
You didn't read the message that sparse was telling you, why didn't you
convert this to netdev_warn() instead?
thanks,
greg k-h
^ permalink raw reply
* Re: I always need a miracle to connect with iwlwifi
From: Felipe Contreras @ 2013-10-28 21:32 UTC (permalink / raw)
To: Krishna Chaitanya
Cc: Oleksij Rempel, ilw, hostap@lists.shmoo.com,
linux-wireless Mailing List
In-Reply-To: <CABPxzYL-Gzbzoc_ui+qUQ6uzoKp=Yq7yLWZvc7PoEjiH3dFczg@mail.gmail.com>
On Mon, Oct 28, 2013 at 2:44 PM, Krishna Chaitanya
<chaitanya.mgit@gmail.com> wrote:
> On Tue, Oct 29, 2013 at 1:36 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> On Mon, Oct 28, 2013 at 1:27 PM, Krishna Chaitanya
>> <chaitanya.mgit@gmail.com> wrote:
>
>>> From the logs we can see that we have received authentication response,
>>> so the association request is getting dropped somewhere? We might
>>> need the mac80211 and iwlwifi trace-cmd logs to check for the drop.
>>>
>>> http://wireless.kernel.org/en/developers/Documentation/mac80211/tracing
>>
>> There you go:
>> http://people.freedesktop.org/~felipec/wpa/trace.dat.xz
>>
> Hmm.."trace-cmd report -i trace.dat" returned lots of errors, i have even
> tried with the trace-cmd from git (ubuntu). Did it worked fro you?
Yes, but maybe I overrode the file. I've pushed a new one again. The
sha-1 is 36c260d8d8c171a24eb1aa7b2ea736b06c9b55b7.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 4/4] wl1251: spi: add device tree support
From: Tomasz Figa @ 2013-10-28 22:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Kumar Gala, Sebastian Reichel, Mark Rutland, linux-doc,
Tony Lindgren, Russell King, Sachin Kamat, Ian Campbell,
Sebastian Reichel, Luciano Coelho, devicetree, Pawel Moll,
Stephen Warren, John W. Linville, Rob Herring, Bill Pemberton,
linux-omap, Greg Kroah-Hartman, linux-wireless, linux-kernel,
Felipe Balbi, Rob Landley, netdev
In-Reply-To: <FF34C626-4A49-43B1-B0AD-DC6146ABBB11@codeaurora.org>
On Monday 28 of October 2013 01:37:34 Kumar Gala wrote:
> On Oct 27, 2013, at 11:14 AM, Sebastian Reichel wrote:
> > Add device tree support for the spi variant of wl1251
> > and document the binding.
> >
> > Signed-off-by: Sebastian Reichel <sre@debian.org>
> > ---
> > .../devicetree/bindings/net/wireless/ti,wl1251.txt | 36
> > ++++++++++++++++++++++ drivers/net/wireless/ti/wl1251/spi.c
> > | 23 ++++++++++---- 2 files changed, 53 insertions(+), 6
> > deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt new
> > file mode 100644
> > index 0000000..5f8a154
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
> > @@ -0,0 +1,36 @@
> > +* Texas Instruments wl1251 controller
> > +
> > +The wl1251 chip can be connected via SPI or via SDIO. The linux
> > +kernel currently only supports device tree for the SPI variant.
> > +
>
> From the binding I have no idea what this chip actually does, also we
> don't normally reference linux kernel support in bindings specs (so
> please remove it).
>
> However, what would expect the SDIO binding to look like? Or more
> specifically, how would you distinguish the SPI vs SDIO
> binding/connection? I'm wondering if the compatible should be
> something like "ti,wl1251-spi" and than the sdio can be
> "ti,wl1251-sdio"
Well, you can easily distinguish an SDIO device from an SPI device by its
parent node, but...
The binding for SDIO might require different set of properties (other than
ones inherited from generic SDIO or SPI bindings) than one for SPI. So
probably different compatible values might be justified.
Did we already have such case before? (maybe some I2C + SPI devices?)
> > +Required properties:
> > +- compatible : Should be "ti,wl1251"
>
> reg is not listed as a required prop.
It is implied by SPI bindings, but it might be a good idea to have this
stated here as well.
>
> > +- interrupts : Should contain interrupt line
> > +- interrupt-parent : Should be the phandle for the interrupt
> > + controller that services interrupts for this device
> > +- vio-supply : phandle to regulator providing VIO
> > +- power-gpio : GPIO connected to chip's PMEN pin
>
> should be vendor prefixed: ti,power-gpio
Hmm, out of curiosity, is it a rule for this kind of properties? I can see
both cases with and without prefixes when grepping for "-gpios" in
Documentation/devicetree/bindings. We should really have such things
written down somewhere.
>
> > +- For additional required properties on SPI, please consult
> > + Documentation/devicetree/bindings/spi/spi-bus.txt
> > +
> > +Optional properties:
> > +- ti,use-eeprom : If found, configuration will be loaded from eeprom.
>
> can you be a bit more specific on what cfg will be loaded. Also, is
> this property a boolean, if so how do I know which eeprom the cfg is
> loaded from (is it one that is directly connected to the wl1251?
Maybe one from ti,has-eeprom or ti,config-eeprom would be better name for
this property?
Best regards,
Tomasz
^ permalink raw reply
* Re: Linksys AE3000 iw tool issues
From: Dan Williams @ 2013-10-28 23:19 UTC (permalink / raw)
To: Richard Wang; +Cc: linux-wireless
In-Reply-To: <526ED703.6020901@andrew.cmu.edu>
On Mon, 2013-10-28 at 17:28 -0400, Richard Wang wrote:
> Hi,
>
> I currently have a Linksys AE3000 Wifi USB dongle, which has the
> RalinkRT3573 chipset.
>
> I am able currently able to connect to surrounding APs by installing
> Ralink proprietary drivers as outlined here
> (http://geekniggle.blogspot.com/2012/07/cisco-linksys-ae3000-wifi-usb-dongle.html).
> Ifconfig and iwconfig both recognize the device using the interface ra0.
> Unfortunately, the "iw" tool is having some issues. One machine running
> Lucid Ubuntu 10.04 with the following command "iw dev ra0 info" returns
> "command failed: No such device (-19)". Another machine machine with
> xubuntu on command "iw list" returns "nl80211 not found."
The proprietary ralink drivers do not appear to support the kernel's
nl80211 API. In the first case (no such device) that's what is
happening. IN the second case (nl80211 not found) the nl80211 module is
either not compiled into the kernel, or is not loaded. And since the
wifi driver doesn't use nl80211, that's probably why it's not loaded.
> From what I have read so far, it appears that the current driver may
> not support iw operations. As a result, I looked into installing
Correct, that proprietary driver does not use nl80211.
> rt2800usb driver that a few other threads appear to have working
> successfully. As stated on wikidevi
> (http://wikidevi.com/wiki/Linksys_AE3000), one of the more recent
> patches appears to support the RT3573 chipset. I tried to install the
> latest developmental release. After rebooting and loading the rt2800usb
> driver, "modprobe rt2800usb", I get dmesg errors like "rt2x00lib:
> disagrees about version of... ieee80211....".
>
> Any suggestions to get the "iw" tool working would be much appreciated.
Getting "iw" working would basically involve adding RT3573 support to
rt2800usb, so you're really asking "how can we get RT3573 chips properly
supported in Linux?". If that's done, "iw" comes for free.
Dan
^ permalink raw reply
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Sebastian Reichel @ 2013-10-28 23:26 UTC (permalink / raw)
To: Mark Brown
Cc: Grazvydas Ignotas, Alexander Shiyan, Luciano Coelho, Mark Rutland,
devicetree, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren,
Greg Kroah-Hartman, Stephen Warren, linux-doc, John W. Linville,
Rob Herring, linux-kernel@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20131028192354.GA18208@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1516 bytes --]
Hi,
On Mon, Oct 28, 2013 at 12:23:54PM -0700, Mark Brown wrote:
> On Mon, Oct 28, 2013 at 07:29:52PM +0200, Grazvydas Ignotas wrote:
>
> > When wl12xx family of chips is connected through SDIO, we already have
> > that pin set up as a regulator controlled with the help of mmc
> > subsystem. When time comes to communicate with the chip, mmc subsystem
> > sees this as yet another SD card and looks for associated regulator
> > for it, and the board file has that set up as a fixed regulator
> > controlling that pin (see pandora_vmmc3 in
> > arch/arm/mach-omap2/board-omap3pandora.c). To prevent poweroff after
> > first SDIO communications are over, pm_runtime calls are used in
> > drivers/net/wireless/ti/wl1251/sdio.c .
>
> Is this actually controlling VMMC though, or is it some other control?
> If it's not controlling VMMC then it shouldn't say that it is.
>
> > I don't know if something similar can be done done in SPI case, but
> > I'm sure this is not the first your-so-called regulator misuse.
>
> It's not the first but that doesn't make controlling something other
> than a regulator through the regulator API any less broken.
I gave it a second try to find out details for this pin:
1. The pin is named PMEN in the Nokia N900 schematics
2. PMEN is described as "Power management enable - system shutdown"
in a crippled datasheet of the wl1253, which I found in the internet.
I don't think this is supposed to be handled by the regulator API.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
From: Larry Finger @ 2013-10-28 23:28 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Mark Cave-Ayland, netdev, Larry Finger, Stable
From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
All of the rtlwifi drivers have an error in the routine that tests if
the received data is "special". The 16-bit quantity is big-endian, but
was being extracted in native CPU mode. One of the effects of this bug
is to inhibit association under some conditions.
A statement that would have made the code correct had been changed to
a comment. Rather than just reinstating that code, the fix here passes
sparse tests.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Stable <stable@vger.kernel.org> [2.6.38+]
---
drivers/net/wireless/rtlwifi/base.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
index 9a78e3d..1efde7f 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
SNAP_SIZE + PROTOC_TYPE_SIZE);
- ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
- /* ether_type = ntohs(ether_type); */
+ ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
+ SNAP_SIZE));
if (ETH_P_IP == ether_type) {
if (IPPROTO_UDP == ip->protocol) {
--
1.8.4
^ permalink raw reply related
* Re: [PATCH 03/16] wl1251: add sysfs interface for bluetooth coexistence mode configuration
From: Ben Hutchings @ 2013-10-28 23:39 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen, David Gnedt
In-Reply-To: <1382819655-30430-4-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> From: David Gnedt <david.gnedt@davizone.at>
>
> Port the bt_coex_mode sysfs interface from wl1251 driver version included
> in the Maemo Fremantle kernel to allow bt-coexistence mode configuration.
> This enables userspace applications to set one of the modes
> WL1251_BT_COEX_OFF, WL1251_BT_COEX_ENABLE and WL1251_BT_COEX_MONOAUDIO.
> The default mode is WL1251_BT_COEX_OFF.
> It should be noted that this driver always enabled bt-coexistence before
> and enabled bt-coexistence directly affects the receiving performance,
> rendering it unusable in some low-signal situations. Especially monitor
> mode is affected very badly with bt-coexistence enabled.
[...]
This should be implemented consistently with other drivers:
drivers/net/wireless/ath/ath9k/htc_drv_init.c:module_param_named(btcoex_enable, ath9k_htc_btcoex_enable, int, 0444);
drivers/net/wireless/ath/ath9k/init.c:module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
drivers/net/wireless/b43/main.c:module_param_named(btcoex, modparam_btcoex, int, 0444);
drivers/net/wireless/ipw2x00/ipw2200.c:module_param(bt_coexist, int, 0444);
drivers/net/wireless/iwlegacy/common.c:module_param(bt_coex_active, bool, S_IRUGO);
drivers/net/wireless/iwlwifi/iwl-drv.c:module_param_named(bt_coex_active, iwlwifi_mod_params.bt_coex_active,
drivers/net/wireless/ti/wlcore/sysfs.c:static DEVICE_ATTR(bt_coex_state, S_IRUGO | S_IWUSR,
Oh, hmm, I see a problem here.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Linksys AE3000 iw tool issues
From: Richard Wang @ 2013-10-28 23:48 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless
In-Reply-To: <1383002394.28991.18.camel@dcbw.foobar.com>
On 10/28/2013 7:19 PM, Dan Williams wrote:
> On Mon, 2013-10-28 at 17:28 -0400, Richard Wang wrote:
>> Hi,
>>
>> I currently have a Linksys AE3000 Wifi USB dongle, which has the
>> RalinkRT3573 chipset.
>>
>> I am able currently able to connect to surrounding APs by installing
>> Ralink proprietary drivers as outlined here
>> (http://geekniggle.blogspot.com/2012/07/cisco-linksys-ae3000-wifi-usb-dongle.html).
>> Ifconfig and iwconfig both recognize the device using the interface ra0.
>> Unfortunately, the "iw" tool is having some issues. One machine running
>> Lucid Ubuntu 10.04 with the following command "iw dev ra0 info" returns
>> "command failed: No such device (-19)". Another machine machine with
>> xubuntu on command "iw list" returns "nl80211 not found."
> The proprietary ralink drivers do not appear to support the kernel's
> nl80211 API. In the first case (no such device) that's what is
> happening. IN the second case (nl80211 not found) the nl80211 module is
> either not compiled into the kernel, or is not loaded. And since the
> wifi driver doesn't use nl80211, that's probably why it's not loaded.
>
>> From what I have read so far, it appears that the current driver may
>> not support iw operations. As a result, I looked into installing
> Correct, that proprietary driver does not use nl80211.
>
>> rt2800usb driver that a few other threads appear to have working
>> successfully. As stated on wikidevi
>> (http://wikidevi.com/wiki/Linksys_AE3000), one of the more recent
>> patches appears to support the RT3573 chipset. I tried to install the
>> latest developmental release. After rebooting and loading the rt2800usb
>> driver, "modprobe rt2800usb", I get dmesg errors like "rt2x00lib:
>> disagrees about version of... ieee80211....".
>>
>> Any suggestions to get the "iw" tool working would be much appreciated.
> Getting "iw" working would basically involve adding RT3573 support to
> rt2800usb, so you're really asking "how can we get RT3573 chips properly
> supported in Linux?". If that's done, "iw" comes for free.
>
> Dan
>
Hi Dan,
Thanks for the response and that's exactly my question stated much more
succinctly. Based on other threads, it appeared as if there might be
support for rt2800usb for rt3573 chips in experimental versions
(http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/2013-July/006283.html).
I tried to install the latest development version of backports hoping
that this patch would be part of it but it didn't seem to work. I'm
hoping to see if anyone happens to have a working patch for rt3573 chips.
RIchard
^ permalink raw reply
* Re: [PATCH 16/16] wl1251: Add sysfs file address for setting permanent mac address
From: Ben Hutchings @ 2013-10-28 23:50 UTC (permalink / raw)
To: Pali Rohár
Cc: Luciano Coelho, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen
In-Reply-To: <1382819655-30430-17-git-send-email-pali.rohar@gmail.com>
On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> Driver wl1251 generating mac address randomly at startup and there is no way to
> set permanent mac address via SET_IEEE80211_PERM_ADDR. This patch export sysfs
> file which can set permanent mac address by userspace helper program. Patch is
> needed for devices which do not store mac address in internal wl1251 eeprom.
[...]
This belongs in struct wl12xx_platform_data or (better) Device Tree
properties. It definitely should not be settable once the device is
registered.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH NEXT] rtlwifi: Fix endian error in extracting packet type
From: Ben Hutchings @ 2013-10-29 0:07 UTC (permalink / raw)
To: Larry Finger; +Cc: linville, linux-wireless, Mark Cave-Ayland, netdev, Stable
In-Reply-To: <1383002903-8746-1-git-send-email-Larry.Finger@lwfinger.net>
On Mon, 2013-10-28 at 18:28 -0500, Larry Finger wrote:
> From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
>
> All of the rtlwifi drivers have an error in the routine that tests if
> the received data is "special". The 16-bit quantity is big-endian, but
> was being extracted in native CPU mode. One of the effects of this bug
> is to inhibit association under some conditions.
>
> A statement that would have made the code correct had been changed to
> a comment. Rather than just reinstating that code, the fix here passes
> sparse tests.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> Cc: Stable <stable@vger.kernel.org> [2.6.38+]
> ---
> drivers/net/wireless/rtlwifi/base.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> diff --git a/drivers/net/wireless/rtlwifi/base.c b/drivers/net/wireless/rtlwifi/base.c
> index 9a78e3d..1efde7f 100644
> --- a/drivers/net/wireless/rtlwifi/base.c
> +++ b/drivers/net/wireless/rtlwifi/base.c
> @@ -1077,8 +1077,8 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx)
>
> ip = (struct iphdr *)((u8 *) skb->data + mac_hdr_len +
> SNAP_SIZE + PROTOC_TYPE_SIZE);
> - ether_type = *(u16 *) ((u8 *) skb->data + mac_hdr_len + SNAP_SIZE);
> - /* ether_type = ntohs(ether_type); */
> + ether_type = be16_to_cpu(*(__be16 *)((u8 *)skb->data + mac_hdr_len +
> + SNAP_SIZE));
>
> if (ETH_P_IP == ether_type) {
> if (IPPROTO_UDP == ip->protocol) {
This crazy function also says that *all* IPv6 frames are special, which
apparently means that on TX they should get sent at the lowest possible
bit rate. So I think this is going to cause a regression for IPv6
throughput unless you remove that case.
The DHCP case is also not validating IP and UDP header lengths against
the packet length, though this may be harmless in practice.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 2/4] wl1251: move power GPIO handling into the driver
From: Mark Brown @ 2013-10-29 1:33 UTC (permalink / raw)
To: Grazvydas Ignotas, Alexander Shiyan, Luciano Coelho, Mark Rutland,
devicetree, Russell King, Pawel Moll, Ian Campbell, Tony Lindgren,
Greg Kroah-Hartman, Stephen Warren, linux-doc, John W. Linville,
Rob Herring, linux-kernel@vger.kernel.org, Sachin Kamat,
Bill Pemberton, Felipe Balbi, Rob Landley, netdev,
linux-wireless@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20131028232624.GA950@earth.universe>
[-- Attachment #1: Type: text/plain, Size: 429 bytes --]
On Tue, Oct 29, 2013 at 12:26:26AM +0100, Sebastian Reichel wrote:
> 1. The pin is named PMEN in the Nokia N900 schematics
> 2. PMEN is described as "Power management enable - system shutdown"
> in a crippled datasheet of the wl1253, which I found in the internet.
> I don't think this is supposed to be handled by the regulator API.
I agree, this sounds like a GPIO that the driver should be understanding
directly to me.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH] cfg80211: allow beaconing after CAC
From: Janusz Dziedzic @ 2013-10-29 6:15 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, Janusz Dziedzic
After going throught the Channel Availability Check (CAC)
required by DFS enable beaconing. Channels that have gone
through a CAC will be in the NL80211_DFS_AVAILABLE.
Without this change APs don't start beaconing after
successful CAC.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
---
One flag could be used in the future IEEE80211_CHAN_NO_IR.
net/wireless/chan.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index a6f5c4c..205acf2 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -432,6 +432,7 @@ static bool cfg80211_secondary_chans_ok(struct wiphy *wiphy,
{
struct ieee80211_channel *c;
u32 freq, start_freq, end_freq;
+ u32 ignore_flags;
start_freq = cfg80211_get_start_freq(center_freq, bandwidth);
end_freq = cfg80211_get_end_freq(center_freq, bandwidth);
@@ -441,13 +442,24 @@ static bool cfg80211_secondary_chans_ok(struct wiphy *wiphy,
if (!c)
return false;
+ ignore_flags = IEEE80211_CHAN_RADAR;
+
/* check for radar flags */
- if ((prohibited_flags & c->flags & IEEE80211_CHAN_RADAR) &&
- (c->dfs_state != NL80211_DFS_AVAILABLE))
- return false;
+ if (prohibited_flags & c->flags & IEEE80211_CHAN_RADAR) {
+ if (c->dfs_state != NL80211_DFS_AVAILABLE)
+ return false;
+ /*
+ * If DFS is required we should check only
+ * c->dfs_state == NL80211_DFS_AVAILABLE and
+ * ignore IEEE80211_CHAN_NO_IBSS and
+ * IEEE80211_CHAN_PASSIVE_SCAN flags
+ */
+ ignore_flags |= IEEE80211_CHAN_NO_IBSS |
+ IEEE80211_CHAN_PASSIVE_SCAN;
+ }
/* check for the other flags */
- if (c->flags & prohibited_flags & ~IEEE80211_CHAN_RADAR)
+ if (c->flags & prohibited_flags & ~ignore_flags)
return false;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH] ath9k: Add SERDES initvals for AR9462 2.1
From: Sujith Manoharan @ 2013-10-29 6:12 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 4 ++++
drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h | 7 +++++++
2 files changed, 11 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_hw.c b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
index b07f164..a6e06a1 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
@@ -223,6 +223,10 @@ static void ar9003_hw_init_mode_regs(struct ath_hw *ah)
ar9462_2p1_modes_fast_clock);
INIT_INI_ARRAY(&ah->iniCckfirJapan2484,
ar9462_2p1_baseband_core_txfir_coeff_japan_2484);
+ INIT_INI_ARRAY(&ah->iniPcieSerdes,
+ ar9462_2p1_pciephy_clkreq_disable_L1);
+ INIT_INI_ARRAY(&ah->iniPcieSerdesLowPower,
+ ar9462_2p1_pciephy_clkreq_disable_L1);
} else if (AR_SREV_9462_20(ah)) {
INIT_INI_ARRAY(&ah->iniMac[ATH_INI_CORE], ar9462_2p0_mac_core);
diff --git a/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h b/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h
index 4dbc294..bec18bf 100644
--- a/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9462_2p1_initvals.h
@@ -1771,4 +1771,11 @@ static const u32 ar9462_2p1_baseband_core_txfir_coeff_japan_2484[][2] = {
{0x0000a3a0, 0xca9228ee},
};
+static const u32 ar9462_2p1_pciephy_clkreq_disable_L1[][2] = {
+ /* Addr allmodes */
+ {0x00018c00, 0x18213ede},
+ {0x00018c04, 0x000801d8},
+ {0x00018c08, 0x0003780c},
+};
+
#endif /* INITVALS_9462_2P1_H */
--
1.8.4.1
^ permalink raw reply related
* [PATCH] ath9k: Remove unused AR9462 2.0 initvals
From: Sujith Manoharan @ 2013-10-29 6:12 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h | 14 --------------
1 file changed, 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h b/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h
index 092b9d4..5a10dcf 100644
--- a/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9462_2p0_initvals.h
@@ -33,13 +33,6 @@ static const u32 ar9462_modes_fast_clock_2p0[][3] = {
{0x0000a254, 0x00000898, 0x00001130},
};
-static const u32 ar9462_pciephy_clkreq_enable_L1_2p0[][2] = {
- /* Addr allmodes */
- {0x00018c00, 0x18253ede},
- {0x00018c04, 0x000801d8},
- {0x00018c08, 0x0003780c},
-};
-
static const u32 ar9462_2p0_baseband_postamble[][5] = {
/* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */
{0x00009810, 0xd00a8005, 0xd00a8005, 0xd00a8011, 0xd00a800d},
@@ -366,13 +359,6 @@ static const u32 ar9462_pciephy_clkreq_disable_L1_2p0[][2] = {
{0x00018c08, 0x0003780c},
};
-static const u32 ar9462_pciephy_pll_on_clkreq_disable_L1_2p0[][2] = {
- /* Addr allmodes */
- {0x00018c00, 0x18212ede},
- {0x00018c04, 0x000801d8},
- {0x00018c08, 0x0003780c},
-};
-
static const u32 ar9462_2p0_radio_postamble_sys2ant[][5] = {
/* Addr 5G_HT20 5G_HT40 2G_HT40 2G_HT20 */
{0x000160ac, 0xa4646c08, 0xa4646c08, 0x24645808, 0x24645808},
--
1.8.4.1
^ permalink raw reply related
* [PATCH] ath9k: Remove pcieSerDesWrite
From: Sujith Manoharan @ 2013-10-29 6:23 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
This HW config option is always set to true and is not needed.
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/ar9003_hw.c | 20 +++++++++-----------
drivers/net/wireless/ath/ath9k/hw.c | 1 -
drivers/net/wireless/ath/ath9k/hw.h | 1 -
3 files changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_hw.c b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
index a6e06a1..42daea5 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_hw.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_hw.c
@@ -754,6 +754,9 @@ static void ar9003_hw_init_mode_gain_regs(struct ath_hw *ah)
static void ar9003_hw_configpcipowersave(struct ath_hw *ah,
bool power_off)
{
+ unsigned int i;
+ struct ar5416IniArray *array;
+
/*
* Increase L1 Entry Latency. Some WB222 boards don't have
* this change in eeprom/OTP.
@@ -779,18 +782,13 @@ static void ar9003_hw_configpcipowersave(struct ath_hw *ah,
* Configire PCIE after Ini init. SERDES values now come from ini file
* This enables PCIe low power mode.
*/
- if (ah->config.pcieSerDesWrite) {
- unsigned int i;
- struct ar5416IniArray *array;
-
- array = power_off ? &ah->iniPcieSerdes :
- &ah->iniPcieSerdesLowPower;
+ array = power_off ? &ah->iniPcieSerdes :
+ &ah->iniPcieSerdesLowPower;
- for (i = 0; i < array->ia_rows; i++) {
- REG_WRITE(ah,
- INI_RA(array, i, 0),
- INI_RA(array, i, 1));
- }
+ for (i = 0; i < array->ia_rows; i++) {
+ REG_WRITE(ah,
+ INI_RA(array, i, 0),
+ INI_RA(array, i, 1));
}
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 54b0415..381fbe1 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -454,7 +454,6 @@ static void ath9k_hw_init_config(struct ath_hw *ah)
}
ah->config.rx_intr_mitigation = true;
- ah->config.pcieSerDesWrite = true;
/*
* We need this for PCI devices only (Cardbus, PCI, miniPCI)
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 69542c1..289e5ce 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -283,7 +283,6 @@ struct ath9k_ops_config {
int additional_swba_backoff;
int ack_6mb;
u32 cwm_ignore_extcca;
- bool pcieSerDesWrite;
u8 pcie_clock_req;
u32 pcie_waen;
u8 analog_shiftreg;
--
1.8.4.1
^ permalink raw reply related
* Re: [PATCH 03/16] wl1251: add sysfs interface for bluetooth coexistence mode configuration
From: Luca Coelho @ 2013-10-29 7:09 UTC (permalink / raw)
To: Ben Hutchings
Cc: Pali Rohár, John W. Linville, Johannes Berg, David S. Miller,
linux-wireless, netdev, linux-kernel, freemangordon,
aaro.koskinen, pavel, sre, joni.lapilainen, David Gnedt
In-Reply-To: <1383003587.3779.49.camel@bwh-desktop.uk.level5networks.com>
On Mon, 2013-10-28 at 23:39 +0000, Ben Hutchings wrote:
> On Sat, 2013-10-26 at 22:34 +0200, Pali Rohár wrote:
> > From: David Gnedt <david.gnedt@davizone.at>
> >
> > Port the bt_coex_mode sysfs interface from wl1251 driver version included
> > in the Maemo Fremantle kernel to allow bt-coexistence mode configuration.
> > This enables userspace applications to set one of the modes
> > WL1251_BT_COEX_OFF, WL1251_BT_COEX_ENABLE and WL1251_BT_COEX_MONOAUDIO.
> > The default mode is WL1251_BT_COEX_OFF.
> > It should be noted that this driver always enabled bt-coexistence before
> > and enabled bt-coexistence directly affects the receiving performance,
> > rendering it unusable in some low-signal situations. Especially monitor
> > mode is affected very badly with bt-coexistence enabled.
> [...]
>
> This should be implemented consistently with other drivers:
>
> drivers/net/wireless/ath/ath9k/htc_drv_init.c:module_param_named(btcoex_enable, ath9k_htc_btcoex_enable, int, 0444);
> drivers/net/wireless/ath/ath9k/init.c:module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444);
> drivers/net/wireless/b43/main.c:module_param_named(btcoex, modparam_btcoex, int, 0444);
> drivers/net/wireless/ipw2x00/ipw2200.c:module_param(bt_coexist, int, 0444);
> drivers/net/wireless/iwlegacy/common.c:module_param(bt_coex_active, bool, S_IRUGO);
> drivers/net/wireless/iwlwifi/iwl-drv.c:module_param_named(bt_coex_active, iwlwifi_mod_params.bt_coex_active,
> drivers/net/wireless/ti/wlcore/sysfs.c:static DEVICE_ATTR(bt_coex_state, S_IRUGO | S_IWUSR,
>
> Oh, hmm, I see a problem here.
With so many drivers doing the same thing, isn't it about time to add
this to nl80211?
--
Luca.
^ 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