Per IEEE Std. 802.11-2012, Sec 8.2.4.4.1, the sequence Control field is
not present in control frames. We noticed this problem when processing
Block Ack Requests.
Cc: stable@vger.kernel.org
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Javier Lopez <jlopex@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Prior this fix, those frames were not received, nor forwarded. Fix
this to receive and not forward.
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Doing otherwise is wrong, and may wreak havoc on the mpp tables,
specially if the frame is encrypted.
Cc: stable@vger.kernel.org
Reported-by: Chaoxing Lin <Chaoxing.Lin@ultra-3eti.com>
Signed-off-by: Javier Cardona <javier@cozybit.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of the current whitelist which accepts duplicates
only for the quiet and vendor IEs, use a blacklist of all
IEs (that we currently parse) that can't be duplicated.
This avoids detecting a beacon as corrupt in the future
when new IEs are added that can be duplicated.
Cc: stable@vger.kernel.org
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A few places touch chan->max_power based on updated tx power rules, but
forget to do the same to chan->max_reg_power.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
No driver initializes chan->max_antenna_gain to something sensible, and
the only place where it is being used right now is inside ath9k. This
leads to ath9k potentially using less tx power than it can use, which can
decrease performance/range in some rare cases.
Rather than going through every single driver, this patch initializes
chan->orig_mag in wiphy_register(), ignoring whatever value the driver
left in there. If a driver for some reason wishes to limit it independent
from regulatory rulesets, it can do so internally.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some changes to fix issues with HT40 APs in Korea
and follow-up changes to allow using HT40 even if
the local regulatory database disallows it caused
issues with iwlwifi (and could cause issues with
other devices); iwlwifi firmware would assert if
you tried to connect to an AP that has an invalid
configuration (e.g. using HT40- on channel 140.)
Fix this, while avoiding the "Korean AP" issue by
disabling HT40 and advertising HT20 to the AP
when connecting.
Cc: stable@vger.kernel.org [3.6]
Reported-by: Florian Reitmeir <florian@reitmeir.org>
Tested-by: Florian Reitmeir <florian@reitmeir.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Avoid situation when we are on associate state in mac80211 and
on disassociate state in cfg80211. This can results on crash
during modules unload (like showed on this thread:
http://marc.info/?t=134373976300001&r=1&w=2) and possibly other
problems.
Reported-by: Pedro Francisco <pedrogfrancisco@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
A few places free skbs using dev_kfree_skb even though they're called
after ieee80211_subif_start_xmit might have cloned it for tracking tx
status. Use ieee80211_free_txskb here to prevent skb leaks.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch fixes the following bug:
usb 1-1.1: restart device (8)
BUG: sleeping function called from invalid context at drivers/usb/core/urb.c:654
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
(usb_poison_urb+0x1c/0xf8)
(usb_poison_anchored_urbs+0x48/0x78)
(carl9170_usb_handle_tx_err+0x128/0x150)
(carl9170_usb_reset+0xc/0x20)
(carl9170_handle_command_response+0x298/0xea8)
(carl9170_usb_tasklet+0x68/0x184)
(tasklet_hi_action+0x84/0xdc)
this only happens if the device is plugged in an USB port,
the driver is loaded but inactive (e.g. the wlan interface
is down). If the device is active everything is fine.
Signed-off-by: Ronald Wahl <ronald.wahl@raritan.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The dereference should be moved below the NULL test.
dpatch engine is used to auto generate this patch.
(https://github.com/weiyj/dpatch)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Driver gets LINK_LOST, DEAUTHENTICATED and DISASSOCIATED events
from firmware when connection is lost in different scenarios.
Currently we are using common code WLAN_REASON_DEAUTH_LEAVING
for these cases.
This patch adds support to parse an actual reason code from
firmware event body and send it to cfg80211.
WLAN_REASON_DEAUTH_LEAVING code is used if deauth is initiated
by our device.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch adds support to send correct reason code got from
firmware when association attempt fails. Also, the error message
displayed for association failure due to network incompatibility
is modified. Current message "cannot find ssid.." misleads user.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
scan_processing flag should be reset when scan request is failed
due to some reasons Ex. memory allocation failure etc. Otherwise
further scan requests will be blocked.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
There are cases we cannot scan when request is received.
For example, during WPA group key negociation the scan request
will be blocked. We should return an error code to cfg80211
because cfg80211_scan_done will never be called.
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
The call to drv_get/set_tsf() was put on the workqueue to perform tsf
adjustments since that function might sleep. However it ended up inside
a spinlock, whose critical section must be atomic. Do tsf adjustment
outside the spinlock instead, and get rid of a warning.
Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This should be register 66 instead of 62.
(probably happened by copy&past'ing from the lines below)
Signed-off-by: Daniel Golle <dgolle@allnet.de>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Using ieee80211_free_txskb for tx frames is required, since mac80211 clones
skbs for which socket tx status is requested.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Ensure that drv_start() always returns true, as a failing hw start usually
eventually leads to crashes when there's still a station entry present.
Call a power-on reset after a resume and after a hw reset failure to bring
the hardware back to life again.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
ath_pci_aspm_init is only called on card init, so PCI registers get reset
after a suspend/resume cycle.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
as we hold dst_entry before we call __ip6_del_rt,
so we should alse call dst_release not only return
-ENOENT when the rt6_info is ip6_null_entry.
and we already hold the dst entry, so I think it's
safe to call dst_release out of the write-read lock.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Validation of userspace input shouldn't trigger dmesg spamming.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Marc Kleine-Budde says:
====================
here are three patches for the v3.7 release cycle. Two patches by Peter Senna
Tschudin which fix the return values in the error handling path of the sja1000
peak pci and pcmcia driver. And one patch by myself that fixes a compile
breakage of the mpc5xxx_can mscan driver due to a section conflict.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When large buffers are sent over connected TIPC sockets, it
is likely that the sk_backlog will be filled up on the
receiver side, but the TIPC flow control mechanism is happily
unaware of this since that is based on message count.
The sender will receive a TIPC_ERR_OVERLOAD message when this occurs
and drop it's side of the connection, leaving it stale on
the receiver end.
By increasing the sk_rcvbuf to a 'worst case' value, we avoid the
overload caused by a full backlog queue and the flow control
will work properly.
This worst case value is the max TIPC message size times
the flow control window, multiplied by two because a sender
will transmit up to double the window size before a port is marked
congested.
We multiply this by 2 to account for the sk_buff and other overheads.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fuzzing causes these printks to spew constantly.
Changing them to DEBUG statements is consistent with other usage in the file,
and makes them disappear when CONFIG_IRDA_DEBUG is disabled.
Signed-off-by: Dave Jones <davej@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If a qdisc is installed on a team device, its possible to get
a lockdep splat under stress, because nested dev_queue_xmit() can
lock busylock a second time (on a different device, so its a false
positive)
Avoid this problem using a distinct lock_class_key for team
devices.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jiri Pirko <jpirko@redhat.com>
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: David S. Miller <davem@davemloft.net>
Suppose we have an SCTP connection with two paths. After connection is
established, path1 is not available, thus this path is marked as inactive. Then
traffic goes through path2, but for some reasons packets are delayed (after
rto.max). Because packets are delayed, the retransmit mechanism will switch
again to path1. At this time, we receive a delayed SACK from path2. When we
update the state of the path in sctp_check_transmitted(), we do not take into
account the source address of the SACK, hence we update the wrong path.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Just to avoid confusion when people only reads this prototype.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jeff Kirsher says:
====================
This series contains fixes/updates to ixgbe only. There are three
PTP fixes, polling loop fix and the addition of a device id (X540-AT1).
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
commit d2d68ba9fe (ipv4: Cache input routes in fib_info nexthops.)
introduced a regression for forwarding.
This was hard to reproduce but the symptom was that packets were
delivered to local host instead of being forwarded.
David suggested to add fib_type to fib_info so that we dont
inadvertently share same fib_info for different purposes.
With help from Julian Anastasov who provided very helpful
hints, reproduced here :
<quote>
Can it be a problem related to fib_info reuse
from different routes. For example, when local IP address
is created for subnet we have:
broadcast 192.168.0.255 dev DEV proto kernel scope link src
192.168.0.1
192.168.0.0/24 dev DEV proto kernel scope link src 192.168.0.1
local 192.168.0.1 dev DEV proto kernel scope host src 192.168.0.1
The "dev DEV proto kernel scope link src 192.168.0.1" is
a reused fib_info structure where we put cached routes.
The result can be same fib_info for 192.168.0.255 and
192.168.0.0/24. RTN_BROADCAST is cached only for input
routes. Incoming broadcast to 192.168.0.255 can be cached
and can cause problems for traffic forwarded to 192.168.0.0/24.
So, this patch should solve the problem because it
separates the broadcast from unicast traffic.
And the ip_route_input_slow caching will work for
local and broadcast input routes (above routes 1 and 3) just
because they differ in scope and use different fib_info.
</quote>
Many thanks to Chris Clayton for his patience and help.
Reported-by: Chris Clayton <chris2553@googlemail.com>
Bisected-by: Chris Clayton <chris2553@googlemail.com>
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Julian Anastasov <ja@ssi.bg>
Tested-by: Chris Clayton <chris2553@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since commit:
6d99c4c can: mpc5xxx_can: make data used as *of_device_id.data const
both "struct mpc5xxx_can_data mpc5200_can_data" and "mpc5121_can_data" are
marked as "const" but also as "__devinitdata". This leads to the following
compile error:
drivers/net/can/mscan/mpc5xxx_can.c:383: error: mpc5200_can_data causes a section type conflict
drivers/net/can/mscan/mpc5xxx_can.c:383: error: mpc5200_can_data causes a section type conflict
drivers/net/can/mscan/mpc5xxx_can.c:388: error: mpc5121_can_data causes a section type conflict
drivers/net/can/mscan/mpc5xxx_can.c:388: error: mpc5121_can_data causes a section type conflict
This patch changes the "__devinitdata" to "__devinitconst" and marks the
"struct of_device_id mpc5xxx_can_table" as "const" and "__devinitconst", too.
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Convert a nonnegative error return code to a negative one, as returned
elsewhere in the function.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Peter Senna Tschudin <peter.senna@gmail.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Commit d760fc37b0 caused
1G functions to allocate rx rings which were 1/10 of the
size of 10G functions' rx rings.
However, it also caused 10G functions on 5771x boards to
allocate small rings, which limits their possible (default)
rx throughput. This patch causes all 10G functions to use
rings of intended length by default.
Signed-off-by: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: Ariel Elior <ariele@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch changes memory allocation to reduce stack footprint
Signed-off-by: Jay Hernandez <jay@chelsio.com>
Signed-off-by: Vipul Pandya <vipul@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch adds device support for Ethernet Controller X540-AT1.
Signed-off-by: Josh Hay <joshua.a.hay@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
The loop in ixgbe_reinit_fdir_tables_82599() only polls for up to 100us
resulting in failures to update the FDIR filter table at 1Gbps and 10Gbps
when under load.
The poll times for FDIRCTRL.INIT_DONE are 55us, 550us and 5.5ms for 10Gbps,
1Gbps and 100Mbps respectively.
This patch sets the wait time to be the same as in ixgbe_fdir_enable_82599()
Reported-by: Bhushan <shashi-sm@users.sf.net>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch fixes a development issue that occurred due to invalid modes reported
in the ethtool get_ts_info function. The issue is resolved by removing
unsupported modes from the Rx supported list.
CC: stable <stable@vger.kernel.org> [3.5]
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Driver was enabling PPS interrupt even when user wasn't enabling it via the
ptp core. This patch fixes the PPS so that it is only enabled explicitly, and
moves the interrupt enabling code into the correct location in the driver
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Cc: Stable <stable@vger.kernel.org> [3.5]
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
This patch fixes a bug in the method used for calculating the trigger
alignment for SDP0 when enabling a PPS output on the X540. The alignment math
wasn't properly taking into account the overflow cyclecounter, and was
misaligning the pin triggers so that two X540 devices synced properly had
mis-aligned SDP pins. This patch fixes the math to calculate the correct
seconds alignment for the PPS signal.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
drivers/net/ethernet/broadcom/tg3.c:8121:8: warning: symbol 'i' shadows an earlier one
drivers/net/ethernet/broadcom/tg3.c:8003:6: originally declared here
drivers/net/ethernet/broadcom/tg3.c:785:5: warning: symbol 'tg3_ape_scratchpad_read' was not declared. Should it be static?
drivers/net/ethernet/broadcom/tg3.c:7781:19: warning: Using plain integer as NULL pointer
drivers/net/ethernet/broadcom/tg3.c:10231:31: error: bad constant expression
Reported-by: Fengguang Wu <fenguang.wu@intel.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
skb_reset_mac_len() relies on the value of the skb->network_header pointer,
therefore we must wait for such pointer to be recalculated before computing
the new mac_len value.
Signed-off-by: Antonio Quartulli <ordex@autistici.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
DRV_MODULE_VERSION is smaller than the ->version buffer so the memcpy()
copies 1 byte past the end of the string. It's not super harmful, but
it makes the static checkers complain.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When an address is added on loopback (ip -6 a a 2002::1/128 dev lo), a route
to fe80::/64 is added in the main table:
unreachable fe80::/64 dev lo proto kernel metric 256 error -101
This route does not match any prefix (no fe80:: address on lo). In fact,
addrconf_dev_config() will not add link local address because this function
filters interfaces by type. If the link local address is added manually, the
route to the link local prefix will be automatically added by
addrconf_add_linklocal().
Note also, that this route is not deleted when the address is removed.
After looking at the code, it seems that addrconf_add_lroute() is redundant with
addrconf_add_linklocal(), because this function will add the link local route
when the link local address is configured.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
chan->count is used by rx channel. If the desc count is not updated by
the clean up loop in cpdma_chan_stop, the value written to the rxfree
register in cpdma_chan_start will be incorrect.
Signed-off-by: Tao Hou <hotforest@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The config combination:
CONFIG_PCH_GBE=y
CONFIG_PCH_PTP=y
CONFIG_PTP_1588_CLOCK=m
doesn't work, because then you have a built-in kernel
object (the PCH_PTP code) referring to symbols in a
module (PTP_1588_CLOCK).
Fix this like IXGBE, by using "select PTP_1588_CLOCK"
instead of a "depends on".
Reported-by: Haicheng Li <haicheng.li@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
No framework work here, only a bunch of driver updates of varying sizes:
- Factoring out of the core hardware support from the MXS MMC driver by
Marek Vasut to allow the hardware to also be used for SPI.
- Lots of error handling cleanups from Guenter Roeck
- Removal of the existing Tegra driver which is quite comprehensively
broken as detailed in the changelog for the removal.
- DT suppport for the PL022 and GPIO drivers.
- pinctrl support for OMAP and PL022.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAABAgAGBQJQarn8AAoJEOoSHmUN5Tg49U4QAKeAPTxlKBSwHuJUpvKsCFF7
rfN9wsViOigcItsk065C1g20wViw6t8pSFkNmRzmbsIdSofqCYZlJapgWM5j2cXp
BXs8z7za0JmK62ftS6C3IydacJPRDY/zd0fnSqXnhQOG7Z3YxDYJrM3Ugc97ZE6+
dg9NUn6rw9ZSwHEwpl08H8tLYqNkd8A+wayPYKr0GSWX7EAqS8cJEWjS0DtvDAm1
LxMx4BQHCorR6ydUZJrfhG6fLsubhIuMnXI4Ajhv/Ictl1qHH1Zx3mIAB+BNVV/B
RlaQxPycr0eSikZ9UPMNST2o8vCRvamSfguPfBHMzRdRBp8M3TOKkNM2PmEGzCJW
pgpDsMNAkEfktGqQfMTBJJMbAPLux1W5mPjfcjt7vOS+q6lkFPtecGdKbynnmLX6
Vf6nImwp1vyNIvcCip0YZId+j/LrQimuDfMQOH99mwxbkNqMMA401bsxEt8ELmut
Qt1XEFoS6Xxj8n2BhTS/lMgEzz8zOuH9uOJI0hpNtctOfue6vqPm76GaefVC1i/B
jpMpUwexwsFc6IhekVFG0MAkolMhFmhlTwk9N24yfgArH8D1pa3emBFN762BQUHE
Ba7pghcwZADm8rT5SFNoxblcyekT/hCSRSiQ55MHUpqdH77/eVA1Lah4PaHiOqxz
b0mu9Ae98K077vGP3Z6r
=ld23
-----END PGP SIGNATURE-----
Merge tag 'spi-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc
Pull spi updates from Mark Brown:
"No framework work here, only a bunch of driver updates of varying
sizes:
- Factoring out of the core hardware support from the MXS MMC driver
by Marek Vasut to allow the hardware to also be used for SPI.
- Lots of error handling cleanups from Guenter Roeck
- Removal of the existing Tegra driver which is quite comprehensively
broken as detailed in the changelog for the removal.
- DT suppport for the PL022 and GPIO drivers.
- pinctrl support for OMAP and PL022."
Pulling from Mark Brown as Grant Likely is still busy moving.
* tag 'spi-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/misc: (53 commits)
spi: remove completely broken Tegra driver
spi/imx: set the inactive state of the clock according to the clock polarity
spi/pl022: get/put resources on suspend/resume
spi/pl022: use more managed resources
spi/pl022: Devicetree support w/o platform data
spi/s3c64xx: Don't free controller_data on non-dt platforms
spi: omap2-mcspi: add pinctrl support
spi/pl022: adopt pinctrl support
spi: omap2-mcspi: Cleanup the omap2_mcspi_txrx_dma function
spi/gpio: Fix stub for spi_gpio_probe_dt()
spi/mxs: Make the SPI block clock speed configurable via DT
spi: spi-sh-hspi: drop frees of devm_ alloc'd data
spi/pl022: Fix chipselects pointer computation
spi: spi-tle62x0: Use module_spi_driver macro
mxs/spi: Rework the mxs_ssp_timeout to be more readable
mxs/spi: Decrement the DMA/PIO border
mxs/spi: Increment the transfer length only if transfer succeeded
mxs/spi: Fix issues when doing long continuous transfer
spi: spi-gpio: Add DT bindings
spi: spi-gpio: store chipselect information in private structure
...
Javier Cardona