[PATCH v2 1/2] net: thunderx: HW TSO support for pass-2 hardware
From: Sunil Goutham
This adds support for offloading TCP segmentation to HW in pass-2
revision of hardware. Both driver level SW TSO for pass1.x chips
and HW TSO for pass-2 chip will co-exist. Modified SQ descriptor
structures to reflect pass-2 hw implementation.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/nic.h |6
drivers/net/ethernet/cavium/thunder/nic_main.c | 11 ++-
drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 -
drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 20 ++---
drivers/net/ethernet/cavium/thunder/q_struct.h | 30 ++-
5 files changed, 53 insertions(+), 29 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
b/drivers/net/ethernet/cavium/thunder/nic.h
index 39ca674..6888288 100644
--- a/drivers/net/ethernet/cavium/thunder/nic.h
+++ b/drivers/net/ethernet/cavium/thunder/nic.h
@@ -265,6 +265,7 @@ struct nicvf {
u8 tns_mode:1;
u8 sqs_mode:1;
u8 loopback_supported:1;
+ boolhw_tso;
u16 mtu;
struct queue_set*qs;
#defineMAX_SQS_PER_VF_SINGLE_NODE 5
@@ -489,6 +490,11 @@ static inline int nic_get_node_id(struct pci_dev *pdev)
return ((addr >> NIC_NODE_ID_SHIFT) & NIC_NODE_ID_MASK);
}
+static inline bool pass1_silicon(struct pci_dev *pdev)
+{
+ return pdev->revision < 8;
+}
+
int nicvf_set_real_num_queues(struct net_device *netdev,
int tx_queues, int rx_queues);
int nicvf_open(struct net_device *netdev);
diff --git a/drivers/net/ethernet/cavium/thunder/nic_main.c
b/drivers/net/ethernet/cavium/thunder/nic_main.c
index 4b7fd63..9f80de4 100644
--- a/drivers/net/ethernet/cavium/thunder/nic_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nic_main.c
@@ -55,11 +55,6 @@ struct nicpf {
boolirq_allocated[NIC_PF_MSIX_VECTORS];
};
-static inline bool pass1_silicon(struct nicpf *nic)
-{
- return nic->pdev->revision < 8;
-}
-
/* Supported devices */
static const struct pci_device_id nic_id_table[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_CAVIUM, PCI_DEVICE_ID_THUNDER_NIC_PF) },
@@ -123,7 +118,7 @@ static void nic_send_msg_to_vf(struct nicpf *nic, int vf,
union nic_mbx *mbx)
* when PF writes to MBOX(1), in next revisions when
* PF writes to MBOX(0)
*/
- if (pass1_silicon(nic)) {
+ if (pass1_silicon(nic->pdev)) {
/* see the comment for nic_reg_write()/nic_reg_read()
* functions above
*/
@@ -400,7 +395,7 @@ static void nic_config_cpi(struct nicpf *nic, struct
cpi_cfg_msg *cfg)
padd = cpi % 8; /* 3 bits CS out of 6bits DSCP */
/* Leave RSS_SIZE as '0' to disable RSS */
- if (pass1_silicon(nic)) {
+ if (pass1_silicon(nic->pdev)) {
nic_reg_write(nic, NIC_PF_CPI_0_2047_CFG | (cpi << 3),
(vnic << 24) | (padd << 16) |
(rssi_base + rssi));
@@ -470,7 +465,7 @@ static void nic_config_rss(struct nicpf *nic, struct
rss_cfg_msg *cfg)
}
cpi_base = nic->cpi_base[cfg->vf_id];
- if (pass1_silicon(nic))
+ if (pass1_silicon(nic->pdev))
idx_addr = NIC_PF_CPI_0_2047_CFG;
else
idx_addr = NIC_PF_MPI_0_2047_CFG;
diff --git a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
index dde8dc7..c24cb2a 100644
--- a/drivers/net/ethernet/cavium/thunder/nicvf_main.c
+++ b/drivers/net/ethernet/cavium/thunder/nicvf_main.c
@@ -525,14 +525,22 @@ static void nicvf_snd_pkt_handler(struct net_device
*netdev,
__func__, cqe_tx->sq_qs, cqe_tx->sq_idx,
cqe_tx->sqe_ptr, hdr->subdesc_cnt);
- nicvf_put_sq_desc(sq, hdr->subdesc_cnt + 1);
nicvf_check_cqe_tx_errs(nic, cq, cqe_tx);
skb = (struct sk_buff *)sq->skbuff[cqe_tx->sqe_ptr];
- /* For TSO offloaded packets only one head SKB needs to be freed */
+ /* For TSO offloaded packets only one SQE will have a valid SKB */
if (skb) {
+ nicvf_put_sq_desc(sq, hdr->subdesc_cnt + 1);
prefetch(skb);
dev_consume_skb_any(skb);
sq->skbuff[cqe_tx->sqe_ptr] = (u64)NULL;
+ } else {
+ /* In case of HW TSO, HW sends a CQE for each segment of a TSO
+* packet instead of a single CQE for the whole TSO packet
+* transmitted. Each of this CQE points to the same SQE, so
+* avoid freeing same SQE multiple times.
+*/
+ if (!nic->hw_tso)
+ nicvf_put_sq_desc(sq, hdr->subdesc_cnt + 1);
}
}
@@ -1549,6 +1557,
[PATCH v2 0/2] net: thunderx: Support for pass-2 hw features
From: Sunil Goutham This patch set adds support for new features added in pass-2 revision of hardware like TSO and count based interrupt coalescing. Changes from v1: - Addressed comments received regarding boolean bit field changes by excluding them from this patch. Will submit a seperate patch along with cleanup of unsed field. - Got rid of new macro 'VNIC_NAPI_WEIGHT' introduced in count threshold interrupt patch. Sunil Goutham (2): net: thunderx: HW TSO support for pass-2 hardware net: thunderx: Enable CQE count threshold interrupt drivers/net/ethernet/cavium/thunder/nic.h |6 drivers/net/ethernet/cavium/thunder/nic_main.c | 11 ++- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 - drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 22 ++ drivers/net/ethernet/cavium/thunder/nicvf_queues.h |2 +- drivers/net/ethernet/cavium/thunder/q_struct.h | 30 ++- 6 files changed, 55 insertions(+), 31 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/macb: add support for resetting PHY using GPIO
Hi Gregory, On Wed, Dec 09, 2015 at 06:49:43PM +0100, Gregory CLEMENT wrote: > With device tree it is no more possible to reset the PHY at board > level. Furthermore, doing in the driver allow to power down the PHY when > the network interface is no more used. > > The patch introduces a new optional property "phy-reset-gpio" inspired > from the one use for the FEC. I don't think it's a good idea to further extend the usage of this binding. The driver should use the phy-handle property and of_phy_connect() which gives you a proper device node for the phy. Then the phy device node should get the reset gpio. I know it's more work, but doing it like this gives you additional goodies like proper handling of the max-speed property, a fixed-link if necessary and picking the correct phy if there are muliple phys on the bus. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCHv2 net-next 1/2] tcp: RTO Restart (RTOR)
> On 08 Dec 2015, at 14:47, Eric Dumazet wrote:
>
> On Tue, 2015-12-08 at 10:19 +0100, Per Hurtig wrote:
>
>> +static u32 tcp_unsent_pkts(const struct sock *sk, u32 ulimit)
>> +{
>> +struct sk_buff *skb = tcp_send_head(sk);
>> +u32 pkts = 0;
>> +
>> +if (skb)
>> +tcp_for_write_queue_from(skb, sk) {
>> +pkts += tcp_skb_pcount(skb);
>> +
>> +if (ulimit && pkts >= ulimit)
>> +return ulimit;
>> +}
>> +
>> +return pkts;
>> +}
>
>
> Considering Yuchung feedback, have you looked at using an approximation
> instead ?
>
> (ie using tp->write_seq - tp->snd_nxt)
>
>
Well, an approximation is rather “dangerous” as missing a single packet
could inhibit the desired behaviour. If looping is undesired, I think a
better solution is to actually *not* do this check at all and instead rely
solely on the
tp->packets_out < TCP_RTORESTART_THRESH
check instead. The reason why the number of unsent packets was
included was only to fix a corner case where it should be possible
to use the modified restart, but impossible due to the conditioning.
However, this corner case is likely to not occur very often and we
may be better off with the simpler check.
The corner case (if I remember this correctly) is that the restart is
not triggered when you have 2 segments in flight and (i) have a
congestion window of exactly 3; or (ii) get a packet written to the socket
just between previous data transmission and the arrival of the
acknowledgment that triggers the restart.
— Per
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: [PATCH (net-next.git) 13/18] stmmac: perf, remove modulo in stmmac_rx()
On 12/10/2015 6:11 AM, Giuseppe CAVALLARO wrote: On 12/9/2015 6:21 PM, David Laight wrote: From: Giuseppe Cavallaro Sent: 09 December 2015 08:38 The indexes into the ring buffer are always incremented, and the entry is accessed via doing a modulo to find the "real" index. Modulo is an expensive operation. This patch replaces the modulo with a simple if clamp. It helps improve stmmac RX path as it's being called inside RX loop. Is dma_rx_size always a power of 2 ? no If so you can replace the % by & and remove the conditionals. If you have changed the read and write values to indexes then you need to be certain that the 'ring full' and 'ring empty' cases are correctly distinguished. this is implicitly managed by dirty and curr index. ... also the dma will fail with unavailable buffer. peppe thx peppe David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH (net-next.git) 13/18] stmmac: perf, remove modulo in stmmac_rx()
On 12/9/2015 6:21 PM, David Laight wrote: From: Giuseppe Cavallaro Sent: 09 December 2015 08:38 The indexes into the ring buffer are always incremented, and the entry is accessed via doing a modulo to find the "real" index. Modulo is an expensive operation. This patch replaces the modulo with a simple if clamp. It helps improve stmmac RX path as it's being called inside RX loop. Is dma_rx_size always a power of 2 ? no If so you can replace the % by & and remove the conditionals. If you have changed the read and write values to indexes then you need to be certain that the 'ring full' and 'ring empty' cases are correctly distinguished. this is implicitly managed by dirty and curr index. thx peppe David -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: manual merge of the akpm-current tree with the net-next tree
Hi Andrew,
Today's linux-next merge of the akpm-current tree got a conflict in:
include/net/sock.h
between commits:
297dbde19cf6 ("netprio_cgroup: limit the maximum css->id to USHRT_MAX")
2a56a1fec290 ("net: wrap sock->sk_cgrp_prioidx and ->sk_classid inside a
struct")
from the net-next tree and commit:
c4b672bd7b34 ("net: tcp_memcontrol: simplify linkage between socket and page
counter")
from the akpm-current tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc include/net/sock.h
index c57e7ce0d097,edd552ef8e38..
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@@ -309,8 -292,8 +293,8 @@@ struct cg_proto
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
* @sk_mark: generic packet mark
- * @sk_classid: this socket's cgroup classid
+ * @sk_cgrp_data: cgroup data for this cgroup
- * @sk_cgrp: this socket's cgroup-specific proto data
+ * @sk_memcg: this socket's memory cgroup association
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
@@@ -443,8 -428,11 +427,8 @@@ struct sock
#ifdef CONFIG_SECURITY
void*sk_security;
#endif
- __u32 sk_mark;
-#ifdef CONFIG_CGROUP_NET_CLASSID
- u32 sk_classid;
-#endif
+ struct sock_cgroup_data sk_cgrp_data;
- struct cg_proto *sk_cgrp;
+ struct mem_cgroup *sk_memcg;
void(*sk_state_change)(struct sock *sk);
void(*sk_data_ready)(struct sock *sk);
void(*sk_write_space)(struct sock *sk);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
Gilad Avidov wrote: pointer math on void* ? what is the size of void ? I'm talking about adding and subtracting pointer values, so u32 pkt_len =((void *)ip_hdr(skb) - skb->data) -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v4 12/19] net: fcoe: use __ethtool_get_ksettings
apologies, forgot to make allyesconfig/allmodconfig this time. Fixed
in my local copy. Will be part of v5 after other feedback on this v4.
On Wed, Dec 9, 2015 at 11:18 AM, kbuild test robot wrote:
> Hi David,
>
> [auto build test ERROR on net-next/master]
>
> url:
> https://github.com/0day-ci/linux/commits/David-Decotigny/RFC-new-ETHTOOL_GSETTINGS-SSETTINGS-API/20151210-022123
> config: i386-randconfig-b0-12100240 (attached as .config)
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/scsi/fcoe/fcoe_transport.c: In function 'fcoe_link_speed_update':
>>> drivers/scsi/fcoe/fcoe_transport.c:104:32: error: request for member 'mask'
>>> in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>drivers/scsi/fcoe/fcoe_transport.c:110:32: error: request for member
> 'mask' in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>drivers/scsi/fcoe/fcoe_transport.c:117:32: error: request for member
> 'mask' in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>drivers/scsi/fcoe/fcoe_transport.c:122:32: error: request for member
> 'mask' in something not a structure or union
> if (ecmd.link_modes.supported.mask[0] & (
>^
>
> vim +/mask +104 drivers/scsi/fcoe/fcoe_transport.c
>
> 98 if (!__ethtool_get_ksettings(netdev, &ecmd)) {
> 99 lport->link_supported_speeds &= ~(FC_PORTSPEED_1GBIT
> |
>100FC_PORTSPEED_10GBIT
> |
>101FC_PORTSPEED_20GBIT
> |
>102
> FC_PORTSPEED_40GBIT);
>103
> > 104 if (ecmd.link_modes.supported.mask[0] & (
>105 SUPPORTED_1000baseT_Half |
>106 SUPPORTED_1000baseT_Full |
>107 SUPPORTED_1000baseKX_Full))
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers: net: cpsw: fix RMII/RGMII mode when used with fixed-link PHY
Commit 1f71e8c96fc654724723ce987e0a8b2aeb81746d ("drivers: net: cpsw: Add
support for fixed-link PHY") used a 'goto no_phy_slave' to skip over the
processing of the mutually-exclusive "phy_id" property. Unfortunately that
also skipped the "phy-mode" property processing, leaving slave_data->phy_if
with its default of PHY_INTERFACE_MODE_NA(0). This later gets passed to
phy_connect() in cpsw_slave_open(), and eventually to cpsw_phy_sel() where
it hits a default case that configures the MAC for MII mode.
The user visible symptom is that while kernel log messages seem to indicate
that the interface is set up, there is no network communication. Eventually
a watchdog error occurs:
NETDEV WATCHDOG: eth0 (cpsw): transmit queue 0 timed out
Signed-off-by: David Rivshin (Allworx)
Fixes: 1f71e8c96fc6 ("drivers: net: cpsw: Add support for fixed-link PHY")
---
This patch was originally developed in parallel with 1f71e8c96fc6 to
accomplish the same goal. When I replaced this patch with 1f71e8c96fc6,
I found that it did not work on my hardware (which uses RGMII), so I
am submitting this patch now as a bugfix. I have rebased this to the
current head of the net tree, but because of the different order of the
logic (see explanation below) it ends up replacing 1f71e8c96fc6's changes
in cpsw.c. If a minimal patch is preferred, I can do that instead.
Besides fixing the bug mentioned in the commit log, there are a few other
differences to note:
* If both "phy_id" and a "fixed-link" subnode are present this patch will
use the "phy_id" property. This should preserve current behavior with
existing devicetrees that might incorrectly have both. This motivates
the biggest difference in code organization from 1f71e8c96fc6.
* Some error messages have been tweaked to reflect the slightly changed
meanings of the checks.
* of_node_get() is called on slave_node before passing the result to
of_phy_find_device(). This increments the reference count, which I
believe is correct for this situation, but I'm not certain of that.
* Uses the phy_device's 'addr' instead of 'phy_id' field when constructing
slave_data->phy_id. Pascal Speck separately came to the same conclusion
in another patch [1].
* [2] pointed out that the 'lenp' sanity check was wrong, and since this
patch re-arranged that check anyways I incorporated that fix as well.
Although the last three items could be fixed separately, it seemed like that
would be unnecessary churn since those same lines were already touched in
this patch. Let me know if its preferred to fix them separately.
This patch is also very similar to one Daniel Trautmann submitted [3], with
the biggest difference being that Daniel's patch uses the new priv->phy_node
field and of_node_get(). While this seems like a better path overall it
does not work if more than once CPSW slave is used, due to struct cpsw_priv
being shared with all the slaves. I am under the impression that phy_node
should really be in struct cpsw_slave instead, but I will leave that for
another patch.
Checkpatch does flag 3 issues I've decided to leave, but I'd be happy to
resolve them if desired:
WARNING: line over 80 characters (cpsw.c:2046):
+ dev_err(&pdev->dev, "Invalid slave[%d] phy_id
property\n", i);
WARNING: line over 80 characters (cpsw.c:2077):
+ dev_err(&pdev->dev, "No slave[%d] phy_id or fixed-link
property\n", i);
Both modifications of the same pre-existing messages that was already
over 80 characters. Seemed more readable to leave them as 1-liners.
CHECK: spaces preferred around that '+' (ctx:VxV) (cpsw.c:2051):
+ phyid = be32_to_cpup(parp+1);
ALso pre-existing, and far enough from the purpose of this patch that it
seemed gratuitous to change now.
[1] http://www.spinics.net/lists/netdev/msg355254.html
[2] http://www.spinics.net/lists/netdev/msg351703.html
[3] http://www.spinics.net/lists/netdev/msg351674.html
(Side note: This is my first patch submission, and any feedback on things
to do differently in the future would be appreciated.)
drivers/net/ethernet/ti/cpsw.c | 65 +-
1 file changed, 39 insertions(+), 26 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 48b92c9..ba8d086 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -2026,45 +2027,57 @@ static int cpsw_probe_dt(struct cpsw_priv *priv,
for_each_child_of_node(node, slave_node) {
struct cpsw_slave_data *slave_data = data->slave_data + i;
const void *mac_addr = NULL;
- u32 phyid;
int lenp;
const __be32 *parp;
- struct device_node *mdio_node;
- struct platform_device *mdio;
/* This is no slave child n
Re: [PATCH v5 0/4] stmmac: Fixed Phy & PTP fixes
Please fix the date and time on your computer. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH bluetooth-next 10/10] ipv6: add ipv6_addr_prefix_copy
From: Marcel Holtmann Date: Wed, 9 Dec 2015 14:28:38 -1000 > if there are no objections, I would like to take this change through the > bluetooth-next tree. No problem: Acked-by: David S. Miller -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch -next] VSOCK: signedness bug in virtio_transport_dgram_enqueue()
On Wed, Dec 09, 2015 at 01:27:13PM +0300, Dan Carpenter wrote:
> "written" has to be signed for the error handling to work.
> trans->ops->send_pkt() returns an int so that's fine.
>
> Fixes: 80a19e338d45 ('VSOCK: Introduce virtio-vsock-common.ko')
> Signed-off-by: Dan Carpenter
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c
> b/net/vmw_vsock/virtio_transport_common.c
> index 28f790d..d9a2325 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -815,7 +815,8 @@ virtio_transport_dgram_enqueue(struct vsock_sock *vsk,
> .type = VIRTIO_VSOCK_TYPE_DGRAM,
> .msg = msg,
> };
> - size_t total_written = 0, pkt_off = 0, written;
> + size_t total_written = 0, pkt_off = 0;
> + int written;
> u16 dgram_id;
>
> /* The max size of a single dgram we support is 64KB */
> @@ -845,7 +846,7 @@ virtio_transport_dgram_enqueue(struct vsock_sock *vsk,
> }
> total_written += written;
> pkt_off += written;
> - pr_debug("%s:id=%d, dgram_len=%zu, off=%zu, total_written=%zu,
> written=%zu\n",
> + pr_debug("%s:id=%d, dgram_len=%zu, off=%zu, total_written=%zu,
> written=%d\n",
> __func__, dgram_id, dgram_len, pkt_off,
> total_written, written);
> }
>
Thanks!
The dgram functionality has been dropped in the latest patch revision
but I'll keep your fix in mind if it's brought back.
Stefan
signature.asc
Description: PGP signature
[PATCH net] net: Flush local routes when device changes vrf association
The VRF driver cycles netdevs when an interface is enslaved or released:
the down event is used to flush neighbor and route tables and the up
event (if the interface was already up) effectively moves local and
connected routes to the proper table.
As of 4f823defdd5b the local route is left hanging around after a link
down, so when a netdev is moved from one VRF to another (or released
from a VRF altogether) local routes are left in the wrong table.
Fix by introducing a NETDEV_VRF_CHANGE event that can be used to trigger
the flush of all routes, including local ones.
Fixes: 4f823defdd5b ("ipv4: fix to not remove local route on link down")
Cc: Julian Anastasov
Signed-off-by: David Ahern
---
Dave: longer term I would like to use the NETDEV_VRF_CHANGE event
to reduce the processing on a VRF change, for instance not losing
IPv6 addresses on the move.
drivers/net/vrf.c | 9 +++--
include/linux/netdevice.h | 1 +
net/ipv4/fib_frontend.c | 3 +++
3 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index b9918e8415ea..36d57f06efde 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -601,12 +601,17 @@ static void cycle_netdev(struct net_device *dev)
unsigned int flags = dev->flags;
int ret;
- if (!netif_running(dev))
+ if (!netif_running(dev)) {
+ call_netdevice_notifiers(NETDEV_VRF_CHANGE, dev);
return;
+ }
ret = dev_change_flags(dev, flags & ~IFF_UP);
- if (ret >= 0)
+ if (ret >= 0) {
+ call_netdevice_notifiers(NETDEV_VRF_CHANGE, dev);
+
ret = dev_change_flags(dev, flags);
+ }
if (ret < 0) {
netdev_err(dev,
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 1bb21ff0fa64..858fa09423ea 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2165,6 +2165,7 @@ struct netdev_lag_lower_state_info {
#define NETDEV_BONDING_INFO0x0019
#define NETDEV_PRECHANGEUPPER 0x001A
#define NETDEV_CHANGELOWERSTATE0x001B
+#define NETDEV_VRF_CHANGE 0x001C
int register_netdevice_notifier(struct notifier_block *nb);
int unregister_netdevice_notifier(struct notifier_block *nb);
diff --git a/net/ipv4/fib_frontend.c b/net/ipv4/fib_frontend.c
index cc8f3e506cde..7d30f6436e3b 100644
--- a/net/ipv4/fib_frontend.c
+++ b/net/ipv4/fib_frontend.c
@@ -1193,6 +1193,9 @@ static int fib_netdev_event(struct notifier_block *this,
unsigned long event, vo
case NETDEV_CHANGEMTU:
rt_cache_flush(net);
break;
+ case NETDEV_VRF_CHANGE:
+ fib_disable_ip(dev, NETDEV_DOWN, true);
+ break;
}
return NOTIFY_DONE;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/4] stmmac: Fix calculations for ptp counters when clock input = 50Mhz.
stmmac_config_sub_second_increment set the sub second increment to 20ns.
Driver is configured to use the fine adjustment method where the sub second
register is incremented when the acculumator incremented by the addend
register wraps overflows. This accumulator is update on every ptp clk
cycle. If a ptp clk with a period of greater than 20ns was used the
sub second register would not get updated correctly.
Instead set the sub sec increment to twice the period of the ptp clk.
This result in the addend register being set mid range and overflow
the accumlator every 2 clock cycles.
Signed-off-by: Phil Reid
---
drivers/net/ethernet/stmicro/stmmac/common.h | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 9 ++---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ---
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index f4518bc..1e19c8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -439,7 +439,7 @@ struct stmmac_ops {
/* PTP and HW Timer helpers */
struct stmmac_hwtimestamp {
void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
- void (*config_sub_second_increment) (void __iomem *ioaddr);
+ u32 (*config_sub_second_increment) (void __iomem *ioaddr, u32 clk_rate);
int (*init_systime) (void __iomem *ioaddr, u32 sec, u32 nsec);
int (*config_addend) (void __iomem *ioaddr, u32 addend);
int (*adjust_systime) (void __iomem *ioaddr, u32 sec, u32 nsec,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
index 76ad214..a77f689 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c
@@ -33,22 +33,25 @@ static void stmmac_config_hw_tstamping(void __iomem
*ioaddr, u32 data)
writel(data, ioaddr + PTP_TCR);
}
-static void stmmac_config_sub_second_increment(void __iomem *ioaddr)
+static u32 stmmac_config_sub_second_increment(void __iomem *ioaddr,
+ u32 ptp_clock)
{
u32 value = readl(ioaddr + PTP_TCR);
unsigned long data;
/* Convert the ptp_clock to nano second
-* formula = (1/ptp_clock) * 10
+* formula = (2/ptp_clock) * 10
* where, ptp_clock = 50MHz.
*/
- data = (10ULL / 5000);
+ data = (20ULL / ptp_clock);
/* 0.465ns accuracy */
if (!(value & PTP_TCR_TSCTRLSSR))
data = (data * 1000) / 465;
writel(data, ioaddr + PTP_SSIR);
+
+ return data;
}
static int stmmac_init_systime(void __iomem *ioaddr, u32 sec, u32 nsec)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 3c6549a..2231a01 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -53,6 +53,7 @@
#include "stmmac.h"
#include
#include
+#include "dwmac1000.h"
#define STMMAC_ALIGN(x)L1_CACHE_ALIGN(x)
@@ -185,7 +186,7 @@ static void stmmac_clk_csr_set(struct stmmac_priv *priv)
priv->clk_csr = STMMAC_CSR_100_150M;
else if ((clk_rate >= CSR_F_150M) && (clk_rate < CSR_F_250M))
priv->clk_csr = STMMAC_CSR_150_250M;
- else if ((clk_rate >= CSR_F_250M) && (clk_rate <= CSR_F_300M))
+ else if ((clk_rate >= CSR_F_250M) && (clk_rate < CSR_F_300M))
priv->clk_csr = STMMAC_CSR_250_300M;
}
}
@@ -435,6 +436,7 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
u32 ts_master_en = 0;
u32 ts_event_en = 0;
u32 value = 0;
+ u32 sec_inc;
if (!(priv->dma_cap.time_stamp || priv->adv_ts)) {
netdev_alert(priv->dev, "No support for HW time stamping\n");
@@ -598,24 +600,19 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev,
struct ifreq *ifr)
tstamp_all | ptp_v2 | ptp_over_ethernet |
ptp_over_ipv6_udp | ptp_over_ipv4_udp | ts_event_en |
ts_master_en | snap_type_sel);
-
priv->hw->ptp->config_hw_tstamping(priv->ioaddr, value);
/* program Sub Second Increment reg */
- priv->hw->ptp->config_sub_second_increment(priv->ioaddr);
+ sec_inc = priv->hw->ptp->config_sub_second_increment(
+ priv->ioaddr, priv->clk_ptp_rate);
+ temp = div_u64(10ULL, sec_inc);
/* calculate default added value:
* formula is :
* addend = (2^32)/freq_div_ratio;
-* where, freq_div_ratio = clk
[PATCH v5 0/4] stmmac: Fixed Phy & PTP fixes
Provide ability to specify a fixed phy in the device tree and retain the mdio bus if no phy is found. This is needed where a dsa is connected via a fixed phy and uses the mdio bus for config. Fixed ptp ref clock calculatins for the stmmac when ptp ref clock is running at <= 50Mhz. Also add device tree setting to config ptp clk source on socfpga platforms. Change from V4: - Restore #ifdef CONFIG_OF around setting of reset_gpio. Member doesn't exist when this isn't defined. Changes from V3: - Use if (IS_ENABLED(CONFIG_OF)) instead of #if. Reorder some code to reduce if statements. - of_mdiobus_register already falls back to mdiobus_register - Tested on system with CONFIG_OF Changes from V2: - Formatting, spaces & lines > 80 chars. Using checkpatch - Drop PTP register debugfs patch. Changes from V1: - Fixed mismatch doc / code for ptp_ref_clk dt node. - Remove unit address from doc example. Phil Reid (5): stmmac: create of compatible mdio bus for stmacc driver stmmac: Correct documentation on stmmac clocks. stmmac: Fix calculations for ptp counters when clock input = 50Mhz. stmmac: socfpga: Provide dt node to config ptp clk source. .../devicetree/bindings/net/socfpga-dwmac.txt | 2 ++ Documentation/devicetree/bindings/net/stmmac.txt | 25 ++--- drivers/net/ethernet/stmicro/stmmac/common.h | 2 +- .../net/ethernet/stmicro/stmmac/dwmac-socfpga.c| 9 +++ .../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 9 --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++--- drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 31 +++--- .../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +- 8 files changed, 65 insertions(+), 34 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 4/4] stmmac: socfpga: Provide dt node to config ptp clk source.
Provides an options to use the ptp clock routed from the Altera FPGA
fabric. Instead of the defalt eosc1 clock connected to the ARM HPS core.
This setting affects all emacs in the core as the ptp clock is common.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/socfpga-dwmac.txt | 2 ++
drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 9 +
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 3a9d679..72d82d6 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -11,6 +11,8 @@ Required properties:
designware version numbers documented in stmmac.txt
- altr,sysmgr-syscon : Should be the phandle to the system manager node that
encompasses the glue register, the register offset, and the register shift.
+ - altr,f2h_ptp_ref_clk use f2h_ptp_ref_clk instead of default eosc1 clock
+ for ptp ref clk. This affects all emacs as the clock is common.
Optional properties:
altr,emac-splitter: Should be the phandle to the emac splitter soft IP node if
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index 401383b..f0d797a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -32,6 +32,7 @@
#define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2
#define SYSMGR_EMACGRP_CTRL_PHYSEL_WIDTH 2
#define SYSMGR_EMACGRP_CTRL_PHYSEL_MASK 0x0003
+#define SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK 0x0010
#define EMAC_SPLITTER_CTRL_REG 0x0
#define EMAC_SPLITTER_CTRL_SPEED_MASK 0x3
@@ -47,6 +48,7 @@ struct socfpga_dwmac {
struct regmap *sys_mgr_base_addr;
struct reset_control *stmmac_rst;
void __iomem *splitter_base;
+ bool f2h_ptp_ref_clk;
};
static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed)
@@ -116,6 +118,8 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac
*dwmac, struct device *
return -EINVAL;
}
+ dwmac->f2h_ptp_ref_clk = of_property_read_bool(np,
"altr,f2h_ptp_ref_clk");
+
np_splitter = of_parse_phandle(np, "altr,emac-splitter", 0);
if (np_splitter) {
if (of_address_to_resource(np_splitter, 0, &res_splitter)) {
@@ -171,6 +175,11 @@ static int socfpga_dwmac_setup(struct socfpga_dwmac *dwmac)
ctrl &= ~(SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << reg_shift);
ctrl |= val << reg_shift;
+ if (dwmac->f2h_ptp_ref_clk)
+ ctrl |= SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift / 2);
+ else
+ ctrl &= ~(SYSMGR_EMACGRP_CTRL_PTP_REF_CLK_MASK << (reg_shift /
2));
+
regmap_write(sys_mgr_base_addr, reg_offset, ctrl);
return 0;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/4] stmmac: Correct documentation on stmmac clocks.
devm_get_clk looks in clock-name property for matching clock. the ptp_ref_clk property is ignored. Acked-by: Rob Herring Signed-off-by: Phil Reid --- Documentation/devicetree/bindings/net/stmmac.txt | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt index fd5ddf8..e862a92 100644 --- a/Documentation/devicetree/bindings/net/stmmac.txt +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -35,15 +35,14 @@ Optional properties: - reset-names: Should contain the reset signal name "stmmaceth", if a reset phandle is given - max-frame-size: See ethernet.txt file in the same directory -- clocks: If present, the first clock should be the GMAC main clock and - the second clock should be peripheral's register interface clock. Further - clocks may be specified in derived bindings. -- clock-names: One name for each entry in the clocks property, the - first one should be "stmmaceth" and the second one should be "pclk". -- clk_ptp_ref: this is the PTP reference clock; in case of the PTP is - available this clock is used for programming the Timestamp Addend Register. - If not passed then the system clock will be used and this is fine on some - platforms. +- clocks: If present, the first clock should be the GMAC main clock + The optional second clock should be peripheral's register interface clock. + The third optional clock should be the ptp reference clock. + Further clocks may be specified in derived bindings. +- clock-names: One name for each entry in the clocks property. + The first one should be "stmmaceth". + The optional second one should be "pclk". + The optional third one should be "clk_ptp_ref". - snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register. - tx-fifo-depth: See ethernet.txt file in the same directory - rx-fifo-depth: See ethernet.txt file in the same directory -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/4] stmmac: create of compatible mdio bus for stmacc driver
The DSA driver needs to be passed a reference to an mdio bus. Typically
the mac is configured to use a fixed link but the mdio bus still needs
to be registered so that it con configure the switch.
This patch follows the same process as the altera tse ethernet driver for
creation of the mdio bus.
Acked-by: Rob Herring
Signed-off-by: Phil Reid
---
Documentation/devicetree/bindings/net/stmmac.txt | 8 ++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 31 +++---
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt
b/Documentation/devicetree/bindings/net/stmmac.txt
index f34fc3c..fd5ddf8 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -47,6 +47,7 @@ Optional properties:
- snps,burst_len: The AXI burst lenth value of the AXI BUS MODE register.
- tx-fifo-depth: See ethernet.txt file in the same directory
- rx-fifo-depth: See ethernet.txt file in the same directory
+- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
@@ -65,4 +66,11 @@ Examples:
tx-fifo-depth = <16384>;
clocks = <&clock>;
clock-names = "stmmaceth";
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy1: ethernet-phy@0 {
+ };
+ };
};
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
index bba670c..bb6f75c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c
@@ -29,7 +29,7 @@
#include
#include
#include
-
+#include
#include
#include "stmmac.h"
@@ -200,10 +200,29 @@ int stmmac_mdio_register(struct net_device *ndev)
struct stmmac_priv *priv = netdev_priv(ndev);
struct stmmac_mdio_bus_data *mdio_bus_data = priv->plat->mdio_bus_data;
int addr, found;
+ struct device_node *mdio_node = NULL;
+ struct device_node *child_node = NULL;
if (!mdio_bus_data)
return 0;
+ if (IS_ENABLED(CONFIG_OF)) {
+ for_each_child_of_node(priv->device->of_node, child_node) {
+ if (of_device_is_compatible(child_node,
+ "snps,dwmac-mdio")) {
+ mdio_node = child_node;
+ break;
+ }
+ }
+
+ if (mdio_node) {
+ netdev_dbg(ndev, "FOUND MDIO subnode\n");
+ } else {
+ netdev_err(ndev, "NO MDIO subnode\n");
+ return 0;
+ }
+ }
+
new_bus = mdiobus_alloc();
if (new_bus == NULL)
return -ENOMEM;
@@ -231,7 +250,8 @@ int stmmac_mdio_register(struct net_device *ndev)
new_bus->irq = irqlist;
new_bus->phy_mask = mdio_bus_data->phy_mask;
new_bus->parent = priv->device;
- err = mdiobus_register(new_bus);
+
+ err = of_mdiobus_register(new_bus, mdio_node);
if (err != 0) {
pr_err("%s: Cannot register as MDIO bus\n", new_bus->name);
goto bus_register_fail;
@@ -284,13 +304,6 @@ int stmmac_mdio_register(struct net_device *ndev)
}
}
- if (!found) {
- pr_warn("%s: No PHY found\n", ndev->name);
- mdiobus_unregister(new_bus);
- mdiobus_free(new_bus);
- return -ENODEV;
- }
-
priv->mii = new_bus;
return 0;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index d02691b..6863420 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -146,7 +146,7 @@ stmmac_probe_config_dt(struct platform_device *pdev, const
char **mac)
if (of_property_read_u32(np, "snps,phy-addr", &plat->phy_addr) == 0)
dev_warn(&pdev->dev, "snps,phy-addr property is deprecated\n");
- if (plat->phy_node || plat->phy_bus_name)
+ if (plat->phy_bus_name)
plat->mdio_bus_data = NULL;
else
plat->mdio_bus_data =
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: local route left hanging around in wrong table
On 12/9/15 4:32 PM, David Ahern wrote: At this point I don't see a simple solution to fix this for v4.4 hence this email -- any thoughts? never mind. As soon as you send up the flares you solve problem. patch coming soon. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v2 4/4] bnxt_en: Implement missing tx timeout reset logic.
The reset logic calls bnxt_close_nic() and bnxt_open_nic() under rtnl_lock
from bnxt_sp_task. BNXT_STATE_IN_SP_TASK must be cleared before calling
bnxt_close_nic() to avoid deadlock.
v2: Fixed white space error. Thanks Dave.
Signed-off-by: Michael Chan
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index f5f4489..0c2c3f5 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -5031,8 +5031,10 @@ static void bnxt_dbg_dump_states(struct bnxt *bp)
static void bnxt_reset_task(struct bnxt *bp)
{
bnxt_dbg_dump_states(bp);
- if (netif_running(bp->dev))
- bnxt_tx_disable(bp); /* prevent tx timout again */
+ if (netif_running(bp->dev)) {
+ bnxt_close_nic(bp, false, false);
+ bnxt_open_nic(bp, false, false);
+ }
}
static void bnxt_tx_timeout(struct net_device *dev)
@@ -5111,8 +5113,16 @@ static void bnxt_sp_task(struct work_struct *work)
bnxt_hwrm_tunnel_dst_port_free(
bp, TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN);
}
- if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, &bp->sp_event))
- bnxt_reset_task(bp);
+ if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, &bp->sp_event)) {
+ /* bnxt_reset_task() calls bnxt_close_nic() which waits
+* for BNXT_STATE_IN_SP_TASK to clear.
+*/
+ clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
+ rtnl_lock();
+ bnxt_reset_task(bp);
+ set_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
+ rtnl_unlock();
+ }
smp_mb__before_atomic();
clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v2 0/4] bnxt_en: Bug fix and add tx timeout recovery.
Fix a bitmap declaration bug and add missing tx timeout recovery. v2: Fixed white space error. Thanks Dave. Michael Chan (4): bnxt_en: Fix bitmap declaration to work on 32-bit arches. bnxt_en: Change bp->state to bitmap. bnxt_en: Don't cancel sp_task from bnxt_close_nic(). bnxt_en: Implement missing tx timeout reset logic. drivers/net/ethernet/broadcom/bnxt/bnxt.c | 48 + drivers/net/ethernet/broadcom/bnxt/bnxt.h | 6 ++-- drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +- 3 files changed, 37 insertions(+), 19 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v2 2/4] bnxt_en: Change bp->state to bitmap.
This allows multiple independent bits to be set for various states.
Subsequent patches to implement tx timeout reset will require this.
Signed-off-by: Michael Chan
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 8
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 5 ++---
drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c | 2 +-
3 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index 51671e3..fd89e9d 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4602,7 +4602,7 @@ static int __bnxt_open_nic(struct bnxt *bp, bool
irq_re_init, bool link_re_init)
bp->nge_port_cnt = 1;
}
- bp->state = BNXT_STATE_OPEN;
+ set_bit(BNXT_STATE_OPEN, &bp->state);
bnxt_enable_int(bp);
/* Enable TX queues */
bnxt_tx_enable(bp);
@@ -4678,7 +4678,7 @@ int bnxt_close_nic(struct bnxt *bp, bool irq_re_init,
bool link_re_init)
/* Change device state to avoid TX queue wake up's */
bnxt_tx_disable(bp);
- bp->state = BNXT_STATE_CLOSED;
+ clear_bit(BNXT_STATE_OPEN, &bp->state);
cancel_work_sync(&bp->sp_task);
/* Flush rings before disabling interrupts */
@@ -5080,7 +5080,7 @@ static void bnxt_sp_task(struct work_struct *work)
struct bnxt *bp = container_of(work, struct bnxt, sp_task);
int rc;
- if (bp->state != BNXT_STATE_OPEN)
+ if (!test_bit(BNXT_STATE_OPEN, &bp->state))
return;
if (test_and_clear_bit(BNXT_RX_MASK_SP_EVENT, &bp->sp_event))
@@ -5185,7 +5185,7 @@ static int bnxt_init_board(struct pci_dev *pdev, struct
net_device *dev)
bp->timer.function = bnxt_timer;
bp->current_interval = BNXT_TIMER_INTERVAL;
- bp->state = BNXT_STATE_CLOSED;
+ clear_bit(BNXT_STATE_OPEN, &bp->state);
return 0;
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index 674bc51..a8b6881 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -925,9 +925,8 @@ struct bnxt {
struct timer_list timer;
- int state;
-#define BNXT_STATE_CLOSED 0
-#define BNXT_STATE_OPEN1
+ unsigned long state;
+#define BNXT_STATE_OPEN0
struct bnxt_irq *irq_tbl;
u8 mac_addr[ETH_ALEN];
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
index 7a9af28..ea044bb 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_sriov.c
@@ -21,7 +21,7 @@
#ifdef CONFIG_BNXT_SRIOV
static int bnxt_vf_ndo_prep(struct bnxt *bp, int vf_id)
{
- if (bp->state != BNXT_STATE_OPEN) {
+ if (!test_bit(BNXT_STATE_OPEN, &bp->state)) {
netdev_err(bp->dev, "vf ndo called though PF is down\n");
return -EINVAL;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v2 3/4] bnxt_en: Don't cancel sp_task from bnxt_close_nic().
When implementing driver reset from tx_timeout in the next patch,
bnxt_close_nic() will be called from the sp_task workqueue. Calling
cancel_work() on sp_task will hang the workqueue.
Instead, set a new bit BNXT_STATE_IN_SP_TASK when bnxt_sp_task() is running.
bnxt_close_nic() will wait for BNXT_STATE_IN_SP_TASK to clear before
proceeding.
Signed-off-by: Michael Chan
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 13 +++--
drivers/net/ethernet/broadcom/bnxt/bnxt.h | 1 +
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index fd89e9d..f5f4489 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -4679,7 +4679,9 @@ int bnxt_close_nic(struct bnxt *bp, bool irq_re_init,
bool link_re_init)
bnxt_tx_disable(bp);
clear_bit(BNXT_STATE_OPEN, &bp->state);
- cancel_work_sync(&bp->sp_task);
+ smp_mb__after_atomic();
+ while (test_bit(BNXT_STATE_IN_SP_TASK, &bp->state))
+ msleep(20);
/* Flush rings before disabling interrupts */
bnxt_shutdown_nic(bp, irq_re_init);
@@ -5080,8 +5082,12 @@ static void bnxt_sp_task(struct work_struct *work)
struct bnxt *bp = container_of(work, struct bnxt, sp_task);
int rc;
- if (!test_bit(BNXT_STATE_OPEN, &bp->state))
+ set_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
+ smp_mb__after_atomic();
+ if (!test_bit(BNXT_STATE_OPEN, &bp->state)) {
+ clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
return;
+ }
if (test_and_clear_bit(BNXT_RX_MASK_SP_EVENT, &bp->sp_event))
bnxt_cfg_rx_mode(bp);
@@ -5107,6 +5113,9 @@ static void bnxt_sp_task(struct work_struct *work)
}
if (test_and_clear_bit(BNXT_RESET_TASK_SP_EVENT, &bp->sp_event))
bnxt_reset_task(bp);
+
+ smp_mb__before_atomic();
+ clear_bit(BNXT_STATE_IN_SP_TASK, &bp->state);
}
static int bnxt_init_board(struct pci_dev *pdev, struct net_device *dev)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
index a8b6881..f199f4c 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.h
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.h
@@ -927,6 +927,7 @@ struct bnxt {
unsigned long state;
#define BNXT_STATE_OPEN0
+#define BNXT_STATE_IN_SP_TASK 1
struct bnxt_irq *irq_tbl;
u8 mac_addr[ETH_ALEN];
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net v2 1/4] bnxt_en: Fix bitmap declaration to work on 32-bit arches.
The declaration of the bitmap vf_req_snif_bmap using fixed array of
unsigned long will only work on 64-bit archs. Use DECLARE_BITMAP instead
which will work on all archs.
Signed-off-by: Michael Chan
---
drivers/net/ethernet/broadcom/bnxt/bnxt.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
index bdf094f..51671e3 100644
--- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
+++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
@@ -2693,17 +2693,16 @@ static int bnxt_hwrm_func_drv_rgtr(struct bnxt *bp)
req.ver_upd = DRV_VER_UPD;
if (BNXT_PF(bp)) {
- unsigned long vf_req_snif_bmap[4];
+ DECLARE_BITMAP(vf_req_snif_bmap, 256);
u32 *data = (u32 *)vf_req_snif_bmap;
- memset(vf_req_snif_bmap, 0, 32);
+ memset(vf_req_snif_bmap, 0, sizeof(vf_req_snif_bmap));
for (i = 0; i < ARRAY_SIZE(bnxt_vf_req_snif); i++)
__set_bit(bnxt_vf_req_snif[i], vf_req_snif_bmap);
- for (i = 0; i < 8; i++) {
- req.vf_req_fwd[i] = cpu_to_le32(*data);
- data++;
- }
+ for (i = 0; i < 8; i++)
+ req.vf_req_fwd[i] = cpu_to_le32(data[i]);
+
req.enables |=
cpu_to_le32(FUNC_DRV_RGTR_REQ_ENABLES_VF_REQ_FWD);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH bluetooth-next 10/10] ipv6: add ipv6_addr_prefix_copy
Hi Dave,
> This patch adds a static inline function ipv6_addr_prefix_copy which
> copies a ipv6 address prefix(argument pfx) into the ipv6 address prefix.
> The prefix len is given by plen as bits. This function mainly based on
> ipv6_addr_prefix which copies one address prefix from address into a new
> ipv6 address destination and zero all other address bits.
>
> The difference is that ipv6_addr_prefix_copy don't get a prefix from an
> ipv6 address, it sets a prefix to an ipv6 address with keeping other
> address bits. The use case is for context based address compression
> inside 6LoWPAN IPHC header which keeping ipv6 prefixes inside a context
> table to lookup address-bits without sending them.
>
> Cc: David S. Miller
> Cc: Alexey Kuznetsov
> Cc: James Morris
> Cc: Hideaki YOSHIFUJI
> Cc: Patrick McHardy
> Acked-by: Łukasz Duda
> Acked-by: Hannes Frederic Sowa
> Acked-by: YOSHIFUJI Hideaki
> Reviewed-by: Stefan Schmidt
> Signed-off-by: Alexander Aring
> ---
> include/net/ipv6.h | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/include/net/ipv6.h b/include/net/ipv6.h
> index 9a5c9f0..6570f37 100644
> --- a/include/net/ipv6.h
> +++ b/include/net/ipv6.h
> @@ -401,6 +401,21 @@ static inline void ipv6_addr_prefix(struct in6_addr *pfx,
> pfx->s6_addr[o] = addr->s6_addr[o] & (0xff00 >> b);
> }
>
> +static inline void ipv6_addr_prefix_copy(struct in6_addr *addr,
> + const struct in6_addr *pfx,
> + int plen)
> +{
> + /* caller must guarantee 0 <= plen <= 128 */
> + int o = plen >> 3,
> + b = plen & 0x7;
> +
> + memcpy(addr->s6_addr, pfx, o);
> + if (b != 0) {
> + addr->s6_addr[o] &= ~(0xff00 >> b);
> + addr->s6_addr[o] |= (pfx->s6_addr[o] & (0xff00 >> b));
> + }
> +}
> +
> static inline void __ipv6_addr_set_half(__be32 *addr,
> __be32 wh, __be32 wl)
> {
if there are no objections, I would like to take this change through the
bluetooth-next tree.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
Thank you Timur for the good review.
On Wed, 9 Dec 2015 14:09:27 -0600
Timur Tabi wrote:
> So first of all, thanks for posting this. I know it's missing a bunch
> of stuff that's necessary for Qualcomm's Server chip, but it's a
> start.
>
> Unfortunately, 6,000 lines is a lot to review at once. Any chance you
> can break up the next version into smaller patches?
Agree its a lot to review, however:
1) This driver is the what left after I removed all unnecessary
features, thus it is already minimal.
I have removed features such as support for: server, ACPI, ethtool,
ptp/1588, etc.
2) This size seems comparable to first patches of existing Ethernet
drivers.
>
> On Mon, Dec 7, 2015 at 4:58 PM, Gilad Avidov
> wrote:
>
> > + qcom,emac-gpio-mdc = <&msmgpio 123 0>;
> > + qcom,emac-gpio-mdio = <&msmgpio 124 0>;
>
> Is there any chance you can remove all references to "MSM" throughout
> the entire driver, since the EMAC exists on non-MSM parts?
msm appears only in this DT binding example. None in the code.
I will look into removing this instance too.
>
> > + qcom,emac-tstamp-en;
> > + qcom,emac-ptp-frac-ns-adj = <12500 1>;
> > + phy-addr = <0>;
> > + };
> > diff --git a/drivers/net/ethernet/qualcomm/Kconfig
> > b/drivers/net/ethernet/qualcomm/Kconfig index a76e380..ae9442d
> > 100644 --- a/drivers/net/ethernet/qualcomm/Kconfig
> > +++ b/drivers/net/ethernet/qualcomm/Kconfig
> > @@ -24,4 +24,11 @@ config QCA7000
> > To compile this driver as a module, choose M here. The
> > module will be called qcaspi.
> >
> > +config QCOM_EMAC
> > + tristate "MSM EMAC Gigabit Ethernet support"
> > + default n
>
> "default n" is redundant
>
> > + select CRC32
> > + ---help---
> > + This driver supports the Qualcomm EMAC Gigabit Ethernet
> > controller.
>
> I think should be longer, perhaps by adding some more info about the
> controller itself?
ok.
>
> > +
> > endif # NET_VENDOR_QUALCOMM
> > diff --git a/drivers/net/ethernet/qualcomm/Makefile
> > b/drivers/net/ethernet/qualcomm/Makefile index 9da2d75..b14686e
> > 100644 --- a/drivers/net/ethernet/qualcomm/Makefile
> > +++ b/drivers/net/ethernet/qualcomm/Makefile
> > @@ -4,3 +4,5 @@
> >
> > obj-$(CONFIG_QCA7000) += qcaspi.o
> > qcaspi-objs := qca_spi.o qca_framing.o qca_7k.o qca_debug.o
> > +
> > +obj-$(CONFIG_QCOM_EMAC) += emac/
> > \ No newline at end of file
>
> Please fix
ok.
>
> > +/* RSS */
> > +static void emac_mac_rss_config(struct emac_adapter *adpt)
> > +{
> > + int key_len_by_u32 = sizeof(adpt->rss_key) / sizeof(u32);
> > + int idt_len_by_u32 = sizeof(adpt->rss_idt) / sizeof(u32);
>
> Can you use ARRAY_SIZE here?
Agree.
>
> > + u32 rxq0;
> > + int i;
> > +
> > + /* Fill out hash function keys */
> > + for (i = 0; i < key_len_by_u32; i++) {
> > + u32 key, idx_base;
> > +
> > + idx_base = (key_len_by_u32 - i) * 4;
> > + key = ((adpt->rss_key[idx_base - 1]) |
> > + (adpt->rss_key[idx_base - 2] << 8) |
> > + (adpt->rss_key[idx_base - 3] << 16) |
> > + (adpt->rss_key[idx_base - 4] << 24));
> > + writel_relaxed(key, adpt->base + EMAC_RSS_KEY(i,
> > u32));
> > + }
> > +
> > + /* Fill out redirection table */
> > + for (i = 0; i < idt_len_by_u32; i++)
> > + writel_relaxed(adpt->rss_idt[i],
> > + adpt->base + EMAC_RSS_TBL(i, u32));
> > +
> > + writel_relaxed(adpt->rss_base_cpu, adpt->base +
> > EMAC_BASE_CPU_NUMBER); +
> > + rxq0 = readl_relaxed(adpt->base + EMAC_RXQ_CTRL_0);
> > + if (adpt->rss_hstype & EMAC_RSS_HSTYP_IPV4_EN)
> > + rxq0 |= RXQ0_RSS_HSTYP_IPV4_EN;
> > + else
> > + rxq0 &= ~RXQ0_RSS_HSTYP_IPV4_EN;
> > +
> > + if (adpt->rss_hstype & EMAC_RSS_HSTYP_TCP4_EN)
> > + rxq0 |= RXQ0_RSS_HSTYP_IPV4_TCP_EN;
> > + else
> > + rxq0 &= ~RXQ0_RSS_HSTYP_IPV4_TCP_EN;
> > +
> > + if (adpt->rss_hstype & EMAC_RSS_HSTYP_IPV6_EN)
> > + rxq0 |= RXQ0_RSS_HSTYP_IPV6_EN;
> > + else
> > + rxq0 &= ~RXQ0_RSS_HSTYP_IPV6_EN;
> > +
> > + if (adpt->rss_hstype & EMAC_RSS_HSTYP_TCP6_EN)
> > + rxq0 |= RXQ0_RSS_HSTYP_IPV6_TCP_EN;
> > + else
> > + rxq0 &= ~RXQ0_RSS_HSTYP_IPV6_TCP_EN;
> > +
> > + rxq0 |= ((adpt->rss_idt_size << IDT_TABLE_SIZE_SHFT) &
> > + IDT_TABLE_SIZE_BMSK);
> > + rxq0 |= RSS_HASH_EN;
> > +
> > + wmb(); /* ensure all parameters are written before enabling
> > RSS */ +
> > + writel_relaxed(rxq0, adpt->base + EMAC_RXQ_CTRL_0);
>
> Why not just use writel(), which already includes a wmb()
>
ok.
> > +/* Power Management */
> > +void emac_mac_pm(struct emac_adapter *adpt, u32 speed, bool
> > wol_en, bool rx_en
Re: [PATCH net 2/2] openvswitch: Respect conntrack zone even if invalid
On Wed, Dec 9, 2015 at 2:07 PM, Joe Stringer wrote:
> If userspace executes ct(zone=1), and the connection tracker determines
> that the packet is invalid, then the ct_zone flow key field is populated
> with the default zone rather than the zone that was specified. Even
> though connection tracking failed, this field should be updated with the
> value that the action specified. Fix the issue.
>
> Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
> Signed-off-by: Joe Stringer
Acked-by: Pravin B Shelar
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] openvswitch: Fix helper reference leak
On Wed, Dec 9, 2015 at 3:10 PM, Joe Stringer wrote:
> On 9 December 2015 at 14:50, Pravin Shelar wrote:
>> On Wed, Dec 9, 2015 at 2:07 PM, Joe Stringer wrote:
>>> If the actions (re)allocation fails, or the actions list is larger than the
>>> maximum size, and the conntrack action is the last action when these
>>> problems are hit, then references to helper modules may be leaked. Fix
>>> the issue.
>>>
>>> Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
>>> Signed-off-by: Joe Stringer
>>> ---
>>> net/openvswitch/conntrack.c | 9 -
>>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>>> index c2cc11168fd5..585a5aa81f89 100644
>>> --- a/net/openvswitch/conntrack.c
>>> +++ b/net/openvswitch/conntrack.c
>>> @@ -53,6 +53,8 @@ struct ovs_conntrack_info {
>>> struct md_labels labels;
>>> };
>>>
>>> +static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info);
>>> +
>>> static u16 key_to_nfproto(const struct sw_flow_key *key)
>>> {
>>> switch (ntohs(key->eth.type)) {
>>> @@ -708,7 +710,7 @@ int ovs_ct_copy_action(struct net *net, const struct
>>> nlattr *attr,
>>> nf_conntrack_get(&ct_info.ct->ct_general);
>>
>> I see another issue here. Updates to ct_info are done after it is
>> copied to action list. ct action on the action list and ct_info are
>> inconsistent, So it is still leaking nf-conntrack reference.
>
> You're referring to the below?
>
> __set_bit(IPS_CONFIRMED_BIT, &ct_info.ct->status);
> nf_conntrack_get(&ct_info.ct->ct_general);
>
> ct_info.ct points to the same location as the version that has been
> copied into the action list. I agree it's a bit misleading though. If
> you're not seeing something else, it seems cosmetic so I can (should?)
> follow up on net-next.
Right, there is no leak, cosmetic changes can be done later. I do not
have problem with this patch as it is.
Acked-by: Pravin B Shelar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
local route left hanging around in wrong table
The VRF driver cycles netdevs (down then up) when an interface is
enslaved or released -- the down event is used to flush neighbor and
route tables and the up event effectively moves local and connected
routes to the proper table.
As of 4f823defdd5b ("ipv4: fix to not remove local route on link down")
the local route is left hanging around after a link down and when a
netdev is moved from one VRF to another (or released altogether) the
local route is in the wrong table:
root@kenny:~# ip link set dev eth1 master vrf-red
At this point all routes associated with eth1 should be in the vrf-red
table. Yet:
root@kenny:~# ip ro ls table local | grep eth1
local 10.100.1.2 dev eth1 proto kernel scope host src 10.100.1.2
And it is in the vrf table as well:
root@kenny:~# ip ro ls table vrf-red
unreachable default
broadcast 10.100.1.0 dev eth1 proto kernel scope link src 10.100.1.2
10.100.1.0/24 dev eth1 proto kernel scope link src 10.100.1.2
local 10.100.1.2 dev eth1 proto kernel scope host src 10.100.1.2
broadcast 10.100.1.255 dev eth1 proto kernel scope link src 10.100.1.2
Unenslaving the device leaves the local route in the VRF table:
root@kenny:~# ip link set dev eth1 nomaster
root@kenny:~# ip ro ls table vrf-red
unreachable default
local 10.100.1.2 dev eth1 proto kernel scope host src 10.100.1.2
I realize Julian's patch was fixing a 'bug' introduced in June, so most
likely can't do a revert of it. I am looking at a standalone notifier
(e.g., NETDEV_VRF_CHANGE), but that patch seems a bit large for v4.4.
At this point I don't see a simple solution to fix this for v4.4 hence
this email -- any thoughts? To be clear this is the change that causes
the problem:
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index d97268e8ff10..1801519da446 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -1365,7 +1365,8 @@ int fib_sync_down_dev(struct net_device *dev,
unsigned long event, bool force)
struct hlist_head *head = &fib_info_devhash[hash];
struct fib_nh *nh;
- if (force)
+ if (event == NETDEV_UNREGISTER ||
+ event == NETDEV_DOWN)
scope = -1;
hlist_for_each_entry(nh, head, nh_hash) {
David
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: memcontrol: only manage socket pressure for CONFIG_INET
On Wed, 9 Dec 2015 18:05:05 -0500 Johannes Weiner wrote:
> On Wed, Dec 09, 2015 at 02:28:36PM -0800, Andrew Morton wrote:
> > On Wed, 9 Dec 2015 13:58:58 -0500 Johannes Weiner
> > wrote:
> > > The calls to tcp_init_cgroup() appear earlier in the series than "mm:
> > > memcontrol: hook up vmpressure to socket pressure". However, they get
> > > moved around a few times so fixing it earlier means respinning the
> > > series. Andrew, it's up to you whether we take the bisectability hit
> > > for !CONFIG_INET && CONFIG_MEMCG (how common is this?) or whether you
> > > want me to resend the series.
> >
> > hm, drat, I was suspecting dependency issues here, but a test build
> > said it was OK.
> >
> > Actually, I was expecting this patch series to depend on the linux-next
> > cgroup2 changes, but that doesn't appear to be the case. *should* this
> > series be staged after the cgroup2 code?
>
> Code-wise they are independent. My stuff is finishing up the new memcg
> control knobs, the cgroup2 stuff is changing how and when those knobs
> are exposed from within the cgroup core. I'm not relying on any recent
> changes in the cgroup core AFAICS, so the order shouldn't matter here.
OK, thanks.
> > Regarding this particular series: yes, I think we can live with a
> > bisection hole for !CONFIG_INET && CONFIG_MEMCG users. But I'm not
> > sure why we're discussing bisection issues, because Arnd's build
> > failure occurs with everything applied?
>
> Arnd's patches apply to the top of the stack, but they address issues
> introduced early in the series and the problematic code gets touched a
> lot in subsequent patches. E.g. the first build breakage is in ("net:
> tcp_memcontrol: simplify linkage between socket and page counter")
> when the tcp_init_cgroup() and tcp_destroy_cgroup() function calls get
> moved around and lose the CONFIG_INET protection.
Yeah, this is a pain. I think I'll fold Arnd's fix into
mm-memcontrol-introduce-config_memcg_legacy_kmem.patch (which is staged
after all the other MM patches and after linux-next) and will pretend I
didn't know about the issue ;)
> Anyway, if we can live with the bisection caveat then Arnd's fixes on
> top of the kmem series look good to me. Depending on what Vladimir
> thinks we might want to replace the CONFIG_SLOB fix with something
> else later on, but that shouldn't be a problem, either.
I don't have a fix for the CONFIG_SLOB&&CONFIG_MEMCG issue yet. I
agree that it would be best to make the combination work correctly
rather than banning it, but that does require a bit of runtime testing.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checksum offload queries
On 12/09/15 at 02:51pm, Tom Herbert wrote: > I'm sorry, I still don't understand your point. What is "automatic > nested checksum filling" and how does this relate to RX (e.g. > CHECSUM_COMPLETE). Too much compression ;-) My understanding of the thread was that the desired state is no checksum validation on RX and no automatic checksum offload on TX unless explicitly instructed via csum offset. This is what I would call a CHECKSUM_COMPLETE card (no protocol parsing). As opposed to a CHECKSUM_UNNECESSARY card which does protocol parsing. Some do nested checksum offload on TX as we know even if only instructed to do one of the checksums. So let's assume everybody goes CHECKSUM_COMPLETE and we have at most a single level of checksum offload on TX. (As I understand, a requirement to not break RCO anyway.) RCO would resolve the possible software checksum performance bottleneck in the scenario of outer and inner header checksum requirements. While I agree that this is the case, we need to have support in hardware VTEPs for this in order for it to be usable. (excluding those which require a checksum 0 anyway) Multiple nested tunnels would be another beast outside of the scope of RCO but as I stated in the other email, I don't think we should proactively solve that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] openvswitch: Fix helper reference leak
On 9 December 2015 at 14:50, Pravin Shelar wrote:
> On Wed, Dec 9, 2015 at 2:07 PM, Joe Stringer wrote:
>> If the actions (re)allocation fails, or the actions list is larger than the
>> maximum size, and the conntrack action is the last action when these
>> problems are hit, then references to helper modules may be leaked. Fix
>> the issue.
>>
>> Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
>> Signed-off-by: Joe Stringer
>> ---
>> net/openvswitch/conntrack.c | 9 -
>> 1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
>> index c2cc11168fd5..585a5aa81f89 100644
>> --- a/net/openvswitch/conntrack.c
>> +++ b/net/openvswitch/conntrack.c
>> @@ -53,6 +53,8 @@ struct ovs_conntrack_info {
>> struct md_labels labels;
>> };
>>
>> +static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info);
>> +
>> static u16 key_to_nfproto(const struct sw_flow_key *key)
>> {
>> switch (ntohs(key->eth.type)) {
>> @@ -708,7 +710,7 @@ int ovs_ct_copy_action(struct net *net, const struct
>> nlattr *attr,
>> nf_conntrack_get(&ct_info.ct->ct_general);
>
> I see another issue here. Updates to ct_info are done after it is
> copied to action list. ct action on the action list and ct_info are
> inconsistent, So it is still leaking nf-conntrack reference.
You're referring to the below?
__set_bit(IPS_CONFIRMED_BIT, &ct_info.ct->status);
nf_conntrack_get(&ct_info.ct->ct_general);
ct_info.ct points to the same location as the version that has been
copied into the action list. I agree it's a bit misleading though. If
you're not seeing something else, it seems cosmetic so I can (should?)
follow up on net-next.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: memcontrol: only manage socket pressure for CONFIG_INET
On Wed, Dec 09, 2015 at 02:28:36PM -0800, Andrew Morton wrote:
> On Wed, 9 Dec 2015 13:58:58 -0500 Johannes Weiner wrote:
>
> > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > > index 6faea81e66d7..73cd572167bb 100644
> > > --- a/mm/memcontrol.c
> > > +++ b/mm/memcontrol.c
> > > @@ -4220,13 +4220,13 @@ mem_cgroup_css_online(struct cgroup_subsys_state
> > > *css)
> > > if (ret)
> > > return ret;
> > >
> > > +#ifdef CONFIG_INET
> > > #ifdef CONFIG_MEMCG_LEGACY_KMEM
> > > ret = tcp_init_cgroup(memcg);
> > > if (ret)
> > > return ret;
> > > #endif
> >
> > The calls to tcp_init_cgroup() appear earlier in the series than "mm:
> > memcontrol: hook up vmpressure to socket pressure". However, they get
> > moved around a few times so fixing it earlier means respinning the
> > series. Andrew, it's up to you whether we take the bisectability hit
> > for !CONFIG_INET && CONFIG_MEMCG (how common is this?) or whether you
> > want me to resend the series.
>
> hm, drat, I was suspecting dependency issues here, but a test build
> said it was OK.
>
> Actually, I was expecting this patch series to depend on the linux-next
> cgroup2 changes, but that doesn't appear to be the case. *should* this
> series be staged after the cgroup2 code?
Code-wise they are independent. My stuff is finishing up the new memcg
control knobs, the cgroup2 stuff is changing how and when those knobs
are exposed from within the cgroup core. I'm not relying on any recent
changes in the cgroup core AFAICS, so the order shouldn't matter here.
> Regarding this particular series: yes, I think we can live with a
> bisection hole for !CONFIG_INET && CONFIG_MEMCG users. But I'm not
> sure why we're discussing bisection issues, because Arnd's build
> failure occurs with everything applied?
Arnd's patches apply to the top of the stack, but they address issues
introduced early in the series and the problematic code gets touched a
lot in subsequent patches. E.g. the first build breakage is in ("net:
tcp_memcontrol: simplify linkage between socket and page counter")
when the tcp_init_cgroup() and tcp_destroy_cgroup() function calls get
moved around and lose the CONFIG_INET protection.
This will leave states in between broken for this configuration, which
is why I brought up bisection. Or did you mean something else?
> > Sorry about the trouble. I don't have a git tree on kernel.org because
> > we don't really use git in -mm, but the downside is that we don't get
> > the benefits of the automatic build testing for all kinds of configs.
> > I'll try to set up a git tree to expose series to full build coverage
> > before they hit -mm and -next.
>
> This sort of thing happens quite rarely.
True, this is a particularly tedious one. The only reason I brought it
up is because I use git to prepare patches anyway, and pushing patches
into a branch reachable by Fengguang's rig before I send emails might
have caught this stuff without spamming so many inboxes ;)
Anyway, if we can live with the bisection caveat then Arnd's fixes on
top of the kmem series look good to me. Depending on what Vladimir
thinks we might want to replace the CONFIG_SLOB fix with something
else later on, but that shouldn't be a problem, either.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3] net: Add fib rules at vrf device create
On 12/9/15 3:22 PM, David Miller wrote: Just write a script already... Why do you think this took so long to bubble up? I wrote a script back in July -- well before VRF was accepted into your tree -- that I use for testing. This request comes from other users starting to work with VRFs. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] ip_tunnel: Move stats update to iptunnel_xmit()
On Tue, Dec 8, 2015 at 7:41 PM, David Miller wrote: > From: Pravin B Shelar > Date: Tue, 8 Dec 2015 19:22:34 -0800 > >> By moving stats update into iptunnel_xmit(), we can simplify >> iptunnel_xmit() usage. With this change there is no need to >> call another function (iptunnel_xmit_stats()) to update stats >> in tunnel xmit code path. >> >> Signed-off-by: Pravin B Shelar > > You're going to have to respin this relative to the fix I just > put into 'net'. ok, I will wait for the net -> net-next merge. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checksum offload queries
On Wed, Dec 9, 2015 at 2:29 PM, Thomas Graf wrote: > On 12/09/15 at 08:08am, Tom Herbert wrote: >> On Tue, Dec 8, 2015 at 5:56 PM, Thomas Graf wrote: >> > If I understood Edward correctly, his proposal would be for the >> > card to provide both, the csum as for CHECKSUM_COMPLETE plus the >> > validation yes/no hint. It would be up to the kernel to decide >> > whether to validate itself or trust the card. >> > >> > I'm all in favour CHECKSUM_COMPLETE as the only way to go but >> > we should be aware that it depends on the penetration of RCO in >> > hardware VTEPs. >> >> Thomas, I don't understand what you are saying here. CHECKSUM_COMPLETE >> is an interface for drivers providing the computed checksum of a >> packet on receive, how is this dependent on any use case or any other >> mechanisms? > > I'm referring to the overall change which comes with a pure > CHECSUM_COMPLETE model which would forbid a NIC to do automatic nested > checksum filling even if untold. RCO solves that to some extent but > only if RCO is widely supported. I'm not aware of anybody relying on > the performance of such hardware yet so I doubt we would create a > performance regression. > I'm sorry, I still don't understand your point. What is "automatic nested checksum filling" and how does this relate to RX (e.g. CHECSUM_COMPLETE). -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net 1/2] openvswitch: Fix helper reference leak
On Wed, Dec 9, 2015 at 2:07 PM, Joe Stringer wrote:
> If the actions (re)allocation fails, or the actions list is larger than the
> maximum size, and the conntrack action is the last action when these
> problems are hit, then references to helper modules may be leaked. Fix
> the issue.
>
> Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
> Signed-off-by: Joe Stringer
> ---
> net/openvswitch/conntrack.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
> index c2cc11168fd5..585a5aa81f89 100644
> --- a/net/openvswitch/conntrack.c
> +++ b/net/openvswitch/conntrack.c
> @@ -53,6 +53,8 @@ struct ovs_conntrack_info {
> struct md_labels labels;
> };
>
> +static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info);
> +
> static u16 key_to_nfproto(const struct sw_flow_key *key)
> {
> switch (ntohs(key->eth.type)) {
> @@ -708,7 +710,7 @@ int ovs_ct_copy_action(struct net *net, const struct
> nlattr *attr,
> nf_conntrack_get(&ct_info.ct->ct_general);
I see another issue here. Updates to ct_info are done after it is
copied to action list. ct action on the action list and ct_info are
inconsistent, So it is still leaking nf-conntrack reference.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checksum offload queries
On 12/09/15 at 02:42pm, Tom Herbert wrote: > csum_start and csum_offset together occupy 32 bits. As demonstrated in > VXLAN RCO we can compress csum_start/csum_offset down to 8 bits which > means if necessary we could get up to four pairs in an sk_buff without > increasing its size. If you need more that four checksums to be > offloaded in single packet then I doubt getting checksum offload to > work is going to be your biggest problem. Fair point. I wouldn't suggest even creating it without huge demand first. There should be as many incentives as possible to move or stay away from such horrible architectures. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] r8169: Don't claim WoL works if LanWake flag is not set
Corinna Vinschen : [...] > This patch is supposed to fix this behaviour. If LanWake is 0, the > function now returns 0. Thus ethtool correctly reports "Wake-on: d". Can you turn it into a DMI controlled one (something like drivers/net/ethernet/marvell/skge.c use of dmi_check_system) in order to avoid a global change of behavior ? Btw it's probably time to emit some warning during driver probe if wol bits are not consistent with LanWake. -- Ueimor -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checksum offload queries
On Wed, Dec 9, 2015 at 2:21 PM, Thomas Graf wrote: > On 12/09/15 at 10:00am, Tom Herbert wrote: >> On Wed, Dec 9, 2015 at 9:28 AM, Edward Cree wrote: >> > Which only pushes the problem onto when someone wants to nest >> > encapsulations. (I heard you like tunnels, so I put a tunnel in your >> > tunnel so you can encapsulate while you encapsulate.) >> > Or to put it another way, 2 isn't a number; the only numbers are 0, 1 >> > and infinity ;) >> > Perhaps in practice 2 csums would be enough, for now. But isn't the >> > whole point of the brave new world of generic checksums that it should >> > be future-proof? >> > >> If there is a need then we can add an arbitrary number. But no one has >> proven there is a need, however we do have a real need for checksum >> offload outside of the narrow uses of NETIF_F_IP[V6]_CSUM. > > Need may be a strong word here but people have started doing nested > tunneling by running container orchestration tools which use VXLAN > to isolate containers inside of OpenStack virtual infrastructure which > also creates virtual networks. > > I'm not saying it's sane or desirable but we will start seeing nested > tunnels in the wild :-( csum_start and csum_offset together occupy 32 bits. As demonstrated in VXLAN RCO we can compress csum_start/csum_offset down to 8 bits which means if necessary we could get up to four pairs in an sk_buff without increasing its size. If you need more that four checksums to be offloaded in single packet then I doubt getting checksum offload to work is going to be your biggest problem. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: memcontrol: only manage socket pressure for CONFIG_INET
On Wed, 9 Dec 2015 13:58:58 -0500 Johannes Weiner wrote: > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 6faea81e66d7..73cd572167bb 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -4220,13 +4220,13 @@ mem_cgroup_css_online(struct cgroup_subsys_state > > *css) > > if (ret) > > return ret; > > > > +#ifdef CONFIG_INET > > #ifdef CONFIG_MEMCG_LEGACY_KMEM > > ret = tcp_init_cgroup(memcg); > > if (ret) > > return ret; > > #endif > > The calls to tcp_init_cgroup() appear earlier in the series than "mm: > memcontrol: hook up vmpressure to socket pressure". However, they get > moved around a few times so fixing it earlier means respinning the > series. Andrew, it's up to you whether we take the bisectability hit > for !CONFIG_INET && CONFIG_MEMCG (how common is this?) or whether you > want me to resend the series. hm, drat, I was suspecting dependency issues here, but a test build said it was OK. Actually, I was expecting this patch series to depend on the linux-next cgroup2 changes, but that doesn't appear to be the case. *should* this series be staged after the cgroup2 code? Regarding this particular series: yes, I think we can live with a bisection hole for !CONFIG_INET && CONFIG_MEMCG users. But I'm not sure why we're discussing bisection issues, because Arnd's build failure occurs with everything applied? > Sorry about the trouble. I don't have a git tree on kernel.org because > we don't really use git in -mm, but the downside is that we don't get > the benefits of the automatic build testing for all kinds of configs. > I'll try to set up a git tree to expose series to full build coverage > before they hit -mm and -next. This sort of thing happens quite rarely. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checksum offload queries
On 12/09/15 at 08:08am, Tom Herbert wrote: > On Tue, Dec 8, 2015 at 5:56 PM, Thomas Graf wrote: > > If I understood Edward correctly, his proposal would be for the > > card to provide both, the csum as for CHECKSUM_COMPLETE plus the > > validation yes/no hint. It would be up to the kernel to decide > > whether to validate itself or trust the card. > > > > I'm all in favour CHECKSUM_COMPLETE as the only way to go but > > we should be aware that it depends on the penetration of RCO in > > hardware VTEPs. > > Thomas, I don't understand what you are saying here. CHECKSUM_COMPLETE > is an interface for drivers providing the computed checksum of a > packet on receive, how is this dependent on any use case or any other > mechanisms? I'm referring to the overall change which comes with a pure CHECSUM_COMPLETE model which would forbid a NIC to do automatic nested checksum filling even if untold. RCO solves that to some extent but only if RCO is widely supported. I'm not aware of anybody relying on the performance of such hardware yet so I doubt we would create a performance regression. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
On 12/09/15 at 05:21pm, David Miller wrote: > It is clearly the most appropriate middle layer representation. > > The fact that BPF could be generated from any P4 program, yet the > reverse is not true, tells me everything I need to know. > > I'm sorry if you have either a mental or a time invenstment in P4, but > I really don't see it as really suitable for this. I don't. I like the approach and the effect it has on a currently very vendor secrets oriented environment. I won't drag this further. I'm perfectly fine if BPF is suitable for a wide range of hardware models. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bpf/asan related lockup
On 12/04/2015 08:06 PM, Alexei Starovoitov wrote: On Fri, Dec 04, 2015 at 01:23:33PM -0500, Dave Jones wrote: Trinity had aparently created a bpf program that upset things greatly. I guess I need to find a way to make it record those somewhere for replaying later. Alexei, any ideas ? Dave NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:1:991] irq event stamp: 153214 hardirqs last enabled at (153213): [] _raw_spin_unlock_irq+0x2c/0x50 hardirqs last disabled at (153214): [] _raw_spin_lock_irq+0x19/0x80 softirqs last enabled at (153108): [] __do_softirq+0x2b8/0x590 softirqs last disabled at (153103): [] irq_exit+0xf5/0x100 CPU: 0 PID: 991 Comm: kworker/0:1 Tainted: G D W 4.4.0-rc3-think+ #5 Workqueue: events bpf_prog_free_deferred task: 880464dab700 ti: 8803041d8000 task.ti: 8803041d8000 RIP: 0010:[] [] __asan_load4+0x0/0x70 RSP: 0018:8803041dfa08 EFLAGS: 0202 RAX: 0003 RBX: 880468be39a8 RCX: RDX: dc00 RSI: 0001 RDI: 880468be39c0 RBP: 8803041dfa70 R08: R09: 0001 R10: 8803041dfb8f R11: R12: 880468be39c0 R13: 0001 R14: 8804689dff00 R15: 0001 FS: () GS:88046880() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7faeedb04000 CR3: 000452548000 CR4: 001406f0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0600 Stack: a018f2ce 001dfec0 01ff88030001 8803041dfaf8 a0076610 a18895d8 8804689dff08 0004 a0076610 8803041dfaf8 0001 c9171000 Call Trace: [] ? smp_call_function_many+0x32e/0x410 [] ? rbt_memtype_copy_nth_element+0xd0/0xd0 [] ? rbt_memtype_copy_nth_element+0xd0/0xd0 [] smp_call_function+0x47/0x80 [] ? rbt_memtype_copy_nth_element+0xd0/0xd0 [] on_each_cpu+0x2f/0x90 [] flush_tlb_kernel_range+0xc0/0xd0 [] ? flush_tlb_all+0x20/0x20 [] remove_vm_area+0xaf/0x100 [] __vunmap+0x36/0x180 [] vfree+0x35/0xa0 [] __bpf_prog_free+0x27/0x30 [] bpf_jit_free+0x69/0x6e [] bpf_prog_free_deferred+0x1f/0x30 [] process_one_work+0x3fa/0xa10 [] ? process_one_work+0x334/0xa10 [] ? pwq_dec_nr_in_flight+0x110/0x110 [] worker_thread+0x88/0x6c0 hmm. may be set_memory_rw(ptr) followed by vfree(ptr) have a race deep inside mm logic. Both of them do flush_tlb_kernel_range()... Hmm, was the rbt_memtype_copy_nth_element() by chance unrelated when this happens or are we somehow stuck there each time? Only place where that can be invoked is memtype_get_idx() when a cat /sys/kernel/debug/x86/pat_memtype_list is done. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3] net: Add fib rules at vrf device create
From: David Ahern Date: Wed, 9 Dec 2015 15:05:06 -0700 > On 12/9/15 1:13 PM, David Miller wrote: >> The new attributes make things more complex, because ever _VALID_ tool >> much accomodate the existing situation and be able to perform all of >> the commands above if they are executed on an older kernel. >> >> So the new attributes make things worse, not better. > > Dave, how does this make it more complex - beyond the complexity of > giving a user choices? You keep creating situations where the user has to do the whole thing anyways, to accomodate older kernels that don't have the new attributes. That's complexity. Just write a script already... -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Checksum offload queries
On 12/09/15 at 10:00am, Tom Herbert wrote: > On Wed, Dec 9, 2015 at 9:28 AM, Edward Cree wrote: > > Which only pushes the problem onto when someone wants to nest > > encapsulations. (I heard you like tunnels, so I put a tunnel in your > > tunnel so you can encapsulate while you encapsulate.) > > Or to put it another way, 2 isn't a number; the only numbers are 0, 1 > > and infinity ;) > > Perhaps in practice 2 csums would be enough, for now. But isn't the > > whole point of the brave new world of generic checksums that it should > > be future-proof? > > > If there is a need then we can add an arbitrary number. But no one has > proven there is a need, however we do have a real need for checksum > offload outside of the narrow uses of NETIF_F_IP[V6]_CSUM. Need may be a strong word here but people have started doing nested tunneling by running container orchestration tools which use VXLAN to isolate containers inside of OpenStack virtual infrastructure which also creates virtual networks. I'm not saying it's sane or desirable but we will start seeing nested tunnels in the wild :-( -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
From: Thomas Graf Date: Wed, 9 Dec 2015 23:03:39 +0100 > On 12/09/15 at 09:38am, Alexei Starovoitov wrote: >> On Wed, Dec 09, 2015 at 01:58:57PM +0100, Thomas Graf wrote: >> > >> > So if the goal is to make the intent available to the hardware in >> > a format which both the kernel and the hardware can draw the same >> > conclusions from, wouldn't something like P4 + BPF derived from P4 >> > be a possibly better fit? There is discussion on stateful P4 >> > processing now. >> >> p4 is a high level language and absolutely not suitable for such purpose. >> bpf as intermediate representation can be generated from p4 or C or other >> language. There is room to innovate in the language definition on top >> and in HW design at the bottom. That's the most flexible model. > > If you don't want to discuss it, no problem. But stating that P4 > is a high level language (not sure what this means exactly since > we exactly _want_ an abstraction away from hardware) and that it's > not suitable for this purpose is just wrong. P4 has been created > exactly for the purpose of expressing how a packet should be > processed by a forwarding element independent of specific hardware. Just because it was supposeduly designed for this purpose, doesn't mean it's the most appropriate intermediate language between what the kernel wants hardware to do and what actually has to happen for the hardware to do that. BPF is so much more universal and can cover everything we'd want hardware to perform, and then some. Plus it's everywhere in the kernel already, has a full validation and test suite, full LLVM backend, plus JITs for several prominent architectures with more on the way. It is clearly the most appropriate middle layer representation. The fact that BPF could be generated from any P4 program, yet the reverse is not true, tells me everything I need to know. I'm sorry if you have either a mental or a time invenstment in P4, but I really don't see it as really suitable for this. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 1/2] openvswitch: Fix helper reference leak
If the actions (re)allocation fails, or the actions list is larger than the
maximum size, and the conntrack action is the last action when these
problems are hit, then references to helper modules may be leaked. Fix
the issue.
Fixes: cae3a2627520 ("openvswitch: Allow attaching helpers to ct action")
Signed-off-by: Joe Stringer
---
net/openvswitch/conntrack.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index c2cc11168fd5..585a5aa81f89 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -53,6 +53,8 @@ struct ovs_conntrack_info {
struct md_labels labels;
};
+static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info);
+
static u16 key_to_nfproto(const struct sw_flow_key *key)
{
switch (ntohs(key->eth.type)) {
@@ -708,7 +710,7 @@ int ovs_ct_copy_action(struct net *net, const struct nlattr
*attr,
nf_conntrack_get(&ct_info.ct->ct_general);
return 0;
err_free_ct:
- nf_conntrack_free(ct_info.ct);
+ __ovs_ct_free_action(&ct_info);
return err;
}
@@ -750,6 +752,11 @@ void ovs_ct_free_action(const struct nlattr *a)
{
struct ovs_conntrack_info *ct_info = nla_data(a);
+ __ovs_ct_free_action(ct_info);
+}
+
+static void __ovs_ct_free_action(struct ovs_conntrack_info *ct_info)
+{
if (ct_info->helper)
module_put(ct_info->helper->me);
if (ct_info->ct)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 2/2] openvswitch: Respect conntrack zone even if invalid
If userspace executes ct(zone=1), and the connection tracker determines
that the packet is invalid, then the ct_zone flow key field is populated
with the default zone rather than the zone that was specified. Even
though connection tracking failed, this field should be updated with the
value that the action specified. Fix the issue.
Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
Signed-off-by: Joe Stringer
---
net/openvswitch/conntrack.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/net/openvswitch/conntrack.c b/net/openvswitch/conntrack.c
index 585a5aa81f89..3e8892216f94 100644
--- a/net/openvswitch/conntrack.c
+++ b/net/openvswitch/conntrack.c
@@ -143,6 +143,7 @@ static void __ovs_ct_update_key(struct sw_flow_key *key, u8
state,
* previously sent the packet to conntrack via the ct action.
*/
static void ovs_ct_update_key(const struct sk_buff *skb,
+ const struct ovs_conntrack_info *info,
struct sw_flow_key *key, bool post_ct)
{
const struct nf_conntrack_zone *zone = &nf_ct_zone_dflt;
@@ -160,13 +161,15 @@ static void ovs_ct_update_key(const struct sk_buff *skb,
zone = nf_ct_zone(ct);
} else if (post_ct) {
state = OVS_CS_F_TRACKED | OVS_CS_F_INVALID;
+ if (info)
+ zone = &info->zone;
}
__ovs_ct_update_key(key, state, zone, ct);
}
void ovs_ct_fill_key(const struct sk_buff *skb, struct sw_flow_key *key)
{
- ovs_ct_update_key(skb, key, false);
+ ovs_ct_update_key(skb, NULL, key, false);
}
int ovs_ct_put_key(const struct sw_flow_key *key, struct sk_buff *skb)
@@ -420,7 +423,7 @@ static int __ovs_ct_lookup(struct net *net, struct
sw_flow_key *key,
}
}
- ovs_ct_update_key(skb, key, true);
+ ovs_ct_update_key(skb, info, key, true);
return 0;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3] net: Add fib rules at vrf device create
On 12/9/15 1:13 PM, David Miller wrote: The new attributes make things more complex, because ever _VALID_ tool much accomodate the existing situation and be able to perform all of the commands above if they are executed on an older kernel. So the new attributes make things worse, not better. Dave, how does this make it more complex - beyond the complexity of giving a user choices? If a user wants to install rules directly go for it. That path works fine. That covers whatever user base has popped up over the last 38 days for the IPv4 support in v4.3 and who ever starts on v4.4 with IPv6 support. With this change if a user wants the driver to take care of the details it can -- by the user asking for the driver to deal with the details. The 2 options peacefully co-exist. I will ignore all further attempts to find schemes automate the rule and route additions, because it is simply the wrong way forward. You want to say I failed by not including this in the first patch set - fine blame accepted. The initial patches focused on core infrastructure to enable VRF support in Linux -- a subject which has proved tough enough over the past 15 years. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
On 12/09/15 at 09:38am, Alexei Starovoitov wrote: > On Wed, Dec 09, 2015 at 01:58:57PM +0100, Thomas Graf wrote: > > > > So if the goal is to make the intent available to the hardware in > > a format which both the kernel and the hardware can draw the same > > conclusions from, wouldn't something like P4 + BPF derived from P4 > > be a possibly better fit? There is discussion on stateful P4 > > processing now. > > p4 is a high level language and absolutely not suitable for such purpose. > bpf as intermediate representation can be generated from p4 or C or other > language. There is room to innovate in the language definition on top > and in HW design at the bottom. That's the most flexible model. If you don't want to discuss it, no problem. But stating that P4 is a high level language (not sure what this means exactly since we exactly _want_ an abstraction away from hardware) and that it's not suitable for this purpose is just wrong. P4 has been created exactly for the purpose of expressing how a packet should be processed by a forwarding element independent of specific hardware. There is a lot of interesting open source work coming out of that space and I think we owe it to at least consider P4. The goal is very much in line with what we want to achieve as Linux community as well. I'll wait for your proposal as you stated you are working on something specific. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 net] phy: micrel: Fix finding PHY properties in MAC node.
> >-if (!of_node && dev->parent->of_node)
> >-of_node = dev->parent->of_node;
> >+/* The Micrel driver has a deprecated option to place phy OF
> >+ * properties in the MAC node. Walk up the tree of devices to
> >+ * find a device with an OF node.
> >+ */
> >+dev_walker = &phydev->dev;
> >+do {
> >+of_node = dev_walker->of_node;
> >+dev_walker = dev_walker->parent;
> >+
> >+} while (!of_node && dev_walker);
>
> Looks good to me, can we also issuing à warning so people get a chance to
> update their Device Tree?
I did wounder about that.
But i think it might be better to wait until there are updated dts
files. No point telling users they need to update when there are no
updated DT files to use.
If Dinh updates the SoCFPGA .dts files then i think it makes sense to
add the warning.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] I.MX6: Fix Ethernet PHY mode on Ventana boards
On Tue, Dec 8, 2015 at 9:50 PM, Krzysztof Hałasa wrote: > David Miller writes: > >> Since this only touched DT files in the ARM platform code, maybe >> the ARM tree is the best path for this patch rather than mine? > > I think so. > > Tim, would you like to handle this patch yourself, or should I send it > to the ARM contacts? Krzysztof, Go ahead and send it. You can add my: Acked-by: Tim Harvey I know Shawn would be happy to pick this up as well as he has an imx-fixes tree: http://git.kernel.org/cgit/linux/kernel/git/shawnguo/linux.git/log/?h=imx/soc Tim -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 08/10] 6lowpan: add lowpan dev register helpers
This patch introduces register and unregister functionality for lowpan
interfaces. While register a lowpan interface there are several things
which need to be initialize by the 6lowpan subsystem. Upcoming
functionality need to register/unregister per interface components e.g.
debugfs entry.
Reviewed-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
include/net/6lowpan.h | 7 ++-
net/6lowpan/core.c| 33 +++--
net/bluetooth/6lowpan.c | 8 +++-
net/ieee802154/6lowpan/core.c | 6 ++
4 files changed, 42 insertions(+), 12 deletions(-)
diff --git a/include/net/6lowpan.h b/include/net/6lowpan.h
index cf3bc56..730211f 100644
--- a/include/net/6lowpan.h
+++ b/include/net/6lowpan.h
@@ -185,7 +185,12 @@ static inline void lowpan_push_hc_data(u8 **hc_ptr, const
void *data,
*hc_ptr += len;
}
-void lowpan_netdev_setup(struct net_device *dev, enum lowpan_lltypes lltype);
+int lowpan_register_netdevice(struct net_device *dev,
+ enum lowpan_lltypes lltype);
+int lowpan_register_netdev(struct net_device *dev,
+ enum lowpan_lltypes lltype);
+void lowpan_unregister_netdevice(struct net_device *dev);
+void lowpan_unregister_netdev(struct net_device *dev);
/**
* lowpan_header_decompress - replace 6LoWPAN header with IPv6 header
diff --git a/net/6lowpan/core.c b/net/6lowpan/core.c
index 83b19e0..80fc509 100644
--- a/net/6lowpan/core.c
+++ b/net/6lowpan/core.c
@@ -15,7 +15,8 @@
#include
-void lowpan_netdev_setup(struct net_device *dev, enum lowpan_lltypes lltype)
+int lowpan_register_netdevice(struct net_device *dev,
+ enum lowpan_lltypes lltype)
{
dev->addr_len = EUI64_ADDR_LEN;
dev->type = ARPHRD_6LOWPAN;
@@ -23,8 +24,36 @@ void lowpan_netdev_setup(struct net_device *dev, enum
lowpan_lltypes lltype)
dev->priv_flags |= IFF_NO_QUEUE;
lowpan_priv(dev)->lltype = lltype;
+
+ return register_netdevice(dev);
+}
+EXPORT_SYMBOL(lowpan_register_netdevice);
+
+int lowpan_register_netdev(struct net_device *dev,
+ enum lowpan_lltypes lltype)
+{
+ int ret;
+
+ rtnl_lock();
+ ret = lowpan_register_netdevice(dev, lltype);
+ rtnl_unlock();
+ return ret;
+}
+EXPORT_SYMBOL(lowpan_register_netdev);
+
+void lowpan_unregister_netdevice(struct net_device *dev)
+{
+ unregister_netdevice(dev);
+}
+EXPORT_SYMBOL(lowpan_unregister_netdevice);
+
+void lowpan_unregister_netdev(struct net_device *dev)
+{
+ rtnl_lock();
+ lowpan_unregister_netdevice(dev);
+ rtnl_unlock();
}
-EXPORT_SYMBOL(lowpan_netdev_setup);
+EXPORT_SYMBOL(lowpan_unregister_netdev);
static int __init lowpan_module_init(void)
{
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 9e9cca3..d040365 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -825,9 +825,7 @@ static int setup_netdev(struct l2cap_chan *chan, struct
lowpan_dev **dev)
list_add_rcu(&(*dev)->list, &bt_6lowpan_devices);
spin_unlock(&devices_lock);
- lowpan_netdev_setup(netdev, LOWPAN_LLTYPE_BTLE);
-
- err = register_netdev(netdev);
+ err = lowpan_register_netdev(netdev, LOWPAN_LLTYPE_BTLE);
if (err < 0) {
BT_INFO("register_netdev failed %d", err);
spin_lock(&devices_lock);
@@ -890,7 +888,7 @@ static void delete_netdev(struct work_struct *work)
struct lowpan_dev *entry = container_of(work, struct lowpan_dev,
delete_netdev);
- unregister_netdev(entry->netdev);
+ lowpan_unregister_netdev(entry->netdev);
/* The entry pointer is deleted by the netdev destructor. */
}
@@ -1348,7 +1346,7 @@ static void disconnect_devices(void)
ifdown(entry->netdev);
BT_DBG("Unregistering netdev %s %p",
entry->netdev->name, entry->netdev);
- unregister_netdev(entry->netdev);
+ lowpan_unregister_netdev(entry->netdev);
kfree(entry);
}
}
diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c
index 20c49c7..737c87a 100644
--- a/net/ieee802154/6lowpan/core.c
+++ b/net/ieee802154/6lowpan/core.c
@@ -161,9 +161,7 @@ static int lowpan_newlink(struct net *src_net, struct
net_device *ldev,
wdev->needed_headroom;
ldev->needed_tailroom = wdev->needed_tailroom;
- lowpan_netdev_setup(ldev, LOWPAN_LLTYPE_IEEE802154);
-
- ret = register_netdevice(ldev);
+ ret = lowpan_register_netdevice(ldev, LOWPAN_LLTYPE_IEEE802154);
if (ret < 0) {
dev_put(wdev);
return ret;
@@ -180,7 +178,7 @@ static void lowpan_dellink(struct net_device *ldev, struct
list_head *head)
ASSERT_RTNL();
wdev->ieee802154_ptr->lowpan_dev = NULL;
- unregister_netde
[PATCH bluetooth-next 06/10] 6lowpan: add nhc module for GHC fragmentation extension header detection
From: Stefan Schmidt
Acked-by: Jukka Rissanen
Signed-off-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
net/6lowpan/Kconfig| 6 ++
net/6lowpan/Makefile | 1 +
net/6lowpan/nhc_ghc_ext_frag.c | 28
3 files changed, 35 insertions(+)
create mode 100644 net/6lowpan/nhc_ghc_ext_frag.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index e5184e6..13abcc5 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -81,4 +81,10 @@ config 6LOWPAN_GHC_EXT_HDR_DEST
6LoWPAN IPv6 destination option generic header compression according
to RFC7400.
+config 6LOWPAN_GHC_EXT_HDR_FRAG
+ tristate "GHC Fragmentation Options Header Support"
+ ---help---
+ 6LoWPAN IPv6 fragmentation option generic header compression
+ according to RFC7400.
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index fc4bac0..fb3f48d 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -16,3 +16,4 @@ obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_HOP) += nhc_ghc_ext_hop.o
obj-$(CONFIG_6LOWPAN_GHC_UDP) += nhc_ghc_udp.o
obj-$(CONFIG_6LOWPAN_GHC_ICMPV6) += nhc_ghc_icmpv6.o
obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_DEST) += nhc_ghc_ext_dest.o
+obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_FRAG) += nhc_ghc_ext_frag.o
diff --git a/net/6lowpan/nhc_ghc_ext_frag.c b/net/6lowpan/nhc_ghc_ext_frag.c
new file mode 100644
index 000..1308b79
--- /dev/null
+++ b/net/6lowpan/nhc_ghc_ext_frag.c
@@ -0,0 +1,28 @@
+/*
+ * 6LoWPAN Extension Header compression according to RFC7400
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_EXT_FRAG_IDLEN 1
+#define LOWPAN_GHC_EXT_FRAG_ID_0 0xb4
+#define LOWPAN_GHC_EXT_FRAG_MASK_0 0xfe
+
+static void frag_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_EXT_FRAG_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_EXT_FRAG_MASK_0;
+}
+
+LOWPAN_NHC(ghc_ext_frag, "RFC7400 Fragmentation Extension Header",
+ NEXTHDR_FRAGMENT, 0, frag_ghid_setup,
+ LOWPAN_GHC_EXT_FRAG_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_ext_frag);
+MODULE_DESCRIPTION("6LoWPAN generic header fragmentation extension
compression");
+MODULE_LICENSE("GPL");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 04/10] 6lowpan: add nhc module for GHC ICMPv6 detection
From: Stefan Schmidt
Acked-by: Jukka Rissanen
Signed-off-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
net/6lowpan/Kconfig | 5 +
net/6lowpan/Makefile | 1 +
net/6lowpan/nhc_ghc_icmpv6.c | 27 +++
3 files changed, 33 insertions(+)
create mode 100644 net/6lowpan/nhc_ghc_icmpv6.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 94d5178..0a3f5a8 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -70,4 +70,9 @@ config 6LOWPAN_GHC_UDP
---help---
6LoWPAN IPv6 UDP generic header compression according to RFC7400.
+config 6LOWPAN_GHC_ICMPV6
+ tristate "GHC ICMPv6 Support"
+ ---help---
+ 6LoWPAN IPv6 ICMPv6 generic header compression according to RFC7400.
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index 5e4f2f3..86af3fd 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -14,3 +14,4 @@ obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
#rfc7400 ghcs
obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_HOP) += nhc_ghc_ext_hop.o
obj-$(CONFIG_6LOWPAN_GHC_UDP) += nhc_ghc_udp.o
+obj-$(CONFIG_6LOWPAN_GHC_ICMPV6) += nhc_ghc_icmpv6.o
diff --git a/net/6lowpan/nhc_ghc_icmpv6.c b/net/6lowpan/nhc_ghc_icmpv6.c
new file mode 100644
index 000..32e7c2c
--- /dev/null
+++ b/net/6lowpan/nhc_ghc_icmpv6.c
@@ -0,0 +1,27 @@
+/*
+ * 6LoWPAN ICMPv6 compression according to RFC7400
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_ICMPV6_IDLEN1
+#define LOWPAN_GHC_ICMPV6_ID_0 0xdf
+#define LOWPAN_GHC_ICMPV6_MASK_0 0xff
+
+static void icmpv6_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_ICMPV6_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_ICMPV6_MASK_0;
+}
+
+LOWPAN_NHC(ghc_icmpv6, "RFC7400 ICMPv6", NEXTHDR_ICMP, 0,
+ icmpv6_ghid_setup, LOWPAN_GHC_ICMPV6_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_icmpv6);
+MODULE_DESCRIPTION("6LoWPAN generic header ICMPv6 compression");
+MODULE_LICENSE("GPL");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 07/10] 6lowpan: add nhc module for GHC routing extension header detection
From: Stefan Schmidt
Acked-by: Jukka Rissanen
Signed-off-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
net/6lowpan/Kconfig | 6 ++
net/6lowpan/Makefile| 1 +
net/6lowpan/nhc_ghc_ext_route.c | 27 +++
3 files changed, 34 insertions(+)
create mode 100644 net/6lowpan/nhc_ghc_ext_route.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 13abcc5..bcb9d8a 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -87,4 +87,10 @@ config 6LOWPAN_GHC_EXT_HDR_FRAG
6LoWPAN IPv6 fragmentation option generic header compression
according to RFC7400.
+config 6LOWPAN_GHC_EXT_HDR_ROUTE
+ tristate "GHC Routing Options Header Support"
+ ---help---
+ 6LoWPAN IPv6 routing option generic header compression according
+ to RFC7400.
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index fb3f48d..9e35a5d 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_6LOWPAN_GHC_UDP) += nhc_ghc_udp.o
obj-$(CONFIG_6LOWPAN_GHC_ICMPV6) += nhc_ghc_icmpv6.o
obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_DEST) += nhc_ghc_ext_dest.o
obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_FRAG) += nhc_ghc_ext_frag.o
+obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_ROUTE) += nhc_ghc_ext_route.o
diff --git a/net/6lowpan/nhc_ghc_ext_route.c b/net/6lowpan/nhc_ghc_ext_route.c
new file mode 100644
index 000..d7e5bd7
--- /dev/null
+++ b/net/6lowpan/nhc_ghc_ext_route.c
@@ -0,0 +1,27 @@
+/*
+ * 6LoWPAN Extension Header compression according to RFC7400
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_EXT_ROUTE_IDLEN 1
+#define LOWPAN_GHC_EXT_ROUTE_ID_0 0xb2
+#define LOWPAN_GHC_EXT_ROUTE_MASK_00xfe
+
+static void route_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_EXT_ROUTE_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_EXT_ROUTE_MASK_0;
+}
+
+LOWPAN_NHC(ghc_ext_route, "RFC7400 Routing Extension Header", NEXTHDR_ROUTING,
+ 0, route_ghid_setup, LOWPAN_GHC_EXT_ROUTE_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_ext_route);
+MODULE_DESCRIPTION("6LoWPAN generic header routing extension compression");
+MODULE_LICENSE("GPL");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 02/10] 6lowpan: add nhc module for GHC hop-by-hopextension header detection
From: Stefan Schmidt
Acked-by: Jukka Rissanen
Signed-off-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
net/6lowpan/Kconfig | 6 ++
net/6lowpan/Makefile | 3 +++
net/6lowpan/nhc_ghc_ext_hop.c | 27 +++
3 files changed, 36 insertions(+)
create mode 100644 net/6lowpan/nhc_ghc_ext_hop.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 6af7a46..1bd49eb 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -59,4 +59,10 @@ config 6LOWPAN_NHC_UDP
---help---
6LoWPAN IPv6 UDP Header compression according to RFC6282.
+config 6LOWPAN_GHC_EXT_HDR_HOP
+ tristate "GHC Hop-by-Hop Options Header Support"
+ ---help---
+ 6LoWPAN IPv6 Hop-by-Hop option generic header compression according
+ to RFC7400.
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index c6ffc55..ba20e01 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -10,3 +10,6 @@ obj-$(CONFIG_6LOWPAN_NHC_IPV6) += nhc_ipv6.o
obj-$(CONFIG_6LOWPAN_NHC_MOBILITY) += nhc_mobility.o
obj-$(CONFIG_6LOWPAN_NHC_ROUTING) += nhc_routing.o
obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
+
+#rfc7400 ghcs
+obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_HOP) += nhc_ghc_ext_hop.o
diff --git a/net/6lowpan/nhc_ghc_ext_hop.c b/net/6lowpan/nhc_ghc_ext_hop.c
new file mode 100644
index 000..baec86f
--- /dev/null
+++ b/net/6lowpan/nhc_ghc_ext_hop.c
@@ -0,0 +1,27 @@
+/*
+ * 6LoWPAN Extension Header compression according to RFC7400
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_EXT_HOP_IDLEN 1
+#define LOWPAN_GHC_EXT_HOP_ID_00xb0
+#define LOWPAN_GHC_EXT_HOP_MASK_0 0xfe
+
+static void hop_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_EXT_HOP_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_EXT_HOP_MASK_0;
+}
+
+LOWPAN_NHC(ghc_ext_hop, "RFC7400 Hop-by-Hop Extension Header", NEXTHDR_HOP, 0,
+ hop_ghid_setup, LOWPAN_GHC_EXT_HOP_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_ext_hop);
+MODULE_DESCRIPTION("6LoWPAN generic header hop-by-hop extension compression");
+MODULE_LICENSE("GPL");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 09/10] 6lowpan: add debugfs support
This patch will introduce a 6lowpan entry into the debugfs if enabled.
Inside this 6lowpan directory we create a subdirectories of all 6lowpan
interfaces to offer a per interface debugfs support.
Reviewed-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
include/net/6lowpan.h | 3 +++
net/6lowpan/6lowpan_i.h | 28 ++
net/6lowpan/Kconfig | 8
net/6lowpan/Makefile| 1 +
net/6lowpan/core.c | 28 +-
net/6lowpan/debugfs.c | 53 +
6 files changed, 120 insertions(+), 1 deletion(-)
create mode 100644 net/6lowpan/6lowpan_i.h
create mode 100644 net/6lowpan/debugfs.c
diff --git a/include/net/6lowpan.h b/include/net/6lowpan.h
index 730211f..2f6a3f2 100644
--- a/include/net/6lowpan.h
+++ b/include/net/6lowpan.h
@@ -53,6 +53,8 @@
#ifndef __6LOWPAN_H__
#define __6LOWPAN_H__
+#include
+
#include
#include
@@ -98,6 +100,7 @@ enum lowpan_lltypes {
struct lowpan_priv {
enum lowpan_lltypes lltype;
+ struct dentry *iface_debugfs;
/* must be last */
u8 priv[0] __aligned(sizeof(void *));
diff --git a/net/6lowpan/6lowpan_i.h b/net/6lowpan/6lowpan_i.h
new file mode 100644
index 000..d16bb4b
--- /dev/null
+++ b/net/6lowpan/6lowpan_i.h
@@ -0,0 +1,28 @@
+#ifndef __6LOWPAN_I_H
+#define __6LOWPAN_I_H
+
+#include
+
+#ifdef CONFIG_6LOWPAN_DEBUGFS
+int lowpan_dev_debugfs_init(struct net_device *dev);
+void lowpan_dev_debugfs_exit(struct net_device *dev);
+
+int __init lowpan_debugfs_init(void);
+void lowpan_debugfs_exit(void);
+#else
+static inline int lowpan_dev_debugfs_init(struct net_device *dev)
+{
+ return 0;
+}
+
+static inline void lowpan_dev_debugfs_exit(struct net_device *dev) { }
+
+static inline int __init lowpan_debugfs_init(void)
+{
+ return 0;
+}
+
+static inline void lowpan_debugfs_exit(void) { }
+#endif /* CONFIG_6LOWPAN_DEBUGFS */
+
+#endif /* __6LOWPAN_I_H */
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index bcb9d8a..9c05151 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -5,6 +5,14 @@ menuconfig 6LOWPAN
This enables IPv6 over Low power Wireless Personal Area Network -
"6LoWPAN" which is supported by IEEE 802.15.4 or Bluetooth stacks.
+config 6LOWPAN_DEBUGFS
+ bool "6LoWPAN debugfs support"
+ depends on 6LOWPAN
+ depends on DEBUG_FS
+ ---help---
+ This enables 6LoWPAN debugfs support. For example to manipulate
+ IPHC context information at runtime.
+
menuconfig 6LOWPAN_NHC
tristate "Next Header and Generic Header Compression Support"
depends on 6LOWPAN
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index 9e35a5d..e44f3bf 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_6LOWPAN) += 6lowpan.o
6lowpan-y := core.o iphc.o nhc.o
+6lowpan-$(CONFIG_6LOWPAN_DEBUGFS) += debugfs.o
#rfc6282 nhcs
obj-$(CONFIG_6LOWPAN_NHC_DEST) += nhc_dest.o
diff --git a/net/6lowpan/core.c b/net/6lowpan/core.c
index 80fc509..c7f06f5 100644
--- a/net/6lowpan/core.c
+++ b/net/6lowpan/core.c
@@ -15,9 +15,13 @@
#include
+#include "6lowpan_i.h"
+
int lowpan_register_netdevice(struct net_device *dev,
enum lowpan_lltypes lltype)
{
+ int ret;
+
dev->addr_len = EUI64_ADDR_LEN;
dev->type = ARPHRD_6LOWPAN;
dev->mtu = IPV6_MIN_MTU;
@@ -25,7 +29,15 @@ int lowpan_register_netdevice(struct net_device *dev,
lowpan_priv(dev)->lltype = lltype;
- return register_netdevice(dev);
+ ret = lowpan_dev_debugfs_init(dev);
+ if (ret < 0)
+ return ret;
+
+ ret = register_netdevice(dev);
+ if (ret < 0)
+ lowpan_dev_debugfs_exit(dev);
+
+ return ret;
}
EXPORT_SYMBOL(lowpan_register_netdevice);
@@ -44,6 +56,7 @@ EXPORT_SYMBOL(lowpan_register_netdev);
void lowpan_unregister_netdevice(struct net_device *dev)
{
unregister_netdevice(dev);
+ lowpan_dev_debugfs_exit(dev);
}
EXPORT_SYMBOL(lowpan_unregister_netdevice);
@@ -57,6 +70,12 @@ EXPORT_SYMBOL(lowpan_unregister_netdev);
static int __init lowpan_module_init(void)
{
+ int ret;
+
+ ret = lowpan_debugfs_init();
+ if (ret < 0)
+ return ret;
+
request_module_nowait("ipv6");
request_module_nowait("nhc_dest");
@@ -69,6 +88,13 @@ static int __init lowpan_module_init(void)
return 0;
}
+
+static void __exit lowpan_module_exit(void)
+{
+ lowpan_debugfs_exit();
+}
+
module_init(lowpan_module_init);
+module_exit(lowpan_module_exit);
MODULE_LICENSE("GPL");
diff --git a/net/6lowpan/debugfs.c b/net/6lowpan/debugfs.c
new file mode 100644
index 000..88eef84
--- /dev/null
+++ b/net/6lowpan/debugfs.c
@@ -0,0 +1,53 @@
+/* This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
+
[PATCH bluetooth-next 03/10] 6lowpan: add nhc module for GHC UDP detection
From: Stefan Schmidt
Acked-by: Jukka Rissanen
Signed-off-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
net/6lowpan/Kconfig | 5 +
net/6lowpan/Makefile | 1 +
net/6lowpan/nhc_ghc_udp.c | 27 +++
3 files changed, 33 insertions(+)
create mode 100644 net/6lowpan/nhc_ghc_udp.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 1bd49eb..94d5178 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -65,4 +65,9 @@ config 6LOWPAN_GHC_EXT_HDR_HOP
6LoWPAN IPv6 Hop-by-Hop option generic header compression according
to RFC7400.
+config 6LOWPAN_GHC_UDP
+ tristate "GHC UDP Support"
+ ---help---
+ 6LoWPAN IPv6 UDP generic header compression according to RFC7400.
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index ba20e01..5e4f2f3 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
#rfc7400 ghcs
obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_HOP) += nhc_ghc_ext_hop.o
+obj-$(CONFIG_6LOWPAN_GHC_UDP) += nhc_ghc_udp.o
diff --git a/net/6lowpan/nhc_ghc_udp.c b/net/6lowpan/nhc_ghc_udp.c
new file mode 100644
index 000..17beefa
--- /dev/null
+++ b/net/6lowpan/nhc_ghc_udp.c
@@ -0,0 +1,27 @@
+/*
+ * 6LoWPAN UDP compression according to RFC7400
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_UDP_IDLEN 1
+#define LOWPAN_GHC_UDP_ID_00xd0
+#define LOWPAN_GHC_UDP_MASK_0 0xf8
+
+static void udp_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_UDP_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_UDP_MASK_0;
+}
+
+LOWPAN_NHC(ghc_udp, "RFC7400 UDP", NEXTHDR_UDP, 0,
+ udp_ghid_setup, LOWPAN_GHC_UDP_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_udp);
+MODULE_DESCRIPTION("6LoWPAN generic header UDP compression");
+MODULE_LICENSE("GPL");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 01/10] 6lowpan: clarify Kconfig entries for upcoming GHC support
From: Stefan Schmidt Acked-by: Jukka Rissanen Signed-off-by: Stefan Schmidt Signed-off-by: Alexander Aring --- net/6lowpan/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig index 7fa0f38..6af7a46 100644 --- a/net/6lowpan/Kconfig +++ b/net/6lowpan/Kconfig @@ -6,11 +6,12 @@ menuconfig 6LOWPAN "6LoWPAN" which is supported by IEEE 802.15.4 or Bluetooth stacks. menuconfig 6LOWPAN_NHC - tristate "Next Header Compression Support" + tristate "Next Header and Generic Header Compression Support" depends on 6LOWPAN default y ---help--- - Support for next header compression. + Support for next header and generic header compression defined in + RFC6282 and RFC7400. if 6LOWPAN_NHC -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 05/10] 6lowpan: add nhc module for GHC destination extension header detection
From: Stefan Schmidt
Acked-by: Jukka Rissanen
Signed-off-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
net/6lowpan/Kconfig| 6 ++
net/6lowpan/Makefile | 1 +
net/6lowpan/nhc_ghc_ext_dest.c | 27 +++
3 files changed, 34 insertions(+)
create mode 100644 net/6lowpan/nhc_ghc_ext_dest.c
diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig
index 0a3f5a8..e5184e6 100644
--- a/net/6lowpan/Kconfig
+++ b/net/6lowpan/Kconfig
@@ -75,4 +75,10 @@ config 6LOWPAN_GHC_ICMPV6
---help---
6LoWPAN IPv6 ICMPv6 generic header compression according to RFC7400.
+config 6LOWPAN_GHC_EXT_HDR_DEST
+ tristate "GHC Destination Options Header Support"
+ ---help---
+ 6LoWPAN IPv6 destination option generic header compression according
+ to RFC7400.
+
endif
diff --git a/net/6lowpan/Makefile b/net/6lowpan/Makefile
index 86af3fd..fc4bac0 100644
--- a/net/6lowpan/Makefile
+++ b/net/6lowpan/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_6LOWPAN_NHC_UDP) += nhc_udp.o
obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_HOP) += nhc_ghc_ext_hop.o
obj-$(CONFIG_6LOWPAN_GHC_UDP) += nhc_ghc_udp.o
obj-$(CONFIG_6LOWPAN_GHC_ICMPV6) += nhc_ghc_icmpv6.o
+obj-$(CONFIG_6LOWPAN_GHC_EXT_HDR_DEST) += nhc_ghc_ext_dest.o
diff --git a/net/6lowpan/nhc_ghc_ext_dest.c b/net/6lowpan/nhc_ghc_ext_dest.c
new file mode 100644
index 000..9887b3a
--- /dev/null
+++ b/net/6lowpan/nhc_ghc_ext_dest.c
@@ -0,0 +1,27 @@
+/*
+ * 6LoWPAN Extension Header compression according to RFC7400
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include "nhc.h"
+
+#define LOWPAN_GHC_EXT_DEST_IDLEN 1
+#define LOWPAN_GHC_EXT_DEST_ID_0 0xb6
+#define LOWPAN_GHC_EXT_DEST_MASK_0 0xfe
+
+static void dest_ghid_setup(struct lowpan_nhc *nhc)
+{
+ nhc->id[0] = LOWPAN_GHC_EXT_DEST_ID_0;
+ nhc->idmask[0] = LOWPAN_GHC_EXT_DEST_MASK_0;
+}
+
+LOWPAN_NHC(ghc_ext_dest, "RFC7400 Destination Extension Header", NEXTHDR_DEST,
+ 0, dest_ghid_setup, LOWPAN_GHC_EXT_DEST_IDLEN, NULL, NULL);
+
+module_lowpan_nhc(ghc_ext_dest);
+MODULE_DESCRIPTION("6LoWPAN generic header destination extension compression");
+MODULE_LICENSE("GPL");
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 10/10] ipv6: add ipv6_addr_prefix_copy
This patch adds a static inline function ipv6_addr_prefix_copy which
copies a ipv6 address prefix(argument pfx) into the ipv6 address prefix.
The prefix len is given by plen as bits. This function mainly based on
ipv6_addr_prefix which copies one address prefix from address into a new
ipv6 address destination and zero all other address bits.
The difference is that ipv6_addr_prefix_copy don't get a prefix from an
ipv6 address, it sets a prefix to an ipv6 address with keeping other
address bits. The use case is for context based address compression
inside 6LoWPAN IPHC header which keeping ipv6 prefixes inside a context
table to lookup address-bits without sending them.
Cc: David S. Miller
Cc: Alexey Kuznetsov
Cc: James Morris
Cc: Hideaki YOSHIFUJI
Cc: Patrick McHardy
Acked-by: Łukasz Duda
Acked-by: Hannes Frederic Sowa
Acked-by: YOSHIFUJI Hideaki
Reviewed-by: Stefan Schmidt
Signed-off-by: Alexander Aring
---
include/net/ipv6.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/net/ipv6.h b/include/net/ipv6.h
index 9a5c9f0..6570f37 100644
--- a/include/net/ipv6.h
+++ b/include/net/ipv6.h
@@ -401,6 +401,21 @@ static inline void ipv6_addr_prefix(struct in6_addr *pfx,
pfx->s6_addr[o] = addr->s6_addr[o] & (0xff00 >> b);
}
+static inline void ipv6_addr_prefix_copy(struct in6_addr *addr,
+const struct in6_addr *pfx,
+int plen)
+{
+ /* caller must guarantee 0 <= plen <= 128 */
+ int o = plen >> 3,
+ b = plen & 0x7;
+
+ memcpy(addr->s6_addr, pfx, o);
+ if (b != 0) {
+ addr->s6_addr[o] &= ~(0xff00 >> b);
+ addr->s6_addr[o] |= (pfx->s6_addr[o] & (0xff00 >> b));
+ }
+}
+
static inline void __ipv6_addr_set_half(__be32 *addr,
__be32 wh, __be32 wl)
{
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 00/10] 6lowpan: pending patches
Hi, these are the current pending patches for 6lowpan based on bluetooth-next. It contains the following new features: - per interface debugfs support, useful to add settings to offers a fast/simple userspace api for debugging. - register of available NHC compression by IANA, see [0]. - Adding "ipv6_addr_prefix_copy" functionality for upcoming IPHC stateful compression. - Alex [0] https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#lowpan_nhc Alexander Aring (3): 6lowpan: add lowpan dev register helpers 6lowpan: add debugfs support ipv6: add ipv6_addr_prefix_copy Stefan Schmidt (7): 6lowpan: clarify Kconfig entries for upcoming GHC support 6lowpan: add nhc module for GHC hop-by-hopextension header detection 6lowpan: add nhc module for GHC UDP detection 6lowpan: add nhc module for GHC ICMPv6 detection 6lowpan: add nhc module for GHC destination extension header detection 6lowpan: add nhc module for GHC fragmentation extension header detection 6lowpan: add nhc module for GHC routing extension header detection include/net/6lowpan.h | 10 ++- include/net/ipv6.h | 15 +++ net/6lowpan/6lowpan_i.h | 28 +++ net/6lowpan/Kconfig | 47 ++-- net/6lowpan/Makefile| 9 +++ net/6lowpan/core.c | 59 +++-- net/6lowpan/debugfs.c | 53 net/6lowpan/nhc_ghc_ext_dest.c | 27 +++ net/6lowpan/nhc_ghc_ext_frag.c | 28 +++ net/6lowpan/nhc_ghc_ext_hop.c | 27 +++ net/6lowpan/nhc_ghc_ext_route.c | 27 +++ net/6lowpan/nhc_ghc_icmpv6.c| 27 +++ net/6lowpan/nhc_ghc_udp.c | 27 +++ net/bluetooth/6lowpan.c | 8 +++--- net/ieee802154/6lowpan/core.c | 6 ++--- 15 files changed, 384 insertions(+), 14 deletions(-) create mode 100644 net/6lowpan/6lowpan_i.h create mode 100644 net/6lowpan/debugfs.c create mode 100644 net/6lowpan/nhc_ghc_ext_dest.c create mode 100644 net/6lowpan/nhc_ghc_ext_frag.c create mode 100644 net/6lowpan/nhc_ghc_ext_hop.c create mode 100644 net/6lowpan/nhc_ghc_ext_route.c create mode 100644 net/6lowpan/nhc_ghc_icmpv6.c create mode 100644 net/6lowpan/nhc_ghc_udp.c -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] Doc: Micrel-ksz90x1.txt: Document deprecated MAC OF properties
On December 9, 2015 10:39:03 AM PST, Andrew Lunn wrote:
>Phy properties are expected to be found in the PHY OF node. However
>this Micrel driver also allows them to be placed into the MAC OF node.
>This is deprecated. Document it as such, and remove the example using
>the deprecated method to prevent people copying it into new device
>tree files.
>
>Signed-off-by: Andrew Lunn
Reviewed-by: Florian Fainelli
>---
>.../devicetree/bindings/net/micrel-ksz90x1.txt | 17
>-
> 1 file changed, 4 insertions(+), 13 deletions(-)
>
>diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>index 692076fda0e5..f9c32adab5c6 100644
>--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
>@@ -1,8 +1,9 @@
> Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
>
>-Some boards require special tuning values, particularly when it comes
>to
>-clock delays. You can specify clock delay values by adding
>-micrel-specific properties to an Ethernet OF device node.
>+Some boards require special tuning values, particularly when it comes
>+to clock delays. You can specify clock delay values in the PHY OF
>+device node. Deprecated, but still supported, these properties can
>+also be added to an Ethernet OF device node.
>
> Note that these settings are applied after any phy-specific fixup from
> phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
>@@ -57,16 +58,6 @@ KSZ9031:
>
> Examples:
>
>- /* Attach to an Ethernet device with autodetected PHY */
>- &enet {
>- rxc-skew-ps = <3000>;
>- rxdv-skew-ps = <0>;
>- txc-skew-ps = <3000>;
>- txen-skew-ps = <0>;
>- status = "okay";
>- };
>-
>- /* Attach to an explicitly-specified PHY */
> mdio {
> phy0: ethernet-phy@0 {
> rxc-skew-ps = <3000>;
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 net] phy: micrel: Fix finding PHY properties in MAC node.
On December 9, 2015 10:56:31 AM PST, Andrew Lunn wrote:
>commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
>not the bus' parent.") changed the parenting of PHY devices, making
>them a child of the MDIO bus, instead of the MAC device. This broken
>the Micrel PHY driver which has a deprecated feature of allowing PHY
>properties to be placed into the MAC node.
>
>In order to find the MAC node, we need to walk up the tree of devices
>until we find one with an OF node attached.
>
>Reported-by: Dinh Nguyen
>Suggested-by: David Daney
>Acked-by: David Daney
>Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not
>the bus' parent.")
>Signed-off-by: Andrew Lunn
>---
>- if (!of_node && dev->parent->of_node)
>- of_node = dev->parent->of_node;
>+ /* The Micrel driver has a deprecated option to place phy OF
>+ * properties in the MAC node. Walk up the tree of devices to
>+ * find a device with an OF node.
>+ */
>+ dev_walker = &phydev->dev;
>+ do {
>+ of_node = dev_walker->of_node;
>+ dev_walker = dev_walker->parent;
>+
>+ } while (!of_node && dev_walker);
Looks good to me, can we also issuing à warning so people get a chance to
update their Device Tree?
Acked-by: Florian Fainelli
>
> if (of_node) {
> ksz9021_load_values_from_of(phydev, of_node,
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH bluetooth-next 00/10] 6lowpan: pending patches
Hi, sorry for the noise, I got a at PATCH 02/10: "4.7.0 Temporary System Problem. Try again later " from git send-email. I will look into this issue right now by doing some private testing and if it seems to run fine I will try again. - Alex -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 01/10] 6lowpan: clarify Kconfig entries for upcoming GHC support
From: Stefan Schmidt Acked-by: Jukka Rissanen Signed-off-by: Stefan Schmidt Signed-off-by: Alexander Aring --- net/6lowpan/Kconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/6lowpan/Kconfig b/net/6lowpan/Kconfig index 7fa0f38..6af7a46 100644 --- a/net/6lowpan/Kconfig +++ b/net/6lowpan/Kconfig @@ -6,11 +6,12 @@ menuconfig 6LOWPAN "6LoWPAN" which is supported by IEEE 802.15.4 or Bluetooth stacks. menuconfig 6LOWPAN_NHC - tristate "Next Header Compression Support" + tristate "Next Header and Generic Header Compression Support" depends on 6LOWPAN default y ---help--- - Support for next header compression. + Support for next header and generic header compression defined in + RFC6282 and RFC7400. if 6LOWPAN_NHC -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH bluetooth-next 00/10] 6lowpan: pending patches
Hi, these are the current pending patches for 6lowpan based on bluetooth-next. It contains the following new features: - per interface debugfs support, useful to add settings to offers a fast/simple userspace api for debugging. - register of available NHC compression by IANA, see [0]. - Adding "ipv6_addr_prefix_copy" functionality for upcoming IPHC stateful compression. - Alex [0] https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#lowpan_nhc Alexander Aring (3): 6lowpan: add lowpan dev register helpers 6lowpan: add debugfs support ipv6: add ipv6_addr_prefix_copy Stefan Schmidt (7): 6lowpan: clarify Kconfig entries for upcoming GHC support 6lowpan: add nhc module for GHC hop-by-hopextension header detection 6lowpan: add nhc module for GHC UDP detection 6lowpan: add nhc module for GHC ICMPv6 detection 6lowpan: add nhc module for GHC destination extension header detection 6lowpan: add nhc module for GHC fragmentation extension header detection 6lowpan: add nhc module for GHC routing extension header detection include/net/6lowpan.h | 10 ++- include/net/ipv6.h | 15 +++ net/6lowpan/6lowpan_i.h | 28 +++ net/6lowpan/Kconfig | 47 ++-- net/6lowpan/Makefile| 9 +++ net/6lowpan/core.c | 59 +++-- net/6lowpan/debugfs.c | 53 net/6lowpan/nhc_ghc_ext_dest.c | 27 +++ net/6lowpan/nhc_ghc_ext_frag.c | 28 +++ net/6lowpan/nhc_ghc_ext_hop.c | 27 +++ net/6lowpan/nhc_ghc_ext_route.c | 27 +++ net/6lowpan/nhc_ghc_icmpv6.c| 27 +++ net/6lowpan/nhc_ghc_udp.c | 27 +++ net/bluetooth/6lowpan.c | 8 +++--- net/ieee802154/6lowpan/core.c | 6 ++--- 15 files changed, 384 insertions(+), 14 deletions(-) create mode 100644 net/6lowpan/6lowpan_i.h create mode 100644 net/6lowpan/debugfs.c create mode 100644 net/6lowpan/nhc_ghc_ext_dest.c create mode 100644 net/6lowpan/nhc_ghc_ext_frag.c create mode 100644 net/6lowpan/nhc_ghc_ext_hop.c create mode 100644 net/6lowpan/nhc_ghc_ext_route.c create mode 100644 net/6lowpan/nhc_ghc_icmpv6.c create mode 100644 net/6lowpan/nhc_ghc_udp.c -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: memcontrol: MEMCG no longer works with SLOB
On Wednesday 09 December 2015 15:01:07 Johannes Weiner wrote:
> On Wed, Dec 09, 2015 at 05:32:39PM +0100, Arnd Bergmann wrote:
> > The change to move the kmem accounting into the normal memcg
> > code means we can no longer use memcg with slob, which lacks
> > the memcg_params member in its struct kmem_cache:
> >
> > ../mm/slab.h: In function 'is_root_cache':
> > ../mm/slab.h:187:10: error: 'struct kmem_cache' has no member named
> > 'memcg_params'
> >
> > This enforces the new dependency in Kconfig. Alternatively,
> > we could change the slob code to allow using MEMCG.
>
> I'm curious, was this a random config or do you actually use
> CONFIG_SLOB && CONFIG_MEMCG?
Just a randconfig build, I do a lot of those to check for ARM specific
regressions.
> index 5adec08..0b3ec4b 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -25,6 +25,9 @@ struct kmem_cache {
> int refcount; /* Use counter */
> void (*ctor)(void *); /* Called on object slot creation */
> struct list_head list; /* List of all slab caches on the system */
> +#ifdef CONFIG_MEMCG
> + struct memcg_cache_params memcg_params;
> +#endif
> };
>
> #endif /* CONFIG_SLOB */
This was my first approach to the problem, and it solves the build issues,
I just wasn't sure if it works as expected.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
From: Fabio Estevam
Date: Wed, 9 Dec 2015 18:37:35 -0200
> On Wed, Dec 9, 2015 at 6:09 PM, Timur Tabi wrote:
>
>>> +/* set MAC address */
>>> +void emac_mac_addr_clear(struct emac_adapter *adpt, u8 *addr)
>>> +{
>>> + u32 sta;
>>> +
>>> + /* for example: 00-A0-C6-11-22-33
>>> +* 0<-->C6112233, 1<-->00A0.
>>> +*/
>>
>> /*
>> * Multi-line comments
>> * look like this.
>> */
>
> Except in drivers/net. The convention in drivers/net is to use
> multi-line format as posted in this patch.
Correct.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
On Wed, Dec 9, 2015 at 6:09 PM, Timur Tabi wrote:
>> +/* set MAC address */
>> +void emac_mac_addr_clear(struct emac_adapter *adpt, u8 *addr)
>> +{
>> + u32 sta;
>> +
>> + /* for example: 00-A0-C6-11-22-33
>> +* 0<-->C6112233, 1<-->00A0.
>> +*/
>
> /*
> * Multi-line comments
> * look like this.
> */
Except in drivers/net. The convention in drivers/net is to use
multi-line format as posted in this patch.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 0/2] mlx5 minor SRIOV fixes
From: Saeed Mahameed Date: Wed, 9 Dec 2015 13:39:32 +0200 > On Wed, Dec 9, 2015 at 4:41 AM, David Miller wrote: >> >> Don't do this, submitting two disconnected patch series for the same >> driver (mlx5), for the same tree (net-next). >> > for next time ? or you want me to re-submit those two patch sets ? You must resubmit this current material. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] net: thunderx: HW TSO support for pass-2 hardware
From: Pavel Fedin
Date: Wed, 09 Dec 2015 15:05:01 +0300
> Hello!
>
>> -Original Message-
>> From: netdev-ow...@vger.kernel.org [mailto:netdev-ow...@vger.kernel.org] On
>> Behalf Of Sunil
>> Goutham
>> Sent: Wednesday, December 09, 2015 2:38 PM
>> To: netdev@vger.kernel.org
>> Cc: linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>> p.fe...@samsung.com;
>> sunil.gout...@caviumnetworks.com; Sunil Goutham
>> Subject: [PATCH 1/2] net: thunderx: HW TSO support for pass-2 hardware
>>
>> From: Sunil Goutham
>>
>> This adds support for offloading TCP segmentation to HW in pass-2
>> revision of hardware. Both driver level SW TSO for pass1.x chips
>> and HW TSO for pass-2 chip will co-exist.
>>
>> Signed-off-by: Sunil Goutham
>> ---
>> drivers/net/ethernet/cavium/thunder/nic.h | 12 ++--
>> drivers/net/ethernet/cavium/thunder/nic_main.c | 11 ++-
>> drivers/net/ethernet/cavium/thunder/nicvf_main.c | 15 -
>> drivers/net/ethernet/cavium/thunder/nicvf_queues.c | 20 ++---
>> drivers/net/ethernet/cavium/thunder/q_struct.h | 30
>> ++-
>> 5 files changed, 56 insertions(+), 32 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cavium/thunder/nic.h
>> b/drivers/net/ethernet/cavium/thunder/nic.h
>> index 39ca674..02571f4 100644
>> --- a/drivers/net/ethernet/cavium/thunder/nic.h
>> +++ b/drivers/net/ethernet/cavium/thunder/nic.h
>> @@ -262,9 +262,10 @@ struct nicvf {
>> struct pci_dev *pdev;
>> u8 vf_id;
>> u8 node;
>> -u8 tns_mode:1;
>> -u8 sqs_mode:1;
>> -u8 loopback_supported:1;
>> +booltns_mode:1;
>> +boolsqs_mode:1;
>
> These little refactors are creeping in your code without even being
> mentioned in the commit message, this is not good practice
> IMHO. Additionally, may be turn these two flags into something like:
Also I disagree completely with boolean bitfields. Just use plain 'bool' and
let
the compiler decide how to lay it out.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] Add virtio transport for AF_VSOCK
On Wed, Dec 09, 2015 at 08:03:49PM +0800, Stefan Hajnoczi wrote: > Note: the virtio-vsock device specification is currently under review but not > yet finalized. Please review this code but don't merge until I send an update > when the spec is finalized. Thanks! Yes, this should have RFC in the subject. > v3: > * Remove unnecessary 3-way handshake, just do REQUEST/RESPONSE instead >of REQUEST/RESPONSE/ACK > * Remove SOCK_DGRAM support and focus on SOCK_STREAM first >(also drop v2 Patch 1, it's only needed for SOCK_DGRAM) > * Only allow host->guest connections (same security model as latest >VMware) > * Don't put vhost vsock driver into staging > * Add missing Kconfig dependencies (Arnd Bergmann ) > * Remove unneeded variable used to store return value >(Fengguang Wu and Julia Lawall >) > > v2: > * Rebased onto Linux v4.4-rc2 > * vhost: Refuse to assign reserved CIDs > * vhost: Refuse guest CID if already in use > * vhost: Only accept correctly addressed packets (no spoofing!) > * vhost: Support flexible rx/tx descriptor layout > * vhost: Add missing total_tx_buf decrement > * virtio_transport: Fix total_tx_buf accounting > * virtio_transport: Add virtio_transport global mutex to prevent races > * common: Notify other side of SOCK_STREAM disconnect (fixes shutdown >semantics) > * common: Avoid recursive mutex_lock(tx_lock) for write_space (fixes > deadlock) > * common: Define VIRTIO_VSOCK_TYPE_STREAM/DGRAM hardware interface constants > * common: Define VIRTIO_VSOCK_SHUTDOWN_RCV/SEND hardware interface constants > * common: Fix peer_buf_alloc inheritance on child socket > > This patch series adds a virtio transport for AF_VSOCK (net/vmw_vsock/). > AF_VSOCK is designed for communication between virtual machines and > hypervisors. It is currently only implemented for VMware's VMCI transport. > > This series implements the proposed virtio-vsock device specification from > here: > http://permalink.gmane.org/gmane.comp.emulators.virtio.devel/980 > > Most of the work was done by Asias He and Gerd Hoffmann a while back. I have > picked up the series again. > > The QEMU userspace changes are here: > https://github.com/stefanha/qemu/commits/vsock > > Why virtio-vsock? > - > Guest<->host communication is currently done over the virtio-serial device. > This makes it hard to port sockets API-based applications and is limited to > static ports. > > virtio-vsock uses the sockets API so that applications can rely on familiar > SOCK_STREAM semantics. Applications on the host can easily connect to guest > agents because the sockets API allows multiple connections to a listen socket > (unlike virtio-serial). This simplifies the guest<->host communication and > eliminates the need for extra processes on the host to arbitrate virtio-serial > ports. > > Overview > > This series adds 3 pieces: > > 1. virtio_transport_common.ko - core virtio vsock code that uses vsock.ko > > 2. virtio_transport.ko - guest driver > > 3. drivers/vhost/vsock.ko - host driver > > Howto > - > The following kernel options are needed: > CONFIG_VSOCKETS=y > CONFIG_VIRTIO_VSOCKETS=y > CONFIG_VIRTIO_VSOCKETS_COMMON=y > CONFIG_VHOST_VSOCK=m > > Launch QEMU as follows: > # qemu ... -device vhost-vsock-pci,id=vhost-vsock-pci0,guest-cid=3 > > Guest and host can communicate via AF_VSOCK sockets. The host's CID (address) > is 2 and the guest must be assigned a CID (3 in the example above). > > Status > -- > This patch series implements the latest draft specification. Please review. > > Asias He (4): > VSOCK: Introduce virtio-vsock-common.ko > VSOCK: Introduce virtio-vsock.ko > VSOCK: Introduce vhost-vsock.ko > VSOCK: Add Makefile and Kconfig > > drivers/vhost/Kconfig | 10 + > drivers/vhost/Makefile | 4 + > drivers/vhost/vsock.c | 628 +++ > drivers/vhost/vsock.h | 4 + > include/linux/virtio_vsock.h| 203 > include/uapi/linux/virtio_ids.h | 1 + > include/uapi/linux/virtio_vsock.h | 87 > net/vmw_vsock/Kconfig | 18 + > net/vmw_vsock/Makefile | 2 + > net/vmw_vsock/virtio_transport.c| 466 + > net/vmw_vsock/virtio_transport_common.c | 854 > > 11 files changed, 2277 insertions(+) > create mode 100644 drivers/vhost/vsock.c > create mode 100644 drivers/vhost/vsock.h > create mode 100644 include/linux/virtio_vsock.h > create mode 100644 include/uapi/linux/virtio_vsock.h > create mode 100644 net/vmw_vsock/virtio_transport.c > create mode 100644 net/vmw_vsock/virtio_transport_common.c > > -- > 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3] net: Add fib rules at vrf device create
From: David Ahern
Date: Wed, 9 Dec 2015 09:43:32 -0800
> VRFs require ip rules for route lookups to work properly. Currently
> creating a VRF means instantiating a device and then adding the 4 ip
> and ip6 rules:
>
> ip link add vrf-${VRF} type vrf table ${TBID}
> ip link set vrf-${VRF} up
> ip ru add oif vrf-${VRF} table ${TBID}
> ip ru add iif vrf-${VRF} table ${TBID}
> ip -6 ru add oif vrf-${VRF} table $TBID
> ip -6 ru add iif vrf-${VRF} table $TBID
>
> Similarly, cleanup requires deleting the link and removing the FIB rules.
> Since the table is required when the vrf device is created the rules can
> be inserted and deleted automatically lightening the overhead and improving
> the user experience (only the ip link commands are needed).
>
> The VRF driver will only automatically add and remove FIB rules if
> directed by the user per a new IFLA attribute. This new attribute,
> suggested by Roopa, helps maintain backward compatibility with existing
> users that already manage the fib rules directly.
>
> Signed-off-by: David Ahern
David, please stop.
Just accept that you failed to design this from the beginning properly
and we're stuck with people having to run multiple commands.
There is zero value to the new attributes.
No matter what you do, users have to use the full sequence of commands
above in order for things to work with all kernels, _FULL STOP_.
The new attributes make things more complex, because ever _VALID_ tool
much accomodate the existing situation and be able to perform all of
the commands above if they are executed on an older kernel.
So the new attributes make things worse, not better.
I will ignore all further attempts to find schemes automate the rule
and route additions, because it is simply the wrong way forward.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: emac: emac gigabit ethernet controller driver
So first of all, thanks for posting this. I know it's missing a bunch
of stuff that's necessary for Qualcomm's Server chip, but it's a
start.
Unfortunately, 6,000 lines is a lot to review at once. Any chance you
can break up the next version into smaller patches?
On Mon, Dec 7, 2015 at 4:58 PM, Gilad Avidov wrote:
> + qcom,emac-gpio-mdc = <&msmgpio 123 0>;
> + qcom,emac-gpio-mdio = <&msmgpio 124 0>;
Is there any chance you can remove all references to "MSM" throughout
the entire driver, since the EMAC exists on non-MSM parts?
> + qcom,emac-tstamp-en;
> + qcom,emac-ptp-frac-ns-adj = <12500 1>;
> + phy-addr = <0>;
> + };
> diff --git a/drivers/net/ethernet/qualcomm/Kconfig
> b/drivers/net/ethernet/qualcomm/Kconfig
> index a76e380..ae9442d 100644
> --- a/drivers/net/ethernet/qualcomm/Kconfig
> +++ b/drivers/net/ethernet/qualcomm/Kconfig
> @@ -24,4 +24,11 @@ config QCA7000
> To compile this driver as a module, choose M here. The module
> will be called qcaspi.
>
> +config QCOM_EMAC
> + tristate "MSM EMAC Gigabit Ethernet support"
> + default n
"default n" is redundant
> + select CRC32
> + ---help---
> + This driver supports the Qualcomm EMAC Gigabit Ethernet controller.
I think should be longer, perhaps by adding some more info about the
controller itself?
> +
> endif # NET_VENDOR_QUALCOMM
> diff --git a/drivers/net/ethernet/qualcomm/Makefile
> b/drivers/net/ethernet/qualcomm/Makefile
> index 9da2d75..b14686e 100644
> --- a/drivers/net/ethernet/qualcomm/Makefile
> +++ b/drivers/net/ethernet/qualcomm/Makefile
> @@ -4,3 +4,5 @@
>
> obj-$(CONFIG_QCA7000) += qcaspi.o
> qcaspi-objs := qca_spi.o qca_framing.o qca_7k.o qca_debug.o
> +
> +obj-$(CONFIG_QCOM_EMAC) += emac/
> \ No newline at end of file
Please fix
> +/* RSS */
> +static void emac_mac_rss_config(struct emac_adapter *adpt)
> +{
> + int key_len_by_u32 = sizeof(adpt->rss_key) / sizeof(u32);
> + int idt_len_by_u32 = sizeof(adpt->rss_idt) / sizeof(u32);
Can you use ARRAY_SIZE here?
> + u32 rxq0;
> + int i;
> +
> + /* Fill out hash function keys */
> + for (i = 0; i < key_len_by_u32; i++) {
> + u32 key, idx_base;
> +
> + idx_base = (key_len_by_u32 - i) * 4;
> + key = ((adpt->rss_key[idx_base - 1]) |
> + (adpt->rss_key[idx_base - 2] << 8) |
> + (adpt->rss_key[idx_base - 3] << 16) |
> + (adpt->rss_key[idx_base - 4] << 24));
> + writel_relaxed(key, adpt->base + EMAC_RSS_KEY(i, u32));
> + }
> +
> + /* Fill out redirection table */
> + for (i = 0; i < idt_len_by_u32; i++)
> + writel_relaxed(adpt->rss_idt[i],
> + adpt->base + EMAC_RSS_TBL(i, u32));
> +
> + writel_relaxed(adpt->rss_base_cpu, adpt->base + EMAC_BASE_CPU_NUMBER);
> +
> + rxq0 = readl_relaxed(adpt->base + EMAC_RXQ_CTRL_0);
> + if (adpt->rss_hstype & EMAC_RSS_HSTYP_IPV4_EN)
> + rxq0 |= RXQ0_RSS_HSTYP_IPV4_EN;
> + else
> + rxq0 &= ~RXQ0_RSS_HSTYP_IPV4_EN;
> +
> + if (adpt->rss_hstype & EMAC_RSS_HSTYP_TCP4_EN)
> + rxq0 |= RXQ0_RSS_HSTYP_IPV4_TCP_EN;
> + else
> + rxq0 &= ~RXQ0_RSS_HSTYP_IPV4_TCP_EN;
> +
> + if (adpt->rss_hstype & EMAC_RSS_HSTYP_IPV6_EN)
> + rxq0 |= RXQ0_RSS_HSTYP_IPV6_EN;
> + else
> + rxq0 &= ~RXQ0_RSS_HSTYP_IPV6_EN;
> +
> + if (adpt->rss_hstype & EMAC_RSS_HSTYP_TCP6_EN)
> + rxq0 |= RXQ0_RSS_HSTYP_IPV6_TCP_EN;
> + else
> + rxq0 &= ~RXQ0_RSS_HSTYP_IPV6_TCP_EN;
> +
> + rxq0 |= ((adpt->rss_idt_size << IDT_TABLE_SIZE_SHFT) &
> + IDT_TABLE_SIZE_BMSK);
> + rxq0 |= RSS_HASH_EN;
> +
> + wmb(); /* ensure all parameters are written before enabling RSS */
> +
> + writel_relaxed(rxq0, adpt->base + EMAC_RXQ_CTRL_0);
Why not just use writel(), which already includes a wmb()
> +/* Power Management */
> +void emac_mac_pm(struct emac_adapter *adpt, u32 speed, bool wol_en, bool
> rx_en)
> +{
> + u32 dma_mas, mac;
> +
> + dma_mas = readl_relaxed(adpt->base + EMAC_DMA_MAS_CTRL);
> + dma_mas &= ~LPW_CLK_SEL;
> + dma_mas |= LPW_STATE;
> +
> + mac = readl_relaxed(adpt->base + EMAC_MAC_CTRL);
> + mac &= ~(FULLD | RXEN | TXEN);
> + mac = (mac & ~SPEED_BMSK) |
> + (((u32)emac_mac_speed_10_100 << SPEED_SHFT) & SPEED_BMSK);
> +
> + if (wol_en) {
> + if (rx_en)
> + mac |= (RXEN | BROAD_EN);
You don't need the parentheses.
> +/* Config descriptor rings */
> +static void emac_mac_dma_rings_config(struct emac_adapter *adpt)
> +{
> + if (adpt->timestamp_en)
> + emac_reg_update32(adpt->csr + EMAC_EMAC_WRAPPER_CSR1,
> +
Re: [PATCHv2 net] phy: micrel: Fix finding PHY properties in MAC node.
On 12/09/2015 12:56 PM, Andrew Lunn wrote:
> commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
> not the bus' parent.") changed the parenting of PHY devices, making
> them a child of the MDIO bus, instead of the MAC device. This broken
> the Micrel PHY driver which has a deprecated feature of allowing PHY
> properties to be placed into the MAC node.
>
> In order to find the MAC node, we need to walk up the tree of devices
> until we find one with an OF node attached.
>
> Reported-by: Dinh Nguyen
> Suggested-by: David Daney
> Acked-by: David Daney
> Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the
> bus' parent.")
> Signed-off-by: Andrew Lunn
> ---
> v2: Remove include of netdev.h
> ---
Feel free to add:
Tested-by: Dinh Nguyen
Thanks,
Dinh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 1/6] net: Generalize udp based tunnel offload
From: Alexei Starovoitov Date: Wed, 9 Dec 2015 09:38:44 -0800 > p4 is a high level language and absolutely not suitable for such purpose. > bpf as intermediate representation can be generated from p4 or C or other > language. There is room to innovate in the language definition on top > and in HW design at the bottom. That's the most flexible model. +1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] cgroup: fix sock_cgroup_data initialization on earlier compilers
From: Tejun Heo
Date: Wed, 9 Dec 2015 12:30:46 -0500
> sock_cgroup_data is a struct containing an anonymous union.
> sock_cgroup_set_prioidx() and sock_cgroup_set_classid() were
> initializing a field inside the anonymous union as follows.
>
> struct sock_ccgroup_data skcd_buf = { .val = VAL };
>
> While this is fine on more recent compilers, gcc-4.4.7 triggers the
> following errors.
>
> include/linux/cgroup-defs.h: In function ‘sock_cgroup_set_prioidx’:
> include/linux/cgroup-defs.h:619: error: unknown field ‘val’ specified in
> initializer
> include/linux/cgroup-defs.h:619: warning: missing braces around initializer
> include/linux/cgroup-defs.h:619: warning: (near initialization for
> ‘skcd_buf.’)
>
> This is because .val belongs to the anonymous union nested inside the
> struct but the initializer is missing the nesting. Fix it by adding
> an extra pair of braces.
>
> Signed-off-by: Tejun Heo
> Reported-by: Alaa Hleihel
> Fixes: bd1060a1d671 ("sock, cgroup: add sock->sk_cgroup")
Applied, thanks.
Re: [PATCH] mm: memcontrol: MEMCG no longer works with SLOB
On Wed, Dec 09, 2015 at 05:32:39PM +0100, Arnd Bergmann wrote:
> The change to move the kmem accounting into the normal memcg
> code means we can no longer use memcg with slob, which lacks
> the memcg_params member in its struct kmem_cache:
>
> ../mm/slab.h: In function 'is_root_cache':
> ../mm/slab.h:187:10: error: 'struct kmem_cache' has no member named
> 'memcg_params'
>
> This enforces the new dependency in Kconfig. Alternatively,
> we could change the slob code to allow using MEMCG.
I'm curious, was this a random config or do you actually use
CONFIG_SLOB && CONFIG_MEMCG?
Excluding CONFIG_MEMCG completely for slob seems harsh, but I would
prefer not littering the source with
#if defined(CONFIG_MEMCG) && (defined(CONFIG_SLAB) || defined(CONFIG_SLUB))
or
#if defined(CONFIG_MEMCG) && !defined(CONFIG_SLOB)
for such a special case. The #ifdefs are already out of hand in there.
Vladimir, what would you think of simply doing this?
diff --git a/mm/slab.h b/mm/slab.h
index 5adec08..0b3ec4b 100644
--- a/mm/slab.h
+++ b/mm/slab.h
@@ -25,6 +25,9 @@ struct kmem_cache {
int refcount; /* Use counter */
void (*ctor)(void *); /* Called on object slot creation */
struct list_head list; /* List of all slab caches on the system */
+#ifdef CONFIG_MEMCG
+ struct memcg_cache_params memcg_params;
+#endif
};
#endif /* CONFIG_SLOB */
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] ipv6: sctp: clone options to avoid use after free
On 12/09/2015 06:11 PM, Marcelo Ricardo Leitner wrote: Em 09-12-2015 14:31, David Laight escreveu: From: Eric Dumazet [mailto:eric.duma...@gmail.com] Sent: 09 December 2015 16:00 On Wed, 2015-12-09 at 15:49 +, David Laight wrote: SCTP is lacking proper np->opt cloning at accept() time. TCP and DCCP use ipv6_dup_options() helper, do the same in SCTP. We might later factorize this code in a common helper to avoid future mistakes. I'm wondering what the real impact of this and the other recent SCTP bugs/patches is on real workloads? We have enough trouble getting our customers to use kernels later that the 2.6.18 based RHEL5 - without having to persuade them to use kernels that contain very recent fixes. It all depends if your customers let (hostile ?) people run programs on the boxes. If they require hostile programs I'm not worried. Not really "require", but "allow", as in: allowing third-party applications to run on it. Yeah :/ given distros enable almost everything anyway, the first unpriv'ed socket(..., IPPROTO_SCTP) call auto-loads SCTP module. But to be honest, I'd be surprised if Cloud providers allow for this. Most of this might only run on dedicated boxes with telco appliances. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v4 12/19] net: fcoe: use __ethtool_get_ksettings
Hi David,
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/David-Decotigny/RFC-new-ETHTOOL_GSETTINGS-SSETTINGS-API/20151210-022123
config: i386-randconfig-b0-12100240 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/scsi/fcoe/fcoe_transport.c: In function 'fcoe_link_speed_update':
>> drivers/scsi/fcoe/fcoe_transport.c:104:32: error: request for member 'mask'
>> in something not a structure or union
if (ecmd.link_modes.supported.mask[0] & (
^
drivers/scsi/fcoe/fcoe_transport.c:110:32: error: request for member 'mask'
in something not a structure or union
if (ecmd.link_modes.supported.mask[0] & (
^
drivers/scsi/fcoe/fcoe_transport.c:117:32: error: request for member 'mask'
in something not a structure or union
if (ecmd.link_modes.supported.mask[0] & (
^
drivers/scsi/fcoe/fcoe_transport.c:122:32: error: request for member 'mask'
in something not a structure or union
if (ecmd.link_modes.supported.mask[0] & (
^
vim +/mask +104 drivers/scsi/fcoe/fcoe_transport.c
98 if (!__ethtool_get_ksettings(netdev, &ecmd)) {
99 lport->link_supported_speeds &= ~(FC_PORTSPEED_1GBIT |
100FC_PORTSPEED_10GBIT |
101FC_PORTSPEED_20GBIT |
102FC_PORTSPEED_40GBIT);
103
> 104 if (ecmd.link_modes.supported.mask[0] & (
105 SUPPORTED_1000baseT_Half |
106 SUPPORTED_1000baseT_Full |
107 SUPPORTED_1000baseKX_Full))
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 1/3] ser_gigaset: fix up NULL checks
On wo, 2015-12-09 at 12:12 +, One Thousand Gnomes wrote: > On Wed, 9 Dec 2015 11:45:57 +0100 > Tilman Schmidt wrote: > Want a patch on top of Paul's change or a single > patch including both and crediting him ? There's no change that can be attributed to me, I think. We're discussing a series submitted by Tilman. Confused, Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] phy: micrel: Fix finding PHY properties in MAC node.
On 12/09/2015 10:37 AM, Andrew Lunn wrote:
commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
not the bus' parent.") changed the parenting of PHY devices, making
them a child of the MDIO bus, instead of the MAC device. This broken
the Micrel PHY driver which has a deprecated feature of allowing PHY
properties to be placed into the MAC node.
In order to find the MAC node, we need to walk up the tree of devices
until we find one with an OF node attached.
Reported-by: Dinh Nguyen
Suggested-by: David Daney
Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the bus'
parent.")
Signed-off-by: Andrew Lunn
---
drivers/net/phy/micrel.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index cf6312fafea5..2493d7c035f2 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
No new types are introduced by the patch. Why do we need an additional
#include?
#include
#include
@@ -339,9 +340,18 @@ static int ksz9021_config_init(struct phy_device *phydev)
{
const struct device *dev = &phydev->dev;
const struct device_node *of_node = dev->of_node;
+ const struct device *dev_walker;
- if (!of_node && dev->parent->of_node)
- of_node = dev->parent->of_node;
+ /* The Micrel driver has a deprecated option to place phy OF
+* properties in the MAC node. Walk up the tree of devices to
+* find a device with an OF node.
+*/
+ dev_walker = &phydev->dev;
+ do {
+ of_node = dev_walker->of_node;
+ dev_walker = dev_walker->parent;
+
+ } while (!of_node && dev_walker);
if (of_node) {
ksz9021_load_values_from_of(phydev, of_node,
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/macb: add support for resetting PHY using GPIO
Hi Gregory,
[auto build test ERROR on net-next/master]
[also build test ERROR on v4.4-rc4 next-20151209]
url:
https://github.com/0day-ci/linux/commits/Gregory-CLEMENT/net-macb-add-support-for-resetting-PHY-using-GPIO/20151210-015931
config: x86_64-acpi-redef (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/cadence/macb.c: In function 'macb_probe':
>> drivers/net/ethernet/cadence/macb.c:2930:2: error: implicit declaration of
>> function 'macb_reset_phy' [-Werror=implicit-function-declaration]
macb_reset_phy(bp, np, 1);
^
cc1: some warnings being treated as errors
vim +/macb_reset_phy +2930 drivers/net/ethernet/cadence/macb.c
2924 mac = of_get_mac_address(np);
2925 if (mac)
2926 memcpy(bp->dev->dev_addr, mac, ETH_ALEN);
2927 else
2928 macb_get_hwaddr(bp);
2929
> 2930 macb_reset_phy(bp, np, 1);
2931
2932 err = of_get_phy_mode(np);
2933 if (err < 0) {
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH net] phy: micrel: Fix finding PHY properties in MAC node.
On 12/09/2015 10:37 AM, Andrew Lunn wrote:
commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
not the bus' parent.") changed the parenting of PHY devices, making
them a child of the MDIO bus, instead of the MAC device. This broken
the Micrel PHY driver which has a deprecated feature of allowing PHY
properties to be placed into the MAC node.
In order to find the MAC node, we need to walk up the tree of devices
until we find one with an OF node attached.
Reported-by: Dinh Nguyen
Suggested-by: David Daney
Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the bus'
parent.")
Signed-off-by: Andrew Lunn
Acked-by: David Daney
---
drivers/net/phy/micrel.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index cf6312fafea5..2493d7c035f2 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -339,9 +340,18 @@ static int ksz9021_config_init(struct phy_device *phydev)
{
const struct device *dev = &phydev->dev;
const struct device_node *of_node = dev->of_node;
+ const struct device *dev_walker;
- if (!of_node && dev->parent->of_node)
- of_node = dev->parent->of_node;
+ /* The Micrel driver has a deprecated option to place phy OF
+* properties in the MAC node. Walk up the tree of devices to
+* find a device with an OF node.
+*/
+ dev_walker = &phydev->dev;
+ do {
+ of_node = dev_walker->of_node;
+ dev_walker = dev_walker->parent;
+
+ } while (!of_node && dev_walker);
if (of_node) {
ksz9021_load_values_from_of(phydev, of_node,
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: forwarding of ipv4 link local addresses
On 12/9/15 6:44 AM, Thomas Graf wrote: On 12/03/15 at 02:35pm, David Miller wrote: From: David Ahern Date: Tue, 1 Dec 2015 13:35:58 -0800 RFC 3927 states that packets from/to IPv4 link-local addresses (169.254/16) should not be forwarded, yet the Linux networking stack happily forwards them. Before sending in a patch I wanted to inquire if this behavior is intentional. It probably won't break anything if we prohibit this, so sure send a patch. I don't have the full email context so apologies if this is not relevant. The RFC states that such addresses should not be forwarded _beyond the local link_. So as long as you are not breaking forwarding of these addresses on the local host, I'm perfectly fine. Hi Thomas: The above is the full email context. The behavior that one of our testers tripped over is packets sent to 169.254 addresses received on link A are forwarded out link B. That's the behavior that was surprising and seems to violate the RFC. I bring this up specifically because of: commit d0daebc3d622f95db181601cb0c4a0781f74f758 Author: Thomas Graf Date: Tue Jun 12 00:44:01 2012 + ipv4: Add interface option to enable routing of 127.0.0.0/8 Routing of 127/8 is tradtionally forbidden, we consider packets from that address block martian when routing and do not process corresponding ARP requests. [...] This feature is being used by a popular PaaS which leverages the 127/8 address space locally without polluting an entire routeable address space. Daniel pointed out this commit as well. I am referring strictly to 169.254/16 addresses. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mm: memcontrol: only manage socket pressure for CONFIG_INET
On Wed, Dec 09, 2015 at 05:32:16PM +0100, Arnd Bergmann wrote:
> When IPV4 support is disabled, the memcg->socket_pressure field is
> not defined and we get a build error from the vmpressure code:
>
> mm/vmpressure.c: In function 'vmpressure':
> mm/vmpressure.c:287:9: error: 'struct mem_cgroup' has no member named
> 'socket_pressure'
> memcg->socket_pressure = jiffies + HZ;
> mm/built-in.o: In function `mem_cgroup_css_free':
> :(.text+0x1c03a): undefined reference to `tcp_destroy_cgroup'
> mm/built-in.o: In function `mem_cgroup_css_online':
> :(.text+0x1c20e): undefined reference to `tcp_init_cgroup'
>
> This puts the code causing this in the same #ifdef that guards the
> struct member and the TCP implementation.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 20cc40e66c42 ("mm: memcontrol: hook up vmpressure to socket pressure")
Acked-by: Johannes Weiner
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 6faea81e66d7..73cd572167bb 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4220,13 +4220,13 @@ mem_cgroup_css_online(struct cgroup_subsys_state *css)
> if (ret)
> return ret;
>
> +#ifdef CONFIG_INET
> #ifdef CONFIG_MEMCG_LEGACY_KMEM
> ret = tcp_init_cgroup(memcg);
> if (ret)
> return ret;
> #endif
The calls to tcp_init_cgroup() appear earlier in the series than "mm:
memcontrol: hook up vmpressure to socket pressure". However, they get
moved around a few times so fixing it earlier means respinning the
series. Andrew, it's up to you whether we take the bisectability hit
for !CONFIG_INET && CONFIG_MEMCG (how common is this?) or whether you
want me to resend the series.
Sorry about the trouble. I don't have a git tree on kernel.org because
we don't really use git in -mm, but the downside is that we don't get
the benefits of the automatic build testing for all kinds of configs.
I'll try to set up a git tree to expose series to full build coverage
before they hit -mm and -next.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 net] phy: micrel: Fix finding PHY properties in MAC node.
commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
not the bus' parent.") changed the parenting of PHY devices, making
them a child of the MDIO bus, instead of the MAC device. This broken
the Micrel PHY driver which has a deprecated feature of allowing PHY
properties to be placed into the MAC node.
In order to find the MAC node, we need to walk up the tree of devices
until we find one with an OF node attached.
Reported-by: Dinh Nguyen
Suggested-by: David Daney
Acked-by: David Daney
Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the
bus' parent.")
Signed-off-by: Andrew Lunn
---
v2: Remove include of netdev.h
---
drivers/net/phy/micrel.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index cf6312fafea5..e13ad6cdcc22 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -339,9 +339,18 @@ static int ksz9021_config_init(struct phy_device *phydev)
{
const struct device *dev = &phydev->dev;
const struct device_node *of_node = dev->of_node;
+ const struct device *dev_walker;
- if (!of_node && dev->parent->of_node)
- of_node = dev->parent->of_node;
+ /* The Micrel driver has a deprecated option to place phy OF
+* properties in the MAC node. Walk up the tree of devices to
+* find a device with an OF node.
+*/
+ dev_walker = &phydev->dev;
+ do {
+ of_node = dev_walker->of_node;
+ dev_walker = dev_walker->parent;
+
+ } while (!of_node && dev_walker);
if (of_node) {
ksz9021_load_values_from_of(phydev, of_node,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] phy: micrel: Fix finding PHY properties in MAC node.
> >diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> >index cf6312fafea5..2493d7c035f2 100644
> >--- a/drivers/net/phy/micrel.c
> >+++ b/drivers/net/phy/micrel.c
> >@@ -26,6 +26,7 @@
> > #include
> > #include
> > #include
> >+#include
>
> No new types are introduced by the patch. Why do we need an
> additional #include?
We probably don't.
It took my debug patch which printed additional information, and
stripped the prints out. One of those prints needed netdev, but since
it has now gone, we probably don't need the include.
Andrew
> > #include
> > #include
> >
> >@@ -339,9 +340,18 @@ static int ksz9021_config_init(struct phy_device
> >*phydev)
> > {
> > const struct device *dev = &phydev->dev;
> > const struct device_node *of_node = dev->of_node;
> >+const struct device *dev_walker;
> >
> >-if (!of_node && dev->parent->of_node)
> >-of_node = dev->parent->of_node;
> >+/* The Micrel driver has a deprecated option to place phy OF
> >+ * properties in the MAC node. Walk up the tree of devices to
> >+ * find a device with an OF node.
> >+ */
> >+dev_walker = &phydev->dev;
> >+do {
> >+of_node = dev_walker->of_node;
> >+dev_walker = dev_walker->parent;
> >+
> >+} while (!of_node && dev_walker);
> >
> > if (of_node) {
> > ksz9021_load_values_from_of(phydev, of_node,
> >
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next] Doc: Micrel-ksz90x1.txt: Document deprecated MAC OF properties
Phy properties are expected to be found in the PHY OF node. However
this Micrel driver also allows them to be placed into the MAC OF node.
This is deprecated. Document it as such, and remove the example using
the deprecated method to prevent people copying it into new device
tree files.
Signed-off-by: Andrew Lunn
---
.../devicetree/bindings/net/micrel-ksz90x1.txt | 17 -
1 file changed, 4 insertions(+), 13 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
index 692076fda0e5..f9c32adab5c6 100644
--- a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -1,8 +1,9 @@
Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
-Some boards require special tuning values, particularly when it comes to
-clock delays. You can specify clock delay values by adding
-micrel-specific properties to an Ethernet OF device node.
+Some boards require special tuning values, particularly when it comes
+to clock delays. You can specify clock delay values in the PHY OF
+device node. Deprecated, but still supported, these properties can
+also be added to an Ethernet OF device node.
Note that these settings are applied after any phy-specific fixup from
phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
@@ -57,16 +58,6 @@ KSZ9031:
Examples:
- /* Attach to an Ethernet device with autodetected PHY */
- &enet {
- rxc-skew-ps = <3000>;
- rxdv-skew-ps = <0>;
- txc-skew-ps = <3000>;
- txen-skew-ps = <0>;
- status = "okay";
- };
-
- /* Attach to an explicitly-specified PHY */
mdio {
phy0: ethernet-phy@0 {
rxc-skew-ps = <3000>;
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] phy: micrel: Fix finding PHY properties in MAC node.
commit 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus,
not the bus' parent.") changed the parenting of PHY devices, making
them a child of the MDIO bus, instead of the MAC device. This broken
the Micrel PHY driver which has a deprecated feature of allowing PHY
properties to be placed into the MAC node.
In order to find the MAC node, we need to walk up the tree of devices
until we find one with an OF node attached.
Reported-by: Dinh Nguyen
Suggested-by: David Daney
Fixes: 8b63ec1837fa ("phylib: Make PHYs children of their MDIO bus, not the
bus' parent.")
Signed-off-by: Andrew Lunn
---
drivers/net/phy/micrel.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index cf6312fafea5..2493d7c035f2 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -339,9 +340,18 @@ static int ksz9021_config_init(struct phy_device *phydev)
{
const struct device *dev = &phydev->dev;
const struct device_node *of_node = dev->of_node;
+ const struct device *dev_walker;
- if (!of_node && dev->parent->of_node)
- of_node = dev->parent->of_node;
+ /* The Micrel driver has a deprecated option to place phy OF
+* properties in the MAC node. Walk up the tree of devices to
+* find a device with an OF node.
+*/
+ dev_walker = &phydev->dev;
+ do {
+ of_node = dev_walker->of_node;
+ dev_walker = dev_walker->parent;
+
+ } while (!of_node && dev_walker);
if (of_node) {
ksz9021_load_values_from_of(phydev, of_node,
--
2.6.2
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bpf: undefined shift in __bpf_prog_run
On 12/04/2015 08:10 PM, Alexei Starovoitov wrote: On Fri, Dec 04, 2015 at 08:03:47PM +0100, Dmitry Vyukov wrote: is it with some random seccomp program? If normal libseccomp generates such programs than it needs to be fixed. Yes, it is with completely random seccomp program. Such shifts have undefined behavior according to C standard and behave differently on different archs. I guess we don't want to rely on any kind of undefined behavior in bpf/seccomp. And generally want to completely define results of all operations in bpf. bpf is an engine and we're not going to slow down each shift operation by extra run-time checks or masks. In other words bpf shift instruction == shift in C. Both undefined with for large operands. If seccomp is relying on undefined behavior, it should be fixed. But note that it is not that result of such operation is undefined, it is overall kernel behavior that becomes undefined. not true. just don't generate random bpf programs with such shifts. kernel is fine. Kind of agree, so in case BPF JITs are being used, undefined behavior of the C standard would not really apply here, imho. Sure, clang is the front end, but the actual mapping from BPF to the arch opcode happens in kernel in that case (and pre-checked by the verifier). What matters in that case is the emission of the opcode itself from the BPF JIT compiler and the underlying spec of the ISA. F.e. while on x86 a shift count of > 31 resp. > 63 can be emitted by the JIT for the related 32/64 bit operations, the count will be masked with 31 resp. 63 eventually by the HW. In other cases like ppc the result would be different as the mask there is bigger. In case not JITs but the BPF interpreter is being used (which is compiled along with the kernel of course), we might need to consider it as "undefined behavior" in the sense that gcc _could_ do insane things iff it really wanted to for those cases. Given the interpreter is generic, gcc cannot make any assumptions at compile time (wrt constants), disassembly on x86 looks similar to what we do in JIT case. I think bailing out from the interpreter with 'return 0' seems equally bad/unexpected to me. I recall we had a similar conversation here [1] on rol32() / ror32() and variants. As this would only concern the interpreter itself, one option could be to reject large constants (K) through the verifier and binary AND with upper shift limits the register cases (w/o modifying JITs). That however would give a wrong impression on the JIT developer (thinking he needs to copy this). Thus, I'd agree with others iff gcc really decides to go crazy (and perhaps throw an exception or the like), we need to address the interpreter. Perhaps we should add some test cases to test_bpf.c on this to track the behavior. [1] https://lkml.org/lkml/2014/10/20/186 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net/macb: add support for resetting PHY using GPIO
Hi Gregory,
so far dealt with this in u-boot. The power down the PHY part makes
sense, though. Minor nit down inline.
Will need to test on hardware (Zynq).
On Wed, Dec 9, 2015 at 9:49 AM, Gregory CLEMENT
wrote:
> With device tree it is no more possible to reset the PHY at board
> level. Furthermore, doing in the driver allow to power down the PHY when
> the network interface is no more used.
>
> The patch introduces a new optional property "phy-reset-gpio" inspired
> from the one use for the FEC.
>
> Signed-off-by: Gregory CLEMENT
> ---
> Documentation/devicetree/bindings/net/macb.txt | 3 +++
> drivers/net/ethernet/cadence/macb.c| 26
> ++
> drivers/net/ethernet/cadence/macb.h| 1 +
> 3 files changed, 30 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/macb.txt
> b/Documentation/devicetree/bindings/net/macb.txt
> index b5d7976..546d34d 100644
> --- a/Documentation/devicetree/bindings/net/macb.txt
> +++ b/Documentation/devicetree/bindings/net/macb.txt
> @@ -19,6 +19,9 @@ Required properties:
> Optional elements: 'tx_clk'
> - clocks: Phandles to input clocks.
>
> +Optional properties:
> +- phy-reset-gpio : Should specify the gpio for phy reset
> +
> Examples:
>
> macb0: ethernet@fffc4000 {
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index 88c1e1a..e630c56 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -30,6 +30,7 @@
> #include
> #include
> #include
> +#include
>
> #include "macb.h"
>
> @@ -2733,6 +2734,28 @@ static int at91ether_init(struct platform_device *pdev)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static void macb_reset_phy(struct macb *bp, struct device_node *np, int
> state)
> +{
> + if (!np)
> + return;
> +
> + bp->reset_gpio = of_get_named_gpio(np, "phy-reset-gpio", 0);
Any reason to do of_get_named() all the time instead of using the one
you stored in bp->reset_gpio?
You could move it to probe and then just use the stored value here ...
not sure if it buys much ;-)
Cheers,
Moritz
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v4 09/19] net: ipvlan: use __ethtool_get_ksettings
From: David Decotigny
Signed-off-by: David Decotigny
---
drivers/net/ipvlan/ipvlan_main.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c
index a9268db..63b3aa5 100644
--- a/drivers/net/ipvlan/ipvlan_main.c
+++ b/drivers/net/ipvlan/ipvlan_main.c
@@ -346,12 +346,12 @@ static const struct header_ops ipvlan_header_ops = {
.cache_update = eth_header_cache_update,
};
-static int ipvlan_ethtool_get_settings(struct net_device *dev,
- struct ethtool_cmd *cmd)
+static int ipvlan_ethtool_get_ksettings(struct net_device *dev,
+ struct ethtool_ksettings *cmd)
{
const struct ipvl_dev *ipvlan = netdev_priv(dev);
- return __ethtool_get_settings(ipvlan->phy_dev, cmd);
+ return __ethtool_get_ksettings(ipvlan->phy_dev, cmd);
}
static void ipvlan_ethtool_get_drvinfo(struct net_device *dev,
@@ -377,7 +377,7 @@ static void ipvlan_ethtool_set_msglevel(struct net_device
*dev, u32 value)
static const struct ethtool_ops ipvlan_ethtool_ops = {
.get_link = ethtool_op_get_link,
- .get_settings = ipvlan_ethtool_get_settings,
+ .get_ksettings = ipvlan_ethtool_get_ksettings,
.get_drvinfo= ipvlan_ethtool_get_drvinfo,
.get_msglevel = ipvlan_ethtool_get_msglevel,
.set_msglevel = ipvlan_ethtool_set_msglevel,
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v4 06/19] tx4939: use __ethtool_get_ksettings
From: David Decotigny
Signed-off-by: David Decotigny
---
arch/mips/txx9/generic/setup_tx4939.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/mips/txx9/generic/setup_tx4939.c
b/arch/mips/txx9/generic/setup_tx4939.c
index e3733cd..4a3ebf6 100644
--- a/arch/mips/txx9/generic/setup_tx4939.c
+++ b/arch/mips/txx9/generic/setup_tx4939.c
@@ -320,11 +320,12 @@ void __init tx4939_sio_init(unsigned int sclk, unsigned
int cts_mask)
#if IS_ENABLED(CONFIG_TC35815)
static u32 tx4939_get_eth_speed(struct net_device *dev)
{
- struct ethtool_cmd cmd;
- if (__ethtool_get_settings(dev, &cmd))
+ struct ethtool_ksettings cmd;
+
+ if (__ethtool_get_ksettings(dev, &cmd))
return 100; /* default 100Mbps */
- return ethtool_cmd_speed(&cmd);
+ return cmd.parent.speed;
}
static int tx4939_netdev_event(struct notifier_block *this,
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v4 13/19] net: rdma: use __ethtool_get_ksettings
From: David Decotigny
Signed-off-by: David Decotigny
---
include/rdma/ib_addr.h | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/rdma/ib_addr.h b/include/rdma/ib_addr.h
index 1152859..1820f26 100644
--- a/include/rdma/ib_addr.h
+++ b/include/rdma/ib_addr.h
@@ -254,24 +254,22 @@ static inline enum ib_mtu iboe_get_mtu(int mtu)
static inline int iboe_get_rate(struct net_device *dev)
{
- struct ethtool_cmd cmd;
- u32 speed;
+ struct ethtool_ksettings cmd;
int err;
rtnl_lock();
- err = __ethtool_get_settings(dev, &cmd);
+ err = __ethtool_get_ksettings(dev, &cmd);
rtnl_unlock();
if (err)
return IB_RATE_PORT_CURRENT;
- speed = ethtool_cmd_speed(&cmd);
- if (speed >= 4)
+ if (cmd.parent.speed >= 4)
return IB_RATE_40_GBPS;
- else if (speed >= 3)
+ else if (cmd.parent.speed >= 3)
return IB_RATE_30_GBPS;
- else if (speed >= 2)
+ else if (cmd.parent.speed >= 2)
return IB_RATE_20_GBPS;
- else if (speed >= 1)
+ else if (cmd.parent.speed >= 1)
return IB_RATE_10_GBPS;
else
return IB_RATE_PORT_CURRENT;
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v4 17/19] net: ethtool: remove unused __ethtool_get_settings
From: David Decotigny
replaced by __ethtool_get_ksettings.
Signed-off-by: David Decotigny
---
include/linux/ethtool.h | 4
net/core/ethtool.c | 45 ++---
2 files changed, 14 insertions(+), 35 deletions(-)
diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
index 6077cbb..05d4f0e 100644
--- a/include/linux/ethtool.h
+++ b/include/linux/ethtool.h
@@ -148,10 +148,6 @@ struct ethtool_ksettings {
extern int __ethtool_get_ksettings(struct net_device *dev,
struct ethtool_ksettings *ksettings);
-/* DEPRECATED, use __ethtool_get_ksettings */
-extern int __ethtool_get_settings(struct net_device *dev,
- struct ethtool_cmd *cmd);
-
/**
* struct ethtool_ops - optional netdev operations
* @get_settings: DEPRECATED, use %get_ksettings/%set_ksettings
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 4865031..84dca87 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -495,7 +495,12 @@ int __ethtool_get_ksettings(struct net_device *dev,
* legacy %ethtool_cmd API, unless it's not supported either.
* TODO: remove when ethtool_ops::get_settings disappears internally
*/
- err = __ethtool_get_settings(dev, &cmd);
+ if (!dev->ethtool_ops->get_settings)
+ return -EOPNOTSUPP;
+
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.cmd = ETHTOOL_GSET;
+ err = dev->ethtool_ops->get_settings(dev, &cmd);
if (err < 0)
return err;
@@ -652,30 +657,6 @@ static int ethtool_set_ksettings(struct net_device *dev,
void __user *useraddr)
return dev->ethtool_ops->set_ksettings(dev, &ksettings);
}
-/* Internal kernel helper to query a device ethtool_cmd settings.
- *
- * Note about transition to ethtool_settings API: We do not need (or
- * want) this function to support "dev" instances that implement the
- * ethtool_settings API as we will update the drivers calling this
- * function to call __ethtool_get_ksettings instead, before the first
- * drivers implement ethtool_ops::get_ksettings.
- *
- * TODO 1: at least make this function static when no driver is using it
- * TODO 2: remove when ethtool_ops::get_settings disappears internally
- */
-int __ethtool_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
-{
- ASSERT_RTNL();
-
- if (!dev->ethtool_ops->get_settings)
- return -EOPNOTSUPP;
-
- memset(cmd, 0, sizeof(struct ethtool_cmd));
- cmd->cmd = ETHTOOL_GSET;
- return dev->ethtool_ops->get_settings(dev, cmd);
-}
-EXPORT_SYMBOL(__ethtool_get_settings);
-
static void
warn_incomplete_ethtool_legacy_settings_conversion(const char *details)
{
@@ -717,16 +698,18 @@ static int ethtool_get_settings(struct net_device *dev,
void __user *useraddr)
/* send a sensible cmd tag back to user */
cmd.cmd = ETHTOOL_GSET;
} else {
- int err;
- /* TODO: return -EOPNOTSUPP when
-* ethtool_ops::get_settings disappears internally
-*/
-
/* driver doesn't support %ethtool_ksettings
* API. revert to legacy %ethtool_cmd API, unless it's
* not supported either.
*/
- err = __ethtool_get_settings(dev, &cmd);
+ int err;
+
+ if (!dev->ethtool_ops->get_settings)
+ return -EOPNOTSUPP;
+
+ memset(&cmd, 0, sizeof(cmd));
+ cmd.cmd = ETHTOOL_GSET;
+ err = dev->ethtool_ops->get_settings(dev, &cmd);
if (err < 0)
return err;
}
--
2.6.0.rc2.230.g3dd15c0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
