According to NCI specification, destination type and destination
specific parameters shall uniquely identify a single destination
for the Logical Connection.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
nci_core_conn_close was not retrieving a conn_info using the correct
connection id.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
NCI_CORE_CONN_CREATE may not have any destination type parameter.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
ST21NFCA_ESE_HOST_ID is already defined in st21nfca.h.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
ST_NCI_HCI_HOST_ID_ESE is already having an equivalent in se.c
(ST_NCI_ESE_HOST_ID).
Remove and replace where relevant.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When st_nci_spi_acpi_request_resources() gets called we
already know that the entries in ->acpi_match_table have
matched ACPI ID of the device.
In addition spi_device pointer cannot be NULL in any case
(otherwise SPI core would not call ->probe() for the driver
in the first place).
Drop the two useless checks from the driver.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When st_nci_i2c_acpi_request_resources() gets called we already
know that the entries in ->acpi_match_table have matched ACPI ID
of the device.
In addition I2C client pointer cannot be NULL in any case
(otherwise I2C core would not call ->probe() for the driver in
the first place).
Drop the two useless checks from the driver.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When st21nfca_hci_i2c_acpi_request_resources() gets called we
already know that the entries in ->acpi_match_table have matched
ACPI ID of the device.
In addition I2C client pointer cannot be NULL in any case
(otherwise I2C core would not call ->probe() for the driver in
the first place).
Drop the two useless checks from the driver.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
An APDU_READER_GATE pipe is not expected on a UICC. Be more
explicit so that an other secure element form factor (SD card)
does not prompt this message.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
An APDU_READER_GATE pipe is not expected on a UICC. Be more
explicit so that an other secure element form factor (SD card)
does not prompt this message.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When they're present, set is_ese_present and set is_uicc_present
to the value describe in their package description.
So far is_ese_present and is_uicc_present was set to true if their
property was present.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
When they're present, set is_ese_present and set is_uicc_present
to the value describe in their package description.
So far is_ese_present and is_uicc_present was set to true if their
property was present.
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since
commit 10cf4899f8 ("gpiolib: tighten up ACPI legacy gpio lookups")
If _DSD properties are available in an ACPI node, we are not
allowed to fallback to _CRS data to retrieve gpio properties.
This was causing us to fail if uicc-present and/or ese-present
are defined.
To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
will look for reset-gpios. In the mean time the ACPI table needs
to be fixed as follow:
Device (NFC1)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "SMO2100") // _HID: Hardware ID
Name (_CID, "SMO2100") // _CID: Compatible ID
Name (_DDN, "SMO NFC") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBus (0x0008, ControllerInitiated, 400000,
AddressingMode7Bit, "\\_SB.I2C7",
0x00, ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0001
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0002,
}
})
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02) { "uicc-present", 1 },
Package (0x02) { "ese-present", 1 },
Package (0x02) { "enable-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
}
})
Return (SBUF) /* \_SB_.I2C7.NFC1._CRS.SBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since
commit 10cf4899f8 ("gpiolib: tighten up ACPI legacy gpio lookups")
If _DSD properties are available in an ACPI node, we are not
allowed to fallback to _CRS data to retrieve gpio properties.
This was causing us to fail if uicc-present and/or ese-present
are defined.
To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
will look for reset-gpios. In the mean time the ACPI table needs
to be fixed as follow (Tested on Minnowboard Max):
Device (NFC1)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "SMO2101") // _HID: Hardware ID
Name (_CID, "SMO2101") // _CID: Compatible ID
Name (_DDN, "SMO NFC") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
SpiSerialBus (0, PolarityLow, FourWireMode, 8,
ControllerInitiated, 4000000, ClockPolarityLow,
ClockPhaseFirst, "\\_SB.SPI1",
0x00, ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0001
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0002,
}
})
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02) { "uicc-present", 1 },
Package (0x02) { "ese-present", 1 },
Package (0x02) { "reset-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
}
})
Return (SBUF) /* \_SB_.SPI1.NFC1._CRS.SBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Since
commit 10cf4899f8 ("gpiolib: tighten up ACPI legacy gpio lookups")
If _DSD properties are available in an ACPI node, we are not
allowed to fallback to _CRS data to retrieve gpio properties.
This was causing us to fail if uicc-present and/or ese-present
are defined.
To be consistent with devicetree change ST_NCI_GPIO_NAME_RESET
content to reset so that acpi_find_gpio in drivers/gpio/gpiolib.c
will look for reset-gpios. In the mean time the ACPI table needs
to be fixed as follow:
Device (NFC1)
{
Name (_ADR, Zero) // _ADR: Address
Name (_HID, "SMO2101") // _HID: Hardware ID
Name (_CID, "SMO2101") // _CID: Compatible ID
Name (_DDN, "SMO NFC") // _DDN: DOS Device Name
Name (_UID, One) // _UID: Unique ID
Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings
{
Name (SBUF, ResourceTemplate ()
{
I2cSerialBus (0x0008, ControllerInitiated, 400000,
AddressingMode7Bit, "\\_SB.I2C7",
0x00, ResourceConsumer, ,)
GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0x0000,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0001
}
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
"\\_SB.GPO2", 0x00, ResourceConsumer, ,)
{ // Pin list
0x0002,
}
})
Name (_DSD, Package (0x02)
{
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301") /* Device Properties for _DSD */,
Package (0x03)
{
Package (0x02) { "uicc-present", 1 },
Package (0x02) { "ese-present", 1 },
Package (0x02) { "reset-gpios", Package(0x04) { ^NFC1, 1, 0, 0} },
}
})
Return (SBUF) /* \_SB_.I2C7.NFC1._CRS.SBUF */
}
Method (_STA, 0, NotSerialized) // _STA: Status
{
Return (0x0F)
}
}
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Fix static checker warning:
drivers/nfc/st21nfca/i2c.c:530 st21nfca_hci_i2c_acpi_request_resources()
error: 'gpiod_ena' dereferencing possible ERR_PTR()
Fix so that if no enable gpio can be retrieved an -ENODEV is returned.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Fixes: dfa8070d7f ("nfc: st21nfca: Add support for acpi probing for i2c device.")
Cc: stable@vger.kernel.org
Signed-off-by: Christophe Ricard <christophe-h.ricard@st.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Pull networking fixes from David Miller:
"Some straggler bug fixes:
1) Batman-adv DAT must consider VLAN IDs when choosing candidate
nodes, from Antonio Quartulli.
2) Fix botched reference counting of vlan objects and neigh nodes in
batman-adv, from Sven Eckelmann.
3) netem can crash when it sees GSO packets, the fix is to segment
then upon ->enqueue. Fix from Neil Horman with help from Eric
Dumazet.
4) Fix VXLAN dependencies in mlx5 driver Kconfig, from Matthew
Finlay.
5) Handle VXLAN ops outside of rcu lock, via a workqueue, in mlx5,
since it can sleep. Fix also from Matthew Finlay.
6) Check mdiobus_scan() return values properly in pxa168_eth and macb
drivers. From Sergei Shtylyov.
7) If the netdevice doesn't support checksumming, disable
segmentation. From Alexandery Duyck.
8) Fix races between RDS tcp accept and sending, from Sowmini
Varadhan.
9) In macb driver, probe MDIO bus before we register the netdev,
otherwise we can try to open the device before it is really ready
for that. Fix from Florian Fainelli.
10) Netlink attribute size for ILA "tunnels" not calculated properly,
fix from Nicolas Dichtel"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
ipv6/ila: fix nlsize calculation for lwtunnel
net: macb: Probe MDIO bus before registering netdev
RDS: TCP: Synchronize accept() and connect() paths on t_conn_lock.
RDS:TCP: Synchronize rds_tcp_accept_one with rds_send_xmit when resetting t_sock
vxlan: Add checksum check to the features check function
net: Disable segmentation if checksumming is not supported
net: mvneta: Remove superfluous SMP function call
macb: fix mdiobus_scan() error check
pxa168_eth: fix mdiobus_scan() error check
net/mlx5e: Use workqueue for vxlan ops
net/mlx5e: Implement a mlx5e workqueue
net/mlx5: Kconfig: Fix MLX5_EN/VXLAN build issue
net/mlx5: Unmap only the relevant IO memory mapping
netem: Segment GSO packets on enqueue
batman-adv: Fix reference counting of hardif_neigh_node object for neigh_node
batman-adv: Fix reference counting of vlan object for tt_local_entry
batman-adv: B.A.T.M.A.N V - make sure iface is reactivated upon NETDEV_UP event
batman-adv: fix DAT candidate selection (must use vid)
Pull fuse fixes from Miklos Szeredi:
"Fix a regression and update the MAINTAINERS entry for fuse"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse:
fuse: update mailing list in MAINTAINERS
fuse: Fix return value from fuse_get_user_pages()
The handler 'ila_fill_encap_info' adds one attribute: ILA_ATTR_LOCATOR.
Fixes: 65d7ab8de5 ("net: Identifier Locator Addressing module")
CC: Tom Herbert <tom@herbertland.com>
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the sendmsg function of UDP, raw, ICMP and l2tp sockets, we use local
variables like hlimits, tclass, opt and dontfrag and pass them to corresponding
functions like ip6_make_skb, ip6_append_data and xxx_push_pending_frames.
This is not a good practice and makes it hard to add new parameters.
This fix introduces a new struct ipcm6_cookie similar to ipcm_cookie in
ipv4 and include the above mentioned variables. And we only pass the
pointer to this structure to corresponding functions. This makes it easier
to add new parameters in the future and makes the function cleaner.
Signed-off-by: Wei Wang <weiwan@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The current sequence makes us register for a network device prior to
registering and probing the MDIO bus which could lead to some unwanted
consequences, like a thread of execution calling into ndo_open before
register_netdev() returns, while the MDIO bus is not ready yet.
Rework the sequence to register for the MDIO bus, and therefore attach
to a PHY prior to calling register_netdev(), which implies reworking the
error path a bit.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Sowmini Varadhan says:
====================
RDS: TCP: sychronization during connection startup
This patch series ensures that the passive (accept) side of the
TCP connection used for RDS-TCP is correctly synchronized with
any concurrent active (connect) attempts for a given pair of peers.
Patch 1 in the series makes sure that the t_sock in struct
rds_tcp_connection is only reset after any threads in rds_tcp_xmit
have completed (otherwise a null-ptr deref may be encountered).
Patch 2 synchronizes rds_tcp_accept_one() with the rds_tcp*connect()
path.
v2: review comments from Santosh Shilimkar, other spelling corrections
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
An arbitration scheme for duelling SYNs is implemented as part of
commit 241b271952 ("RDS-TCP: Reset tcp callbacks if re-using an
outgoing socket in rds_tcp_accept_one()") which ensures that both nodes
involved will arrive at the same arbitration decision. However, this
needs to be synchronized with an outgoing SYN to be generated by
rds_tcp_conn_connect(). This commit achieves the synchronization
through the t_conn_lock mutex in struct rds_tcp_connection.
The rds_conn_state is checked in rds_tcp_conn_connect() after acquiring
the t_conn_lock mutex. A SYN is sent out only if the RDS connection is
not already UP (an UP would indicate that rds_tcp_accept_one() has
completed 3WH, so no SYN needs to be generated).
Similarly, the rds_conn_state is checked in rds_tcp_accept_one() after
acquiring the t_conn_lock mutex. The only acceptable states (to
allow continuation of the arbitration logic) are UP (i.e., outgoing SYN
was SYN-ACKed by peer after it sent us the SYN) or CONNECTING (we sent
outgoing SYN before we saw incoming SYN).
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
There is a race condition between rds_send_xmit -> rds_tcp_xmit
and the code that deals with resolution of duelling syns added
by commit 241b271952 ("RDS-TCP: Reset tcp callbacks if re-using an
outgoing socket in rds_tcp_accept_one()").
Specifically, we may end up derefencing a null pointer in rds_send_xmit
if we have the interleaving sequence:
rds_tcp_accept_one rds_send_xmit
conn is RDS_CONN_UP, so
invoke rds_tcp_xmit
tc = conn->c_transport_data
rds_tcp_restore_callbacks
/* reset t_sock */
null ptr deref from tc->t_sock
The race condition can be avoided without adding the overhead of
additional locking in the xmit path: have rds_tcp_accept_one wait
for rds_tcp_xmit threads to complete before resetting callbacks.
The synchronization can be done in the same manner as rds_conn_shutdown().
First set the rds_conn_state to something other than RDS_CONN_UP
(so that new threads cannot get into rds_tcp_xmit()), then wait for
RDS_IN_XMIT to be cleared in the conn->c_flags indicating that any
threads in rds_tcp_xmit are done.
Fixes: 241b271952 ("RDS-TCP: Reset tcp callbacks if re-using an
outgoing socket in rds_tcp_accept_one()")
Signed-off-by: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hosts sending lot of ACK packets exhibit high sock_wfree() cost
because of cache line miss to test SOCK_USE_WRITE_QUEUE
We could move this flag close to sk_wmem_alloc but it is better
to perform the atomic_sub_and_test() on a clean cache line,
as it avoid one extra bus transaction.
skb_orphan_partial() can also have a fast track for packets that either
are TCP acks, or already went through another skb_orphan_partial()
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Alexander Duyck says:
====================
Fixes for tunnel checksum and segmentation offloads
This patch series is a subset of patches I had submitted for net-next. I
plan to drop these two patches from the v3 of "Fix Tunnel features and
enable GSO partial for several drivers" and I am instead submitting them
for net since these are truly fixes and likely will need to be backported
to stable branches.
This series addresses 2 specific issues. The first is that we could
request TSO on a v4 inner header while not supporting checksum offload of
the outer IPv6 header. The second is that we could request an IPv6 inner
checksum offload without validating that we could actually support an inner
IPv6 checksum offload.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
We need to perform an additional check on the inner headers to determine if
we can offload the checksum for them. Previously this check didn't occur
so we would generate an invalid frame in the case of an IPv6 header
encapsulated inside of an IPv4 tunnel. To fix this I added a secondary
check to vxlan_features_check so that we can verify that we can offload the
inner checksum.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the case of the mlx4 and mlx5 driver they do not support IPv6 checksum
offload for tunnels. With this being the case we should disable GSO in
addition to the checksum offload features when we find that a device cannot
perform a checksum on a given packet type.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Jon Maloy says:
====================
tipc: redesign socket-level flow control
The socket-level flow control in TIPC has long been due for a major
overhaul. This series fixes this.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
There are two flow control mechanisms in TIPC; one at link level that
handles network congestion, burst control, and retransmission, and one
at connection level which' only remaining task is to prevent overflow
in the receiving socket buffer. In TIPC, the latter task has to be
solved end-to-end because messages can not be thrown away once they
have been accepted and delivered upwards from the link layer, i.e, we
can never permit the receive buffer to overflow.
Currently, this algorithm is message based. A counter in the receiving
socket keeps track of number of consumed messages, and sends a dedicated
acknowledge message back to the sender for each 256 consumed message.
A counter at the sending end keeps track of the sent, not yet
acknowledged messages, and blocks the sender if this number ever reaches
512 unacknowledged messages. When the missing acknowledge arrives, the
socket is then woken up for renewed transmission. This works well for
keeping the message flow running, as it almost never happens that a
sender socket is blocked this way.
A problem with the current mechanism is that it potentially is very
memory consuming. Since we don't distinguish between small and large
messages, we have to dimension the socket receive buffer according
to a worst-case of both. I.e., the window size must be chosen large
enough to sustain a reasonable throughput even for the smallest
messages, while we must still consider a scenario where all messages
are of maximum size. Hence, the current fix window size of 512 messages
and a maximum message size of 66k results in a receive buffer of 66 MB
when truesize(66k) = 131k is taken into account. It is possible to do
much better.
This commit introduces an algorithm where we instead use 1024-byte
blocks as base unit. This unit, always rounded upwards from the
actual message size, is used when we advertise windows as well as when
we count and acknowledge transmitted data. The advertised window is
based on the configured receive buffer size in such a way that even
the worst-case truesize/msgsize ratio always is covered. Since the
smallest possible message size (from a flow control viewpoint) now is
1024 bytes, we can safely assume this ratio to be less than four, which
is the value we are now using.
This way, we have been able to reduce the default receive buffer size
from 66 MB to 2 MB with maintained performance.
In order to keep this solution backwards compatible, we introduce a
new capability bit in the discovery protocol, and use this throughout
the message sending/reception path to always select the right unit.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
During neighbor discovery, nodes advertise their capabilities as a bit
map in a dedicated 16-bit field in the discovery message header. This
bit map has so far only be stored in the node structure on the peer
nodes, but we now see the need to keep a copy even in the socket
structure.
This commit adds this functionality.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
In the refactoring commit d570d86497 ("tipc: enqueue arrived buffers
in socket in separate function") we did by accident replace the test
if (sk->sk_backlog.len == 0)
atomic_set(&tsk->dupl_rcvcnt, 0);
with
if (sk->sk_backlog.len)
atomic_set(&tsk->dupl_rcvcnt, 0);
This effectively disables the compensation we have for the double
receive buffer accounting that occurs temporarily when buffers are
moved from the backlog to the socket receive queue. Until now, this
has gone unnoticed because of the large receive buffer limits we are
applying, but becomes indispensable when we reduce this buffer limit
later in this series.
We now fix this by inverting the mentioned condition.
Acked-by: Ying Xue <ying.xue@windriver.com>
Signed-off-by: Jon Maloy <jon.maloy@ericsson.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Configure and enable various tunnels on the
adapter after PF start.
This change was missed as a part of
'commit 464f664501
("qed: Add infrastructure support for tunneling")'
Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Signed-off-by: Yuval Mintz <yuval.mintz@qlogic.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since commit 3b9d6da67e ("cpu/hotplug: Fix rollback during error-out
in __cpu_disable()") it is ensured that callbacks of CPU_ONLINE and
CPU_DOWN_PREPARE are processed on the hotplugged CPU. Due to this SMP
function calls are no longer required.
Replace smp_call_function_single() with a direct call to
mvneta_percpu_enable() or mvneta_percpu_disable(). The functions do
not require to be called with interrupts disabled, therefore the
smp_call_function_single() calling convention is not preserved.
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Anna-Maria Gleixner <anna-maria@linutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Joachim Eastwood says:
====================
stmmac: dwmac-socfpga refactor+cleanup
This patch aims to remove the init/exit callbacks from the dwmac-
socfpga driver and instead use standard PM callbacks. Doing this
will also allow us to cleanup the driver.
Eventually the init/exit callbacks will be deprecated and removed
from all drivers dwmac-* except for dwmac-generic. Drivers will be
refactored to use standard PM and remove callbacks.
This patch set should not change the behavior of the driver itself,
it only moves code around. The only exception to this is patch
number 4 which restores the resume callback behavior which was
changed in the "net: stmmac: socfpga: Remove re-registration of
reset controller" patch. I belive calling phy_resume() only
from the resume callback and not probe is the right thing to do.
Changes from v1:
- Rebase on net-next
One heads-up here:
The first patch changes the prototype of a couple of
functions used in Alexandre's "add Ethernet glue logic for
stm32 chip" patch [1] and will cause build failures for
dwmac-stm32.c if not fixed up!
If Alexandre's patch set is applied first I will gladly
rebase my patch set to account for his driver as well.
[1] https://patchwork.ozlabs.org/patch/614405/
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove old init callback which now contains only a call to
socfpga_dwmac_setup(). Also rename socfpga_dwmac_setup() to indicate
what the function really does.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Calling phy_resume() should only be need during driver resume to
workaround a hardware errata.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
The dwmac-socfpga driver needs to control the reset usually managed
by the core driver to set the PHY mode. Take a copy of the reset
handle from core priv data so it can be used by the driver later.
This also allow us to move reset handling into socfpga_dwmac_setup()
where the code that needs it is located.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Implement the needed PM callbacks in the driver instead of
relying on the init/exit hooks in stmmac_platform. This gives
the driver more flexibility in how the code is organized.
Eventually the init/exit callbacks will be deprecated in favor
of the standard PM callbacks and driver remove function.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Change stmmac_remove/resume/suspend to take a device pointer so
they can be used directly by drivers that doesn't need to perform
anything device specific.
This lets us remove the PCI pm functions and later simplifiy the
platform drivers.
Signed-off-by: Joachim Eastwood <manabian@gmail.com>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now mdiobus_scan() returns ERR_PTR(-ENODEV) instead of NULL if the PHY
device ID was read as all ones. As this was not an error before, this
value should be filtered out now in this driver.
Fixes: b74766a0a0 ("phylib: don't return NULL from get_phy_device()")
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since mdiobus_scan() returns either an error code or NULL on error, the
driver should check for both, not only for NULL, otherwise a crash is
imminent...
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
batadv_iv_ogm_orig_del_if handles two different buffers bcast_own and
bcast_own_sum which should be resized. The error handling two for
allocating these buffers causes the complexity of this function. This can
be avoided completely when the function is split into a main function
handling the locking, freeing and call of the subfunctions.
The subfunction can then independently handle the resize of the buffers.
This also allows to easily reuse the old buffer (which always is larger) in
case a smaller buffer could not be allocated without increasing the code
complexity.
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Marek Lindner <mareklindner@neomailbox.ch>
Signed-off-by: Antonio Quartulli <a@unstable.cc>
