* Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
From: Jakub Kicinski @ 2016-10-17 17:04 UTC (permalink / raw)
To: David Miller; +Cc: jarod, linux-kernel, netdev
In-Reply-To: <20161017180027.4936fa15@jkicinski-Precision-T1700>
On Mon, 17 Oct 2016 18:00:27 +0100, Jakub Kicinski wrote:
> On Mon, 17 Oct 2016 12:49:54 -0400 (EDT), David Miller wrote:
> > From: Jakub Kicinski <kubakici@wp.pl>
> > Date: Mon, 17 Oct 2016 17:20:06 +0100
> >
> > > Please correct me if I'm wrong but it seems like we are now limiting
> > > _all_ ethernet drivers to ETH_DATA_LEN in net-next.
> >
> > No, because the driver can increase the netdev->max_mtu value as needed.
>
> But since almost no driver is doing that, yet, right now in net-next
> jumbo frames are not possible, no? I thought the idea was the leave
> the value at 0 so drivers can opt-in as needed but since setup_ether()
> is initializing to 1500 now all ethernet driver get a default of
> limiting to 1500.
>
> IOW this patch made checks which were done only in eth_change_mtu()
> mandatory for all drivers.
all ethernet drivers to be clear
^ permalink raw reply
* Re: [PATCH 0/7] net: Fix module autoload for several platform drivers
From: David Miller @ 2016-10-17 17:03 UTC (permalink / raw)
To: javier
Cc: linux-kernel, arnd, timur, noamca, xieqianqian, vivien.didelot,
Lada.Trimasova, huangdaode, sf84, f.fainelli, eladkan,
weiyongjun1, salil.mehta, yisen.zhuang, andrew, yankejian,
tremyfr, mans, netdev, giladby, jarod, oulijun
In-Reply-To: <1476713146-26632-1-git-send-email-javier@osg.samsung.com>
From: Javier Martinez Canillas <javier@osg.samsung.com>
Date: Mon, 17 Oct 2016 11:05:39 -0300
> I noticed that module autoload won't be working in a bunch of platform
> drivers in the net subsystem and this patch series contains the fixes.
Looks good, series applied, thanks.
^ permalink raw reply
* [PATCH net-next] net: report right mtu value in error message
From: Jakub Kicinski @ 2016-10-17 17:02 UTC (permalink / raw)
To: netdev; +Cc: jarod, Jakub Kicinski
Check is for max_mtu but message reports min_mtu.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6498cc2ba8f6..352e98129601 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6372,7 +6372,7 @@ int dev_set_mtu(struct net_device *dev, int new_mtu)
if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
- dev->name, new_mtu, dev->min_mtu);
+ dev->name, new_mtu, dev->max_mtu);
return -EINVAL;
}
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 1/9] ipv6: implement dataplane support for rthdr type 4 (Segment Routing Header)
From: Tom Herbert @ 2016-10-17 17:01 UTC (permalink / raw)
To: David Lebrun; +Cc: Linux Kernel Network Developers
In-Reply-To: <1476715350-18983-2-git-send-email-david.lebrun@uclouvain.be>
On Mon, Oct 17, 2016 at 7:42 AM, David Lebrun <david.lebrun@uclouvain.be> wrote:
> Implement minimal support for processing of SR-enabled packets
> as described in
> https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-02.
>
> This patch implements the following operations:
> - Intermediate segment endpoint: incrementation of active segment and rerouting.
> - Egress for SR-encapsulated packets: decapsulation of outer IPv6 header + SRH
> and routing of inner packet.
> - Cleanup flag support for SR-inlined packets: removal of SRH if we are the
> penultimate segment endpoint.
>
> A per-interface sysctl seg6_enabled is provided, to accept/deny SR-enabled
> packets. Default is deny.
>
> This patch does not provide support for HMAC-signed packets.
>
> Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
> ---
> include/linux/ipv6.h | 3 +
> include/linux/seg6.h | 6 ++
> include/uapi/linux/ipv6.h | 2 +
> include/uapi/linux/seg6.h | 46 +++++++++++++++
> net/ipv6/Kconfig | 13 +++++
> net/ipv6/addrconf.c | 18 ++++++
> net/ipv6/exthdrs.c | 140 ++++++++++++++++++++++++++++++++++++++++++++++
> 7 files changed, 228 insertions(+)
> create mode 100644 include/linux/seg6.h
> create mode 100644 include/uapi/linux/seg6.h
>
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index 7e9a789..75395ad 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -64,6 +64,9 @@ struct ipv6_devconf {
> } stable_secret;
> __s32 use_oif_addrs_only;
> __s32 keep_addr_on_down;
> +#ifdef CONFIG_IPV6_SEG6
> + __s32 seg6_enabled;
> +#endif
>
> struct ctl_table_header *sysctl_header;
> };
> diff --git a/include/linux/seg6.h b/include/linux/seg6.h
> new file mode 100644
> index 0000000..7a66d2b
> --- /dev/null
> +++ b/include/linux/seg6.h
> @@ -0,0 +1,6 @@
> +#ifndef _LINUX_SEG6_H
> +#define _LINUX_SEG6_H
> +
> +#include <uapi/linux/seg6.h>
> +
> +#endif
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index 8c27723..7ff1d65 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -39,6 +39,7 @@ struct in6_ifreq {
> #define IPV6_SRCRT_STRICT 0x01 /* Deprecated; will be removed */
> #define IPV6_SRCRT_TYPE_0 0 /* Deprecated; will be removed */
> #define IPV6_SRCRT_TYPE_2 2 /* IPv6 type 2 Routing Header */
> +#define IPV6_SRCRT_TYPE_4 4 /* Segment Routing with IPv6 */
>
> /*
> * routing header
> @@ -178,6 +179,7 @@ enum {
> DEVCONF_DROP_UNSOLICITED_NA,
> DEVCONF_KEEP_ADDR_ON_DOWN,
> DEVCONF_RTR_SOLICIT_MAX_INTERVAL,
> + DEVCONF_SEG6_ENABLED,
> DEVCONF_MAX
> };
>
> diff --git a/include/uapi/linux/seg6.h b/include/uapi/linux/seg6.h
> new file mode 100644
> index 0000000..9f9e157
> --- /dev/null
> +++ b/include/uapi/linux/seg6.h
> @@ -0,0 +1,46 @@
> +/*
> + * SR-IPv6 implementation
> + *
> + * Author:
> + * David Lebrun <david.lebrun@uclouvain.be>
> + *
> + *
> + * 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.
> + */
> +
> +#ifndef _UAPI_LINUX_SEG6_H
> +#define _UAPI_LINUX_SEG6_H
> +
> +/*
> + * SRH
> + */
> +struct ipv6_sr_hdr {
> + __u8 nexthdr;
> + __u8 hdrlen;
> + __u8 type;
> + __u8 segments_left;
> + __u8 first_segment;
> + __be16 flags;
Bad alignment for 16 bit field could be unpleasant on some
architectures. Might be better to split this into to u8's, defined
flags are only in first eight bits anyway.
> + __u8 reserved;
> +
> + struct in6_addr segments[0];
> +} __attribute__((packed));
> +
> +#define SR6_FLAG_CLEANUP (1 << 15)
> +#define SR6_FLAG_PROTECTED (1 << 14)
> +#define SR6_FLAG_OAM (1 << 13)
> +#define SR6_FLAG_ALERT (1 << 12)
> +#define SR6_FLAG_HMAC (1 << 11)
> +
> +#define SR6_TLV_INGRESS 1
> +#define SR6_TLV_EGRESS 2
> +#define SR6_TLV_OPAQUE 3
> +#define SR6_TLV_PADDING 4
> +#define SR6_TLV_HMAC 5
> +
> +#define sr_get_flags(srh) (be16_to_cpu((srh)->flags))
> +
> +#endif
> diff --git a/net/ipv6/Kconfig b/net/ipv6/Kconfig
> index 2343e4f..691c318 100644
> --- a/net/ipv6/Kconfig
> +++ b/net/ipv6/Kconfig
> @@ -289,4 +289,17 @@ config IPV6_PIMSM_V2
> Support for IPv6 PIM multicast routing protocol PIM-SMv2.
> If unsure, say N.
>
> +config IPV6_SEG6
> + bool "IPv6: Segment Routing support"
> + depends on IPV6
> + select CRYPTO_HMAC
> + select CRYPTO_SHA1
> + select CRYPTO_SHA256
> + ---help---
> + Experimental support for IPv6 Segment Routing dataplane as defined
I don't think calling this experimental is relevant.
> + in IETF draft-ietf-6man-segment-routing-header-02. This option
> + enables the processing of SR-enabled packets allowing the kernel
> + to act as a segment endpoint (intermediate or egress). It also
> + enables an API for the kernel to act as an ingress SR router.
> +
> endif # IPV6
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index d8983e1..42c0ffb 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -239,6 +239,9 @@ static struct ipv6_devconf ipv6_devconf __read_mostly = {
> .use_oif_addrs_only = 0,
> .ignore_routes_with_linkdown = 0,
> .keep_addr_on_down = 0,
> +#ifdef CONFIG_IPV6_SEG6
> + .seg6_enabled = 0,
> +#endif
> };
>
> static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
> @@ -285,6 +288,9 @@ static struct ipv6_devconf ipv6_devconf_dflt __read_mostly = {
> .use_oif_addrs_only = 0,
> .ignore_routes_with_linkdown = 0,
> .keep_addr_on_down = 0,
> +#ifdef CONFIG_IPV6_SEG6
> + .seg6_enabled = 0,
> +#endif
> };
>
> /* Check if a valid qdisc is available */
> @@ -4965,6 +4971,9 @@ static inline void ipv6_store_devconf(struct ipv6_devconf *cnf,
> array[DEVCONF_DROP_UNICAST_IN_L2_MULTICAST] = cnf->drop_unicast_in_l2_multicast;
> array[DEVCONF_DROP_UNSOLICITED_NA] = cnf->drop_unsolicited_na;
> array[DEVCONF_KEEP_ADDR_ON_DOWN] = cnf->keep_addr_on_down;
> +#ifdef CONFIG_IPV6_SEG6
> + array[DEVCONF_SEG6_ENABLED] = cnf->seg6_enabled;
> +#endif
> }
>
> static inline size_t inet6_ifla6_size(void)
> @@ -6056,6 +6065,15 @@ static const struct ctl_table addrconf_sysctl[] = {
> .proc_handler = proc_dointvec,
>
> },
> +#ifdef CONFIG_IPV6_SEG6
> + {
> + .procname = "seg6_enabled",
> + .data = &ipv6_devconf.seg6_enabled,
> + .maxlen = sizeof(int),
> + .mode = 0644,
> + .proc_handler = proc_dointvec,
> + },
> +#endif
> {
> /* sentinel */
> }
> diff --git a/net/ipv6/exthdrs.c b/net/ipv6/exthdrs.c
> index 139ceb6..b31f811 100644
> --- a/net/ipv6/exthdrs.c
> +++ b/net/ipv6/exthdrs.c
> @@ -47,6 +47,9 @@
> #if IS_ENABLED(CONFIG_IPV6_MIP6)
> #include <net/xfrm.h>
> #endif
> +#ifdef CONFIG_IPV6_SEG6
> +#include <linux/seg6.h>
> +#endif
>
> #include <linux/uaccess.h>
>
> @@ -286,6 +289,137 @@ static int ipv6_destopt_rcv(struct sk_buff *skb)
> return -1;
> }
>
> +#ifdef CONFIG_IPV6_SEG6
> +static int ipv6_srh_rcv(struct sk_buff *skb)
> +{
> + struct in6_addr *addr = NULL, *last_addr = NULL, *active_addr = NULL;
> + struct inet6_skb_parm *opt = IP6CB(skb);
> + struct net *net = dev_net(skb->dev);
> + struct ipv6_sr_hdr *hdr;
> + struct inet6_dev *idev;
> + int cleanup = 0;
> + int accept_seg6;
> +
> + hdr = (struct ipv6_sr_hdr *)skb_transport_header(skb);
> +
> + idev = __in6_dev_get(skb->dev);
> +
> + accept_seg6 = net->ipv6.devconf_all->seg6_enabled;
> + if (accept_seg6 > idev->cnf.seg6_enabled)
> + accept_seg6 = idev->cnf.seg6_enabled;
> +
> + if (!accept_seg6) {
> + kfree_skb(skb);
> + return -1;
> + }
> +
> +looped_back:
> + last_addr = hdr->segments;
> +
> + if (hdr->segments_left > 0) {
> + if (hdr->nexthdr != NEXTHDR_IPV6 && hdr->segments_left == 1 &&
> + sr_get_flags(hdr) & SR6_FLAG_CLEANUP)
> + cleanup = 1;
> + } else {
> + if (hdr->nexthdr == NEXTHDR_IPV6) {
> + int offset = (hdr->hdrlen + 1) << 3;
> +
> + if (!pskb_pull(skb, offset)) {
> + kfree_skb(skb);
> + return -1;
> + }
> + skb_postpull_rcsum(skb, skb_transport_header(skb),
> + offset);
> +
> + skb_reset_network_header(skb);
> + skb_reset_transport_header(skb);
> + skb->encapsulation = 0;
> +
> + __skb_tunnel_rx(skb, skb->dev, net);
> +
> + netif_rx(skb);
> + return -1;
> + }
> +
> + opt->srcrt = skb_network_header_len(skb);
> + opt->lastopt = opt->srcrt;
> + skb->transport_header += (hdr->hdrlen + 1) << 3;
> + opt->nhoff = (&hdr->nexthdr) - skb_network_header(skb);
> +
> + return 1;
> + }
> +
> + if (skb_cloned(skb)) {
> + if (pskb_expand_head(skb, 0, 0, GFP_ATOMIC)) {
> + __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
> + IPSTATS_MIB_OUTDISCARDS);
> + kfree_skb(skb);
> + return -1;
> + }
> + }
> +
> + if (skb->ip_summed == CHECKSUM_COMPLETE)
> + skb->ip_summed = CHECKSUM_NONE;
> +
Because the packet is being changed? Would it make sense to update the
checksum complete value based on the changes being made. Consider the
case that the next hop is local to the host (someone may try to
implement network virtualization this way).
> + hdr = (struct ipv6_sr_hdr *)skb_transport_header(skb);
> +
> + active_addr = hdr->segments + hdr->segments_left;
> + hdr->segments_left--;
> + addr = hdr->segments + hdr->segments_left;
> +
> + ipv6_hdr(skb)->daddr = *addr;
> +
> + skb_push(skb, sizeof(struct ipv6hdr));
> +
> + if (cleanup) {
> + int srhlen = (hdr->hdrlen + 1) << 3;
> + int nh = hdr->nexthdr;
> +
> + memmove(skb_network_header(skb) + srhlen,
> + skb_network_header(skb),
> + (unsigned char *)hdr - skb_network_header(skb));
> + skb_pull(skb, srhlen);
> + skb->network_header += srhlen;
> + ipv6_hdr(skb)->nexthdr = nh;
> + ipv6_hdr(skb)->payload_len = htons(skb->len -
> + sizeof(struct ipv6hdr));
> + }
> +
> + skb_dst_drop(skb);
> +
> + ip6_route_input(skb);
> +
> + if (skb_dst(skb)->error) {
> + dst_input(skb);
> + return -1;
> + }
> +
> + if (skb_dst(skb)->dev->flags & IFF_LOOPBACK) {
> + if (ipv6_hdr(skb)->hop_limit <= 1) {
> + __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
> + IPSTATS_MIB_INHDRERRORS);
> + icmpv6_send(skb, ICMPV6_TIME_EXCEED,
> + ICMPV6_EXC_HOPLIMIT, 0);
> + kfree_skb(skb);
> + return -1;
> + }
> + ipv6_hdr(skb)->hop_limit--;
> +
> + /* be sure that srh is still present before reinjecting */
> + if (!cleanup) {
> + skb_pull(skb, sizeof(struct ipv6hdr));
> + goto looped_back;
> + }
> + skb_set_transport_header(skb, sizeof(struct ipv6hdr));
> + IP6CB(skb)->nhoff = offsetof(struct ipv6hdr, nexthdr);
> + }
> +
> + dst_input(skb);
> +
> + return -1;
> +}
> +#endif
> +
> /********************************
> Routing header.
> ********************************/
> @@ -326,6 +460,12 @@ static int ipv6_rthdr_rcv(struct sk_buff *skb)
> return -1;
> }
>
> +#ifdef CONFIG_IPV6_SEG6
> + /* segment routing */
> + if (hdr->type == IPV6_SRCRT_TYPE_4)
> + return ipv6_srh_rcv(skb);
> +#endif
This doesn't belong in one of the switch statements in ipv6_rthdr_rcv?
> +
> looped_back:
> if (hdr->segments_left == 0) {
> switch (hdr->type) {
> --
> 2.7.3
>
^ permalink raw reply
* Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
From: Jakub Kicinski @ 2016-10-17 17:00 UTC (permalink / raw)
To: David Miller; +Cc: jarod, linux-kernel, netdev
In-Reply-To: <20161017.124954.360760874377344385.davem@davemloft.net>
On Mon, 17 Oct 2016 12:49:54 -0400 (EDT), David Miller wrote:
> From: Jakub Kicinski <kubakici@wp.pl>
> Date: Mon, 17 Oct 2016 17:20:06 +0100
>
> > Please correct me if I'm wrong but it seems like we are now limiting
> > _all_ ethernet drivers to ETH_DATA_LEN in net-next.
>
> No, because the driver can increase the netdev->max_mtu value as needed.
But since almost no driver is doing that, yet, right now in net-next
jumbo frames are not possible, no? I thought the idea was the leave
the value at 0 so drivers can opt-in as needed but since setup_ether()
is initializing to 1500 now all ethernet driver get a default of
limiting to 1500.
IOW this patch made checks which were done only in eth_change_mtu()
mandatory for all drivers.
^ permalink raw reply
* Re: [ANNOUNCE] bridge-utils 1.6 release
From: Alexander Alemayhu @ 2016-10-17 16:59 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, linux-kernel
In-Reply-To: <20161017090330.270fe160@xeon-e3>
On Mon, Oct 17, 2016 at 09:03:30AM -0700, Stephen Hemminger wrote:
>
> Source:
> http://www.kernel.org/pub/linux/utils/net/bridge-utils/bridge-utils.1.6.tar.gz
>
This link seems to be broken.
--
Mit freundlichen Grüßen
Alexander Alemayhu
^ permalink raw reply
* Re: [PATCH 1/2] dwc_eth_qos: do not clear pause flags from phy_device->supported
From: David Miller @ 2016-10-17 16:53 UTC (permalink / raw)
To: niklas.cassel; +Cc: larper, netdev, linux-kernel, niklass
In-Reply-To: <1476685548-15574-1-git-send-email-niklass@axis.com>
From: Niklas Cassel <niklas.cassel@axis.com>
Date: Mon, 17 Oct 2016 08:25:48 +0200
> From: Niklas Cassel <niklas.cassel@axis.com>
>
> phy_device->supported is originally set by the PHY driver.
> The ethernet driver should filter phy_device->supported to only contain
> flags supported by the IP.
> The IP supports setting rx and tx flow control independently,
> therefore SUPPORTED_Pause and SUPPORTED_Asym_Pause should not be cleared.
> If the flags are cleared, pause frames cannot be enabled (even if they
> are supported by the PHY).
>
> Signed-off-by: Niklas Cassel <niklas.cassel@axis.com>
> Signed-off-by: Lars Persson <larper@axis.com>
These two patches do not apply to the current 'net' tree, please respin.
^ permalink raw reply
* [PATCH] e1000e: x86: e1000 driver trying to free already-free irq.
From: David Singleton @ 2016-10-17 16:51 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: khalidm, intel-wired-lan, netdev, linux-kernel
From: khalidm <khalidm@cisco.com>
During systemd reboot sequence network driver interface is shutdown
by e1000_close. The PCI driver interface is shut by e1000_shutdown.
The e1000_shutdown checks for netif_running status, if still up it
brings down driver. But it disables msi outside of this if statement,
regardless of netif status. All this is OK when e1000_close happens
after shutdown. However, by default, everything in systemd is done
in parallel. This creates a conditions where e1000_shutdown is called
after e1000_close, therefore hitting BUG_ON assert in free_msi_irqs.
Cc-Id: xe-kernel@external.cisco.com
Signed-off-by: khalidm <khalidm@cisco.com>
Signed-off-by: David Singleton <davsingl@cisco.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 7017281..79f02a6 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -6283,8 +6283,8 @@ static int e1000e_pm_freeze(struct device *dev)
/* Quiesce the device without resetting the hardware */
e1000e_down(adapter, false);
e1000_free_irq(adapter);
+ e1000e_reset_interrupt_capability(adapter);
}
- e1000e_reset_interrupt_capability(adapter);
/* Allow time for pending master requests to run */
e1000e_disable_pcie_master(&adapter->hw);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
From: David Miller @ 2016-10-17 16:49 UTC (permalink / raw)
To: kubakici; +Cc: jarod, linux-kernel, netdev
In-Reply-To: <20161017172006.4d549daa@jkicinski-Precision-T1700>
From: Jakub Kicinski <kubakici@wp.pl>
Date: Mon, 17 Oct 2016 17:20:06 +0100
> Please correct me if I'm wrong but it seems like we are now limiting
> _all_ ethernet drivers to ETH_DATA_LEN in net-next.
No, because the driver can increase the netdev->max_mtu value as needed.
^ permalink raw reply
* [PATCH net] bnx2: fix locking when netconsole is used
From: Ivan Vecera @ 2016-10-17 16:20 UTC (permalink / raw)
To: netdev; +Cc: Sony Chacko, Dept-HSGLinuxNICDev
Functions bnx2_reg_rd_ind(), bnx2_reg_wr_ind() and bnx2_ctx_wr()
can be called with IRQs disabled when netconsole is enabled. So they
should use spin_{,un}lock_irq{save,restore} instead of _bh variants.
Example call flow:
bnx2_poll()
->bnx2_poll_link()
->bnx2_phy_int()
->bnx2_set_remote_link()
->bnx2_shmem_rd()
->bnx2_reg_rd_ind()
-> spin_lock_bh(&bp->indirect_lock);
spin_unlock_bh(&bp->indirect_lock);
...
-> __local_bh_enable_ip
static inline void __local_bh_enable_ip(unsigned long ip)
WARN_ON_ONCE(in_irq() || irqs_disabled()); <<<<<< WARN
Cc: Sony Chacko <sony.chacko@qlogic.com>
Cc: Dept-HSGLinuxNICDev@qlogic.com
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 27f11a5..9c408413 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -272,21 +272,24 @@ static u32
bnx2_reg_rd_ind(struct bnx2 *bp, u32 offset)
{
u32 val;
+ unsigned long flags;
- spin_lock_bh(&bp->indirect_lock);
+ spin_lock_irqsave(&bp->indirect_lock, flags);
BNX2_WR(bp, BNX2_PCICFG_REG_WINDOW_ADDRESS, offset);
val = BNX2_RD(bp, BNX2_PCICFG_REG_WINDOW);
- spin_unlock_bh(&bp->indirect_lock);
+ spin_unlock_irqrestore(&bp->indirect_lock, flags);
return val;
}
static void
bnx2_reg_wr_ind(struct bnx2 *bp, u32 offset, u32 val)
{
- spin_lock_bh(&bp->indirect_lock);
+ unsigned long flags;
+
+ spin_lock_irqsave(&bp->indirect_lock, flags);
BNX2_WR(bp, BNX2_PCICFG_REG_WINDOW_ADDRESS, offset);
BNX2_WR(bp, BNX2_PCICFG_REG_WINDOW, val);
- spin_unlock_bh(&bp->indirect_lock);
+ spin_unlock_irqrestore(&bp->indirect_lock, flags);
}
static void
@@ -304,8 +307,10 @@ bnx2_shmem_rd(struct bnx2 *bp, u32 offset)
static void
bnx2_ctx_wr(struct bnx2 *bp, u32 cid_addr, u32 offset, u32 val)
{
+ unsigned long flags;
+
offset += cid_addr;
- spin_lock_bh(&bp->indirect_lock);
+ spin_lock_irqsave(&bp->indirect_lock, flags);
if (BNX2_CHIP(bp) == BNX2_CHIP_5709) {
int i;
@@ -322,7 +327,7 @@ bnx2_ctx_wr(struct bnx2 *bp, u32 cid_addr, u32 offset, u32 val)
BNX2_WR(bp, BNX2_CTX_DATA_ADR, offset);
BNX2_WR(bp, BNX2_CTX_DATA, val);
}
- spin_unlock_bh(&bp->indirect_lock);
+ spin_unlock_irqrestore(&bp->indirect_lock, flags);
}
#ifdef BCM_CNIC
--
2.7.3
^ permalink raw reply related
* Re: [PATCH v3 net-next 2/2] net: deprecate eth_change_mtu, remove usage
From: Jakub Kicinski @ 2016-10-17 16:20 UTC (permalink / raw)
To: Jarod Wilson, David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20161008020434.9691-3-jarod@redhat.com>
On Fri, 7 Oct 2016 22:04:34 -0400, Jarod Wilson wrote:
> @@ -357,6 +356,8 @@ void ether_setup(struct net_device *dev)
> dev->type = ARPHRD_ETHER;
> dev->hard_header_len = ETH_HLEN;
> dev->mtu = ETH_DATA_LEN;
> + dev->min_mtu = ETH_MIN_MTU;
> + dev->max_mtu = ETH_DATA_LEN;
> dev->addr_len = ETH_ALEN;
> dev->tx_queue_len = 1000; /* Ethernet wants good queues */
> dev->flags = IFF_BROADCAST|IFF_MULTICAST;
This chunk seems to be breaking MTUs > 1500 for me.
On Fri, 7 Oct 2016 22:04:33 -0400, Jarod Wilson wrote:
> diff --git a/net/core/dev.c b/net/core/dev.c
> index f1fe26f..f376639 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6499,9 +6499,18 @@ int dev_set_mtu(struct net_device *dev, int new_mtu)
> if (new_mtu == dev->mtu)
> return 0;
>
> - /* MTU must be positive. */
> - if (new_mtu < 0)
> + /* MTU must be positive, and in range */
> + if (new_mtu < 0 || new_mtu < dev->min_mtu) {
> + net_err_ratelimited("%s: Invalid MTU %d requested, hw min %d\n",
> + dev->name, new_mtu, dev->min_mtu);
> return -EINVAL;
> + }
> +
> + if (dev->max_mtu > 0 && new_mtu > dev->max_mtu) {
> + net_err_ratelimited("%s: Invalid MTU %d requested, hw max %d\n",
> + dev->name, new_mtu, dev->min_mtu);
> + return -EINVAL;
> + }
Please correct me if I'm wrong but it seems like we are now limiting
_all_ ethernet drivers to ETH_DATA_LEN in net-next.
^ permalink raw reply
* [ANNOUNCE] bridge-utils 1.6 release
From: Stephen Hemminger @ 2016-10-17 16:03 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Release of bridge-utils version 1.6
This is the first bridge-utils release in a long time.
There are not any new features, since bridge-utils is deprecated in
favor of bridge command in iproute2. But there are several small
bug fixes and minor cleanups.
Source:
http://www.kernel.org/pub/linux/utils/net/bridge-utils/bridge-utils.1.6.tar.gz
Repository:
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
Report problems (or enhancements) to the netdev@vger.kernel.org mailing list.
---
Andrey Mazo (4):
bridge-utils: Abort compilation on error in any subdirectory
bridge-utils: Remove unused variable in doc/Makefile.in
bridge-utils: AC_OUTPUT should be used without arguments
bridge-utils: Pretty print configure help
David Johnson (1):
bug with older glibc: "brctl show" shows nothing
Kylie McClain (1):
Fix building on musl libc
Russell Senior (1):
bridge-utils: Fix compile against linux-3.8.x
Stephen Hemminger (10):
Fix incorrect command in manual
Fix error message for incorrect command
Check error returns from write to sysfs
Fix typo's on man page
update email address
ignore build files
Clean up autoconf debris when doing make maintainer-clean
brctl: better error handling
man: add obsolete notice to man page
bridge-utils 1.6 release
Xiaochen Wang (1):
skip . and .. in accurately in isbridge()
Yegor Yefremov (1):
rename configure.in to configure.ac
^ permalink raw reply
* [PATCH v5 4/4] net: phy: leds: add support for led triggers on phy link state change
From: Zach Brown @ 2016-10-17 15:49 UTC (permalink / raw)
To: f.fainelli
Cc: devel, florian.c.schilhabel, andrew, netdev, linux-kernel,
rpurdie, gregkh, Larry.Finger, j.anaszewski, linux-leds, mlindner
In-Reply-To: <1476719395-28273-1-git-send-email-zach.brown@ni.com>
Create an option CONFIG_LED_TRIGGER_PHY (default n), which will create a
set of led triggers for each instantiated PHY device. There is one LED
trigger per link-speed, per-phy.
The triggers are registered during phy_attach and unregistered during
phy_detach.
This allows for a user to configure their system to allow a set of LEDs
not controlled by the phy to represent link state changes on the phy.
LEDS controlled by the phy are unaffected.
For example, we have a board where some of the leds in the
RJ45 socket are controlled by the phy, but others are not. Using the
triggers provided by this patch the leds not controlled by the phy can
be configured to show the current speed of the ethernet connection. The
leds controlled by the phy are unaffected.
Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Signed-off-by: Nathan Sullivan <nathan.sullivan@ni.com>
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
drivers/net/phy/Kconfig | 13 ++++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 1 +
drivers/net/phy/phy_device.c | 5 ++
drivers/net/phy/phy_led_triggers.c | 136 +++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 7 ++
include/linux/phy_led_triggers.h | 51 ++++++++++++++
7 files changed, 214 insertions(+)
create mode 100644 drivers/net/phy/phy_led_triggers.c
create mode 100644 include/linux/phy_led_triggers.h
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 5078a0d..54c8eb8 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -15,6 +15,19 @@ if PHYLIB
config SWPHY
bool
+config LED_TRIGGER_PHY
+ bool "Support LED triggers for tracking link state"
+ depends on LEDS_TRIGGERS
+ ---help---
+ Adds support for a set of LED trigger events per-PHY. Link
+ state change will trigger the events, for consumption by an
+ LED class driver. There are triggers for each link speed currently
+ supported by the phy, and are of the form:
+ <mii bus id>:<phy>:<speed>
+
+ Where speed is in the form:
+ <Speed in megabits>Mbps or <Speed in gigabits>Gbps
+
comment "MDIO bus device drivers"
config MDIO_BCM_IPROC
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index e58667d..86d12cd 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -2,6 +2,7 @@
libphy-y := phy.o phy_device.o mdio_bus.o mdio_device.o
libphy-$(CONFIG_SWPHY) += swphy.o
+libphy-$(CONFIG_LED_TRIGGER_PHY) += phy_led_triggers.o
obj-$(CONFIG_PHYLIB) += libphy.o
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index 82ee233..ef0e3d0 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -931,6 +931,7 @@ EXPORT_SYMBOL(phy_start);
static void phy_adjust_link(struct phy_device *phydev)
{
phydev->adjust_link(phydev->attached_dev);
+ phy_led_trigger_change_speed(phydev);
}
/**
diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e977ba9..b41ebd5 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -30,6 +30,7 @@
#include <linux/mii.h>
#include <linux/ethtool.h>
#include <linux/phy.h>
+#include <linux/phy_led_triggers.h>
#include <linux/mdio.h>
#include <linux/io.h>
#include <linux/uaccess.h>
@@ -916,6 +917,8 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
else
phy_resume(phydev);
+ phy_led_triggers_register(phydev);
+
return err;
error:
@@ -989,6 +992,8 @@ void phy_detach(struct phy_device *phydev)
}
}
+ phy_led_triggers_unregister(phydev);
+
/*
* The phydev might go away on the put_device() below, so avoid
* a use-after-free bug by reading the underlying bus first.
diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
new file mode 100644
index 0000000..cda600a
--- /dev/null
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -0,0 +1,136 @@
+/* Copyright (C) 2016 National Instruments Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include <linux/leds.h>
+#include <linux/phy.h>
+#include <linux/netdevice.h>
+
+static struct phy_led_trigger *phy_speed_to_led_trigger(struct phy_device *phy,
+ unsigned int speed)
+{
+ unsigned int i;
+
+ for (i = 0; i < phy->phy_num_led_triggers; i++) {
+ if (phy->phy_led_triggers[i].speed == speed)
+ return &phy->phy_led_triggers[i];
+ }
+ return NULL;
+}
+
+void phy_led_trigger_change_speed(struct phy_device *phy)
+{
+ struct phy_led_trigger *plt;
+
+ if (!phy->link)
+ goto out_change_speed;
+
+ if (phy->speed == 0)
+ return;
+
+ plt = phy_speed_to_led_trigger(phy, phy->speed);
+ if (!plt) {
+ netdev_alert(phy->attached_dev,
+ "No phy led trigger registered for speed(%d)\n",
+ phy->speed);
+ goto out_change_speed;
+ }
+
+ if (plt != phy->last_triggered) {
+ led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
+ led_trigger_event(&plt->trigger, LED_FULL);
+ phy->last_triggered = plt;
+ }
+ return;
+
+out_change_speed:
+ if (phy->last_triggered) {
+ led_trigger_event(&phy->last_triggered->trigger,
+ LED_OFF);
+ phy->last_triggered = NULL;
+ }
+}
+EXPORT_SYMBOL_GPL(phy_led_trigger_change_speed);
+
+static int phy_led_trigger_register(struct phy_device *phy,
+ struct phy_led_trigger *plt,
+ unsigned int speed)
+{
+ char name_suffix[PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE];
+
+ plt->speed = speed;
+
+ if (speed < SPEED_1000)
+ snprintf(name_suffix, sizeof(name_suffix), "%dMbps", speed);
+ else if (speed == SPEED_2500)
+ snprintf(name_suffix, sizeof(name_suffix), "2.5Gbps");
+ else
+ snprintf(name_suffix, sizeof(name_suffix), "%dGbps",
+ DIV_ROUND_CLOSEST(speed, 1000));
+
+ snprintf(plt->name, sizeof(plt->name), PHY_ID_FMT ":%s",
+ phy->mdio.bus->id, phy->mdio.addr, name_suffix);
+ plt->trigger.name = plt->name;
+
+ return led_trigger_register(&plt->trigger);
+}
+
+static void phy_led_trigger_unregister(struct phy_led_trigger *plt)
+{
+ led_trigger_unregister(&plt->trigger);
+}
+
+int phy_led_triggers_register(struct phy_device *phy)
+{
+ int i, err;
+ unsigned int speeds[50];
+
+ phy->phy_num_led_triggers = phy_supported_speeds(phy, speeds,
+ ARRAY_SIZE(speeds));
+ if (!phy->phy_num_led_triggers)
+ return 0;
+
+ phy->phy_led_triggers = devm_kzalloc(&phy->mdio.dev,
+ sizeof(struct phy_led_trigger) *
+ phy->phy_num_led_triggers,
+ GFP_KERNEL);
+ if (!phy->phy_led_triggers)
+ return -ENOMEM;
+
+ for (i = 0; i < phy->phy_num_led_triggers; i++) {
+ err = phy_led_trigger_register(phy, &phy->phy_led_triggers[i],
+ speeds[i]);
+ if (err)
+ goto out_unreg;
+ }
+
+ phy->last_triggered = NULL;
+ phy_led_trigger_change_speed(phy);
+
+ return 0;
+out_unreg:
+ while (i--)
+ phy_led_trigger_unregister(&phy->phy_led_triggers[i]);
+ devm_kfree(&phy->mdio.dev, phy->phy_led_triggers);
+ return err;
+}
+EXPORT_SYMBOL_GPL(phy_led_triggers_register);
+
+void phy_led_triggers_unregister(struct phy_device *phy)
+{
+ int i;
+
+ for (i = 0; i < phy->phy_num_led_triggers; i++)
+ phy_led_trigger_unregister(&phy->phy_led_triggers[i]);
+
+ devm_kfree(&phy->mdio.dev, phy->phy_led_triggers);
+}
+EXPORT_SYMBOL_GPL(phy_led_triggers_unregister);
diff --git a/include/linux/phy.h b/include/linux/phy.h
index 8761f30..8ecfd75 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -25,6 +25,7 @@
#include <linux/timer.h>
#include <linux/workqueue.h>
#include <linux/mod_devicetable.h>
+#include <linux/phy_led_triggers.h>
#include <linux/atomic.h>
@@ -420,6 +421,12 @@ struct phy_device {
int link_timeout;
+#ifdef CONFIG_LED_TRIGGER_PHY
+ struct phy_led_trigger *phy_led_triggers;
+ unsigned int phy_num_led_triggers;
+ struct phy_led_trigger *last_triggered;
+#endif
+
/*
* Interrupt number for this PHY
* -1 means no interrupt
diff --git a/include/linux/phy_led_triggers.h b/include/linux/phy_led_triggers.h
new file mode 100644
index 0000000..a2daea0
--- /dev/null
+++ b/include/linux/phy_led_triggers.h
@@ -0,0 +1,51 @@
+/* Copyright (C) 2016 National Instruments Corp.
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __PHY_LED_TRIGGERS
+#define __PHY_LED_TRIGGERS
+
+struct phy_device;
+
+#ifdef CONFIG_LED_TRIGGER_PHY
+
+#include <linux/leds.h>
+
+#define PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE 10
+#define PHY_MII_BUS_ID_SIZE (20 - 3)
+
+#define PHY_LINK_LED_TRIGGER_NAME_SIZE (PHY_MII_BUS_ID_SIZE + \
+ FIELD_SIZEOF(struct mdio_device, addr)+\
+ PHY_LED_TRIGGER_SPEED_SUFFIX_SIZE)
+
+struct phy_led_trigger {
+ struct led_trigger trigger;
+ char name[PHY_LINK_LED_TRIGGER_NAME_SIZE];
+ unsigned int speed;
+};
+
+
+extern int phy_led_triggers_register(struct phy_device *phy);
+extern void phy_led_triggers_unregister(struct phy_device *phy);
+extern void phy_led_trigger_change_speed(struct phy_device *phy);
+
+#else
+
+static inline int phy_led_triggers_register(struct phy_device *phy)
+{
+ return 0;
+}
+static inline void phy_led_triggers_unregister(struct phy_device *phy) { }
+static inline void phy_led_trigger_change_speed(struct phy_device *phy) { }
+
+#endif
+
+#endif
--
2.7.4
^ permalink raw reply related
* [PATCH v5 3/4] net: phy: Create phy_supported_speeds function which lists speeds currently supported by a phydevice
From: Zach Brown @ 2016-10-17 15:49 UTC (permalink / raw)
To: f.fainelli
Cc: devel, florian.c.schilhabel, andrew, netdev, linux-kernel,
rpurdie, gregkh, Larry.Finger, j.anaszewski, linux-leds, mlindner
In-Reply-To: <1476719395-28273-1-git-send-email-zach.brown@ni.com>
phy_supported_speeds provides a means to get a list of all the speeds a
phy device currently supports.
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
drivers/net/phy/phy.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/phy.h | 15 +++++++++++++++
2 files changed, 50 insertions(+)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index f5721db..82ee233 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -261,6 +261,41 @@ static inline unsigned int phy_find_valid(unsigned int idx, u32 features)
}
/**
+ * phy_supported_speeds - return all speeds currently supported by a phy device
+ * @phy: The phy device to return supported speeds of.
+ * @speeds: buffer to store supported speeds in.
+ * @size: size of speeds buffer.
+ *
+ * Description: Returns the number of supported speeds, and fills the speeds
+ * buffer with the supported speeds. If speeds buffer is too small to contain
+ * all currently supported speeds, will return as many speeds as can fit.
+ */
+unsigned int phy_supported_speeds(struct phy_device *phy,
+ unsigned int *speeds,
+ unsigned int size)
+{
+ unsigned int count = 0;
+ unsigned int idx = 0;
+
+ while (idx < MAX_NUM_SETTINGS && count < size) {
+ idx = phy_find_valid(idx, phy->supported);
+
+ if (!(settings[idx].setting & phy->supported))
+ break;
+
+ /* Assumes settings are grouped by speed */
+ if ((count == 0) ||
+ (speeds[count - 1] != settings[idx].speed)) {
+ speeds[count] = settings[idx].speed;
+ count++;
+ }
+ idx++;
+ }
+
+ return count;
+}
+
+/**
* phy_check_valid - check if there is a valid PHY setting which matches
* speed, duplex, and feature mask
* @speed: speed to match
diff --git a/include/linux/phy.h b/include/linux/phy.h
index e25f183..8761f30 100644
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -85,6 +85,21 @@ typedef enum {
} phy_interface_t;
/**
+ * phy_supported_speeds - return all speeds currently supported by a phy device
+ * @phy: The phy device to return supported speeds of.
+ * @speeds: buffer to store supported speeds in.
+ * @size: size of speeds buffer.
+ *
+ * Description: Returns the number of supported speeds, and
+ * fills the speeds * buffer with the supported speeds. If speeds buffer is
+ * too small to contain * all currently supported speeds, will return as
+ * many speeds as can fit.
+ */
+unsigned int phy_supported_speeds(struct phy_device *phy,
+ unsigned int *speeds,
+ unsigned int size);
+
+/**
* It maps 'enum phy_interface_t' found in include/linux/phy.h
* into the device tree binding of 'phy-mode', so that Ethernet
* device driver can get phy interface from device tree.
--
2.7.4
^ permalink raw reply related
* [PATCH v5 2/4] net: phy: Encapsulate actions performed during link state changes into function phy_adjust_link
From: Zach Brown @ 2016-10-17 15:49 UTC (permalink / raw)
To: f.fainelli
Cc: devel, florian.c.schilhabel, andrew, netdev, linux-kernel,
rpurdie, gregkh, Larry.Finger, j.anaszewski, linux-leds, mlindner
In-Reply-To: <1476719395-28273-1-git-send-email-zach.brown@ni.com>
During phy state machine state transitions some set of actions should
occur whenever the link state changes. These actions should be
encapsulated into a single function
This patch adds the phy_adjust_link function, which is called whenever
phydev->adjust_link would have been called before. Actions that should
occur whenever the phy link is adjusted can now be added to the
phy_adjust_link function.
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
drivers/net/phy/phy.c | 21 +++++++++++++--------
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index c6f6683..f5721db 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -893,6 +893,11 @@ void phy_start(struct phy_device *phydev)
}
EXPORT_SYMBOL(phy_start);
+static void phy_adjust_link(struct phy_device *phydev)
+{
+ phydev->adjust_link(phydev->attached_dev);
+}
+
/**
* phy_state_machine - Handle the state machine
* @work: work_struct that describes the work to be done
@@ -935,7 +940,7 @@ void phy_state_machine(struct work_struct *work)
if (!phydev->link) {
phydev->state = PHY_NOLINK;
netif_carrier_off(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
break;
}
@@ -948,7 +953,7 @@ void phy_state_machine(struct work_struct *work)
if (err > 0) {
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
} else if (0 == phydev->link_timeout--)
needs_aneg = true;
@@ -975,7 +980,7 @@ void phy_state_machine(struct work_struct *work)
}
phydev->state = PHY_RUNNING;
netif_carrier_on(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
}
break;
case PHY_FORCING:
@@ -991,7 +996,7 @@ void phy_state_machine(struct work_struct *work)
needs_aneg = true;
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
break;
case PHY_RUNNING:
/* Only register a CHANGE if we are polling and link changed
@@ -1020,7 +1025,7 @@ void phy_state_machine(struct work_struct *work)
netif_carrier_off(phydev->attached_dev);
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
if (phy_interrupt_is_valid(phydev))
err = phy_config_interrupt(phydev,
@@ -1030,7 +1035,7 @@ void phy_state_machine(struct work_struct *work)
if (phydev->link) {
phydev->link = 0;
netif_carrier_off(phydev->attached_dev);
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
do_suspend = true;
}
break;
@@ -1054,7 +1059,7 @@ void phy_state_machine(struct work_struct *work)
} else {
phydev->state = PHY_NOLINK;
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
} else {
phydev->state = PHY_AN;
phydev->link_timeout = PHY_AN_TIMEOUT;
@@ -1070,7 +1075,7 @@ void phy_state_machine(struct work_struct *work)
} else {
phydev->state = PHY_NOLINK;
}
- phydev->adjust_link(phydev->attached_dev);
+ phy_adjust_link(phydev);
}
break;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v5 1/4] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace
From: Zach Brown @ 2016-10-17 15:49 UTC (permalink / raw)
To: f.fainelli
Cc: devel, florian.c.schilhabel, andrew, netdev, linux-kernel,
rpurdie, gregkh, Larry.Finger, j.anaszewski, linux-leds, mlindner
In-Reply-To: <1476719395-28273-1-git-send-email-zach.brown@ni.com>
Adding led support for phy causes namespace conflicts for some
phy drivers.
The marvel skge driver declared an enum for representing the states of
Link LED Register. The enum contained constant LED_OFF which conflicted
with declartation found in linux/leds.h.
LED_OFF changed to LED_REG_OFF
Also changed LED_ON to LED_REG_ON to avoid possible future conflict and
for consistency.
Signed-off-by: Zach Brown <zach.brown@ni.com>
---
drivers/net/ethernet/marvell/skge.c | 6 +++---
drivers/net/ethernet/marvell/skge.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/skge.c b/drivers/net/ethernet/marvell/skge.c
index 7173836..783df01 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -1048,7 +1048,7 @@ static const char *skge_pause(enum pause_status status)
static void skge_link_up(struct skge_port *skge)
{
skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG),
- LED_BLK_OFF|LED_SYNC_OFF|LED_ON);
+ LED_BLK_OFF|LED_SYNC_OFF|LED_REG_ON);
netif_carrier_on(skge->netdev);
netif_wake_queue(skge->netdev);
@@ -1062,7 +1062,7 @@ static void skge_link_up(struct skge_port *skge)
static void skge_link_down(struct skge_port *skge)
{
- skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+ skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
netif_carrier_off(skge->netdev);
netif_stop_queue(skge->netdev);
@@ -2668,7 +2668,7 @@ static int skge_down(struct net_device *dev)
if (hw->ports == 1)
free_irq(hw->pdev->irq, hw);
- skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+ skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
if (is_genesis(hw))
genesis_stop(skge);
else
diff --git a/drivers/net/ethernet/marvell/skge.h b/drivers/net/ethernet/marvell/skge.h
index a2eb341..3ea151f 100644
--- a/drivers/net/ethernet/marvell/skge.h
+++ b/drivers/net/ethernet/marvell/skge.h
@@ -662,8 +662,8 @@ enum {
LED_BLK_OFF = 1<<4, /* Link LED Blinking Off */
LED_SYNC_ON = 1<<3, /* Use Sync Wire to switch LED */
LED_SYNC_OFF = 1<<2, /* Disable Sync Wire Input */
- LED_ON = 1<<1, /* switch LED on */
- LED_OFF = 1<<0, /* switch LED off */
+ LED_REG_ON = 1<<1, /* switch LED on */
+ LED_REG_OFF = 1<<0, /* switch LED off */
};
/* Receive GMAC FIFO (YUKON) */
--
2.7.4
^ permalink raw reply related
* [PATCH v5 0/4] Add support for led triggers on phy link state change
From: Zach Brown @ 2016-10-17 15:49 UTC (permalink / raw)
To: f.fainelli
Cc: devel, florian.c.schilhabel, andrew, netdev, linux-kernel,
rpurdie, gregkh, Larry.Finger, j.anaszewski, linux-leds, mlindner
Fix skge driver that declared enum contants that conflicted with enum
constants in linux/leds.h
Create function that encapsulates actions taken during the adjust phy link step
of phy state changes.
Create function that provides list of speeds currently supported by the phy.
Add support for led triggers on phy link state changes by adding
a config option. When set the config option will create a set of led triggers
for each phy device. Users can use the led triggers to represent link state
changes on the phy.
v2:
* New patch that creates phy_adjust_link function to encapsulate actions taken
when adjusting phy link during phy state changes
* led trigger speed strings changed to match existing phy speed strings
* New function that maps speeds to led triggers
* Replace magic constants with definitions when declaring trigger name
buffer and number of triggers.
v3:
* Changed LED_ON to LED_REG_ON in skge driver to avoid possible future
conflict and improve consistency.
* Dropped rtl8712 patch that was accepted separately.
v4:
* tweaked commit message
v5
* Changed commit message to explain relationship between the new triggers and
leds driven by phys.
* Added new patch that creates phy_supported_speeds function.
* Moved phy_leds_triggers_register and phy_leds_triggers_unregister to
phy_attach and phy_detach respectively. This change is so the
phydev->supported field will be filled by the time the triggers are
registered.
* Changed hardcoded list of triggers to dynamic list determined by speeds
return by phy_supported_speeds.
Zach Brown (4):
skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid
conflicts with leds namespace
net: phy: Encapsulate actions performed during link state changes into
function phy_adjust_link
net: phy: Create phy_supported_speeds function which lists speeds
currently supported by a phydevice
net: phy: leds: add support for led triggers on phy link state change
drivers/net/ethernet/marvell/skge.c | 6 +-
drivers/net/ethernet/marvell/skge.h | 4 +-
drivers/net/phy/Kconfig | 13 ++++
drivers/net/phy/Makefile | 1 +
drivers/net/phy/phy.c | 57 ++++++++++++---
drivers/net/phy/phy_device.c | 5 ++
drivers/net/phy/phy_led_triggers.c | 136 ++++++++++++++++++++++++++++++++++++
include/linux/phy.h | 22 ++++++
include/linux/phy_led_triggers.h | 51 ++++++++++++++
9 files changed, 282 insertions(+), 13 deletions(-)
create mode 100644 drivers/net/phy/phy_led_triggers.c
create mode 100644 include/linux/phy_led_triggers.h
--
2.7.4
^ permalink raw reply
* Re: [patch] netfilter: nft_exthdr: fix error handling in nft_exthdr_init()
From: Pablo Neira Ayuso @ 2016-10-17 15:40 UTC (permalink / raw)
To: Dan Carpenter
Cc: Laura Garcia Liebana, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller, netfilter-devel, coreteam, netdev,
kernel-janitors
In-Reply-To: <20161012060912.GF12841@mwanda>
On Wed, Oct 12, 2016 at 09:09:12AM +0300, Dan Carpenter wrote:
> "err" needs to be signed for the error handling to work.
Applied, thanks Dan.
^ permalink raw reply
* Re: [patch v2] netfilter: nf_tables: underflow in nft_parse_u32_check()
From: Pablo Neira Ayuso @ 2016-10-17 15:40 UTC (permalink / raw)
To: Dan Carpenter
Cc: Laura Garcia Liebana, Patrick McHardy, Jozsef Kadlecsik,
David S. Miller, netfilter-devel, coreteam, netdev,
kernel-janitors
In-Reply-To: <20161012091429.GA27317@mwanda>
On Wed, Oct 12, 2016 at 12:14:29PM +0300, Dan Carpenter wrote:
> We don't want to allow negatives here.
Applied, thanks.
^ permalink raw reply
* Re: [Intel-wired-lan] Kernel 4.6.7-rt13: Intel Ethernet driver igb causes huge latencies in cyclictest
From: Alexander Duyck @ 2016-10-17 15:39 UTC (permalink / raw)
To: Koehrer Mathias (ETAS/ESW5)
Cc: Julia Cartwright, Bjorn Helgaas, linux-rt-users@vger.kernel.org,
Sebastian Andrzej Siewior, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, Matthew Garrett, Bjorn Helgaas,
Greg
In-Reply-To: <82dcd5bb210f4f82af1e88313c3ec742@FE-MBX1012.de.bosch.com>
On Mon, Oct 17, 2016 at 8:00 AM, Koehrer Mathias (ETAS/ESW5)
<mathias.koehrer@etas.com> wrote:
> Hi Julia!
>> > > Have you tested on a vanilla (non-RT) kernel? I doubt there is
>> > > anything RT specific about what you are seeing, but it might be nice
>> > > to get confirmation. Also, bisection would probably be easier if you confirm on a
>> vanilla kernel.
>> > >
>> > > I find it unlikely that it's a kernel config option that changed
>> > > which regressed you, but instead was a code change to a driver.
>> > > Which driver is now the question, and the surface area is still big
>> > > (processor mapping attributes for this region, PCI root complex configuration,
>> PCI brige configuration, igb driver itself, etc.).
>> > >
>> > > Big enough that I'd recommend a bisection. It looks like a
>> > > bisection between 3.18 and 4.8 would take you about 18 tries to narrow down,
>> assuming all goes well.
>> > >
>> >
>> > I have now repeated my tests using the vanilla kernel.
>> > There I got the very same issue.
>> > Using kernel 4.0 is fine, however starting with kernel 4.1, the issue appears.
>>
>> Great, thanks for confirming! That helps narrow things down quite a bit.
>>
>> > Here is my exact (reproducible) test description:
>> > I applied the following patch to the kernel to get the igb trace.
>> > This patch instruments the igb_rd32() function to measure the call to
>> > readl() which is used to access registers of the igb NIC.
>>
>> I took your test setup and ran it between 4.0 and 4.1 on the hardware on my desk,
>> which is an Atom-based board with dual I210s, however I didn't see much
>> difference.
>>
>> However, it's a fairly simple board, with a much simpler PCI topology than your
>> workstation. I'll see if I can find some other hardware to test on.
>>
>> [..]
>> > This means, that I think that some other stuff in kernel 4.1 has
>> > changed, which has impact on the igb accesses.
>> >
>> > Any idea what component could cause this kind of issue?
>>
>> Can you continue your bisection using 'git bisect'? You've already narrowed it down
>> between 4.0 and 4.1, so you're well on your way.
>>
>
> OK - done.
> And finally I was successful!
> The following git commit is the one that is causing the trouble!
> (The full commit is in the attachment).
> +++++++++++++++++++++ BEGIN +++++++++++++++++++++++++++
> commit 387d37577fdd05e9472c20885464c2a53b3c945f
> Author: Matthew Garrett <mjg59@coreos.com>
> Date: Tue Apr 7 11:07:00 2015 -0700
>
> PCI: Don't clear ASPM bits when the FADT declares it's unsupported
>
> Communications with a hardware vendor confirm that the expected behaviour
> on systems that set the FADT ASPM disable bit but which still grant full
> PCIe control is for the OS to leave any BIOS configuration intact and
> refuse to touch the ASPM bits. This mimics the behaviour of Windows.
>
> Signed-off-by: Matthew Garrett <mjg59@coreos.com>
> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
> +++++++++++++++++++++ HEADER +++++++++++++++++++++++++++
>
> The only files that are modified by this commit are
> drivers/acpi/pci_root.c
> drivers/pci/pcie/aspm.c
> include/linux/pci-aspm.h
>
> This is all generic PCIe stuff - however I do not really understand what
> the changes of the commit are...
>
> In my setup I am using a dual port igb Ethernet adapter.
> This has an onboard PCIe switch and it might be that the configuration of this
> PCIe switch on the Intel board is causing the trouble.
>
> Please see also the output of "lspci -v" in the attachment.
> The relevant PCI address of the NIC is 04:00.0 / 04:00.1
>
> Any feedback on this is welcome!
>
> Thanks
>
> Mathias
Hi Mathias,
If you could set the output of lspci -vvv it might be more useful as
most of the configuration data isn't present in the lspci dump you had
attached. Specifically if you could do this for the working case and
the non-working case we could verify if this issue is actually due to
the ASPM configuration on the device.
Also one thing you might try is booting your kernel with the kernel
parameter "pcie_aspm=off". It sounds like the extra latency is likely
due to your platform enabling ASPM on the device and this in turn will
add latency if the PCIe link is disabled when you attempt to perform a
read as it takes some time to bring the PCIe link up when in L1 state.
Thanks for bisecting this.
- Alex
^ permalink raw reply
* Re: [PATCH net 1/2] conntrack: remove obsolete sysctl (nf_conntrack_events_retry_timeout)
From: Pablo Neira Ayuso @ 2016-10-17 15:39 UTC (permalink / raw)
To: Florian Westphal; +Cc: Nicolas Dichtel, davem, netdev, netfilter-devel
In-Reply-To: <20161010135737.GA21057@breakpoint.cc>
On Mon, Oct 10, 2016 at 03:57:37PM +0200, Florian Westphal wrote:
> Nicolas Dichtel <nicolas.dichtel@6wind.com> wrote:
> > This entry has been removed in commit 9500507c6138.
> >
> > Fixes: 9500507c6138 ("netfilter: conntrack: remove timer from ecache extension")
> > Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
>
> Acked-by: Florian Westphal <fw@strlen.de>
Applied, thanks Nicolas.
^ permalink raw reply
* Re: [PATCH -next] net: ethernet: nb8800: fix error return code in nb8800_open()
From: Måns Rullgård @ 2016-10-17 15:35 UTC (permalink / raw)
To: Wei Yongjun
Cc: jarod, sf84, peter.chen, tremyfr, arnd, f.fainelli, Wei Yongjun,
netdev
In-Reply-To: <1476718318-28428-1-git-send-email-weiyj.lk@gmail.com>
Wei Yongjun <weiyj.lk@gmail.com> writes:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return error code -ENODEV from the of_phy_connect() error
> handling case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Mans Rullgard <mans@mansr.com>
> ---
> drivers/net/ethernet/aurora/nb8800.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
> index 453dc09..99c4055 100644
> --- a/drivers/net/ethernet/aurora/nb8800.c
> +++ b/drivers/net/ethernet/aurora/nb8800.c
> @@ -975,8 +975,10 @@ static int nb8800_open(struct net_device *dev)
> phydev = of_phy_connect(dev, priv->phy_node,
> nb8800_link_reconfigure, 0,
> priv->phy_mode);
> - if (!phydev)
> + if (!phydev) {
> + err = -ENODEV;
> goto err_free_irq;
> + }
>
> nb8800_pause_adv(dev);
>
--
Måns Rullgård
^ permalink raw reply
* [PATCH -next] net: ethernet: nb8800: fix error return code in nb8800_open()
From: Wei Yongjun @ 2016-10-17 15:31 UTC (permalink / raw)
To: jarod, sf84, peter.chen, mans, tremyfr, arnd, f.fainelli
Cc: Wei Yongjun, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return error code -ENODEV from the of_phy_connect() error
handling case instead of 0, as done elsewhere in this function.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/aurora/nb8800.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
index 453dc09..99c4055 100644
--- a/drivers/net/ethernet/aurora/nb8800.c
+++ b/drivers/net/ethernet/aurora/nb8800.c
@@ -975,8 +975,10 @@ static int nb8800_open(struct net_device *dev)
phydev = of_phy_connect(dev, priv->phy_node,
nb8800_link_reconfigure, 0,
priv->phy_mode);
- if (!phydev)
+ if (!phydev) {
+ err = -ENODEV;
goto err_free_irq;
+ }
nb8800_pause_adv(dev);
^ permalink raw reply related
* Re: [PATCH 2/9] ipv6: sr: add code base for control plane support of SR-IPv6
From: David Miller @ 2016-10-17 15:21 UTC (permalink / raw)
To: david.lebrun; +Cc: netdev
In-Reply-To: <5804E8DE.20200@uclouvain.be>
From: David Lebrun <david.lebrun@uclouvain.be>
Date: Mon, 17 Oct 2016 17:06:06 +0200
> The mutex is not taken, just initialized. Unless mutex_init takes the
> lock, which would be quite strange ?
My bad, I misread the code.
^ permalink raw reply
* [PATCH -next] fsl/fman: fix error return code in mac_probe()
From: Wei Yongjun @ 2016-10-17 15:19 UTC (permalink / raw)
To: Madalin Bucur; +Cc: Wei Yongjun, netdev
From: Wei Yongjun <weiyongjun1@huawei.com>
Fix to return a negative error code from the error handling
case instead of 0, as done elsewhere in this function.
Fixes: 3933961682a3 ("fsl/fman: Add FMan MAC driver")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/freescale/fman/mac.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fman/mac.c b/drivers/net/ethernet/freescale/fman/mac.c
index 8fe6b3e..cc5d07c 100644
--- a/drivers/net/ethernet/freescale/fman/mac.c
+++ b/drivers/net/ethernet/freescale/fman/mac.c
@@ -879,13 +879,17 @@ static int mac_probe(struct platform_device *_of_dev)
priv->fixed_link = kzalloc(sizeof(*priv->fixed_link),
GFP_KERNEL);
- if (!priv->fixed_link)
+ if (!priv->fixed_link) {
+ err = -ENOMEM;
goto _return_dev_set_drvdata;
+ }
priv->phy_node = of_node_get(mac_node);
phy = of_phy_find_device(priv->phy_node);
- if (!phy)
+ if (!phy) {
+ err = -EINVAL;
goto _return_dev_set_drvdata;
+ }
priv->fixed_link->link = phy->link;
priv->fixed_link->speed = phy->speed;
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox