* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 16:24 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <1469204186.15064.6.camel@redhat.com>
Hi Dan,
I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
For now though - the iwlist scan results for both a USB device and the
libertas device:
USB: http://termbin.com/hdwl
Libertas: http://termbin.com/jxh7
Will follow up shortly with WPA and Open network configs.
Christopher Williamson
On 22 July 2016 at 17:16:29, Dan Williams
(dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> Hi Dan,
>
> I will check out the WPA2 vs WPA vs open wireless thing in a few mins.
>
> For now though - the iwlist scan results for both a USB device and the
> libertas device:
>
> USB: http://termbin.com/hdwl
> Libertas: http://termbin.com/jxh7
>
> Will follow up shortly with WPA and Open network configs.
>
> *Christopher Williamson*
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Dan Williams @ 2016-07-22 16:16 UTC (permalink / raw)
To: Christopher Williamson, Arend Van Spriel,
linux-wireless@vger.kernel.org
In-Reply-To: <CANXHH3mOsN3-U=BS4fA6iax0ciwbSSywHAgOhHCNj8e7CPCyfQ@mail.gmail.com>
On Fri, 2016-07-22 at 01:48 -0700, Christopher Williamson wrote:
> Looking through the log lines I see gaps between what WPA is doing
> and what
> dmesg reports and figured this is because of the libertas debugging
> level
> so I’ve set that to 0xfffffff (for libertas) and created a combined
> log of
> the events from both sources labelled with either [wpa] or [dmesg]
> and
> timestamped which should help to give a much clearer combined
> picture:
>
> http://termbin.com/sjqn
>
> I’ll have a look through and see if anything jumps out at me but I
> wanted
> to send it out to get expert eyes on it.
Thanks.
The ASSOC command looks OK, but do you have 'iw scan' output for
shaunthesheep from a different card? Just to make sure that the
passed-in rates and RSN IE is correct.
The ASSOC command completes .5 seconds after it's sent, and the
firmware returns a result that means "association response timeout".
According to the API docs it doesn't look like this status code (1)
comes from the AP, but from the firmware.
I'm afraid at this point we'd need a second machine to listen on the
channel and see if we can get the exchange between the marvell device
and the AP.
Can you test the device with a WPA-only AP, ie one that's not WPA2/RSN?
Does it work with an open AP?
Dan
> As a side note - I really appreciate all of the help on this so far -
> there’s a beer in it for all involved! :P
>
> Christopher Williamson
>
>
>
> On 22 July 2016 at 09:21:44, Christopher Williamson
> (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> >
> >
> > I was thinking about redirecting the wpa logging to syslog but
> > figured I’d take the lazy way out by abusing curl:
> >
> > curl -s http://termbin.com/cx0e http://termbin.com/bvdj | sort
> >
> > Resulting combined log file:
> > http://termbin.com/909y
> >
> > Christopher Williamson
> >
> >
> > On 22 July 2016 at 09:09:59, Arend Van Spriel (arend.vanspriel@broa
> > dcom.com(mailto:arend.vanspriel@broadcom.com)) wrote:
> >
> > >
> > > On 22-7-2016 0:00, Christopher Williamson wrote:
> > > >
> > > > I’ve created cleaner logs (particularly the dmesg one) and have
> > > > added
> > > > timestamps line-by-line to both so it should be easier to track
> > > > between the two log files:
> > > >
> > > > wpa_supplicant:
> > > > http://termbin.com/cx0e
> > > >
> > > > dmesg | grep libertas:
> > > > http://termbin.com/bvdj
> > > You can make wpa_supplicant log to syslog. That way you get
> > > kernel and
> > > wpa_supplicant log in one file.
> > >
> > > Regards,
> > > Arend
> > >
> > > >
> > > > Christopher Williamson
> > > >
> > > >
> > > >
> > > >
> > > > On 21 July 2016 at 22:00:02, Christopher Williamson
> > > > (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > >
> > > > >
> > > > > Sure!
> > > > >
> > > > > wpa_supplicant logs:
> > > > > http://termbin.com/z1hg
> > > > >
> > > > > dmesg logs (grepped for libertas):
> > > > > http://termbin.com/7rt5
> > > > >
> > > > >
> > > > > Christopher Williamson
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On 21 July 2016 at 21:38:26, Dan Williams (dcbw@redhat.com(ma
> > > > > ilto:dcbw@redhat.com)) wrote:
> > > > >
> > > > > >
> > > > > > On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson
> > > > > > wrote:
> > > > > > >
> > > > > > > Just to confirm - I can connect to the same network using
> > > > > > > the same
> > > > > > > configurations using a USB wifi adapter I tried.
> > > > > > Can you grab simultaneous driver debug logging and
> > > > > > supplicant debug
> > > > > > logging? Unfortunately the 'status 1' is an unspecified
> > > > > > failure, which
> > > > > > could be from the AP or the firmware.
> > > > > >
> > > > > > Dan
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Unfortunately it’s not ideal since the point of the Viliv
> > > > > > > N5 is that
> > > > > > > it’s ultra portable so I would really like to get the
> > > > > > > inbuilt wifi
> > > > > > > card working.
> > > > > > >
> > > > > > > It seems odd that wpa_supplicant reports the connection
> > > > > > > being
> > > > > > > “rejected” as seen below:
> > > > > > >
> > > > > > > wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43
> > > > > > > status_code=1
> > > > > > >
> > > > > > > Most of the debug output sadly doesn’t mean a great deal
> > > > > > > to me - wifi
> > > > > > > isn’t really my area of expertise.
> > > > > > >
> > > > > > > On 21 July 2016 at 19:10:56, Christopher Williamson
> > > > > > > (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Sure, here are the results:
> > > > > > > >
> > > > > > > > http://termbin.com/e8e2
> > > > > > > >
> > > > > > > > Christopher Williamson
> > > > > > > >
> > > > > > > >
> > > > > > > > On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.
> > > > > > > > com(mailto:d
> > > > > > > > cbw@redhat.com)) wrote:
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Wed, 2016-07-20 at 15:16 -0700, Christopher
> > > > > > > > > Williamson wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I used NetworkManager in the previous test.
> > > > > > > > > >
> > > > > > > > > > This time around I have used wpa_supplicant
> > > > > > > > > > directly and get
> > > > > > > > > > the
> > > > > > > > > > following results:
> > > > > > > > > >
> > > > > > > > > > http://termbin.com/j8ea
> > > > > > > > > >
> > > > > > > > > > Thought I’d throw them on a pastebin since it’s
> > > > > > > > > > over 700 lines.
> > > > > > > > > Can you try with "-D nl80211" instead of using the
> > > > > > > > > WEXT
> > > > > > > > > supplicant
> > > > > > > > > driver? NM is likely going to use nl80211 since the
> > > > > > > > > driver has
> > > > > > > > > some
> > > > > > > > > support for cfg80211/nl80211 and only does WEXT
> > > > > > > > > through the glue
> > > > > > > > > layer.
> > > > > > > > >
> > > > > > > > > Dan
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Christopher Williamson
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On 20 July 2016 at 22:50:34, Dan Williams
> > > > > > > > > > (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 2016-07-20 at 13:06 -0700, Christopher
> > > > > > > > > > > Williamson
> > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Dan,
> > > > > > > > > > > >
> > > > > > > > > > > > Ah - yeah I hadn’t thought it may be a kernel
> > > > > > > > > > > > build option.
> > > > > > > > > > > > I’ve
> > > > > > > > > > > > now
> > > > > > > > > > > > built that and dmesg is a much more lively
> > > > > > > > > > > > place!
> > > > > > > > > > > >
> > > > > > > > > > > > I’ve provided output logs for both when the
> > > > > > > > > > > > device is
> > > > > > > > > > > > connected
> > > > > > > > > > > > and
> > > > > > > > > > > > when a connection attempt is made - hopefully
> > > > > > > > > > > > this is
> > > > > > > > > > > > useful.
> > > > > > > > > > > The card is scanning and only finds
> > > > > > > > > > > 'shaunthesheep' 20
> > > > > > > > > > > seconds
> > > > > > > > > > > after
> > > > > > > > > > > you "connect for the first time". The logs stop 3
> > > > > > > > > > > seconds
> > > > > > > > > > > later.
> > > > > > > > > > > Are
> > > > > > > > > > > you connecting with wicd or something else?
> > > > > > > > > > >
> > > > > > > > > > > Can you run wpa_supplicant with the "-dddtu"
> > > > > > > > > > > option so we can
> > > > > > > > > > > get
> > > > > > > > > > > debug
> > > > > > > > > > > log output from it?
> > > > > > > > > > >
> > > > > > > > > > > Dan
> > > > > > > > > > --
> > > > > > > > > > To unsubscribe from this list: send the line
> > > > > > > > > > "unsubscribe
> > > > > > > > > > linux-
> > > > > > > > > > wireless" in
> > > > > > > > > > the body of a message to majordomo@vger.kernel.org
> > > > > > > > > > More majordomo info at http://vger.kernel.org/major
> > > > > > > > > > domo-info.ht
> > > > > > > > > > ml
> > > > > > > --
> > > > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > > > > linux-
> > > > > > > wireless" in
> > > > > > > the body of a message to majordomo@vger.kernel.org
> > > > > > > More majordomo info at http://vger.kernel.org/majordomo-i
> > > > > > > nfo.html
> > > > > > --
> > > > > > To unsubscribe from this list: send the line "unsubscribe
> > > > > > linux-wireless" in
> > > > > > the body of a message to majordomo@vger.kernel.org
> > > > > > More majordomo info at http://vger.kernel.org/majordomo-inf
> > > > > > o.html
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe
> > > > linux-wireless" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.ht
> > > > ml
> > > >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
From: Amitkumar Karwar @ 2016-07-22 15:59 UTC (permalink / raw)
To: Jouni Malinen
Cc: Kalle Valo, linux-wireless@vger.kernel.org, Cathy Luo,
Nishant Sarmukadam
In-Reply-To: <20160721155131.GA6292@w1.fi>
Hi Jouni,
> From: Jouni Malinen [mailto:j@w1.fi]
> Sent: Thursday, July 21, 2016 9:22 PM
> To: Amitkumar Karwar
> Cc: Kalle Valo; linux-wireless@vger.kernel.org; Cathy Luo; Nishant
> Sarmukadam
> Subject: Re: [PATCH 5/9] mwifiex: cfg80211 set_default_mgmt_key handler
>
> On Thu, Jul 21, 2016 at 09:18:11AM +0000, Amitkumar Karwar wrote:
> > > From: Kalle Valo [mailto:kvalo@codeaurora.org] Is it correct to
> > > ignore the key index? I see that brcmfmac ignores it as well but I
> > > want to still confirm this.
> > >
> > > Does this mean that with this patcfh mwifiex properly supports MFP?
> >
> > Yes. We do pass MFP tests with this patch.
>
> Did you test IGTK rekeying? This patch looks exactly as broken as it did
> the last time it was proposed more than a year ago and after the same
> concern not receiving any reaction.. hostapd will configure two
> different IGTKs with different Key IDs and change the TX key on the AP
> once all associated STAs have the new key. If the driver does not
> support updating the TX key index, either the old or the new STAs
> associated after rekeying will not have the correct key.
>
Thanks for your feedback and guidance on this.
I am trying to understand the problem you mentioned during IGTK rekeying. Today I ran tests with two stations connecting an AP. MFP is enabled on all of them.
On hostapd side, my observation is add_key() is always called followed by set_default_mgmt_key(). set_default_mgmt_key() sets the key added by add_key() as default key.
We are ignoring set_default_mgmt_key() and updating Tx key index during add_key() itself.
Your concerns is we should not update Tx key index during add_key(). Reason is IGTK rekeying is not yet completed with all stations. Right?
Regards,
Amitkumar
^ permalink raw reply
* Re: ath10k + iw set bitrates is causing FW crash
From: Krishna Chaitanya @ 2016-07-22 14:48 UTC (permalink / raw)
To: Ben Greear; +Cc: Manoharan, Rajkumar, linux-wireless, ath10k
In-Reply-To: <57922074.5060009@candelatech.com>
On Fri, Jul 22, 2016 at 7:02 PM, Ben Greear <greearb@candelatech.com> wrote:
>
>
> On 07/22/2016 05:21 AM, Krishna Chaitanya wrote:
>>
>> On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
>> <rmanohar@qti.qualcomm.com> wrote:
>>>
>>> [...]
>>>>>>
>>>>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>>>>> seeing 0-9, so its
>>>>>> working.
>>>>>>
>>>>>> But i am seeing a weird issues, the moment i give bitrates command,
>>>>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>>>>> interface up/down
>>>>>> it doesn't work.
>>>>>
>>>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>>>> some more testing on limiting the rates, currently in my setup its
>>>>> not reaching MCS9 so cannot verify now.
>>>>
>>>> Rajkumar,
>>>>
>>>> I am still not able to make mcs9 work, so i have tried to change the Nss
>>>> to 1
>>>> using iw, but that is not taking affect. This command is not taking
>>>> effect.
>>>>
>>> you mean not able to fix VHT rates alone. am i right? By auto rate mode,
>>> is firmware selecting
>>> mcs9? What is the command used for fixing vht rate?
>>
>> Basically my requirement is to disable MCS8 and 9 for comparison.
>> to check whether ath10k honors the iw command, i used below
>> command. changing to 1SS, but i could see that it still transmits
>> using 2SS. Does your patch ignore these settings except for
>> adhoc mode?
>>
>> iw set bitrates vht-mcs-5 1:0-7
>
>
> You can set the number of spatial streams on the phy device. Search around
> for a 'chainmask' configurable.
>
> In general, stock ath10k firmware does not have full support for setting
> arbitrary bitrates options.
Yes, i know that option but havent tried that. My intention was to limit to MCS7
so in order to verify that commands i tried to change nss.
^ permalink raw reply
* pull-request: wireless-drivers-next 2016-07-22
From: Kalle Valo @ 2016-07-22 14:28 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, Brian Norris
Hi Dave,
I'm sick so I have to keep this short, but here's the last pull request
to net-next. This time there's a trivial conflict with mtd tree:
http://lkml.kernel.org/g/20160720123133.44dab209@canb.auug.org.au
We concluded with Brian (CCed) that it's best that we ask Linus to fix
this. The patches have been in linux-next for a couple of days. This
time I haven't done any merge tests so I don't know if there are any
other conflicts etc.
Please let me know if there are any problems.
Kalle
The following changes since commit 2186f6eec2739ecd3944f9278e59edf0474f207c:
net: ethernet: marvell: pxa168_eth: use phy_ethtool_{get|set}_link_ksettings (2016-07-17 23:22:02 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git tags/wireless-drivers-next-for-davem-2016-07-22
for you to fetch changes up to cb6a115188500a448709df1f2d7698a4e1b7a099:
wlcore: spi: fix build warning caused by redundant variable (2016-07-20 21:09:13 +0300)
----------------------------------------------------------------
wireless-drivers-next patches for 4.8
Major changes:
wl18xx
* add initial mesh support
bcma
* serial flash support on non-MIPS SoCs
ath10k
* enable support for QCA9888
* disable wake_tx_queue() mac80211 op for older devices to workaround
throughput regression
ath9k
* implement temperature compensation support for AR9003+
----------------------------------------------------------------
Amitkumar Karwar (2):
mwifiex: fix PCIe legacy interrupt problem
mwifiex: update command response skb length correctly
Anilkumar Kolli (2):
ath10k: remove unused member in ath10k_hw_regs
ath10k: enable support for QCA9888
Arend Van Spriel (2):
brcmfmac: restore stopping netdev queue when bus clogs up
brcmfmac: defer DPC processing during probe
Arnd Bergmann (1):
rtlwifi: don't add include path for rtl8188ee
Ashok Raj Nagarajan (1):
ath10k: simplify pktlog htt event processing
Ben Greear (4):
ath10k: ensure txrx-compl-task is stopped when cleaning htt-tx
ath10k: ensure peer_map references are cleaned up
ath10k: Add WARN_ON if we over-write peer-map pointer.
ath10k: Clean up peer when sta goes away.
Benjamin Berg (6):
ath9k: Correct TSF adjustment to align the beacon time correctly
ath9k: Handle channel context in get_/set_/reset_tsf
ath9k: Use tsf offset helper in ath9k_hw_reset
ath9k: Expose tsf_adjustment in mac80211 tsf getters and setters.
ath9k: Remove some #defined constants to decrease verbosity
ath9k: Fix beacon configuration for addition/removal of interfaces
Bjorn Andersson (6):
wcn36xx: Fold indication payload into message header
wcn36xx: Change indication list lock to spinlock
wcn36xx: Split mmio space into explicit regions
wcn36xx: Correct DXE chip version differentiation
wcn36xx: Fix up wcn36xx_smd_update_scan_params()
wcn36xx: Silence error about unsupported smd event 188
Bob Copeland (1):
ath10k: fix potential null dereference bugs
Chaehyun Lim (1):
ath10k: remove unused <linux/semaphore.h>
Dan Kephart (1):
ath6kl: sme_state shortcut to SME_DISCONNECTED removed
Eduardo Abinader (2):
ath9k: return false when reading wrong eeprom offset
ath10k: remove extra space on ath10k_update_channel_list
Eyal Reizer (1):
wlcore: spi: add wl18xx support
Felix Fietkau (5):
ath9k_hw: fix spectral scan on AR9285 and newer
ath9k_hw: fix duplicate (and partially wrong) definition of AR_CH0_THERM
ath9k_hw: simplify ar9003_hw_per_calibration
ath9k_hw: get rid of some duplicate code in calibration init
ath9k_hw: implement temperature compensation support for AR9003+
Florian Fainelli (3):
brcmfmac: Fix glob_skb leak in brcmf_sdiod_recv_chain
brcmsmac: Free packet if dma_mapping_error() fails in dma_rxfill
brcmsmac: Initialize power in brcms_c_stf_ss_algo_channel_get()
Kalle Valo (3):
Merge tag 'iwlwifi-next-for-kalle-2016-07-11' of git://git.kernel.org/.../iwlwifi/iwlwifi-next
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Merge ath-next from git://git.kernel.org/.../kvalo/ath.git
Karthik D A (1):
mwifiex: Fix request_irq() failure handling
Luciano Coelho (1):
iwlwifi: mvm: bump MAX firmware API for mvm devices
Maital Hahn (1):
wlcore/wl18xx: mesh: added initial mesh support for wl8
Martin Blumenstingl (6):
ath9k: Allow configuration of LED polarity in platform data.
ath9k: remove variable which is set but never read
ath9k: ath9k_hw_init_macaddr should not overwrite valid MAC addresses
ath9k: remove return value from ath9k_hw_init_macaddr
ath9k: move all ath9k_platform_data initialization into one function
ath9k: simplify the code-paths when not using the built-in EEPROM
Maxim Altshul (2):
wlcore/wl18xx: Add functionality to accept TX rate per link
wlcore: Add support for get_expected_throughput opcode
Michal Kazior (1):
ath10k: disable wake_tx_queue for older devices
Mohammed Shafi Shajakhan (9):
ath10k: fix crash during card removal
ath10k: remove unneccessary WARN_ON_ONCE in rx during ACS
ath10k: enable beacon loss detection support for 10.4
ath10k: disable TX_STBC for tx chainmask of 1
ath10k: fix some typo in spectral code commments
ath10k: fix 10.4 extended peer stats update
ath10k: add support for ath10k_sta_statistics support
ath10k: remove debugfs support for Per STA total rx duration
ath10k: replace warning with an error message if HTT op version is unset
Pierre Le Magourou (3):
ath6kl: Fix WLAN tethering authentication problem.
ath6kl: Fix wrong regulatory domain disconnection.
ath6kl: Unset IFF_LOWER_UP flag on AP mode leave.
Prasun Maiti (1):
mwifiex: Reduce endian conversion for REG Host Commands
Rafał Miłecki (5):
brcmfmac: respect hidden_ssid for AP interfaces
bcma: add PCI ID for Foxconn's BCM43142 device
bcma: allow enabling serial flash support on non-MIPS SoCs
bcma: define ChipCommon B MII registers
mtd: add arch dependency for MTD_BCM47XXSFLASH symbol
Reizer, Eyal (1):
wlcore: spi: fix build warning caused by redundant variable
Sven Eckelmann (1):
ath9k: Fix programming of minCCA power threshold
Vasanthakumar Thiagarajan (1):
ath10k: fix possible wrong rx_busy time reporting in QCA4019
Wei Yongjun (2):
libertas: fix non static symbol warning
mwifiex: fix possible memory leak in mwifiex_cfg80211_start_ap()
.../bindings/net/wireless/ti,wlcore,spi.txt | 41 +++-
drivers/bcma/Kconfig | 11 +-
drivers/bcma/driver_chipcommon_b.c | 9 +-
drivers/bcma/host_pci.c | 1 +
drivers/mtd/devices/Kconfig | 2 +-
drivers/net/wireless/ath/ath10k/core.c | 28 ++-
drivers/net/wireless/ath/ath10k/core.h | 10 +
drivers/net/wireless/ath/ath10k/debug.c | 19 +-
drivers/net/wireless/ath/ath10k/debug.h | 11 +-
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 74 +++---
drivers/net/wireless/ath/ath10k/htc.h | 1 -
drivers/net/wireless/ath/ath10k/htt_rx.c | 10 +-
drivers/net/wireless/ath/ath10k/htt_tx.c | 22 +-
drivers/net/wireless/ath/ath10k/hw.c | 15 +-
drivers/net/wireless/ath/ath10k/hw.h | 33 +--
drivers/net/wireless/ath/ath10k/mac.c | 67 +++++-
drivers/net/wireless/ath/ath10k/pci.c | 24 ++
drivers/net/wireless/ath/ath10k/spectral.c | 4 +-
drivers/net/wireless/ath/ath10k/txrx.c | 6 +-
drivers/net/wireless/ath/ath10k/wmi.c | 67 ++++--
drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
drivers/net/wireless/ath/ath6kl/cfg80211.c | 6 +-
drivers/net/wireless/ath/ath6kl/txrx.c | 9 +-
drivers/net/wireless/ath/ath9k/ahb.c | 18 +-
drivers/net/wireless/ath/ath9k/ar9002_phy.c | 32 ++-
drivers/net/wireless/ath/ath9k/ar9002_phy.h | 5 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 128 ++++++-----
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 2 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 25 +-
drivers/net/wireless/ath/ath9k/ath9k.h | 7 +-
drivers/net/wireless/ath/ath9k/beacon.c | 240 +++++++++++---------
drivers/net/wireless/ath/ath9k/common.h | 1 +
drivers/net/wireless/ath/ath9k/dynack.c | 4 +-
drivers/net/wireless/ath/ath9k/eeprom.c | 33 ++-
drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 2 +-
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 2 +-
drivers/net/wireless/ath/ath9k/hw.c | 54 ++---
drivers/net/wireless/ath/ath9k/hw.h | 1 +
drivers/net/wireless/ath/ath9k/init.c | 54 +++--
drivers/net/wireless/ath/ath9k/mac.h | 4 -
drivers/net/wireless/ath/ath9k/main.c | 73 ++++--
drivers/net/wireless/ath/ath9k/pci.c | 41 ++--
drivers/net/wireless/ath/wcn36xx/dxe.c | 31 +--
drivers/net/wireless/ath/wcn36xx/dxe.h | 7 +-
drivers/net/wireless/ath/wcn36xx/hal.h | 4 +-
drivers/net/wireless/ath/wcn36xx/main.c | 67 +++---
drivers/net/wireless/ath/wcn36xx/smd.c | 44 ++--
drivers/net/wireless/ath/wcn36xx/smd.h | 4 +-
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 10 +-
.../wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 4 +-
.../broadcom/brcm80211/brcmfmac/cfg80211.c | 13 ++
.../broadcom/brcm80211/brcmfmac/fwsignal.c | 22 +-
.../wireless/broadcom/brcm80211/brcmfmac/sdio.c | 7 +-
.../net/wireless/broadcom/brcm80211/brcmsmac/dma.c | 4 +-
.../net/wireless/broadcom/brcm80211/brcmsmac/stf.c | 2 +-
drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 4 +-
drivers/net/wireless/intel/iwlwifi/iwl-9000.c | 2 +-
drivers/net/wireless/marvell/libertas/cfg.c | 4 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 +-
drivers/net/wireless/marvell/mwifiex/ioctl.h | 10 +-
drivers/net/wireless/marvell/mwifiex/pcie.c | 9 +-
drivers/net/wireless/marvell/mwifiex/sta_cmd.c | 28 +--
drivers/net/wireless/marvell/mwifiex/sta_cmdresp.c | 37 ++-
drivers/net/wireless/marvell/mwifiex/sta_ioctl.c | 21 +-
.../wireless/realtek/rtlwifi/rtl8188ee/Makefile | 2 +-
drivers/net/wireless/ti/wl18xx/main.c | 19 +-
drivers/net/wireless/ti/wl18xx/tx.c | 22 +-
drivers/net/wireless/ti/wl18xx/wl18xx.h | 8 +-
drivers/net/wireless/ti/wlcore/acx.h | 1 +
drivers/net/wireless/ti/wlcore/boot.c | 2 +-
drivers/net/wireless/ti/wlcore/cmd.c | 13 +-
drivers/net/wireless/ti/wlcore/main.c | 44 +++-
drivers/net/wireless/ti/wlcore/rx.c | 7 +
drivers/net/wireless/ti/wlcore/spi.c | 124 ++++++++--
drivers/net/wireless/ti/wlcore/wlcore_i.h | 14 ++
include/linux/ath9k_platform.h | 1 +
include/linux/bcma/bcma_driver_chipcommon.h | 3 +
78 files changed, 1178 insertions(+), 644 deletions(-)
--
Kalle Valo
^ permalink raw reply
* [PATCH -next] wlcore: spi: fix non static symbol warning
From: Wei Yongjun @ 2016-07-22 14:08 UTC (permalink / raw)
To: Kalle Valo, Andrew F. Davis, Arnd Bergmann, Igor Grinberg,
Uri Mashiach, Rob Herring, Reizer, Eyal
Cc: Wei Yongjun, linux-wireless
Fixes the following sparse warning:
drivers/net/wireless/ti/wlcore/spi.c:87:34: warning:
symbol 'wilink_data' was not declared. Should it be static?
Signed-off-by: Wei Yongjun <weiyj.lk@gmail.com>
---
drivers/net/wireless/ti/wlcore/spi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ti/wlcore/spi.c b/drivers/net/wireless/ti/wlcore/spi.c
index 6d24040..0ed526e 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -84,7 +84,7 @@ struct wilink_familiy_data {
char name[8];
};
-const struct wilink_familiy_data *wilink_data;
+static const struct wilink_familiy_data *wilink_data;
static const struct wilink_familiy_data wl18xx_data = {
.name = "wl18xx",
^ permalink raw reply related
* Re: ath10k + iw set bitrates is causing FW crash
From: Ben Greear @ 2016-07-22 13:32 UTC (permalink / raw)
To: Krishna Chaitanya, Manoharan, Rajkumar; +Cc: linux-wireless, ath10k
In-Reply-To: <CABPxzYL2D1b08vOJc9b9WCjjEDtgHW2UQFNVSyxD5wSjidmiQA@mail.gmail.com>
On 07/22/2016 05:21 AM, Krishna Chaitanya wrote:
> On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
> <rmanohar@qti.qualcomm.com> wrote:
>> [...]
>>>>> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>>>>> seeing 0-9, so its
>>>>> working.
>>>>>
>>>>> But i am seeing a weird issues, the moment i give bitrates command,
>>>>> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>>>>> interface up/down
>>>>> it doesn't work.
>>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>>> some more testing on limiting the rates, currently in my setup its
>>>> not reaching MCS9 so cannot verify now.
>>> Rajkumar,
>>>
>>> I am still not able to make mcs9 work, so i have tried to change the Nss to 1
>>> using iw, but that is not taking affect. This command is not taking effect.
>>>
>> you mean not able to fix VHT rates alone. am i right? By auto rate mode, is firmware selecting
>> mcs9? What is the command used for fixing vht rate?
> Basically my requirement is to disable MCS8 and 9 for comparison.
> to check whether ath10k honors the iw command, i used below
> command. changing to 1SS, but i could see that it still transmits
> using 2SS. Does your patch ignore these settings except for
> adhoc mode?
>
> iw set bitrates vht-mcs-5 1:0-7
You can set the number of spatial streams on the phy device. Search around
for a 'chainmask' configurable.
In general, stock ath10k firmware does not have full support for setting
arbitrary bitrates options.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Prarit Bhargava @ 2016-07-22 12:51 UTC (permalink / raw)
To: Arend Van Spriel, Stanislaw Gruszka
Cc: Emmanuel Grumbach, Michal Kazior, Kalle Valo, linux-wireless,
ath10k, Arend van Spriel, Greg Kroah-Hartman, Ming Lei,
Luis R. Rodriguez
In-Reply-To: <84a2cfbe-3d58-a5ec-e028-166dce4c9304@broadcom.com>
On 07/22/2016 08:21 AM, Arend Van Spriel wrote:
> On 22-7-2016 12:26, Stanislaw Gruszka wrote:
>> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
>>> + Luis
>>>
>>> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
>>>> (cc: firmware and brcmfmac maintainers)
>>>>
>>>> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>>>>
>>>>>
>>>>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>>>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>>>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>>>>> Firmware files are versioned to prevent older
>>>>>>>>> driver instances to load unsupported firmware
>>>>>>>>> blobs. This is reflected with a fallback logic
>>>>>>>>> which attempts to load several firmware files.
>>>>>>>>>
>>>>>>>>> This however produced a lot of unnecessary
>>>>>>>>> warnings sometimes confusing users and leading
>>>>>>>>> them to rename firmware files making things even
>>>>>>>>> more confusing.
>>>>>>>>
>>>>>>>> This happens on kernels configured with
>>>>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>>>>> but also 60 seconds delay before loading next firmware version.
>>>>>>>> For some reason RHEL kernel needs above config option, so this
>>>>>>>> patch is very welcome from my perspective.
>>>>>>>>
>>>>>>>
>>>>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>>>>> with udev's help?
>>>>>>
>>>>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>>>>> file data directly from mounted filesystem without user space helper.
>>>>>
>>>>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>>>>> loading magic via a "usermode helper". This delay is there to allow, for
>>>>> example, userspace to unpack or download a new firmware image or verify the
>>>>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>>>>
>>>>> Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
>>>>> handshake on completion.
>>>>>
>>>>>>
>>>>>>> As you can imagine, iwlwifi is suffering from the
>>>>>>> same problem and I would be interested in applying the same change,
>>>>>>> but I'd love to understand a bit more :)
>>>>>>
>>>>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>>>>> happen when the newest firmware version is not installed on the system
>>>>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>>>>> it's not common.
>>>>>
>>>>> request_firmware_direct() was introduced at my request because (as you've
>>>>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>>>>> periods of time when starting. The bug that this introduced was a 60 second
>>>>> delay per logical cpu when starting a system. On a 64 cpu system that meant the
>>>>> boot would complete in a little over one hour.
>>>>>
>>>>>>
>>>>>> I started to see this currently, because that option was enabled on
>>>>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>>>>> happened because of that, i.e. thermal device was not functional
>>>>>> because f/w wasn't loaded due to big delay.
>>>>>>
>>>>>> I'm not sure if replacing to request_firmware_direct() is a good
>>>>>> fix though. For example I can see this problem also on brcmfmac, which
>>>>>> use request_firmware_nowait(). I think I would rather prefer special
>>>>>> helper for firmware drivers that needs user helper and have
>>>>>> request_firmware() be direct as default.
>>>>>>
>>>>>
>>>>> The difference between request_firmware_direct() and request_firmware() is that
>>>>> the _direct() version does not wait the 60 seconds for udev interaction. The
>>>>> only userspace check performed is to see if the file is there, and if the file
>>>>> does exist it is provided to the driver to be applied to the hardware.
>>>>>
>>>>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>>>>> iwlwifi require udev to do anything beyond checking for the existence and
>>>>> loading the firmware image. If they don't, then it is better to use
>>>>> request_firmware_direct().
>>>>
>>>> They don't need that, like 99% of the drivers I think, hence changing the
>>>> default seems to be more reasonable. However changing 3 drivers would work
>>>> for me as well, and that change do not introduce risk of broking drivers
>>>> that require udev fw download.
>>>>
>>>> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
>>>> use request_firmware_nowait(), so it first need to be converted to
>>>> ordinary request_firmware(), but this should be doable and I can do
>>>> that.
>>>
>>> I am going bonkers here. This is the Nth time a discussion pops up on
>>> firmware API usage. I stopped counting N :-( So the first issue was that
>>> the INIT was taking to long as we were requesting firmware during probe
>>> which was executed in the INIT context. So we added a worker and
>>> register the driver from there. There was probably a reason for
>>> switching to _no_wait() as well, but I do not recall the details. The
>>> things is I don't know if I need user-space or not. I just need firmware
>>> to get the device up and running. We have changed our driver a couple of
>>> times now to accommodate something that in my opinion should have been
>>> abstracted behind the firmware API in the first place and now here is
>>> another proposal to change the drivers. Come on!
>>
>> I understand you dislike that :-) Just to clarify the issue here:
>>
>> Some drivers (including brcmfmac) request new firmware images, which are
>> not yet available (i.e. development F/W versions) and then fall-back
>> to older firmware version and works perfectly fine.
>>
>> However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
>> of missing F/W image, request firmware involve user space helper and
>> waits 60s (loading_timeout value from drivers/base/firmware_class.c),
>> what delays creating network interface and confuse users.
>>
>> For brcmfmac this looks like this:
>>
>> [ 15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
>> [ 15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
>> <snip>
>> [ 75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
>> [ 75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
>>
>> Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
>> silently fail and then instantly next F/W image is loaded.
>>
>> Another option to solve to problem would be stop requesting not
>> available publicly firmware. However, I assume some drivers would
>> like to preserve that option.
>
> Actually, this is not the case with brcmfmac. We do need a firmware
> file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
> ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
> works fine without it.
>
> What is still unclear to me is when request_firmware_direct() would fail
> and in what circumstances the udev helper is a valid callback. Can you
> explain such a scenario. Another question I have is what the reasons are
> behind the 60 seconds timeout.
request_firmware_direct() will fail when the specified FW file is not present.
This is different from request_firmware() which implements a usermode helper to
potentially download firmware, or unpack a firmware image.
Re: 60 second timeout ... The 60 second timeout with request_firmware() is
completely arbitrary. There is no way for udev to signal back to the kernel
that userspace helper has not completed its actions, so the kernel has a 60 dead
man timer-ish delay.
>
>>>> However I wonder if changing that will not broke the case when
>>>> driver is build-in in the kernel and f/w is not yet available when
>>>> driver start to initialize. Or maybe nowadays this is not the case
>>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
>>>> images are build-in in the kernel or copied to initramfs?
>>>
>>> That is a nice idea, but I have not seen any change in that area. Could
>>> have missed it.
>>
>> I believe this is how the things are already done, IOW switching to
>> request_firmware_direct() in the driver should be no harm.
>
> Ok. What are the consequences when:
> - driver is built-in.
> - driver+firmware present on initramfs.
> - driver on initramfs, firmware only present on rootfs.
> - driver+firmware only on rootfs.
>
> I assume the third one would be considered a configuration issue.
I think your question here can be answered by reading drivers/base/Kconfig:88,
and reading about those 4 config options. I could paraphrase it butI think the
Kconfig notes are better than I could explain it. Note that this is how things
currently work with request_firmware_nowait(). IIRC request_firmware_nowait()
is just an asynchronous version of request_firmware().
HTH,
P.
^ permalink raw reply
* Re: ath10k + iw set bitrates is causing FW crash
From: Krishna Chaitanya @ 2016-07-22 12:21 UTC (permalink / raw)
To: Manoharan, Rajkumar; +Cc: linux-wireless, ath10k
In-Reply-To: <1469188781289.75799@qti.qualcomm.com>
On Fri, Jul 22, 2016 at 5:29 PM, Manoharan, Rajkumar
<rmanohar@qti.qualcomm.com> wrote:
> [...]
>> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
>> >> seeing 0-9, so its
>> >> working.
>> >>
>> >> But i am seeing a weird issues, the moment i give bitrates command,
>> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
>> >> interface up/down
>> >> it doesn't work.
>>> After reboot i dont see the "unencrypted" packet issue, i will do
>>> some more testing on limiting the rates, currently in my setup its
>>> not reaching MCS9 so cannot verify now.
>> Rajkumar,
>>
>> I am still not able to make mcs9 work, so i have tried to change the Nss to 1
>> using iw, but that is not taking affect. This command is not taking effect.
>>
> you mean not able to fix VHT rates alone. am i right? By auto rate mode, is firmware selecting
> mcs9? What is the command used for fixing vht rate?
Basically my requirement is to disable MCS8 and 9 for comparison.
to check whether ath10k honors the iw command, i used below
command. changing to 1SS, but i could see that it still transmits
using 2SS. Does your patch ignore these settings except for
adhoc mode?
iw set bitrates vht-mcs-5 1:0-7
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Arend Van Spriel @ 2016-07-22 12:21 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: Prarit Bhargava, Emmanuel Grumbach, Michal Kazior, Kalle Valo,
linux-wireless, ath10k, Arend van Spriel, Greg Kroah-Hartman,
Ming Lei, Luis R. Rodriguez
In-Reply-To: <20160722102559.GA2662@redhat.com>
On 22-7-2016 12:26, Stanislaw Gruszka wrote:
> On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
>> + Luis
>>
>> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
>>> (cc: firmware and brcmfmac maintainers)
>>>
>>> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>>>
>>>>
>>>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>>>> Firmware files are versioned to prevent older
>>>>>>>> driver instances to load unsupported firmware
>>>>>>>> blobs. This is reflected with a fallback logic
>>>>>>>> which attempts to load several firmware files.
>>>>>>>>
>>>>>>>> This however produced a lot of unnecessary
>>>>>>>> warnings sometimes confusing users and leading
>>>>>>>> them to rename firmware files making things even
>>>>>>>> more confusing.
>>>>>>>
>>>>>>> This happens on kernels configured with
>>>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>>>> but also 60 seconds delay before loading next firmware version.
>>>>>>> For some reason RHEL kernel needs above config option, so this
>>>>>>> patch is very welcome from my perspective.
>>>>>>>
>>>>>>
>>>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>>>> with udev's help?
>>>>>
>>>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>>>> file data directly from mounted filesystem without user space helper.
>>>>
>>>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>>>> loading magic via a "usermode helper". This delay is there to allow, for
>>>> example, userspace to unpack or download a new firmware image or verify the
>>>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>>>
>>>> Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
>>>> handshake on completion.
>>>>
>>>>>
>>>>>> As you can imagine, iwlwifi is suffering from the
>>>>>> same problem and I would be interested in applying the same change,
>>>>>> but I'd love to understand a bit more :)
>>>>>
>>>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>>>> happen when the newest firmware version is not installed on the system
>>>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>>>> it's not common.
>>>>
>>>> request_firmware_direct() was introduced at my request because (as you've
>>>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>>>> periods of time when starting. The bug that this introduced was a 60 second
>>>> delay per logical cpu when starting a system. On a 64 cpu system that meant the
>>>> boot would complete in a little over one hour.
>>>>
>>>>>
>>>>> I started to see this currently, because that option was enabled on
>>>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>>>> happened because of that, i.e. thermal device was not functional
>>>>> because f/w wasn't loaded due to big delay.
>>>>>
>>>>> I'm not sure if replacing to request_firmware_direct() is a good
>>>>> fix though. For example I can see this problem also on brcmfmac, which
>>>>> use request_firmware_nowait(). I think I would rather prefer special
>>>>> helper for firmware drivers that needs user helper and have
>>>>> request_firmware() be direct as default.
>>>>>
>>>>
>>>> The difference between request_firmware_direct() and request_firmware() is that
>>>> the _direct() version does not wait the 60 seconds for udev interaction. The
>>>> only userspace check performed is to see if the file is there, and if the file
>>>> does exist it is provided to the driver to be applied to the hardware.
>>>>
>>>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>>>> iwlwifi require udev to do anything beyond checking for the existence and
>>>> loading the firmware image. If they don't, then it is better to use
>>>> request_firmware_direct().
>>>
>>> They don't need that, like 99% of the drivers I think, hence changing the
>>> default seems to be more reasonable. However changing 3 drivers would work
>>> for me as well, and that change do not introduce risk of broking drivers
>>> that require udev fw download.
>>>
>>> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
>>> use request_firmware_nowait(), so it first need to be converted to
>>> ordinary request_firmware(), but this should be doable and I can do
>>> that.
>>
>> I am going bonkers here. This is the Nth time a discussion pops up on
>> firmware API usage. I stopped counting N :-( So the first issue was that
>> the INIT was taking to long as we were requesting firmware during probe
>> which was executed in the INIT context. So we added a worker and
>> register the driver from there. There was probably a reason for
>> switching to _no_wait() as well, but I do not recall the details. The
>> things is I don't know if I need user-space or not. I just need firmware
>> to get the device up and running. We have changed our driver a couple of
>> times now to accommodate something that in my opinion should have been
>> abstracted behind the firmware API in the first place and now here is
>> another proposal to change the drivers. Come on!
>
> I understand you dislike that :-) Just to clarify the issue here:
>
> Some drivers (including brcmfmac) request new firmware images, which are
> not yet available (i.e. development F/W versions) and then fall-back
> to older firmware version and works perfectly fine.
>
> However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
> of missing F/W image, request firmware involve user space helper and
> waits 60s (loading_timeout value from drivers/base/firmware_class.c),
> what delays creating network interface and confuse users.
>
> For brcmfmac this looks like this:
>
> [ 15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
> [ 15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
> <snip>
> [ 75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
> [ 75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
>
> Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
> silently fail and then instantly next F/W image is loaded.
>
> Another option to solve to problem would be stop requesting not
> available publicly firmware. However, I assume some drivers would
> like to preserve that option.
Actually, this is not the case with brcmfmac. We do need a firmware
file, ie. brcm/brcmfmac4356-pcie.bin, and also request for a nvram file,
ie. brcm/brcmfmac4356-pcie.txt. The latter is optional and the device
works fine without it.
What is still unclear to me is when request_firmware_direct() would fail
and in what circumstances the udev helper is a valid callback. Can you
explain such a scenario. Another question I have is what the reasons are
behind the 60 seconds timeout.
>>> However I wonder if changing that will not broke the case when
>>> driver is build-in in the kernel and f/w is not yet available when
>>> driver start to initialize. Or maybe nowadays this is not the case
>>> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
>>> images are build-in in the kernel or copied to initramfs?
>>
>> That is a nice idea, but I have not seen any change in that area. Could
>> have missed it.
>
> I believe this is how the things are already done, IOW switching to
> request_firmware_direct() in the driver should be no harm.
Ok. What are the consequences when:
- driver is built-in.
- driver+firmware present on initramfs.
- driver on initramfs, firmware only present on rootfs.
- driver+firmware only on rootfs.
I assume the third one would be considered a configuration issue.
Regards,
Arend
^ permalink raw reply
* Re: ath10k + iw set bitrates is causing FW crash
From: Manoharan, Rajkumar @ 2016-07-22 11:59 UTC (permalink / raw)
To: Krishna Chaitanya; +Cc: linux-wireless, ath10k
In-Reply-To: <CABPxzYKomhw5rF4Crj6sMbmr3VuuDYi=zqN2ky83v-=RJe7Zhg@mail.gmail.com>
[...]
> >> Thanks Raj, with this fix the rates are 0-7, if i disable then i am
> >> seeing 0-9, so its
> >> working.
> >>
> >> But i am seeing a weird issues, the moment i give bitrates command,
> >> ath10k no longer does encryption, link is a WPA2-PSK: AES. Even after
> >> interface up/down
> >> it doesn't work.
>> After reboot i dont see the "unencrypted" packet issue, i will do
>> some more testing on limiting the rates, currently in my setup its
>> not reaching MCS9 so cannot verify now.
> Rajkumar,
>
> I am still not able to make mcs9 work, so i have tried to change the Nss to 1
> using iw, but that is not taking affect. This command is not taking effect.
>
you mean not able to fix VHT rates alone. am i right? By auto rate mode, is firmware selecting
mcs9? What is the command used for fixing vht rate?
-Rajkumar
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Jes Sorensen @ 2016-07-22 11:55 UTC (permalink / raw)
To: Stefan Lippers-Hollmann
Cc: Arnd Bergmann, linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel,
Andrea Merello
In-Reply-To: <20160722043922.0a878698@mir>
Stefan Lippers-Hollmann <s.l-h@gmx.de> writes:
> Hi
>
> On 2016-07-20, Arnd Bergmann wrote:
>> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
>> > Arnd Bergmann <arnd@arndb.de> writes:
>> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
>> > >> Arnd Bergmann <arnd@arndb.de> writes:
> [...]
>> Yes, I was just agreeing here that it's not worth doing that one.
>> As far as I can see, the evolution of these devices is
>>
>> RTL81xxU (2008)
>> RTL81xxSU (2009)
>> RTL81xxCU (2010)
>
> There is also RTL81xxDU, apparently from 2011, a dualband device
> coming in several variants (single MAC + single PHY, double MAC +
> double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC).
>
> While probably not overly common, it was/ is (hardware-wise) a pretty
> interesting device due to its support for 5 GHz[1] - actually I hoped
> it to be a (supported-) RTL8192CU variant when I bought it.
> Unfortunately no driver[2] made it to staging or the proper kernel.
I actually have one of those in my USB dongle box, but as you say, not
overly common so not sure if/when I'll get to it.
Adding 8192du support for 2.4GHz to rtl8xxxu probably wouldn't be too
complicated.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH] iw: display 5/10 MHz channel widths
From: Julian Calaby @ 2016-07-22 11:21 UTC (permalink / raw)
To: Bob Copeland; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20160722103807.GA15262@localhost>
Hi Bob,
On Fri, Jul 22, 2016 at 8:38 PM, Bob Copeland <me@bobcopeland.com> wrote:
> On Fri, Jul 22, 2016 at 07:53:35PM +1000, Julian Calaby wrote:
>> Hi Bob,
>
> Hi!
>
>> > --- a/interface.c
>> > +++ b/interface.c
>> > @@ -295,6 +295,10 @@ char *channel_width_name(enum nl80211_chan_width width)
>> > return "80+80 MHz";
>> > case NL80211_CHAN_WIDTH_160:
>> > return "160 MHz";
>> > + case NL80211_CHAN_WIDTH_5:
>> > + return "5 MHz";
>> > + case NL80211_CHAN_WIDTH_10:
>> > + return "10 MHz";
>> > default:
>> > return "unknown";
>> > }
>>
>> Judging by the previous two entries, it looks like the case statements
>> are sorted, so should these ones therefore be at the top of the list?
>
> These are sorted by NL80211_CHAN_WIDTH_* attribute value, which makes
> a little more sense to me than sorting by the string or numerically by
> width, but sure, I can do it either way.
That's fine by me: I was asking because it looked like you might have
just added them to the bottom.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: TCP performance regression in mac80211 triggered by the fq code
From: Toke Høiland-Jørgensen @ 2016-07-22 10:51 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Michal Kazior, Dave Taht
In-Reply-To: <11fa6d16-21e2-2169-8d18-940f6dc11dca@nbd.name>
Felix Fietkau <nbd@nbd.name> writes:
> Please let me know if you have any ideas.
Two more things to try:
- Andrew McGregor mentioned that some versions of Iperf on OSX has a
threading bug when running multiple streams against the same server
instance. So try running two separate instances of iperf on the server
side, or run netperf instead.
- It could be that HyStart is acting up. You could try disabling it
(echo 0 > /sys/module/tcp_cubic/parameters/hystart) and see if that
makes a difference.
-Toke
^ permalink raw reply
* Re: [PATCH] iw: display 5/10 MHz channel widths
From: Bob Copeland @ 2016-07-22 10:38 UTC (permalink / raw)
To: Julian Calaby; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <CAGRGNgWHJEFBnak-MCK2htkaeQcZ6dmZ=w96omC99G5Z2UJWFg@mail.gmail.com>
On Fri, Jul 22, 2016 at 07:53:35PM +1000, Julian Calaby wrote:
> Hi Bob,
Hi!
> > --- a/interface.c
> > +++ b/interface.c
> > @@ -295,6 +295,10 @@ char *channel_width_name(enum nl80211_chan_width width)
> > return "80+80 MHz";
> > case NL80211_CHAN_WIDTH_160:
> > return "160 MHz";
> > + case NL80211_CHAN_WIDTH_5:
> > + return "5 MHz";
> > + case NL80211_CHAN_WIDTH_10:
> > + return "10 MHz";
> > default:
> > return "unknown";
> > }
>
> Judging by the previous two entries, it looks like the case statements
> are sorted, so should these ones therefore be at the top of the list?
These are sorted by NL80211_CHAN_WIDTH_* attribute value, which makes
a little more sense to me than sorting by the string or numerically by
width, but sure, I can do it either way.
--
Bob Copeland %% http://bobcopeland.com/
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Stanislaw Gruszka @ 2016-07-22 10:26 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Prarit Bhargava, Emmanuel Grumbach, Michal Kazior, Kalle Valo,
linux-wireless, ath10k, Arend van Spriel, Greg Kroah-Hartman,
Ming Lei, Luis R. Rodriguez
In-Reply-To: <a264e995-fc46-7fcd-69f9-80992385b6b1@broadcom.com>
On Fri, Jul 22, 2016 at 10:38:24AM +0200, Arend Van Spriel wrote:
> + Luis
>
> On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> > (cc: firmware and brcmfmac maintainers)
> >
> > On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
> >>
> >>
> >> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
> >>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
> >>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> >>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
> >>>>>> Firmware files are versioned to prevent older
> >>>>>> driver instances to load unsupported firmware
> >>>>>> blobs. This is reflected with a fallback logic
> >>>>>> which attempts to load several firmware files.
> >>>>>>
> >>>>>> This however produced a lot of unnecessary
> >>>>>> warnings sometimes confusing users and leading
> >>>>>> them to rename firmware files making things even
> >>>>>> more confusing.
> >>>>>
> >>>>> This happens on kernels configured with
> >>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
> >>>>> but also 60 seconds delay before loading next firmware version.
> >>>>> For some reason RHEL kernel needs above config option, so this
> >>>>> patch is very welcome from my perspective.
> >>>>>
> >>>>
> >>>> Sorry for my ignorance but how does the firmware loading work if not
> >>>> with udev's help?
> >>>
> >>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
> >>> file data directly from mounted filesystem without user space helper.
> >>
> >> Here's the situation: request_firmware() waits 60 seconds for udev to do its
> >> loading magic via a "usermode helper". This delay is there to allow, for
> >> example, userspace to unpack or download a new firmware image or verify the
> >> firmware image *in userspace* before providing it to the driver to apply to the HW.
> >>
> >> Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
> >> handshake on completion.
> >>
> >>>
> >>>> As you can imagine, iwlwifi is suffering from the
> >>>> same problem and I would be interested in applying the same change,
> >>>> but I'd love to understand a bit more :)
> >>>
> >>> Yes, iwlwifi (and some other drivers) suffer from this. However this
> >>> happen when the newest firmware version is not installed on the system
> >>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
> >>> it's not common.
> >>
> >> request_firmware_direct() was introduced at my request because (as you've
> >> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
> >> periods of time when starting. The bug that this introduced was a 60 second
> >> delay per logical cpu when starting a system. On a 64 cpu system that meant the
> >> boot would complete in a little over one hour.
> >>
> >>>
> >>> I started to see this currently, because that option was enabled on
> >>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
> >>> happened because of that, i.e. thermal device was not functional
> >>> because f/w wasn't loaded due to big delay.
> >>>
> >>> I'm not sure if replacing to request_firmware_direct() is a good
> >>> fix though. For example I can see this problem also on brcmfmac, which
> >>> use request_firmware_nowait(). I think I would rather prefer special
> >>> helper for firmware drivers that needs user helper and have
> >>> request_firmware() be direct as default.
> >>>
> >>
> >> The difference between request_firmware_direct() and request_firmware() is that
> >> the _direct() version does not wait the 60 seconds for udev interaction. The
> >> only userspace check performed is to see if the file is there, and if the file
> >> does exist it is provided to the driver to be applied to the hardware.
> >>
> >> So the real question to ask here is whether or not the ath10k, brcmfmac, and
> >> iwlwifi require udev to do anything beyond checking for the existence and
> >> loading the firmware image. If they don't, then it is better to use
> >> request_firmware_direct().
> >
> > They don't need that, like 99% of the drivers I think, hence changing the
> > default seems to be more reasonable. However changing 3 drivers would work
> > for me as well, and that change do not introduce risk of broking drivers
> > that require udev fw download.
> >
> > iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> > use request_firmware_nowait(), so it first need to be converted to
> > ordinary request_firmware(), but this should be doable and I can do
> > that.
>
> I am going bonkers here. This is the Nth time a discussion pops up on
> firmware API usage. I stopped counting N :-( So the first issue was that
> the INIT was taking to long as we were requesting firmware during probe
> which was executed in the INIT context. So we added a worker and
> register the driver from there. There was probably a reason for
> switching to _no_wait() as well, but I do not recall the details. The
> things is I don't know if I need user-space or not. I just need firmware
> to get the device up and running. We have changed our driver a couple of
> times now to accommodate something that in my opinion should have been
> abstracted behind the firmware API in the first place and now here is
> another proposal to change the drivers. Come on!
I understand you dislike that :-) Just to clarify the issue here:
Some drivers (including brcmfmac) request new firmware images, which are
not yet available (i.e. development F/W versions) and then fall-back
to older firmware version and works perfectly fine.
However with CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y configured, in case
of missing F/W image, request firmware involve user space helper and
waits 60s (loading_timeout value from drivers/base/firmware_class.c),
what delays creating network interface and confuse users.
For brcmfmac this looks like this:
[ 15.160923] brcmfmac 0000:03:00.0: Direct firmware load for brcm/brcmfmac4356-pcie.txt failed with error -2
[ 15.170759] brcmfmac 0000:03:00.0: Falling back to user helper
<snip>
[ 75.709397] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Oct 22 2015 06:16:41 version 7.35.180.119 (r594535) FWID 01-1a5c4016
[ 75.736941] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code (0x30 0x30)
Without CONFIG_FW_LOADER_USER_HELPER_FALLBACK first firmware request
silently fail and then instantly next F/W image is loaded.
Another option to solve to problem would be stop requesting not
available publicly firmware. However, I assume some drivers would
like to preserve that option.
> > However I wonder if changing that will not broke the case when
> > driver is build-in in the kernel and f/w is not yet available when
> > driver start to initialize. Or maybe nowadays this is not the case
> > any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
> > images are build-in in the kernel or copied to initramfs?
>
> That is a nice idea, but I have not seen any change in that area. Could
> have missed it.
I believe this is how the things are already done, IOW switching to
request_firmware_direct() in the driver should be no harm.
Stanislaw
^ permalink raw reply
* Re: [PATCH] iw: display 5/10 MHz channel widths
From: Julian Calaby @ 2016-07-22 9:53 UTC (permalink / raw)
To: Bob Copeland; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <20160721153948.32171-1-me@bobcopeland.com>
Hi Bob,
On Fri, Jul 22, 2016 at 1:39 AM, Bob Copeland <me@bobcopeland.com> wrote:
> iw was showing 'width: unknown' for channels on OCB interfaces; teach
> it the values for 5/10 MHz so it will show the configured width.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
> interface.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/interface.c b/interface.c
> index 209561d..2802235 100644
> --- a/interface.c
> +++ b/interface.c
> @@ -295,6 +295,10 @@ char *channel_width_name(enum nl80211_chan_width width)
> return "80+80 MHz";
> case NL80211_CHAN_WIDTH_160:
> return "160 MHz";
> + case NL80211_CHAN_WIDTH_5:
> + return "5 MHz";
> + case NL80211_CHAN_WIDTH_10:
> + return "10 MHz";
> default:
> return "unknown";
> }
Judging by the previous two entries, it looks like the case statements
are sorted, so should these ones therefore be at the top of the list?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* [PATCH v3] cfg80211: Allow different beacon interval if driver supports
From: Purushottam Kushwaha @ 2016-07-22 9:42 UTC (permalink / raw)
To: johannes
Cc: linux-wireless, jouni, usdutt, ganeshk, mkalikot, amarnath,
pkushwah
Driver may allow support for different beacon interval on virtual interfaces.
Allow if such support is advertised by driver. This adds new ext_feature as
NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL.
Signed-off-by: Purushottam Kushwaha <pkushwah@qti.qualcomm.com>
---
include/uapi/linux/nl80211.h | 3 +++
net/wireless/util.c | 4 ++++
2 files changed, 7 insertions(+)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 2206941..a910d0e 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4551,6 +4551,8 @@ enum nl80211_feature_flags {
* (if available).
* @NL80211_EXT_FEATURE_SET_SCAN_DWELL: This driver supports configuration of
* channel dwell time.
+ * @NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL: This driver supports different
+ * beacon interval on virtual interfaces.
*
* @NUM_NL80211_EXT_FEATURES: number of extended features.
* @MAX_NL80211_EXT_FEATURES: highest extended feature index.
@@ -4562,6 +4564,7 @@ enum nl80211_ext_feature_index {
NL80211_EXT_FEATURE_SCAN_START_TIME,
NL80211_EXT_FEATURE_BSS_PARENT_TSF,
NL80211_EXT_FEATURE_SET_SCAN_DWELL,
+ NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL,
/* add new features before the definition below */
NUM_NL80211_EXT_FEATURES,
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 2443ee3..65eeb23 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -1560,6 +1560,10 @@ int cfg80211_validate_beacon_int(struct cfg80211_registered_device *rdev,
if (!beacon_int)
return -EINVAL;
+ if (wiphy_ext_feature_isset(&rdev->wiphy,
+ NL80211_EXT_FEATURE_DIFF_BEACON_INTERVAL))
+ return 0;
+
list_for_each_entry(wdev, &rdev->wiphy.wdev_list, list) {
if (!wdev->beacon_interval)
continue;
--
1.9.1
^ permalink raw reply related
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 8:48 UTC (permalink / raw)
To: Arend Van Spriel, linux-wireless@vger.kernel.org, Dan Williams
In-Reply-To: <CANXHH3mn2U5X5n9OB6+uESDgeRt6r6WyGV5wT0=MQwvuvD870g@mail.gmail.com>
Looking through the log lines I see gaps between what WPA is doing and what
dmesg reports and figured this is because of the libertas debugging level
so I’ve set that to 0xfffffff (for libertas) and created a combined log of
the events from both sources labelled with either [wpa] or [dmesg] and
timestamped which should help to give a much clearer combined picture:
http://termbin.com/sjqn
I’ll have a look through and see if anything jumps out at me but I wanted
to send it out to get expert eyes on it.
As a side note - I really appreciate all of the help on this so far -
there’s a beer in it for all involved! :P
Christopher Williamson
On 22 July 2016 at 09:21:44, Christopher Williamson
(home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
> I was thinking about redirecting the wpa logging to syslog but figured I’d take the lazy way out by abusing curl:
>
> curl -s http://termbin.com/cx0e http://termbin.com/bvdj | sort
>
> Resulting combined log file:
> http://termbin.com/909y
>
> Christopher Williamson
>
>
> On 22 July 2016 at 09:09:59, Arend Van Spriel (arend.vanspriel@broadcom.com(mailto:arend.vanspriel@broadcom.com)) wrote:
>
> > On 22-7-2016 0:00, Christopher Williamson wrote:
> > > I’ve created cleaner logs (particularly the dmesg one) and have added
> > > timestamps line-by-line to both so it should be easier to track
> > > between the two log files:
> > >
> > > wpa_supplicant:
> > > http://termbin.com/cx0e
> > >
> > > dmesg | grep libertas:
> > > http://termbin.com/bvdj
> >
> > You can make wpa_supplicant log to syslog. That way you get kernel and
> > wpa_supplicant log in one file.
> >
> > Regards,
> > Arend
> >
> > > Christopher Williamson
> > >
> > >
> > >
> > >
> > > On 21 July 2016 at 22:00:02, Christopher Williamson
> > > (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > >
> > >> Sure!
> > >>
> > >> wpa_supplicant logs:
> > >> http://termbin.com/z1hg
> > >>
> > >> dmesg logs (grepped for libertas):
> > >> http://termbin.com/7rt5
> > >>
> > >>
> > >> Christopher Williamson
> > >>
> > >>
> > >>
> > >>
> > >> On 21 July 2016 at 21:38:26, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > >>
> > >>> On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson wrote:
> > >>>> Just to confirm - I can connect to the same network using the same
> > >>>> configurations using a USB wifi adapter I tried.
> > >>>
> > >>> Can you grab simultaneous driver debug logging and supplicant debug
> > >>> logging? Unfortunately the 'status 1' is an unspecified failure, which
> > >>> could be from the AP or the firmware.
> > >>>
> > >>> Dan
> > >>>
> > >>>
> > >>>> Unfortunately it’s not ideal since the point of the Viliv N5 is that
> > >>>> it’s ultra portable so I would really like to get the inbuilt wifi
> > >>>> card working.
> > >>>>
> > >>>> It seems odd that wpa_supplicant reports the connection being
> > >>>> “rejected” as seen below:
> > >>>>
> > >>>> wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
> > >>>>
> > >>>> Most of the debug output sadly doesn’t mean a great deal to me - wifi
> > >>>> isn’t really my area of expertise.
> > >>>>
> > >>>> On 21 July 2016 at 19:10:56, Christopher Williamson
> > >>>> (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> Sure, here are the results:
> > >>>>>
> > >>>>> http://termbin.com/e8e2
> > >>>>>
> > >>>>> Christopher Williamson
> > >>>>>
> > >>>>>
> > >>>>> On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.com(mailto:d
> > >>>>> cbw@redhat.com)) wrote:
> > >>>>>
> > >>>>>>
> > >>>>>> On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> > >>>>>>>
> > >>>>>>> I used NetworkManager in the previous test.
> > >>>>>>>
> > >>>>>>> This time around I have used wpa_supplicant directly and get
> > >>>>>>> the
> > >>>>>>> following results:
> > >>>>>>>
> > >>>>>>> http://termbin.com/j8ea
> > >>>>>>>
> > >>>>>>> Thought I’d throw them on a pastebin since it’s over 700 lines.
> > >>>>>> Can you try with "-D nl80211" instead of using the WEXT
> > >>>>>> supplicant
> > >>>>>> driver? NM is likely going to use nl80211 since the driver has
> > >>>>>> some
> > >>>>>> support for cfg80211/nl80211 and only does WEXT through the glue
> > >>>>>> layer.
> > >>>>>>
> > >>>>>> Dan
> > >>>>>>
> > >>>>>>>
> > >>>>>>> Christopher Williamson
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On 20 July 2016 at 22:50:34, Dan Williams
> > >>>>>>> (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> > >>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson
> > >>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Hi Dan,
> > >>>>>>>>>
> > >>>>>>>>> Ah - yeah I hadn’t thought it may be a kernel build option.
> > >>>>>>>>> I’ve
> > >>>>>>>>> now
> > >>>>>>>>> built that and dmesg is a much more lively place!
> > >>>>>>>>>
> > >>>>>>>>> I’ve provided output logs for both when the device is
> > >>>>>>>>> connected
> > >>>>>>>>> and
> > >>>>>>>>> when a connection attempt is made - hopefully this is
> > >>>>>>>>> useful.
> > >>>>>>>>
> > >>>>>>>> The card is scanning and only finds 'shaunthesheep' 20
> > >>>>>>>> seconds
> > >>>>>>>> after
> > >>>>>>>> you "connect for the first time". The logs stop 3 seconds
> > >>>>>>>> later.
> > >>>>>>>> Are
> > >>>>>>>> you connecting with wicd or something else?
> > >>>>>>>>
> > >>>>>>>> Can you run wpa_supplicant with the "-dddtu" option so we can
> > >>>>>>>> get
> > >>>>>>>> debug
> > >>>>>>>> log output from it?
> > >>>>>>>>
> > >>>>>>>> Dan
> > >>>>>>> --
> > >>>>>>> To unsubscribe from this list: send the line "unsubscribe
> > >>>>>>> linux-
> > >>>>>>> wireless" in
> > >>>>>>> the body of a message to majordomo@vger.kernel.org
> > >>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.ht
> > >>>>>>> ml
> > >>>> --
> > >>>> To unsubscribe from this list: send the line "unsubscribe linux-
> > >>>> wireless" in
> > >>>> the body of a message to majordomo@vger.kernel.org
> > >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >>> --
> > >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > >>> the body of a message to majordomo@vger.kernel.org
> > >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >>
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
^ permalink raw reply
* Re: [RFC] ath10k: silence firmware file probing warnings
From: Arend Van Spriel @ 2016-07-22 8:38 UTC (permalink / raw)
To: Stanislaw Gruszka, Prarit Bhargava
Cc: Emmanuel Grumbach, Michal Kazior, Kalle Valo, linux-wireless,
ath10k, Arend van Spriel, Greg Kroah-Hartman, Ming Lei,
Luis R. Rodriguez
In-Reply-To: <20160721115122.GA31869@redhat.com>
+ Luis
On 21-7-2016 13:51, Stanislaw Gruszka wrote:
> (cc: firmware and brcmfmac maintainers)
>
> On Thu, Jul 21, 2016 at 06:23:11AM -0400, Prarit Bhargava wrote:
>>
>>
>> On 07/21/2016 04:05 AM, Stanislaw Gruszka wrote:
>>> On Thu, Jul 21, 2016 at 10:36:42AM +0300, Emmanuel Grumbach wrote:
>>>> On Thu, Jul 21, 2016 at 10:09 AM, Stanislaw Gruszka <sgruszka@redhat.com> wrote:
>>>>> On Tue, Jul 19, 2016 at 03:00:37PM +0200, Michal Kazior wrote:
>>>>>> Firmware files are versioned to prevent older
>>>>>> driver instances to load unsupported firmware
>>>>>> blobs. This is reflected with a fallback logic
>>>>>> which attempts to load several firmware files.
>>>>>>
>>>>>> This however produced a lot of unnecessary
>>>>>> warnings sometimes confusing users and leading
>>>>>> them to rename firmware files making things even
>>>>>> more confusing.
>>>>>
>>>>> This happens on kernels configured with
>>>>> CONFIG_FW_LOADER_USER_HELPER_FALLBACK and cause not only ugly warnings,
>>>>> but also 60 seconds delay before loading next firmware version.
>>>>> For some reason RHEL kernel needs above config option, so this
>>>>> patch is very welcome from my perspective.
>>>>>
>>>>
>>>> Sorry for my ignorance but how does the firmware loading work if not
>>>> with udev's help?
>>>
>>> I'm not sure exactly, but I think kernel VFS layer is capable to copy
>>> file data directly from mounted filesystem without user space helper.
>>
>> Here's the situation: request_firmware() waits 60 seconds for udev to do its
>> loading magic via a "usermode helper". This delay is there to allow, for
>> example, userspace to unpack or download a new firmware image or verify the
>> firmware image *in userspace* before providing it to the driver to apply to the HW.
>>
>> Why 60 seconds? It is arbitrary and there is no way for udev & the kernel to
>> handshake on completion.
>>
>>>
>>>> As you can imagine, iwlwifi is suffering from the
>>>> same problem and I would be interested in applying the same change,
>>>> but I'd love to understand a bit more :)
>>>
>>> Yes, iwlwifi (and some other drivers) suffer from this. However this
>>> happen when the newest firmware version is not installed on the system
>>> and CONFIG_FW_LOADER_USER_HELPER_FALLBACK is enabled. What I suppose
>>> it's not common.
>>
>> request_firmware_direct() was introduced at my request because (as you've
>> noticed) when CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y drivers may stall for long
>> periods of time when starting. The bug that this introduced was a 60 second
>> delay per logical cpu when starting a system. On a 64 cpu system that meant the
>> boot would complete in a little over one hour.
>>
>>>
>>> I started to see this currently, because that option was enabled on
>>> RHEL kernel. BTW: I think Prarit iwlwifi thermal_zone problem was
>>> happened because of that, i.e. thermal device was not functional
>>> because f/w wasn't loaded due to big delay.
>>>
>>> I'm not sure if replacing to request_firmware_direct() is a good
>>> fix though. For example I can see this problem also on brcmfmac, which
>>> use request_firmware_nowait(). I think I would rather prefer special
>>> helper for firmware drivers that needs user helper and have
>>> request_firmware() be direct as default.
>>>
>>
>> The difference between request_firmware_direct() and request_firmware() is that
>> the _direct() version does not wait the 60 seconds for udev interaction. The
>> only userspace check performed is to see if the file is there, and if the file
>> does exist it is provided to the driver to be applied to the hardware.
>>
>> So the real question to ask here is whether or not the ath10k, brcmfmac, and
>> iwlwifi require udev to do anything beyond checking for the existence and
>> loading the firmware image. If they don't, then it is better to use
>> request_firmware_direct().
>
> They don't need that, like 99% of the drivers I think, hence changing the
> default seems to be more reasonable. However changing 3 drivers would work
> for me as well, and that change do not introduce risk of broking drivers
> that require udev fw download.
>
> iwlwifi and ath10k are trivial, bcrmfmac is a bit more complex as it
> use request_firmware_nowait(), so it first need to be converted to
> ordinary request_firmware(), but this should be doable and I can do
> that.
I am going bonkers here. This is the Nth time a discussion pops up on
firmware API usage. I stopped counting N :-( So the first issue was that
the INIT was taking to long as we were requesting firmware during probe
which was executed in the INIT context. So we added a worker and
register the driver from there. There was probably a reason for
switching to _no_wait() as well, but I do not recall the details. The
things is I don't know if I need user-space or not. I just need firmware
to get the device up and running. We have changed our driver a couple of
times now to accommodate something that in my opinion should have been
abstracted behind the firmware API in the first place and now here is
another proposal to change the drivers. Come on!
> However I wonder if changing that will not broke the case when
> driver is build-in in the kernel and f/w is not yet available when
> driver start to initialize. Or maybe nowadays this is not the case
> any longer, i.e. the MODULE_FIRMWARE macros assure proper f/w
> images are build-in in the kernel or copied to initramfs?
That is a nice idea, but I have not seen any change in that area. Could
have missed it.
Regards,
Arend
> Thanks
> Stanislaw
>
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Christopher Williamson @ 2016-07-22 8:21 UTC (permalink / raw)
To: Dan Williams, linux-wireless@vger.kernel.org, Arend Van Spriel
In-Reply-To: <435adbc6-9fa3-e9e3-9815-8cf4b62e5342@broadcom.com>
I was thinking about redirecting the wpa logging to syslog but figured
I’d take the lazy way out by abusing curl:
curl -s http://termbin.com/cx0e http://termbin.com/bvdj | sort
Resulting combined log file:
http://termbin.com/909y
Christopher Williamson
On 22 July 2016 at 09:09:59, Arend Van Spriel
(arend.vanspriel@broadcom.com(mailto:arend.vanspriel@broadcom.com))
wrote:
> On 22-7-2016 0:00, Christopher Williamson wrote:
> > I’ve created cleaner logs (particularly the dmesg one) and have added
> > timestamps line-by-line to both so it should be easier to track
> > between the two log files:
> >
> > wpa_supplicant:
> > http://termbin.com/cx0e
> >
> > dmesg | grep libertas:
> > http://termbin.com/bvdj
>
> You can make wpa_supplicant log to syslog. That way you get kernel and
> wpa_supplicant log in one file.
>
> Regards,
> Arend
>
> > Christopher Williamson
> >
> >
> >
> >
> > On 21 July 2016 at 22:00:02, Christopher Williamson
> > (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> >
> >> Sure!
> >>
> >> wpa_supplicant logs:
> >> http://termbin.com/z1hg
> >>
> >> dmesg logs (grepped for libertas):
> >> http://termbin.com/7rt5
> >>
> >>
> >> Christopher Williamson
> >>
> >>
> >>
> >>
> >> On 21 July 2016 at 21:38:26, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> >>
> >>> On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson wrote:
> >>>> Just to confirm - I can connect to the same network using the same
> >>>> configurations using a USB wifi adapter I tried.
> >>>
> >>> Can you grab simultaneous driver debug logging and supplicant debug
> >>> logging? Unfortunately the 'status 1' is an unspecified failure, which
> >>> could be from the AP or the firmware.
> >>>
> >>> Dan
> >>>
> >>>
> >>>> Unfortunately it’s not ideal since the point of the Viliv N5 is that
> >>>> it’s ultra portable so I would really like to get the inbuilt wifi
> >>>> card working.
> >>>>
> >>>> It seems odd that wpa_supplicant reports the connection being
> >>>> “rejected” as seen below:
> >>>>
> >>>> wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
> >>>>
> >>>> Most of the debug output sadly doesn’t mean a great deal to me - wifi
> >>>> isn’t really my area of expertise.
> >>>>
> >>>> On 21 July 2016 at 19:10:56, Christopher Williamson
> >>>> (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> Sure, here are the results:
> >>>>>
> >>>>> http://termbin.com/e8e2
> >>>>>
> >>>>> Christopher Williamson
> >>>>>
> >>>>>
> >>>>> On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.com(mailto:d
> >>>>> cbw@redhat.com)) wrote:
> >>>>>
> >>>>>>
> >>>>>> On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
> >>>>>>>
> >>>>>>> I used NetworkManager in the previous test.
> >>>>>>>
> >>>>>>> This time around I have used wpa_supplicant directly and get
> >>>>>>> the
> >>>>>>> following results:
> >>>>>>>
> >>>>>>> http://termbin.com/j8ea
> >>>>>>>
> >>>>>>> Thought I’d throw them on a pastebin since it’s over 700 lines.
> >>>>>> Can you try with "-D nl80211" instead of using the WEXT
> >>>>>> supplicant
> >>>>>> driver? NM is likely going to use nl80211 since the driver has
> >>>>>> some
> >>>>>> support for cfg80211/nl80211 and only does WEXT through the glue
> >>>>>> layer.
> >>>>>>
> >>>>>> Dan
> >>>>>>
> >>>>>>>
> >>>>>>> Christopher Williamson
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> On 20 July 2016 at 22:50:34, Dan Williams
> >>>>>>> (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Hi Dan,
> >>>>>>>>>
> >>>>>>>>> Ah - yeah I hadn’t thought it may be a kernel build option.
> >>>>>>>>> I’ve
> >>>>>>>>> now
> >>>>>>>>> built that and dmesg is a much more lively place!
> >>>>>>>>>
> >>>>>>>>> I’ve provided output logs for both when the device is
> >>>>>>>>> connected
> >>>>>>>>> and
> >>>>>>>>> when a connection attempt is made - hopefully this is
> >>>>>>>>> useful.
> >>>>>>>>
> >>>>>>>> The card is scanning and only finds 'shaunthesheep' 20
> >>>>>>>> seconds
> >>>>>>>> after
> >>>>>>>> you "connect for the first time". The logs stop 3 seconds
> >>>>>>>> later.
> >>>>>>>> Are
> >>>>>>>> you connecting with wicd or something else?
> >>>>>>>>
> >>>>>>>> Can you run wpa_supplicant with the "-dddtu" option so we can
> >>>>>>>> get
> >>>>>>>> debug
> >>>>>>>> log output from it?
> >>>>>>>>
> >>>>>>>> Dan
> >>>>>>> --
> >>>>>>> To unsubscribe from this list: send the line "unsubscribe
> >>>>>>> linux-
> >>>>>>> wireless" in
> >>>>>>> the body of a message to majordomo@vger.kernel.org
> >>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.ht
> >>>>>>> ml
> >>>> --
> >>>> To unsubscribe from this list: send the line "unsubscribe linux-
> >>>> wireless" in
> >>>> the body of a message to majordomo@vger.kernel.org
> >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: Problem connecting to wifi on libertas_cpio (sd8686)
From: Arend Van Spriel @ 2016-07-22 8:09 UTC (permalink / raw)
To: Christopher Williamson, linux-wireless@vger.kernel.org,
Dan Williams
In-Reply-To: <CANXHH3=852nV-4rjt8bO47Mbt02JNHNFGzytk3kiV1RQ39rLwg@mail.gmail.com>
On 22-7-2016 0:00, Christopher Williamson wrote:
> I’ve created cleaner logs (particularly the dmesg one) and have added
> timestamps line-by-line to both so it should be easier to track
> between the two log files:
>
> wpa_supplicant:
> http://termbin.com/cx0e
>
> dmesg | grep libertas:
> http://termbin.com/bvdj
You can make wpa_supplicant log to syslog. That way you get kernel and
wpa_supplicant log in one file.
Regards,
Arend
> Christopher Williamson
>
>
>
>
> On 21 July 2016 at 22:00:02, Christopher Williamson
> (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>
>> Sure!
>>
>> wpa_supplicant logs:
>> http://termbin.com/z1hg
>>
>> dmesg logs (grepped for libertas):
>> http://termbin.com/7rt5
>>
>>
>> Christopher Williamson
>>
>>
>>
>>
>> On 21 July 2016 at 21:38:26, Dan Williams (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>>
>>> On Thu, 2016-07-21 at 11:55 -0700, Christopher Williamson wrote:
>>>> Just to confirm - I can connect to the same network using the same
>>>> configurations using a USB wifi adapter I tried.
>>>
>>> Can you grab simultaneous driver debug logging and supplicant debug
>>> logging? Unfortunately the 'status 1' is an unspecified failure, which
>>> could be from the AP or the firmware.
>>>
>>> Dan
>>>
>>>
>>>> Unfortunately it’s not ideal since the point of the Viliv N5 is that
>>>> it’s ultra portable so I would really like to get the inbuilt wifi
>>>> card working.
>>>>
>>>> It seems odd that wpa_supplicant reports the connection being
>>>> “rejected” as seen below:
>>>>
>>>> wlan0: CTRL-EVENT-ASSOC-REJECT bssid=a0:63:91:1e:ee:43 status_code=1
>>>>
>>>> Most of the debug output sadly doesn’t mean a great deal to me - wifi
>>>> isn’t really my area of expertise.
>>>>
>>>> On 21 July 2016 at 19:10:56, Christopher Williamson
>>>> (home@chrisaw.com(mailto:home@chrisaw.com)) wrote:
>>>>
>>>>>
>>>>>
>>>>> Sure, here are the results:
>>>>>
>>>>> http://termbin.com/e8e2
>>>>>
>>>>> Christopher Williamson
>>>>>
>>>>>
>>>>> On 21 July 2016 at 16:37:24, Dan Williams (dcbw@redhat.com(mailto:d
>>>>> cbw@redhat.com)) wrote:
>>>>>
>>>>>>
>>>>>> On Wed, 2016-07-20 at 15:16 -0700, Christopher Williamson wrote:
>>>>>>>
>>>>>>> I used NetworkManager in the previous test.
>>>>>>>
>>>>>>> This time around I have used wpa_supplicant directly and get
>>>>>>> the
>>>>>>> following results:
>>>>>>>
>>>>>>> http://termbin.com/j8ea
>>>>>>>
>>>>>>> Thought I’d throw them on a pastebin since it’s over 700 lines.
>>>>>> Can you try with "-D nl80211" instead of using the WEXT
>>>>>> supplicant
>>>>>> driver? NM is likely going to use nl80211 since the driver has
>>>>>> some
>>>>>> support for cfg80211/nl80211 and only does WEXT through the glue
>>>>>> layer.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>>
>>>>>>> Christopher Williamson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20 July 2016 at 22:50:34, Dan Williams
>>>>>>> (dcbw@redhat.com(mailto:dcbw@redhat.com)) wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, 2016-07-20 at 13:06 -0700, Christopher Williamson
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hi Dan,
>>>>>>>>>
>>>>>>>>> Ah - yeah I hadn’t thought it may be a kernel build option.
>>>>>>>>> I’ve
>>>>>>>>> now
>>>>>>>>> built that and dmesg is a much more lively place!
>>>>>>>>>
>>>>>>>>> I’ve provided output logs for both when the device is
>>>>>>>>> connected
>>>>>>>>> and
>>>>>>>>> when a connection attempt is made - hopefully this is
>>>>>>>>> useful.
>>>>>>>>
>>>>>>>> The card is scanning and only finds 'shaunthesheep' 20
>>>>>>>> seconds
>>>>>>>> after
>>>>>>>> you "connect for the first time". The logs stop 3 seconds
>>>>>>>> later.
>>>>>>>> Are
>>>>>>>> you connecting with wicd or something else?
>>>>>>>>
>>>>>>>> Can you run wpa_supplicant with the "-dddtu" option so we can
>>>>>>>> get
>>>>>>>> debug
>>>>>>>> log output from it?
>>>>>>>>
>>>>>>>> Dan
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>> linux-
>>>>>>> wireless" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.ht
>>>>>>> ml
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-
>>>> wireless" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH v3 3/3] mac80211: mesh: fixed HT ies in beacon template
From: Masashi Honma @ 2016-07-22 5:26 UTC (permalink / raw)
To: Yaniv Machani, linux-kernel
Cc: Meirav Kama, Johannes Berg, David S. Miller, linux-wireless,
netdev
In-Reply-To: <20160713200755.26839-1-yanivma@ti.com>
On 2016年07月14日 05:07, Yaniv Machani wrote:
> +
> + /* if channel width is 20MHz - configure HT capab accordingly*/
> + if (sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20) {
> + cap &= ~IEEE80211_HT_CAP_SUP_WIDTH_20_40;
> + cap &= ~IEEE80211_HT_CAP_DSSSCCK40;
> + }
I have tested this part of your patch and this works for me.
Previouly, "Supported Channel Width Set bit" in HT Capabilities element
was 1 even though disable_ht40=1 existed in wpa_supplicant.conf.
After appllication of patch, the bit was 0.
^ permalink raw reply
* Re: [PATCH] ath9k: fix misleading indent
From: Julian Calaby @ 2016-07-22 4:49 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-wireless
In-Reply-To: <20160721163107.686-1-me@bobcopeland.com>
Hi All,
On Fri, Jul 22, 2016 at 2:31 AM, Bob Copeland <me@bobcopeland.com> wrote:
> Fixes smatch warning:
>
> ath9k_vif_iter_set_beacon() warn if statement not indented
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
Looks right to me.
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
> ---
> drivers/net/wireless/ath/ath9k/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH 2/3] staging/rtl8192e: use s8 instead of char
From: Stefan Lippers-Hollmann @ 2016-07-22 2:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Jes Sorensen, linux-wireless, Kalle Valo, Larry Finger, netdev,
Greg Kroah-Hartman, Mateusz Kulikowski, devel, linux-kernel,
Andrea Merello
In-Reply-To: <8046944.AyQGVaNKWH@wuerfel>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
Hi
On 2016-07-20, Arnd Bergmann wrote:
> On Wednesday, July 20, 2016 11:33:43 AM CEST Jes Sorensen wrote:
> > Arnd Bergmann <arnd@arndb.de> writes:
> > > On Wednesday, July 20, 2016 7:25:19 AM CEST Jes Sorensen wrote:
> > >> Arnd Bergmann <arnd@arndb.de> writes:
[...]
> Yes, I was just agreeing here that it's not worth doing that one.
> As far as I can see, the evolution of these devices is
>
> RTL81xxU (2008)
> RTL81xxSU (2009)
> RTL81xxCU (2010)
There is also RTL81xxDU, apparently from 2011, a dualband device
coming in several variants (single MAC + single PHY, double MAC +
double PHY and double PHY); e.g. 0bda:8194 (single PHY + single MAC).
While probably not overly common, it was/ is (hardware-wise) a pretty
interesting device due to its support for 5 GHz[1] - actually I hoped
it to be a (supported-) RTL8192CU variant when I bought it.
Unfortunately no driver[2] made it to staging or the proper kernel.
> RTL81xxEU (2013)
Regards
Stefan Lippers-Hollmann
[1] apparently even concurrent operations for the double MAC +
double PHY variants
[2] https://github.com/lwfinger/rtl8192du
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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