Change the code to allow making all the rate control ops
const, nothing ever needs to change them. Also change all
drivers to make use of this and mark the ops const.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Restrict our published beamformee STS capability according
to the AP value.
Some AP show bad behaviour in interoperability testing
when our capabilities are better.
Signed-off-by: Eyal Shapira <eyalx.shapira@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Initialize the buffer to all zeroes, otherwise the stack
data might be interpreted as the TID, which is likely to
fail completely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In case the given ROC duration is 0, update it to a minimal value before
setting the ieee80211_roc_work parameters, so it also would be valid
for cases where scan is in progress or there are other ROCs queued.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Since we copy the mesh_id_len into our own data structures,
use it consistently and don't sometimes use cfg80211's copy.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The mesh_id is an array so can't ever be NULL, it looks
like mesh_id_len check was intended instead. However,
since the previous patch, cfg80211 does the check, so
just remove it here.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Before allowing userspace to initiate a channel switch, check
that it's actually connected in some sense. Also use a more
appropriate error code for the not connected case.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The mesh precedence value in ieee80211_channel_switch
should be incremented or set to 1 only if this is the
initiator of mesh channel switch. For non-initiator,
the precedence value has updated using the Mesh
Channel Switch Parameters element. Fix this.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix the following issues in reg_process_hint():
1. Add verification that wiphy is valid before processing
NL80211_REGDOMAIN_SET_BY_COUNTRY_IE.
2. Free the request in case of invalid initiator.
3. Remove WARN_ON check on reg_request->alpha2 as it is not a
pointer.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When IEEE80211_HW_SIGNAL_UNSPEC is set, mac80211 will perform a
division by max_signal in ieee80211_bss_info_update. If max_signal
is not properly set by the driver (for example it is zero) this
leads to a divide error and crash.
Thanks to Larry Finger, who pointed me to this.
This patch adds in ieee80211_register_hw one more check to detect
this condition and eventually returns -EINVAL, as already done for
other checks already performed there.
Signed-off-by: andrea merello <andrea.merello@gmail.com>
[move to an already existing SIGNAL_UNSPEC check]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Commit 7ec7c4a9a6 ("mac80211: port CCMP to cryptoapi's CCM driver")
resulted in the 'encrypted' param of ccmp_special_blocks() to be no
longer used so it can be dropped from the prototype.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Allow to force SGI, LGI.
Mainly for test purpose.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This required liberally sprinkling 'const' over brcmfmac
and mwifiex but seems like a useful thing to do since the
pointer can't really be written.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Addition of the frequency hints showed up couple of places in cfg80211
where pointers could be marked const and a shared function could be used
to fetch a valid channel.
Signed-off-by: Jouni Malinen <j@w1.fi>
[fix mwifiex]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This allows drivers to advertise the maximum number of associated
stations they support in AP mode (including P2P GO). User space
applications can use this for cleaner way of handling the limit (e.g.,
hostapd rejecting IEEE 802.11 authentication without manual
configuration of the limit) or to figure out what type of use cases can
be executed with multiple devices before trying and failing.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This clarifies the expected driver behavior on the older
NL80211_ATTR_MAC and NL80211_ATTR_WIPHY_FREQ attributes and adds a new
set of similar attributes with _HINT postfix to enable use of a
recommendation of the initial BSS to choose. This can be helpful for
some drivers that can avoid an additional full scan on connection
request if the information is provided to them (user space tools like
wpa_supplicant already has that information available based on earlier
scans).
In addition, this can be used to get more expected behavior for cases
where a specific BSS should be picked first based on operations like
Interworking network selection or WPS. These cases were already easily
addressed with drivers that leave BSS selection to user space, but there
was no convenient way to do this with drivers that take care of BSS
selection internally without using the NL80211_ATTR_MAC which is not
really desired since it is needed for other purposes to force the
association to remain with the same BSS.
Signed-off-by: Jouni Malinen <j@w1.fi>
[add const, fix policy]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A beacon should never have a Channel Switch Announcement information
element with a count of 0, because a count of 1 means switch just
before the next beacon. So, if a count of 0 was valid in a beacon, it
would have been transmitted in the next channel already, which is
useless. A CSA count equal to zero is only meaningful in action
frames or probe_responses.
Fix the ieee80211_csa_is_complete() and ieee80211_update_csa()
functions accordingly.
With a CSA count of 0, we won't transmit any CSA beacons, because the
switch will happen before the next TBTT. To avoid extra work and
potential confusion in the drivers, complete the CSA immediately,
instead of waiting for the driver to call ieee80211_csa_finish().
To keep things simpler, we also switch immediately when the CSA count
is 1, while in theory we should delay the switch until just before the
next TBTT.
Additionally, move the ieee80211_csa_finish() function to cfg.c,
where it makes more sense.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The return value of ieee80211_mesh_csa_beacon is not aligned with the
return value of ieee80211_assign_beacon() and
ieee80211_ibss_csa_beacon(). For consistency and to be able to use
both functions with similar code, change ieee80211_mesh_csa_beacon()
not to send the bss changed notification itself, but return what has
changed so the caller can send the notification instead.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Refactor ieee80211_mesh_process_chanswitch() to use
ieee80211_channel_switch() and avoid code duplication.
Tested-by: Simon Wunderlich <sw@simonwunderlich.de>
Acked-by: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: Luciano Coelho <luciano.coelho@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Hi Greg,
Here's four patches for 3.14.
One of them adds an xHCI host quirk, and the other three of them fix
regressions introduced in 3.14. One regression causes USB 3.0 Link PM to
be enabled on all xHCI hosts (even those that may not support it), which
causes some USB 3.0 devices to not enumerate. A second regression causes
some xHCI hosts that don't support 64-bit addressing to stop responding to
commands and die.
Note, these patches don't fix the recent usbfs regression that was caused
by commit 35773dac5f "usb: xhci: Link TRB
must not occur within a USB payload burst". I'm waiting for those patches
to be tested.
Please pull usb-linus into usb-next, as I have feature patches that rely on
140e3026a5 Revert "usbcore: set lpm_capable field for LPM capable root
hubs"
Sarah Sharp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAABAgAGBQJS8UyYAAoJEBMGWMLi1Gc5G9AP/jTLQoh/9ILE3fPN9UeXHr7x
TR3sWrB2JB6HzO53FJqoIWdnyei+GQRHRYKFZbJRMIXSdfI7EiJ9ZaFvGKYkOjyg
FblD2WqYn5jY2yiW8roxOebDzDadxxqafwtrqIGx88sV9o9yKInhBq5NqxD1ZC/X
QM9Dbgxed4TX6OVVE8hvUbzr1gldYiUr8rKfvN8X6RDBEi6wh6HV0B/7T96vw6Hp
hFDIgIdwgVYsnah2QjS007tpNFfWQtoi3sq+Jcq0S6QVpCrTPjPB6MqHJM/MQtG+
8JkmZRPA8jjwaPvow8Kx3bmt89H5Q/hWKlUPZmaShOO4OKN3xOQNh+FNbvqs1pPZ
XpL3/dv/w/zzQ7sqD2IaT9HiDfzeYfspdiv9QsSJg7XlfiulgdCggrhIGvta6p51
bR0JEHMxSuI/Aqe/fr5Prf4YyeWS+fDKIwRsaNXG143pd7hFJxoyT91QE3FCxAdD
qmw/YdeDT7J+3TB55OCPIxuaOTEjJQ9GyKXP/TKaSrTVWcH8/N0wNMa7IPSplysN
fgeNNDtZ0A7P4XyyMNxaQpbRcM39eV/yGaVR6yDqjJ4RlEZTTTOMfNSaVoCXIb74
3km6DVSqEQ0xPq08nrIcWbPqor+hShbw/bbUJCQBITKJp6oDeImacCvZw7RaYhfs
cx7UuQPKmv7iYaG1Vmcm
=sPwW
-----END PGP SIGNATURE-----
Merge tag 'for-usb-linus-2014-02-04' of git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci into usb-linus
Sarah writes:
xhci: Fix some regressions introduced in 3.14.
Hi Greg,
Here's four patches for 3.14.
One of them adds an xHCI host quirk, and the other three of them fix
regressions introduced in 3.14. One regression causes USB 3.0 Link PM to
be enabled on all xHCI hosts (even those that may not support it), which
causes some USB 3.0 devices to not enumerate. A second regression causes
some xHCI hosts that don't support 64-bit addressing to stop responding to
commands and die.
Note, these patches don't fix the recent usbfs regression that was caused
by commit 35773dac5f "usb: xhci: Link TRB
must not occur within a USB payload burst". I'm waiting for those patches
to be tested.
Please pull usb-linus into usb-next, as I have feature patches that rely on
140e3026a5 Revert "usbcore: set lpm_capable field for LPM capable root
hubs"
Sarah Sharp
Take non-idle time into account when calculating core busy time.
This ensures that intel_pstate will notice a decrease in load.
References: https://bugzilla.kernel.org/show_bug.cgi?id=66581
Cc: 3.10+ <stable@vger.kernel.org> # 3.10+
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Otherwise, spi_setup() fails with unsupported mode bits message.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Cc: stable@vger.kernel.org
We cannot unconditionally use dma_map_single() to map data for use with
SPI since transfers may exceed a page and virtual addresses may not be
provided with physically contiguous pages. Further, addresses allocated
using vmalloc() need to be mapped differently to other addresses.
Currently only the MXS driver handles all this, a few drivers do handle
the possibility that buffers may not be physically contiguous which is
the main potential problem but many don't even do that. Factoring this
out into the core will make it easier for drivers to do a good job so if
the driver is using the core DMA code then generate a scatterlist
instead of mapping to a single address so do that.
This code is mainly based on a combination of the existing code in the MXS
and PXA2xx drivers. In future we should be able to extend it to allow the
core to concatenate adjacent transfers if they are compatible, improving
performance.
Currently for simplicity clients are not allowed to use the scatterlist
when they do DMA mapping, in the future the existing single address
mappings will be replaced with use of the scatterlist most likely as
part of pre-verifying transfers.
This change makes it mandatory to use scatterlists when using the core DMA
mapping so update the s3c64xx driver to do this when used with dmaengine.
Doing so makes the code more ugly but it is expected that the old s3c-dma
code can be removed very soon.
Signed-off-by: Mark Brown <broonie@linaro.org>
It is fairly common for SPI devices to require that one or both transfer
directions is always active. Currently drivers open code this in various
ways with varying degrees of efficiency. Start factoring this out by
providing flags SPI_MASTER_MUST_TX and SPI_MASTER_MUST_RX. These will cause
the core to provide buffers for the requested direction if none are
specified in the underlying transfer.
Currently this is fairly inefficient since we actually allocate a data
buffer which may get large, support for mapping transfers using a
scatterlist will allow us to avoid this for DMA based transfers.
Signed-off-by: Mark Brown <broonie@linaro.org>
The commit, "ath9k_hw: Fix incorrect Tx control power in AR9003 template"
fixed the incorrect values in the eeprom templates, but if
boards have already been calibrated with incorrect values,
they would still be using the wrong TX power. Fix this by assigning
a default value in such cases.
Cc: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Even though we make sure PowerSave is not enabled by default
by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init,
PS could be enabled by userspace based on various factors
like battery usage etc. Since PS in ath9k is just broken
and has been untested for years, remove support for it, but
allow a user to explicitly enable it using a module parameter.
Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
mac80211 ->sta_rc_update() callback must be atomic. Since we have to
take mutex and do other operations that can sleep when sending fimrware
commands to device, the only option to satisfy atomicity requirement of
->sta_rc_update(), that I can see, is introduce work_struct and defer
uploading new rates to that work.
Tested-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Raw id and FW id should be switched.
Tested-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is a copy/paste of patch provided by Sujith for ath9k.
"Even though we make sure PowerSave is not enabled by default
by disabling the flag, WIPHY_FLAG_PS_ON_BY_DEFAULT on init,
PS could be enabled by userspace based on various factors
like battery usage etc. Since PS in ath9k is just broken
and has been untested for years, remove support for it, but
allow a user to explicitly enable it using a module parameter."
Cc: stable@vger.kernel.org
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is know that PS cause issues on that old devices, disable it by
default.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We have disabled it currently on other buses. PS can cause some issues,
not necessarily with our driver but on AP, that are not easy to debug.
Since behaviour differs on rt2800usb and rt2800pci, user usually blame
for malfunction rt2800usb driver, whereas issue is on AP side.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
sta_rc_update() callback must be atomic, hence we can not take mutexes
or do other operations, which can sleep in ath9k_htc_sta_rc_update().
I think we can just return from ath9k_htc_sta_rc_update(), if it is
called without IEEE80211_RC_SUPP_RATES_CHANGED bit. That will help
with scheduling while atomic bug for most cases (except mesh and IBSS
modes).
For mesh and IBSS I do not see other solution like creating additional
workqueue, because sending firmware command require us to sleep, but
this can be done in additional patch.
Patch partially fixes bug:
https://bugzilla.redhat.com/show_bug.cgi?id=990955
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Pull btrfs fixes from Chris Mason:
"Filipe is fixing compile and boot problems with our crc32c rework, and
Josef has disabled snapshot aware defrag for now.
As the number of snapshots increases, we're hitting OOM. For the
short term we're disabling things until a bigger fix is ready"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: use late_initcall instead of module_init
Btrfs: use btrfs_crc32c everywhere instead of libcrc32c
Btrfs: disable snapshot aware defrag for now
Add USB ID [2040:f900] for Hauppauge WinTV-MiniStick 2.
Device is build upon IT9135 chipset.
Tested-by: Stefan Becker <schtefan@gmx.net>
Signed-off-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
It really isn't very interesting to have DEBUG_INFO when doing compile
coverage stuff (you wouldn't want to run the result anyway, that's kind
of the whole point of COMPILE_TEST), and it currently makes the build
take longer and use much more disk space for "all{yes,mod}config".
There's somewhat active discussion about this still, and we might end up
with some new config option for things like this (Andi points out that
the silly X86_DECODER_SELFTEST option also slows down the normal
coverage tests hugely), but I'm starting the ball rolling with this
simple one-liner.
DEBUG_INFO isn't that noticeable if you have tons of memory and a good
IO subsystem, but it hurts you a lot if you don't - for very little
upside for the common use.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE.
While at it, add a #define for MAX_DSLP and make the message a bit more
informative.
v2: use DRM_INFO_ONCE, add MAX_DSLP, pimp the message.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Just like DRM_INFO(), but only do it once.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Moved to a common location so that Jani also can push to it, to avoid
moving it every time I go on vacation. Please update autobuilders and
everything else pointing at the drm-intel.git repo, the old one won't
be updated any more.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
This moves the set-up of the HREF500 with its AB8505 ASIC to
a device tree include. Since there is not yet any device tree
for this board the DTSI is currently unused. After this delete
the board file for pins for good and migration of pins to the
device tree is complete.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the AB8500 pin settings for the clock out pins over
to the device tree. We can delete the special setup calls for the
platforms only using the AB8500 and not AB8505.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the pin setup of the AB8500 modem I2C pins
(SCL/SDA) from the board file to the device tree.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the configuration of the AB8500 EXTCPENA pin
from the board file to the device tree.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This move the AB8500 DMIC (microphone) pin setup from the board
file to the device tree.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the set-up of the USB UICC (InteChip USB) from the
board file to the device tree.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the pin muxing and configuration for audio interface
one over to the device tree as a hog configuration.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the muxing and biasing of the AB8500 PWM output pins
over to the device tree for affected platforms.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
This moves the pin control settings for the YCBCR connector
on the AB8500 over to the device tree as a hog.
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
