Some MMCIF implementations support the Dual Data Rate. With this patch,
platforms can set the MMC_CAP_UHS_DDR50 capability flag in MMCIF platform
data. This will let the MMC core to actually use the DDR mode.
Signed-off-by: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
With this post-v2.6.35 change applied:
commit a0a1a5fd4f
Author: Tejun Heo <tj@kernel.org>
Date: Tue Jun 29 10:07:12 2010 +0200
workqueue: reimplement workqueue freeze using max_active
freeze_workqueues_begin() was introduced and workqueue now gets frozen
before device drivers suspend operations.
We have to ensure that run-time PM suspend operation completes before
system-wide suspend is started.
Signed-off-by: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
mmc_rescan() sends CMD52 (SD_IO_RW_DIRECT) to reset SDIO card during
card detection. CMD52 should be ignored by SD/eMMC cards, but we can
also abort it in the driver immediately, since MMCIF doesn't support
SDIO cards anyway.
Signed-off-by: Teppei Kamijou <teppei.kamijou.yb@renesas.com>
Signed-off-by: Shinya Kuribayashi <shinya.kuribayashi.px@renesas.com>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Since slot-gpio uses devm_* managed functions in mmc_gpio_request_cd()
now, we can remove those mmc_gpio_free_cd() call from host drivers'
.probe() error path and .remove().
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Use devm_* managed functions, so that slot-gpio users do not have to
call mmc_gpio_free_ro/cd to free up resources requested in
mmc_gpio_request_ro/cd.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Call mmc_gpio_get_cd() to query card presence from cd-gpio before
asking SDHCI. The rationale behind this change is that flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is designed for SDHCI controller to
tell that SDHCI_PRESENT_STATE is broken, and it should be used for this
case only. So when cd-gpio is being used, the controller should set
the flag to tell that SDHCI_PRESENT_STATE is not available.
However, the existing code will skip checking cd-gpio as long as flag
SDHCI_QUIRK_BROKEN_CARD_DETECTION is set. Change the querying order
between cd-gpio and SDHCI to support the rationale above.
Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
When SDIO3.0 card is detected, incorrect bus speed mode
is printed as part of card detection print in kernel logs.
This change fixes it so that user won't be confused by
looking at incorrect card detection message in logs.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Tested-by: Jackey Shen <Jackey.Shen@amd.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
According to UHS-I initialization sequence for SDIO 3.0 cards,
the host must set bit[24] (S18R) of OCR register during OCR
handshake to know whether the SDIO card is capable of doing
1.8V I/O.
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org>
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Reviewed-by: Johan Rudholm <johan.rudholm@stericsson.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
If SDIO keep power flag (MMC_PM_KEEP_POWER) is not set, card would
be reinitialized during resume but as we are not resetting
(CMD52 reset) the SDIO card during this reinitialization, card may
fail to respond back to subsequent commands (CMD5 etc...).
This change resets the card before the reinitialization of card
during resume.
Signed-off-by: Subhash Jadavani <subhashj@codeaurora.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
When we get to association, the AP station already exists and
is marked authenticated, so moving it into IEEE80211_STA_AUTH
again is a NOP, remove it.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Now that we have channel contexts, idle is (pretty
much) equivalent to not having a channel context.
Change the code to use this relation so that there
no longer is a need for a lot of idle recalculate
calls everywhere.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are only a few drivers that use HW scan, and
all of those don't need a non-idle transition before
starting the scan -- some don't even care about idle
at all. Remove the flag and code associated with it.
The only driver that really actually needed this is
wl1251 and it can just do it itself in the hw_scan
callback -- implement that.
Acked-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The functions were added for some sort of Bluetooth
coexistence, but aren't used, so remove them again.
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In order to be able to predict the next DTIM TBTT
in the driver, add the ability to use timing data
from beacons only with the new hardware flag
IEEE80211_HW_TIMING_BEACON_ONLY and the BSS info
value sync_dtim_count which is only valid if the
timing data came from a beacon. The data can only
come from a beacon, and if no beacon was received
before association it is updated later together
with the DTIM count notification.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
While technically the TSF isn't an IE, it can be
necessary to distinguish between the TSF from a
beacon and a probe response, in particular in
order to know the next DTIM TBTT, as not all APs
are spec compliant wrt. TSF==0 being a DTIM TBTT
and thus the DTIM count needs to be taken into
account as well.
To allow this, move the TSF into the IE struct
so it can be known whence it came.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's no way scan BSS IEs can be NULL as even
if the allocation fails the frame is discarded.
Remove some code checking for this and document
that it is always non-NULL.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add debugfs driver callbacks so drivers can add
debugfs entries for interfaces. Note that they
_must_ remove the entries again as add/remove in
the driver doesn't correspond to add/remove in
debugfs; the former is up/down while the latter
is netdev create/destroy.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, cfg80211 will copy beacon IEs from a previously
received hidden SSID beacon to a probe response entry, if
that entry is created after the beacon entry. However, if
it is the other way around, or if the beacon is updated,
such changes aren't propagated.
Fix this by tracking the relation between the probe
response and beacon BSS structs in this case.
In case drivers have private data stored in a BSS struct
and need access to such data from a beacon entry, cfg80211
now provides the hidden_beacon_bss pointer from the probe
response entry to the beacon entry.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently the code assigns channel contexts to VLANs
(for use by the TX/RX code) when the AP master gets
its channel context assigned. This works fine, but
in the upcoming radar detection work the VLANs don't
require a channel context (during radar detection)
and assigning one to them anyway causes issues with
locking and also inconsistencies -- a VLAN interface
that is added before radar detection would get the
channel context, while one added during it wouldn't.
Fix these issues moving the channel context copying
to a new explicit operation that will not be used
in the radar detection code.
Acked-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The chandef tracing writes center_freq1 twice, so
that it is always 0 (no driver supports 80+80 yet)
and leaves center_freq2 unset. Fix this mistake.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The messages currently refer to probe request probes,
but on some devices null data packets will be used
instead. Make the messages more generic.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch fixes the problem which was discussed in
"mac80211: Fix PN corruption in case of multiple
virtual interface" [1].
Amit Shakya reported a serious issue with my patch:
mac80211: serialize rx path workers" [2]:
In case, ieee80211_rx_handlers processing is going on
for skbs received on one vif and at the same time, rx
aggregation reorder timer expires on another vif then
sta_rx_agg_reorder_timer_expired is invoked and it will
push skbs into the single queue (local->rx_skb_queue).
ieee80211_rx_handlers in the while loop assumes that
the skbs are for the same sdata and sta. This assumption
doesn't hold good in this scenario and the PN gets
corrupted by PN received in other vif's skb, causing
traffic to stop due to PN mismatch."
[1] Message-Id: http://mid.gmane.org/201302041844.44436.chunkeey@googlemail.com
[2] Commit-Id: 24a8fdad35
Reported-by: Amit Shakya <amit.shakya@stericsson.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There seems to be no reason, why it has to be limited to 2.4 GHz.
Signed-off-by: Emanuel Taube <emanuel.taube@gmail.com>
[remove 'local' variable]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The patch "mac80211: clean up mesh sta allocation warning"
moved some mesh initialization into a path which is only
called when the kernel handles peering. This causes a hang
when mac80211 tries to clean up a userspace-allocated
station entry and delete a timer which has never been
initialized.
To avoid this, only do any mesh sta peering teardown if
the kernel is actually handling it.
The same is true when quiescing before suspend.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fix most kernel-doc warnings, for some reason it
seems to have issues with __aligned, don't remove
the documentation entries it considers to be in
excess due to that.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This prepares for using the spinlock instead of krefs
which is needed in the next patch to track the refs
of combined BSSes correctly.
Acked-by: Bing Zhao <bzhao@marvell.com> [mwifiex]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
patches. This pull request contains a fix for an issue discovered during
branch integration.
Basic test logs are available at:
http://www.pwsan.com/omap/testlogs/omap4_prcm_devel_a_3.9/20130210112717/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRF+dcAAoJEMePsQ0LvSpLsu0QALPjiHCpqJugavzVWC/4Df/f
WTSntioocQbuOgfbGn+4lQLF6Qa0mad8FcEtugS+m5rdaKoCCU70YTwgw7XyEzIs
QJmalDi9GGrfJwF5Q+JKVrlPyQjtejHkuQHWZYiJ4pHnF2NkHX7rnv4+Jp0XnW5n
gVqfHyNimcNEM5P0wyGf/YeHD4+Lw82FFbKvg5vGHEXXUXXv9IPjj9IWFpF4znqg
c6hJJw/h7U5LdBMKuNiSYh6VWwbjctFJVXt7lualDnuxznNxx0+JC1hHlS6v+0af
K75Y6ELYsotvt2WI0ELC53IAjieUK9TUnCWNwKv2aBHDBkvO0yjvH6y2+DTnc2Zc
TzpWepfYnQ+Jlv9ZJgQj9XhH2YK/ywri/Tus0KHnKzyaGWn4W8KVGGI6LsVBGilv
AIN1yyDD+osKZtVRCU/JKxrDaRUCgG56TO2X0fvKjADqDIw//tlXsEXfZ4yvQAV0
0xJYGl9Uw2ffXW27GT/LuE5ISoxH/XGINvkS1uXvguvsjCkJvWndX0CGwL7RpFnt
2oAEDA8rz0jkGfTdcgVQRrLjHAyOWR+htrg25eBtD9Srnq/K0UEbvJABNpsCpd91
EDZCnmrl0UX4/7TDDgxJqVvMa36b13z5aOuz0LF2nXmBMF8UowuSgmna4XbeZUwF
1BRozLuNHSSkY4ObcmVx
=Tgzf
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-d2-for-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.9/pm-omap4
Some OMAP4 power management fixes and audio device integration
patches. This pull request contains a fix for an issue discovered during
branch integration.
Basic test logs are available at:
http://www.pwsan.com/omap/testlogs/omap4_prcm_devel_a_3.9/20130210112717/
The MEI bus API changed according to the latest comments from the char-misc
maintainers, and this patch fixes the microread mei physical layer code
according to those changes:
We pass the MEI id back to the probe routine, and the mei_driver takes a
table of MEI ids instead of one static id.
Also, mei_bus_driver got renamed to mei_driver, mei_bus_client to
mei_device, and mei_bus_set/get_clientdata to mei_set/get_clientdata.
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
If we want load epoch_cyc and epoch_ns atomically,
we should update epoch_cyc_copy first of all.
This notify reader that updating is in progress.
If we update epoch_cyc first like as current implementation,
there is subtle error case.
Look at the below example.
<Initial Condition>
cyc = 9
ns = 900
cyc_copy = 9
== CASE 1 ==
<CPU A = reader> <CPU B = updater>
write cyc = 10
read cyc = 10
read ns = 900
write ns = 1000
write cyc_copy = 10
read cyc_copy = 10
output = (10, 900)
== CASE 2 ==
<CPU A = reader> <CPU B = updater>
read cyc = 9
write cyc = 10
write ns = 1000
read ns = 1000
read cyc_copy = 9
write cyc_copy = 10
output = (9, 1000)
If atomic read is ensured, output should be (9, 900) or (10, 1000).
But, output in example case are not.
So, change updating sequence in order to correct this problem.
Cc: <stable@vger.kernel.org>
Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
From Will Deacon, this lays the foundation for a basic virtualzed machine type.
* 'for-arm-soc/virt/mach' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux:
ARM: mach-virt: add SMP support using PSCI
ARM: Dummy Virtual Machine platform support
Signed-off-by: Olof Johansson <olof@lixom.net>
Basic test logs are available here:
http://www.pwsan.com/omap/testlogs/wfi_devel_a_3.9/20130208085027/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRFTM3AAoJEMePsQ0LvSpLyJ8P/ipCXyynb1wmYf5Qm0O8jrgS
a+jS3RD/o+N9RmnerkhfKh4PELolHF5iYvRSX/Iygu4oPWJFlugVw8MQS5R7mqO5
4LSh8oazYjym20txURp3rp3W8sAq2lX+fBjDVqmHKOmckG6LyBMwd2EEmaS0owa3
5mv6Gb8ySyhVFkKnabIHHFaxVBy8rI5Ay4I+bBNInZI4QJh71guJu27Cb1Sg2ng/
TmMqTllWyb4dnbx3u1jw7MCE7e6VMHFU59d8q7aj0wr1yJXzUrZ8wDYYycmHW2ye
yq3E6MNnKzXyrHYoLCvkJl8mrx0bZIohYycA3WNl3BMSTlllx3gBWuD/+z6nWnkq
JIG8jRp6DysgEXjHuQXHT5lawSg2ByjKkk0kPOLCXdRFnns9Q75nNFTqR/6SCdON
hM+sKFgbz5jz+H1gtXoaaRGNeoMcsVKTxFQ4vlisgWwFxTWnmRZX0+WzKM/3oO/K
3KIimEh+aEmHQna4cy3HCtcMJy5IovqupTLea/JWUG0kvcfweTeDzr4YKVttuqFD
8+6A+ZeKTNkJG3R1IQ4NlAmOIKGTHSaz0px1eoFZo+kMVB9h8LYgxQ44ulSBNki/
VZcBFaSz67EtgINSnLDBBAP2q79QbsOLSz784rofWQdU6h/e2lK7lmDCawAzlz7C
nhPTm0BRVfzeC1D4Gds8
=jJVz
-----END PGP SIGNATURE-----
Merge tag 'omap-devel-b-for-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.9/pm-wfi-take2
On OMAP2+ devices, standardize and clean up WFI entry and WFI blocking.
Basic test logs are available here:
http://www.pwsan.com/omap/testlogs/wfi_devel_a_3.9/20130208085027/
Conflicts:
arch/arm/mach-omap2/pm24xx.c
Remove some dead OMAP clock and device integration code and data.
Also, clean up the way that the OMAP device integration code blocks
WFI/WFE to use a consistent mechanism, controlled by a data flag.
Several OMAP2+ power management fixes, optimizations, and cleanup.
This series is a prerequisite for the functional powerdomain
conversion series.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJRD/2AAAoJEBvUPslcq6VzZ0UP+wdb7Nzn0ZFSMkWpOvjdIRfl
XWfdsh2mIOpP97GmitF0iwflI5vx/Jfv9vHxk8elcmHvFOnjrHIuNXU3rTFzYHgS
ho0DZsGAuI/RbIekZbq2+UUs5sd5+vpV85c533S/vYuDBM11tUeysb7sx5Vcc6y8
5u2wWfi4ZifgqtcaoEBV/w/cdivz0J3cqDPLJi5En1qsh6toD7fecTnhVHFo51mS
72QGNKDWUvhKUPmKpaNMBf/sS+Xyp0OnezlDfyRo1dj6SUxUt0zhsGZM9aVGOMIB
unCiDJNtW7FQsw2TYKEbngrY9i8WPSmw26womRpxGknQSCJRoeNmZsGq3rRQgnfX
Bh8VUdYSrjs8covv7pZ7wP6MaMuH1CvS34G7Yy7hKbYPW04RoKswyD7emnIpM3yk
4wtvoB6D85BaDMzGKyTyxOKOCqyamdriI397jXdKsw6jDJl+DVtLkkNADYtkFs+d
GzBw81DhnrKmVwYP656yZflDguAKzZvuSoygFBAK7/nwR/qZPLtAN3ZUc1sTbe0u
RaqGcUtkYMyRwRuzTSdeFDf+NJAnw7ME7lrlyX01jhKb8oynPRHH1vGROeMOgR22
atF7Z8HQjPWsFR8Zre2Mj85cFmpeuEukFIYKrzN5OWtHjHD0L16dRh4/hLmexOTM
A9vnxaD3VbWEjpBVgB21
=Rhql
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v3.9/pm-signed' into omap-for-v3.9/pm-wfi-take2
OMAP PM related updates via Paul Walmsley <paul@pwsan.com>:
Remove some dead OMAP clock and device integration code and data.
Also, clean up the way that the OMAP device integration code blocks
WFI/WFE to use a consistent mechanism, controlled by a data flag.
Several OMAP2+ power management fixes, optimizations, and cleanup.
This series is a prerequisite for the functional powerdomain
conversion series.
From Will Deacon:
This set of changes moves the arch-timer driver out from arch/arm/ and
into drivers/clocksource and unifies the new driver with the arm64 copy.
* 'for-arm-soc/arch-timers' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux:
ARM: arch_timers: switch to physical timers if HYP mode is available
Documentation: Add ARMv8 to arch_timer devicetree
arm64: move from arm_generic to arm_arch_timer
arm64: arm_generic: prevent reading stale time
arm: arch_timer: move core to drivers/clocksource
arm: arch_timer: add arch_counter_set_user_access
arm: arch_timer: divorce from local_timer api
arm: arch_timer: add isbs to register accessors
arm: arch_timer: factor out register accessors
arm: arch_timer: split cntfrq accessor
arm: arch_timer: standardise counter reading
arm: arch_timer: use u64/u32 for register data
arm: arch_timer: remove redundant available check
arm: arch_timer: balance device_node refcounting
Signed-off-by: Olof Johansson <olof@lixom.net>
* 'for-rmk/perf' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux:
ARM: perf: simplify __hw_perf_event_init err handling
ARM: perf: remove unnecessary checks for idx < 0
ARM: perf: handle armpmu_register failing
ARM: perf: don't pretend to support counting of L1I writes
ARM: perf: remove redundant NULL check on cpu_pmu
ARM: Use implementor and part defines from cputype.h
ARM: Define CPU part numbers and implementors
Remove unused memory ressource get from McPDM driver.
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Fix the following sparse warning:
sound/soc/fsl/imx-audmux.c:182:3: warning: symbol 'audmux_type' was not declared. Should it be static?
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When using HPDET to identify the accessory still run MICDET before we
report a microphone in order to ensure that the accessory identified is
compatible with the MICDET detection ranges after having confirmed that
the device is not using a headphone.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This should always be the most accurate reading for supported accessory
configurations.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
It is important to clear the wake trigger status bits otherwise DCVDD
will be held high independent of the state of the LDOENA line.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The magic is already done as part of enabling the headphone output so
does not need to be done when the headphone outputs are enabled. We hold
the DAPM lock so the headphone status can't be changed underneath us.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
