l2cap/rfcomm/sco_sock_accept() are wait loops which may acquire
sleeping locks. Since both wait loops and sleeping locks use
task_struct.state to sleep and wake, the nested sleeping locks
destroy the wait loop state.
Use the newly-minted wait_woken() and DEFINE_WAIT_FUNC() for the
wait loop. DEFINE_WAIT_FUNC() allows an alternate wake function
to be specified; in this case, the predefined scheduler function,
woken_wake_function(). This wait construct ensures wakeups will
not be missed without requiring the wait loop to set the
task state before condition evaluation. How this works:
CPU 0 | CPU 1
|
| is <condition> set?
| no
set <condition> |
|
wake_up_interruptible |
woken_wake_function |
set WQ_FLAG_WOKEN |
try_to_wake_up |
| wait_woken
| set TASK_INTERRUPTIBLE
| WQ_FLAG_WOKEN? yes
| set TASK_RUNNING
|
| - loop -
|
| is <condition> set?
| yes - exit wait loop
Fixes "do not call blocking ops when !TASK_RUNNING" warnings
in l2cap_sock_accept(), rfcomm_sock_accept() and sco_sock_accept().
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This patch converts the Set Secure Connection HCI handling to use a HCI
request instead of using a hard-coded callback in hci_event.c. This e.g.
ensures that we don't clear the flags incorrectly if something goes
wrong with the power up process (not related to a mgmt Set SC command).
The code can also be simplified a bit since only one pending Set SC
command is allowed, i.e. mgmt_pending_foreach usage is not needed.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The Add Remote OOB Data mgmt command should allow data to be passed for
LE as well. This patch removes a left-over check for BDADDR_BREDR that
should not be there anymore.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Before doing any other verifications, the add_remote_oob_data function
should first check that the given address is valid. This patch adds such
a missing check to the beginning of the function.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
When BR/EDR is supported by a controller, then it is required to enable
Secure Simple Pairing first before enabling the Secure Connections
feature.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When a powered on dual-mode controller has been configured to operate
as LE only with secure connections, then the BR/EDR side of things can
not be switched back on. Do reconfigure the controller it first needs
to be powered down.
The secure connections feature is implemented in the BR/EDR controller
while for LE it is implemented in the host. So explicitly forbid such
a transaction to avoid inconsistent states.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The BR/EDR Secure Connections feature should only be enabled when the
Secure Simple Pairing mode has been enabled first. However since secure
connections is feature that is valid for BR/EDR and LE, this needs
special handling.
When enabling secure connections on a LE only configured controller,
thent the BR/EDR side should not be enabled in the controller. This
patches makes the BR/EDR Secure Connections feature depending on
enabling Secure Simple Pairing mode first.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Start Discovery was reporting 0 RSSI for invalid RSSI only for
BR/EDR devices. LE devices were reported with RSSI 127.
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Cc: stable@vger.kernel.org # 3.19+
Some further updates for net-next:
* fix network-manager which was broken by the previous changes
* fix delete-station events, which were broken by me making the
genlmsg_end() mistake
* fix a timer left running during suspend in some race conditions
that would cause an annoying (but harmless) warning
* (less important, but in the tree already) remove 80+80 MHz rate
reporting since the spec doesn't distinguish it from 160 MHz;
as the bitrate they're both 160 MHz bandwidth
Signed-off-by: David S. Miller <davem@davemloft.net>
My previous patch to this file changed the code to be bug-compatible
towards userspace. Unless userspace (which I wasn't able to find)
implements the dump reader by hand in a wrong way, this isn't needed.
If it uses libnl or similar code putting multiple messages into a
single SKB is far more efficient.
Change the code to do this. While at it, also clean it up and don't
use so many variables - just store the address in the callback args
directly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The commit (3d125f9c91) cause i.MX6SX sdb enet cannot work. The cause is
the commit add mdio node with un-correct phy address.
The patch just correct i.MX6sx sdb board enet phy address.
Signed-off-by: Fugang Duan <B38611@freescale.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: David S. Miller <davem@davemloft.net>
This tc action allows you to retrieve the connection tracking mark
This action has been used heavily by openwrt for a few years now.
There are known limitations currently:
doesn't work for initial packets, since we only query the ct table.
Fine given use case is for returning packets
no implicit defrag.
frags should be rare so fix later..
won't work for more complex tasks, e.g. lookup of other extensions
since we have no means to store results
we still have a 2nd lookup later on via normal conntrack path.
This shouldn't break anything though since skb->nfct isn't altered.
V2:
remove unnecessary braces (Jiri)
change the action identifier to 14 (Jiri)
Fix some stylistic issues caught by checkpatch
V3:
Move module params to bottom (Cong)
Get rid of tcf_hashinfo_init and friends and conform to newer API (Cong)
Acked-by: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Florian Fainelli says:
====================
net: DSA fixes for bridge and ip-autoconf
These two patches address some real world use cases of the DSA master and slave
network devices.
You have already seen patch 1 previously and you rejected it since my
explanations were not good enough to provide a justification as to why it is
useful, hopefully this time my explanation is better.
Patch 2 solves a different, yet very real problem as well at the bridge layer
when using DSA network devices.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
DSA-enabled master network devices with a switch tagging protocol should
strip the protocol specific format before handing the frame over to
higher layer.
When adding such a DSA master network device as a bridge member, we go
through the following code path when receiving a frame:
__netif_receive_skb_core
-> first ptype check against ptype_all is not returning any
handler for this skb
-> check and invoke rx_handler:
-> deliver frame to the bridge layer: br_handle_frame
DSA registers a ptype handler with the fake ETH_XDSA ethertype, which is
called *after* the bridge-layer rx_handler has run. br_handle_frame()
tries to parse the frame it received from the DSA master network device,
and will not be able to match any of its conditions and jumps straight
at the end of the end of br_handle_frame() and returns
RX_HANDLER_CONSUMED there.
Since we returned RX_HANDLER_CONSUMED, __netif_receive_skb_core() stops
RX processing for this frame and returns NET_RX_SUCCESS, so we never get
a chance to call our switch tag packet processing logic and deliver
frames to the DSA slave network devices, and so we do not get any
functional bridge members at all.
Instead of cluttering the bridge receive path with DSA-specific checks,
and rely on assumptions about how __netif_receive_skb_core() is
processing frames, we simply deny adding the DSA master network device
(conduit interface) as a bridge member, leaving only the slave DSA
network devices to be bridge members, since those will work correctly in
all circumstances.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The logic to configure a network interface for kernel IP
auto-configuration is very simplistic, and does not handle the case
where a device is stacked onto another such as with DSA. This causes the
kernel not to open and configure the master network device in a DSA
switch tree, and therefore slave network devices using this master
network devices as conduit device cannot be open.
This restriction comes from a check in net/dsa/slave.c, which is
basically checking the master netdev flags for IFF_UP and returns
-ENETDOWN if it is not the case.
Automatically bringing-up DSA master network devices allows DSA slave
network devices to be used as valid interfaces for e.g: NFS root booting
by allowing kernel IP autoconfiguration to succeed on these interfaces.
On the reverse path, make sure we do not attempt to close a DSA-enabled
device as this would implicitely prevent the slave DSA network device
from operating.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
mii_check_media() does not update the link (carrier) state or log link
changes when the link mode is forced. Drivers using the mii library
must do this themselves, but most of them do not.
Instead of changing them all, provide a sensible default behaviour
similar to mii_check_link() when the mode is forced.
via-rhine depends on it being a no-op in this case, so make its call
to mii_check_media() conditional.
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Praveen Madhavan says:
====================
csiostor: Remove T4 FCoE support
We found a subtle issue with FCoE on T4 very late in the game
and decided not to productize FCoE on T4 and therefore there
are no customers that will be impacted by this change. FCoE is
supported on T5 cards.
Please apply on net-next since depends on previous commits.
Changes in v2:
- Make the commit message more clearer.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We have decided not to productize FCoE on T4.
Hence file is removed.
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
We found a subtle issue with FCoE on T4 very late in the game
and decided not to productize FCoE on T4 and therefore there
are no customers that will be impacted by this change. Hence
T4 FCoE support is removed. FCoE supported only on T5 cards.
changes in v2:
- Make the commit message more clearer.
Signed-off-by: Praveen Madhavan <praveenm@chelsio.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Murali Karicheri says:
====================
net: Add Keystone NetCP ethernet driver support
The Network Coprocessor (NetCP) is a hardware accelerator that processes
Ethernet packets. NetCP has a gigabit Ethernet (GbE) subsystem with a ethernet
switch sub-module to send and receive packets. NetCP also includes a packet
accelerator (PA) module to perform packet classification operations such as
header matching, and packet modification operations such as checksum
generation. NetCP can also optionally include a Security Accelerator(SA)
capable of performing IPSec operations on ingress/egress packets.
Keystone SoC's also have a 10 Gigabit Ethernet Subsystem (XGbE) which
includes a 3-port Ethernet switch sub-module capable of 10Gb/s and
1Gb/s rates per Ethernet port.
Both GBE and XGBE network processors supported using common driver. It
is also designed to handle future variants of NetCP.
version history
---------------
v7->v8
- Reworked comments against v7, related to checker warning.
- Patch 2/4 that has all of the driver code in v7 is now split into 3
patches based on functionality so that we have 3 smaller patches
review instead of a big patch.
- Patch for MAINTAINER is merged to 2/4 along with netcp core driver
- Separate patch (3/4) for 1G and (4/4) for 10G
- Removed big endian support for initial version (will add it later)
v6->v7
- Fixed some minor documentation error and also modified the netcp driver
to fix the set* functions to include correct le/be macros.
v5->v6
- updated version after incorporating comments [6] from David Miller,
David Laight & Geert Uytterhoeven on v5. I would like get this in
for v3.19 merge window if the latest version is acceptable.
v4->v5
- Sorry to spin v5 quickly but I missed few check-patch warnings which
were pointed by Joe Perches(thanks). I folded his changes [5] along with
few more check-patch warning fixes. I would like get this in for v3.18
merge window if David is happy with this version.
v3->v4
- Couple of fixes in in error path as pointed [4] out by David. Rest of
the patches are unchanged from v3.
v2->v3
- Update v3 after incorporating Jamal and David Miller's comment/suggestion
from earlier versions [1] [2]. After per the discussion here [3], the
controversial custom exports have been dropped now. And for future
future offload support additions, we will plug into generic frameworks
as an when they are available.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch add support for 1G Ethernet driver based on Keystone
NetCP hardware. The gigabit Ethernet (GbE) switch subsystem is one of the main
components of the network coprocessor (NETCP) peripheral. The purpose of the
gigabit Ethernet switch subsystem in the NETCP is to provide an interface to
transfer data between the host device and another connected device in
compliance with the Ethernet protocol. GbE consists of 5 port Ethernet Switch
module, 4 Serial Gigabit Media Independent Interface (SGMII) modules, MDIO
module and SerDes.
Driver for 5 port GbE switch and SGMII module is added in this patch. These
hardware modules along with netcp core driver provides Network driver functions
for 1G Ethernet.
Detailed hardware spec is available at
http://www.ti.com/lit/ug/sprugv9d/sprugv9d.pdf
Cc: David Miller <davem@davemloft.net>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Wingman Kwok <w-kwok2@ti.com>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The network coprocessor (NetCP) is a hardware accelerator available in
Keystone SoCs that processes Ethernet packets. NetCP consists of following
hardware components
1 Gigabit Ethernet (GbE) subsystem with a Ethernet switch sub-module to
send and receive packets.
2 Packet Accelerator (PA) module to perform packet classification
operations such as header matching, and packet modification operations
such as checksum generation.
3 Security Accelerator(SA) capable of performing IPSec operations on
ingress/egress packets.
4 An optional 10 Gigabit Ethernet Subsystem (XGbE) which includes a
3-port Ethernet switch sub-module capable of 10Gb/s and 1Gb/s rates
per Ethernet port.
5 Packet DMA and Queue Management Subsystem (QMSS) to enqueue and dequeue
packets and DMA the packets between memory and NetCP hardware components
described above.
NetCP core driver make use of the Keystone Navigator driver API to allocate
DMA channel for the Ethenet device and to handle packet queue/de-queue,
Please refer API's in include/linux/soc/ti/knav_dma.h and
drivers/soc/ti/knav_qmss.h for details.
NetCP driver consists of NetCP core driver and at a minimum Gigabit
Ethernet (GBE) module (1) driver to implement the Network device function.
Other modules (2,3) can be optionally added to achieve supported hardware
acceleration function. The initial version of the driver include NetCP
core driver and GBE driver modules.
Please refer Documentation/devicetree/bindings/net/keystone-netcp.txt
for design of the driver.
Cc: David Miller <davem@davemloft.net>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Grant Likely <grant.likely@linaro.org>
Cc: Santosh Shilimkar <santosh.shilimkar@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Wingman Kwok <w-kwok2@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Peter Hurley
Johan Hedberg
Marcel Holtmann
Szymon Janc
Rick Dunn
Dmitry Tunin
David S. Miller
Johannes Berg
Nimrod Andy
Felix Fietkau
Florian Fainelli
Ben Hutchings
Praveen Madhavan
Wingman Kwok
Karicheri, Muralidharan