* Re: [PATCH iproute2 net-next] gre: add support for ERSPAN tunnel
From: Stephen Hemminger @ 2017-08-09 21:21 UTC (permalink / raw)
To: William Tu; +Cc: netdev, Alexey Kuznetsov
In-Reply-To: <1502310882-8802-1-git-send-email-u9012063@gmail.com>
On Wed, 9 Aug 2017 13:34:42 -0700
William Tu <u9012063@gmail.com> wrote:
> The patch adds ERSPAN type II tunnel support. The implementation
> is based on the draft at https://tools.ietf.org/html/draft-foschiano-erspan-01
> One of the purposes is for Linux box to be able to receive ERSPAN
> monitoring traffic sent from the Cisco switch, by creating a ERSPAN
> tunnel device. In addition, the patch also adds ERSPAN TX, so traffic
> can also be encapsulated into ERSPAN and sent out.
>
> The implementation reuses the key as ERSPAN session ID, and
> field 'erspan' as ERSPAN Index fields:
> ./ip link add dev ers11 type erspan seq key 100 erspan 123 \
> local 172.16.1.200 remote 172.16.1.100
>
> Signed-off-by: William Tu <u9012063@gmail.com>
> Cc: Stephen Hemminger <stephen@networkplumber.org>
> Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> ---
> include/linux/if_tunnel.h | 1 +
> ip/link_gre.c | 26 +++++++++++++++++++++++++-
> 2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/if_tunnel.h b/include/linux/if_tunnel.h
> index 7375335a0773..21834cac4c0d 100644
> --- a/include/linux/if_tunnel.h
> +++ b/include/linux/if_tunnel.h
> @@ -134,6 +134,7 @@ enum {
> IFLA_GRE_COLLECT_METADATA,
> IFLA_GRE_IGNORE_DF,
> IFLA_GRE_FWMARK,
> + IFLA_GRE_ERSPAN_INDEX,
> __IFLA_GRE_MAX,
> };
>
> diff --git a/ip/link_gre.c b/ip/link_gre.c
> index c2ec5f26902f..c28fac1eb5de 100644
> --- a/ip/link_gre.c
> +++ b/ip/link_gre.c
> @@ -26,7 +26,7 @@
> static void print_usage(FILE *f)
> {
> fprintf(f,
> - "Usage: ... { gre | gretap } [ remote ADDR ]\n"
> + "Usage: ... { gre | gretap | erspan } [ remote ADDR ]\n"
> " [ local ADDR ]\n"
> " [ [i|o]seq ]\n"
> " [ [i|o]key KEY ]\n"
> @@ -44,6 +44,7 @@ static void print_usage(FILE *f)
> " [ [no]encap-csum6 ]\n"
> " [ [no]encap-remcsum ]\n"
> " [ fwmark MARK ]\n"
> + " [ erspan IDX ]\n"
> "\n"
> "Where: ADDR := { IP_ADDRESS | any }\n"
> " TOS := { NUMBER | inherit }\n"
> @@ -96,6 +97,7 @@ static int gre_parse_opt(struct link_util *lu, int argc, char **argv,
> __u8 metadata = 0;
> __u8 ignore_df = 0;
> __u32 fwmark = 0;
> + __u32 erspan_idx = 0;
>
> if (!(n->nlmsg_flags & NLM_F_CREATE)) {
> if (rtnl_talk(&rth, &req.n, &req.n, sizeof(req)) < 0) {
> @@ -172,6 +174,9 @@ get_failed:
>
> if (greinfo[IFLA_GRE_FWMARK])
> fwmark = rta_getattr_u32(greinfo[IFLA_GRE_FWMARK]);
> +
> + if (greinfo[IFLA_GRE_ERSPAN_INDEX])
> + erspan_idx = rta_getattr_u32(greinfo[IFLA_GRE_ERSPAN_INDEX]);
> }
>
> while (argc > 0) {
> @@ -328,6 +333,10 @@ get_failed:
> NEXT_ARG();
> if (get_u32(&fwmark, *argv, 0))
> invarg("invalid fwmark\n", *argv);
> + } else if (strcmp(*argv, "erspan") == 0) {
> + NEXT_ARG();
> + if (get_u32(&erspan_idx, *argv, 0))
> + invarg("invalid erspan index\n", *argv);
> } else
> usage();
> argc--; argv++;
> @@ -359,6 +368,7 @@ get_failed:
> addattr_l(n, 1024, IFLA_GRE_TTL, &ttl, 1);
> addattr_l(n, 1024, IFLA_GRE_TOS, &tos, 1);
> addattr32(n, 1024, IFLA_GRE_FWMARK, fwmark);
> + addattr32(n, 1024, IFLA_GRE_ERSPAN_INDEX, htonl(erspan_idx));
If erspan_idx is zero, then you probably shouldn't send it to kernel.
Also you need to update manual pages.
^ permalink raw reply
* Re: [RFC PATCH] net: don't set __LINK_STATE_START until after dev->open() call
From: David Miller @ 2017-08-09 21:24 UTC (permalink / raw)
To: jacob.e.keller; +Cc: netdev
In-Reply-To: <02874ECE860811409154E81DA85FBB5882A3F62D@ORSMSX115.amr.corp.intel.com>
From: "Keller, Jacob E" <jacob.e.keller@intel.com>
Date: Wed, 9 Aug 2017 20:00:55 +0000
> That's what I am worried about. However, I think there are problems
> with leaving it. A lot of drivers rely on netif_running() to
> determine whether or not the device is open, but they may be using
> it relying on all the changes caused by the .ndo_open() handler are
> finished. The current system there is a race, since you set the
> __LINK_STATE_START before .ndo_open is called.
I think this is only a half-accurate description.
What drivers want to know is if initialization phase X of ndo_open()
has completed.
And honestly it must be like this because this is what one would
use to guide the teardown during failure paths of ndo_open(), right?
So I would really rather drivers internally track this "I initialized
X" state, as most drivers do, rather than take the risk of changing
the netif_running() behavior which can impact ~500 drivers :-)
^ permalink raw reply
* Re: [PATCH net-next 1/9] bpf: add BPF_J{LT,LE,SLT,SLE} instructions
From: David Miller @ 2017-08-09 21:26 UTC (permalink / raw)
To: daniel; +Cc: ast, holzheu, naveen.n.rao, jakub.kicinski, netdev
In-Reply-To: <598B7162.90509@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 09 Aug 2017 22:32:34 +0200
> For the case of cilium, we are not in control of the kernel, by
> the way, we run a few probes that are small BPF insns snippets
> that test the kernel for presence of certain features (e.g. helper,
> verifier, maps) and enable/disable them accordingly later in the
> code generation. On the user space side, we're indeed a bit more
> flexible and have no such restriction.
>
> Plan is for LLVM as one of the frontends that generate byte code
> (ply, for example, can probe the kernel directly for its code
> generation) to have i) a target specific option to offer a
> possibility to explicitly enable the extension by the user (as we
> have with -m target specific extensions today for various cpu
> insns), and ii) have the kernel check for presence of the extensions
> and enable it transparently when the user selects more aggressive
> options such as -march=native in a bpf target context, so we can
> select the underlying features transparently. I should have made
> that more clear earlier, sorry about that.
I think this explanation needs to be in either your header posting
or the commit message of patch #1.
Thanks :)
^ permalink raw reply
* Re: [PATCH net-next 1/9] bpf: add BPF_J{LT,LE,SLT,SLE} instructions
From: Daniel Borkmann @ 2017-08-09 21:29 UTC (permalink / raw)
To: David Miller; +Cc: ast, holzheu, naveen.n.rao, jakub.kicinski, netdev
In-Reply-To: <20170809.142600.872268659837843440.davem@davemloft.net>
On 08/09/2017 11:26 PM, David Miller wrote:
> From: Daniel Borkmann <daniel@iogearbox.net>
> Date: Wed, 09 Aug 2017 22:32:34 +0200
>
>> For the case of cilium, we are not in control of the kernel, by
>> the way, we run a few probes that are small BPF insns snippets
>> that test the kernel for presence of certain features (e.g. helper,
>> verifier, maps) and enable/disable them accordingly later in the
>> code generation. On the user space side, we're indeed a bit more
>> flexible and have no such restriction.
>>
>> Plan is for LLVM as one of the frontends that generate byte code
>> (ply, for example, can probe the kernel directly for its code
>> generation) to have i) a target specific option to offer a
>> possibility to explicitly enable the extension by the user (as we
>> have with -m target specific extensions today for various cpu
>> insns), and ii) have the kernel check for presence of the extensions
>> and enable it transparently when the user selects more aggressive
>> options such as -march=native in a bpf target context, so we can
>> select the underlying features transparently. I should have made
>> that more clear earlier, sorry about that.
>
> I think this explanation needs to be in either your header posting
> or the commit message of patch #1.
>
> Thanks :)
Ok, sure, I'll do a v2 with that included. Thanks!
^ permalink raw reply
* [PATCH net-next] phylink: Fix an uninitialized variable bug
From: Dan Carpenter @ 2017-08-09 21:35 UTC (permalink / raw)
To: Andrew Lunn, Russell King; +Cc: Florian Fainelli, netdev, kernel-janitors
"ret" isn't necessarily initialized here.
Fixes: 9525ae83959b ("phylink: add phylink infrastructure")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
index 32917bdd1432..bcb4755bcd95 100644
--- a/drivers/net/phy/phylink.c
+++ b/drivers/net/phy/phylink.c
@@ -958,7 +958,7 @@ int phylink_ethtool_ksettings_set(struct phylink *pl,
}
mutex_unlock(&pl->state_mutex);
- return ret;
+ return 0;
}
EXPORT_SYMBOL_GPL(phylink_ethtool_ksettings_set);
^ permalink raw reply related
* RE: [PATCH net] net: dsa: ksz: fix skb freeing
From: Woojung.Huh @ 2017-08-09 21:43 UTC (permalink / raw)
To: vivien.didelot, netdev; +Cc: linux-kernel, kernel, davem, f.fainelli, andrew
In-Reply-To: <20170809204609.8114-1-vivien.didelot@savoirfairelinux.com>
> The DSA layer frees the original skb when an xmit function returns NULL,
> meaning an error occurred. But if the tagging code copied the original
> skb, it is responsible of freeing the copy if an error occurs.
>
> The ksz tagging code currently has two issues: if skb_put_padto fails,
> the skb copy is not freed, and the original skb will be freed twice.
>
> To fix that, move skb_put_padto inside both branches of the skb_tailroom
> condition, before freeing the original skb, and free the copy on error.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Reviewed-by: Woojung Huh <woojung.huh@microchip.com>
^ permalink raw reply
* [net-next 00/12][pull request] 1GbE Intel Wired LAN Driver Updates 2017-08-08
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, nhorman, sassmann, jogreene
This series contains updates to e1000e and igb/igbvf.
Gangfeng Huang fixes an issue with receive network flow classification,
where igb_nfc_filter_exit() was not being called in igb_down() which
would cause the filter tables to "fill up" if a user where to change
the adapter settings (such as speed) which requires a reset of the
adapter.
Cliff Spradlin fixes a timestamping issue, where igb was allowing requests
for hardware timestamping even if it was not configured for hardware
transmit timestamping.
Corinna Vinschen removes the error message that there was an "unexpected
SYS WRAP", when it is actually expected. So remove the message to not
confuse users.
Greg Edwards provides several patches for the mailbox interface between
the PF and VF drivers. Added a mailbox unlock method to be used to unlock
the PF/VF mailbox by the PF. Added a lock around the VF mailbox ops to
prevent the VF from sending another message while the PF is still
processing the previous message. Fixed a "scheduling while atomic" issue
by changing msleep() to mdelay().
Sasha adds support for the next LOM generations i219 (v8 & v9) which
will be available in the next Intel client platform IceLake.
John Linville adds support for a Broadcom PHY to the igb driver, since
there are designs out in the world which use the igb MAC and a third
party PHY. This allows the driver to load and function as expected on
these designs.
The following are changes since commit 53b948356554376ec6f89016376825d48bf396c3:
net: vrf: Add extack messages for newlink failures
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue 1GbE
Cliff Spradlin (1):
igb: protect TX timestamping from API misuse
Corinna Vinschen (1):
igb: Remove incorrect "unexpected SYS WRAP" log message
Gangfeng Huang (1):
igb: Fix error of RX network flow classification
Greg Edwards (6):
igb: add argument names to mailbox op function declarations
igb: expose mailbox unlock method
igb: do not drop PF mailbox lock after read of VF message
igbvf: add lock around mailbox ops
igbvf: after mailbox write, wait for reply
igbvf: convert msleep to mdelay in atomic context
Gustavo A R Silva (1):
e1000e: add check on e1e_wphy() return value
John W Linville (1):
igb: support BCM54616 PHY
Sasha Neftin (1):
e1000e: Initial Support for IceLake
drivers/net/ethernet/intel/e1000e/hw.h | 4 ++
drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 +
drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++
drivers/net/ethernet/intel/igb/e1000_82575.c | 6 +++
drivers/net/ethernet/intel/igb/e1000_defines.h | 1 +
drivers/net/ethernet/intel/igb/e1000_hw.h | 18 ++++----
drivers/net/ethernet/intel/igb/e1000_mbx.c | 57 +++++++++++++++++++++++---
drivers/net/ethernet/intel/igb/e1000_mbx.h | 14 ++++---
drivers/net/ethernet/intel/igb/igb_main.c | 23 +++++++----
drivers/net/ethernet/intel/igbvf/ethtool.c | 4 ++
drivers/net/ethernet/intel/igbvf/mbx.c | 4 ++
drivers/net/ethernet/intel/igbvf/netdev.c | 47 +++++++++++++++++++++
drivers/net/ethernet/intel/igbvf/vf.c | 12 ++++--
drivers/net/ethernet/intel/igbvf/vf.h | 1 +
14 files changed, 166 insertions(+), 31 deletions(-)
--
2.13.3
^ permalink raw reply
* [net-next 01/12] igb: Fix error of RX network flow classification
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Gangfeng Huang, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Gangfeng Huang <gangfeng.huang@ni.com>
After add an ethertype filter, if user change the adapter speed several
times, the error "ethtool -N: etype filters are all used" is reported by
igb driver.
In older patch, function igb_nfc_filter_exit() and igb_nfc_filter_restore()
is not paried. igb_nfc_filter_restore() exist in igb_up(), but function
igb_nfc_filter_exit() is exist in __igb_close(). In the process of speed
changing, only igb_nfc_filter_restore() is called, it will take a position
of ethertype bitmap.
Reproduce steps:
Step 1: Add a etype filter by ethtool
$ethtool -N eth0 flow-type ether proto 0x88F8 action 1
Step 2: Change the adapter speed to 100M/full duplex
$ethtool -s eth0 speed 100 duplex full
Step 3: Change the adapter speed to 1000M/full duplex
ethtool -s eth0 speed 1000 duplex full
Repeat step2 and step3, then dmesg the system log, you can find the error
message, add new ethtype filter is also failed.
This fixing is move igb_nfc_filter_exit() from __igb_close() to igb_down()
to make igb_nfc_filter_restore()/igb_nfc_filter_exit() is paired.
Signed-off-by: Gangfeng Huang <gangfeng.huang@ni.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index ec62410b035a..6a63ea564a57 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1791,6 +1791,8 @@ void igb_down(struct igb_adapter *adapter)
wr32(E1000_RCTL, rctl & ~E1000_RCTL_EN);
/* flush and sleep below */
+ igb_nfc_filter_exit(adapter);
+
netif_carrier_off(netdev);
netif_tx_stop_all_queues(netdev);
@@ -3317,8 +3319,6 @@ static int __igb_close(struct net_device *netdev, bool suspending)
igb_down(adapter);
igb_free_irq(adapter);
- igb_nfc_filter_exit(adapter);
-
igb_free_all_tx_resources(adapter);
igb_free_all_rx_resources(adapter);
--
2.13.3
^ permalink raw reply related
* [net-next 05/12] igb: add argument names to mailbox op function declarations
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Greg Edwards, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Greg Edwards <gedwards@ddn.com>
Signed-off-by: Greg Edwards <gedwards@ddn.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_hw.h | 15 ++++++++-------
drivers/net/ethernet/intel/igb/e1000_mbx.h | 12 ++++++------
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h b/drivers/net/ethernet/intel/igb/e1000_hw.h
index 2fb2213cd562..fd7865a8d2e3 100644
--- a/drivers/net/ethernet/intel/igb/e1000_hw.h
+++ b/drivers/net/ethernet/intel/igb/e1000_hw.h
@@ -491,13 +491,14 @@ struct e1000_fc_info {
struct e1000_mbx_operations {
s32 (*init_params)(struct e1000_hw *hw);
- s32 (*read)(struct e1000_hw *, u32 *, u16, u16);
- s32 (*write)(struct e1000_hw *, u32 *, u16, u16);
- s32 (*read_posted)(struct e1000_hw *, u32 *, u16, u16);
- s32 (*write_posted)(struct e1000_hw *, u32 *, u16, u16);
- s32 (*check_for_msg)(struct e1000_hw *, u16);
- s32 (*check_for_ack)(struct e1000_hw *, u16);
- s32 (*check_for_rst)(struct e1000_hw *, u16);
+ s32 (*read)(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
+ s32 (*write)(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
+ s32 (*read_posted)(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
+ s32 (*write_posted)(struct e1000_hw *hw, u32 *msg, u16 size,
+ u16 mbx_id);
+ s32 (*check_for_msg)(struct e1000_hw *hw, u16 mbx_id);
+ s32 (*check_for_ack)(struct e1000_hw *hw, u16 mbx_id);
+ s32 (*check_for_rst)(struct e1000_hw *hw, u16 mbx_id);
};
struct e1000_mbx_stats {
diff --git a/drivers/net/ethernet/intel/igb/e1000_mbx.h b/drivers/net/ethernet/intel/igb/e1000_mbx.h
index 3e7fed73df15..73d90aeb48b2 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mbx.h
+++ b/drivers/net/ethernet/intel/igb/e1000_mbx.h
@@ -67,11 +67,11 @@
#define E1000_PF_CONTROL_MSG 0x0100 /* PF control message */
-s32 igb_read_mbx(struct e1000_hw *, u32 *, u16, u16);
-s32 igb_write_mbx(struct e1000_hw *, u32 *, u16, u16);
-s32 igb_check_for_msg(struct e1000_hw *, u16);
-s32 igb_check_for_ack(struct e1000_hw *, u16);
-s32 igb_check_for_rst(struct e1000_hw *, u16);
-s32 igb_init_mbx_params_pf(struct e1000_hw *);
+s32 igb_read_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
+s32 igb_write_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
+s32 igb_check_for_msg(struct e1000_hw *hw, u16 mbx_id);
+s32 igb_check_for_ack(struct e1000_hw *hw, u16 mbx_id);
+s32 igb_check_for_rst(struct e1000_hw *hw, u16 mbx_id);
+s32 igb_init_mbx_params_pf(struct e1000_hw *hw);
#endif /* _E1000_MBX_H_ */
--
2.13.3
^ permalink raw reply related
* [net-next 06/12] igb: expose mailbox unlock method
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Greg Edwards, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Greg Edwards <gedwards@ddn.com>
Add a mailbox unlock method to e1000_mbx_operations, which will be used
to unlock the PF/VF mailbox by the PF.
Signed-off-by: Greg Edwards <gedwards@ddn.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_hw.h | 1 +
drivers/net/ethernet/intel/igb/e1000_mbx.c | 39 ++++++++++++++++++++++++++++++
drivers/net/ethernet/intel/igb/e1000_mbx.h | 1 +
3 files changed, 41 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h b/drivers/net/ethernet/intel/igb/e1000_hw.h
index fd7865a8d2e3..6076f258a0a5 100644
--- a/drivers/net/ethernet/intel/igb/e1000_hw.h
+++ b/drivers/net/ethernet/intel/igb/e1000_hw.h
@@ -499,6 +499,7 @@ struct e1000_mbx_operations {
s32 (*check_for_msg)(struct e1000_hw *hw, u16 mbx_id);
s32 (*check_for_ack)(struct e1000_hw *hw, u16 mbx_id);
s32 (*check_for_rst)(struct e1000_hw *hw, u16 mbx_id);
+ s32 (*unlock)(struct e1000_hw *hw, u16 mbx_id);
};
struct e1000_mbx_stats {
diff --git a/drivers/net/ethernet/intel/igb/e1000_mbx.c b/drivers/net/ethernet/intel/igb/e1000_mbx.c
index 00e263f0c030..6aa44723507b 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mbx.c
+++ b/drivers/net/ethernet/intel/igb/e1000_mbx.c
@@ -125,6 +125,24 @@ s32 igb_check_for_rst(struct e1000_hw *hw, u16 mbx_id)
}
/**
+ * igb_unlock_mbx - unlock the mailbox
+ * @hw: pointer to the HW structure
+ * @mbx_id: id of mailbox to check
+ *
+ * returns SUCCESS if the mailbox was unlocked or else ERR_MBX
+ **/
+s32 igb_unlock_mbx(struct e1000_hw *hw, u16 mbx_id)
+{
+ struct e1000_mbx_info *mbx = &hw->mbx;
+ s32 ret_val = -E1000_ERR_MBX;
+
+ if (mbx->ops.unlock)
+ ret_val = mbx->ops.unlock(hw, mbx_id);
+
+ return ret_val;
+}
+
+/**
* igb_poll_for_msg - Wait for message notification
* @hw: pointer to the HW structure
* @mbx_id: id of mailbox to write
@@ -341,6 +359,26 @@ static s32 igb_obtain_mbx_lock_pf(struct e1000_hw *hw, u16 vf_number)
}
/**
+ * igb_release_mbx_lock_pf - release mailbox lock
+ * @hw: pointer to the HW structure
+ * @vf_number: the VF index
+ *
+ * return SUCCESS if we released the mailbox lock
+ **/
+static s32 igb_release_mbx_lock_pf(struct e1000_hw *hw, u16 vf_number)
+{
+ u32 p2v_mailbox;
+
+ /* drop PF lock of mailbox, if set */
+ p2v_mailbox = rd32(E1000_P2VMAILBOX(vf_number));
+ if (p2v_mailbox & E1000_P2VMAILBOX_PFU)
+ wr32(E1000_P2VMAILBOX(vf_number),
+ p2v_mailbox & ~E1000_P2VMAILBOX_PFU);
+
+ return 0;
+}
+
+/**
* igb_write_mbx_pf - Places a message in the mailbox
* @hw: pointer to the HW structure
* @msg: The message buffer
@@ -437,6 +475,7 @@ s32 igb_init_mbx_params_pf(struct e1000_hw *hw)
mbx->ops.check_for_msg = igb_check_for_msg_pf;
mbx->ops.check_for_ack = igb_check_for_ack_pf;
mbx->ops.check_for_rst = igb_check_for_rst_pf;
+ mbx->ops.unlock = igb_release_mbx_lock_pf;
mbx->stats.msgs_tx = 0;
mbx->stats.msgs_rx = 0;
diff --git a/drivers/net/ethernet/intel/igb/e1000_mbx.h b/drivers/net/ethernet/intel/igb/e1000_mbx.h
index 73d90aeb48b2..a98c5dc60afd 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mbx.h
+++ b/drivers/net/ethernet/intel/igb/e1000_mbx.h
@@ -72,6 +72,7 @@ s32 igb_write_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
s32 igb_check_for_msg(struct e1000_hw *hw, u16 mbx_id);
s32 igb_check_for_ack(struct e1000_hw *hw, u16 mbx_id);
s32 igb_check_for_rst(struct e1000_hw *hw, u16 mbx_id);
+s32 igb_unlock_mbx(struct e1000_hw *hw, u16 mbx_id);
s32 igb_init_mbx_params_pf(struct e1000_hw *hw);
#endif /* _E1000_MBX_H_ */
--
2.13.3
^ permalink raw reply related
* [net-next 04/12] igb: Remove incorrect "unexpected SYS WRAP" log message
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Corinna Vinschen, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Corinna Vinschen <vinschen@redhat.com>
TSAUXC.DisableSystime is never set, so SYSTIM runs into a SYS WRAP
every 1100 secs on 80580/i350/i354 (40 bit SYSTIM) and every 35000
secs on 80576 (45 bit SYSTIM).
This wrap event sets the TSICR.SysWrap bit unconditionally.
However, checking TSIM at interrupt time shows that this event does not
actually cause the interrupt. Rather, it's just bycatch while the
actual interrupt is caused by, for instance, TSICR.TXTS.
The conclusion is that the SYS WRAP is actually expected, so the
"unexpected SYS WRAP" message is entirely bogus and just helps to
confuse users. Drop it.
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Acked-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 5d0a75c1ba0c..1a99164d5d11 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5746,8 +5746,6 @@ static void igb_tsync_interrupt(struct igb_adapter *adapter)
event.type = PTP_CLOCK_PPS;
if (adapter->ptp_caps.pps)
ptp_clock_event(adapter->ptp_clock, &event);
- else
- dev_err(&adapter->pdev->dev, "unexpected SYS WRAP");
ack |= TSINTR_SYS_WRAP;
}
--
2.13.3
^ permalink raw reply related
* [net-next 03/12] e1000e: add check on e1e_wphy() return value
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Gustavo A R Silva, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Gustavo A R Silva <garsilva@embeddedor.com>
Check return value from call to e1e_wphy(). This value is being
checked during previous calls to function e1e_wphy() and it seems
a check was missing here.
Addresses-Coverity-ID: 1226905
Signed-off-by: Gustavo A R Silva <garsilva@embeddedor.com>
Reviewed-by: Ethan Zhao <ethan.zhao@oracle.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/ich8lan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet/intel/e1000e/ich8lan.c
index 68ea8b4555ab..d6d4ed7acf03 100644
--- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
+++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
@@ -2437,6 +2437,8 @@ static s32 e1000_hv_phy_workarounds_ich8lan(struct e1000_hw *hw)
if (hw->phy.revision < 2) {
e1000e_phy_sw_reset(hw);
ret_val = e1e_wphy(hw, MII_BMCR, 0x3140);
+ if (ret_val)
+ return ret_val;
}
}
--
2.13.3
^ permalink raw reply related
* [net-next 02/12] igb: protect TX timestamping from API misuse
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Cliff Spradlin, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Cliff Spradlin <cspradlin@google.com>
HW timestamping can only be requested for a packet if the NIC is first
setup via ioctl(SIOCSHWTSTAMP). If this step was skipped, then the igb
driver still allowed TX packets to request HW timestamping. In this
situation, the _IGB_PTP_TX_IN_PROGRESS flag was set and would never
clear. This prevented any future HW timestamping requests to succeed.
Fix this by checking that the NIC is configured for HW TX timestamping
before accepting a HW TX timestamping request.
Signed-off-by: Cliff Spradlin <cspradlin@google.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 6a63ea564a57..5d0a75c1ba0c 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -5380,7 +5380,8 @@ netdev_tx_t igb_xmit_frame_ring(struct sk_buff *skb,
if (unlikely(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP)) {
struct igb_adapter *adapter = netdev_priv(tx_ring->netdev);
- if (!test_and_set_bit_lock(__IGB_PTP_TX_IN_PROGRESS,
+ if (adapter->tstamp_config.tx_type & HWTSTAMP_TX_ON &&
+ !test_and_set_bit_lock(__IGB_PTP_TX_IN_PROGRESS,
&adapter->state)) {
skb_shinfo(skb)->tx_flags |= SKBTX_IN_PROGRESS;
tx_flags |= IGB_TX_FLAGS_TSTAMP;
--
2.13.3
^ permalink raw reply related
* [net-next 09/12] igbvf: add lock around mailbox ops
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Greg Edwards, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Greg Edwards <gedwards@ddn.com>
The PF driver assumes the VF will not send another mailbox message until
the PF has written its reply to the previous message. If the VF does,
that message will be silently dropped by the PF before it writes its
reply to the mailbox. This results in a VF mailbox timeout for posted
messages waiting for an ACK, and the VF is reset by the
igbvf_watchdog_task in the VM.
Add a lock around the VF mailbox ops to prevent the VF from sending
another message while the PF is still processing the previous one.
Signed-off-by: Greg Edwards <gedwards@ddn.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igbvf/ethtool.c | 4 +++
drivers/net/ethernet/intel/igbvf/mbx.c | 4 +++
drivers/net/ethernet/intel/igbvf/netdev.c | 47 ++++++++++++++++++++++++++++++
drivers/net/ethernet/intel/igbvf/vf.h | 1 +
4 files changed, 56 insertions(+)
diff --git a/drivers/net/ethernet/intel/igbvf/ethtool.c b/drivers/net/ethernet/intel/igbvf/ethtool.c
index 34faa113a8a0..a127688e83e6 100644
--- a/drivers/net/ethernet/intel/igbvf/ethtool.c
+++ b/drivers/net/ethernet/intel/igbvf/ethtool.c
@@ -296,8 +296,12 @@ static int igbvf_link_test(struct igbvf_adapter *adapter, u64 *data)
struct e1000_hw *hw = &adapter->hw;
*data = 0;
+ spin_lock_bh(&hw->mbx_lock);
+
hw->mac.ops.check_for_link(hw);
+ spin_unlock_bh(&hw->mbx_lock);
+
if (!(er32(STATUS) & E1000_STATUS_LU))
*data = 1;
diff --git a/drivers/net/ethernet/intel/igbvf/mbx.c b/drivers/net/ethernet/intel/igbvf/mbx.c
index 01752f44ace2..c9a441632e9f 100644
--- a/drivers/net/ethernet/intel/igbvf/mbx.c
+++ b/drivers/net/ethernet/intel/igbvf/mbx.c
@@ -264,6 +264,8 @@ static s32 e1000_write_mbx_vf(struct e1000_hw *hw, u32 *msg, u16 size)
s32 err;
u16 i;
+ WARN_ON_ONCE(!spin_is_locked(&hw->mbx_lock));
+
/* lock the mailbox to prevent pf/vf race condition */
err = e1000_obtain_mbx_lock_vf(hw);
if (err)
@@ -300,6 +302,8 @@ static s32 e1000_read_mbx_vf(struct e1000_hw *hw, u32 *msg, u16 size)
s32 err;
u16 i;
+ WARN_ON_ONCE(!spin_is_locked(&hw->mbx_lock));
+
/* lock the mailbox to prevent pf/vf race condition */
err = e1000_obtain_mbx_lock_vf(hw);
if (err)
diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
index 1b9cbbe88f6f..1ed556911b14 100644
--- a/drivers/net/ethernet/intel/igbvf/netdev.c
+++ b/drivers/net/ethernet/intel/igbvf/netdev.c
@@ -1235,7 +1235,12 @@ static void igbvf_set_rlpml(struct igbvf_adapter *adapter)
struct e1000_hw *hw = &adapter->hw;
max_frame_size = adapter->max_frame_size + VLAN_TAG_SIZE;
+
+ spin_lock_bh(&hw->mbx_lock);
+
e1000_rlpml_set_vf(hw, max_frame_size);
+
+ spin_unlock_bh(&hw->mbx_lock);
}
static int igbvf_vlan_rx_add_vid(struct net_device *netdev,
@@ -1244,10 +1249,16 @@ static int igbvf_vlan_rx_add_vid(struct net_device *netdev,
struct igbvf_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
+ spin_lock_bh(&hw->mbx_lock);
+
if (hw->mac.ops.set_vfta(hw, vid, true)) {
dev_err(&adapter->pdev->dev, "Failed to add vlan id %d\n", vid);
+ spin_unlock_bh(&hw->mbx_lock);
return -EINVAL;
}
+
+ spin_unlock_bh(&hw->mbx_lock);
+
set_bit(vid, adapter->active_vlans);
return 0;
}
@@ -1258,11 +1269,17 @@ static int igbvf_vlan_rx_kill_vid(struct net_device *netdev,
struct igbvf_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
+ spin_lock_bh(&hw->mbx_lock);
+
if (hw->mac.ops.set_vfta(hw, vid, false)) {
dev_err(&adapter->pdev->dev,
"Failed to remove vlan id %d\n", vid);
+ spin_unlock_bh(&hw->mbx_lock);
return -EINVAL;
}
+
+ spin_unlock_bh(&hw->mbx_lock);
+
clear_bit(vid, adapter->active_vlans);
return 0;
}
@@ -1428,7 +1445,11 @@ static void igbvf_set_multi(struct net_device *netdev)
netdev_for_each_mc_addr(ha, netdev)
memcpy(mta_list + (i++ * ETH_ALEN), ha->addr, ETH_ALEN);
+ spin_lock_bh(&hw->mbx_lock);
+
hw->mac.ops.update_mc_addr_list(hw, mta_list, i, 0, 0);
+
+ spin_unlock_bh(&hw->mbx_lock);
kfree(mta_list);
}
@@ -1449,16 +1470,24 @@ static int igbvf_set_uni(struct net_device *netdev)
return -ENOSPC;
}
+ spin_lock_bh(&hw->mbx_lock);
+
/* Clear all unicast MAC filters */
hw->mac.ops.set_uc_addr(hw, E1000_VF_MAC_FILTER_CLR, NULL);
+ spin_unlock_bh(&hw->mbx_lock);
+
if (!netdev_uc_empty(netdev)) {
struct netdev_hw_addr *ha;
/* Add MAC filters one by one */
netdev_for_each_uc_addr(ha, netdev) {
+ spin_lock_bh(&hw->mbx_lock);
+
hw->mac.ops.set_uc_addr(hw, E1000_VF_MAC_FILTER_ADD,
ha->addr);
+
+ spin_unlock_bh(&hw->mbx_lock);
udelay(200);
}
}
@@ -1503,12 +1532,16 @@ static void igbvf_reset(struct igbvf_adapter *adapter)
struct net_device *netdev = adapter->netdev;
struct e1000_hw *hw = &adapter->hw;
+ spin_lock_bh(&hw->mbx_lock);
+
/* Allow time for pending master requests to run */
if (mac->ops.reset_hw(hw))
dev_err(&adapter->pdev->dev, "PF still resetting\n");
mac->ops.init_hw(hw);
+ spin_unlock_bh(&hw->mbx_lock);
+
if (is_valid_ether_addr(adapter->hw.mac.addr)) {
memcpy(netdev->dev_addr, adapter->hw.mac.addr,
netdev->addr_len);
@@ -1643,6 +1676,7 @@ static int igbvf_sw_init(struct igbvf_adapter *adapter)
igbvf_irq_disable(adapter);
spin_lock_init(&adapter->stats_lock);
+ spin_lock_init(&adapter->hw.mbx_lock);
set_bit(__IGBVF_DOWN, &adapter->state);
return 0;
@@ -1786,8 +1820,12 @@ static int igbvf_set_mac(struct net_device *netdev, void *p)
memcpy(hw->mac.addr, addr->sa_data, netdev->addr_len);
+ spin_lock_bh(&hw->mbx_lock);
+
hw->mac.ops.rar_set(hw, hw->mac.addr, 0);
+ spin_unlock_bh(&hw->mbx_lock);
+
if (!ether_addr_equal(addr->sa_data, hw->mac.addr))
return -EADDRNOTAVAIL;
@@ -1858,7 +1896,12 @@ static bool igbvf_has_link(struct igbvf_adapter *adapter)
if (test_bit(__IGBVF_DOWN, &adapter->state))
return false;
+ spin_lock_bh(&hw->mbx_lock);
+
ret_val = hw->mac.ops.check_for_link(hw);
+
+ spin_unlock_bh(&hw->mbx_lock);
+
link_active = !hw->mac.get_link_status;
/* if check for link returns error we will need to reset */
@@ -2808,6 +2851,8 @@ static int igbvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
netdev->min_mtu = ETH_MIN_MTU;
netdev->max_mtu = MAX_STD_JUMBO_FRAME_SIZE;
+ spin_lock_bh(&hw->mbx_lock);
+
/*reset the controller to put the device in a known good state */
err = hw->mac.ops.reset_hw(hw);
if (err) {
@@ -2824,6 +2869,8 @@ static int igbvf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
netdev->addr_len);
}
+ spin_unlock_bh(&hw->mbx_lock);
+
if (!is_valid_ether_addr(netdev->dev_addr)) {
dev_info(&pdev->dev, "Assigning random MAC address.\n");
eth_hw_addr_random(netdev);
diff --git a/drivers/net/ethernet/intel/igbvf/vf.h b/drivers/net/ethernet/intel/igbvf/vf.h
index 4cf78b0dec50..d213eefb6169 100644
--- a/drivers/net/ethernet/intel/igbvf/vf.h
+++ b/drivers/net/ethernet/intel/igbvf/vf.h
@@ -245,6 +245,7 @@ struct e1000_hw {
struct e1000_mac_info mac;
struct e1000_mbx_info mbx;
+ spinlock_t mbx_lock; /* serializes mailbox ops */
union {
struct e1000_dev_spec_vf vf;
--
2.13.3
^ permalink raw reply related
* [net-next 10/12] igbvf: after mailbox write, wait for reply
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Greg Edwards, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Greg Edwards <gedwards@ddn.com>
Two of the VF mailbox commands were not waiting for a reply from the PF,
which can result in a VF mailbox timeout in the VM for the next command.
Signed-off-by: Greg Edwards <gedwards@ddn.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igbvf/vf.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c
index 528be116184e..1d3aa9adcaa8 100644
--- a/drivers/net/ethernet/intel/igbvf/vf.c
+++ b/drivers/net/ethernet/intel/igbvf/vf.c
@@ -230,6 +230,7 @@ static void e1000_update_mc_addr_list_vf(struct e1000_hw *hw,
u16 *hash_list = (u16 *)&msgbuf[1];
u32 hash_value;
u32 cnt, i;
+ s32 ret_val;
/* Each entry in the list uses 1 16 bit word. We have 30
* 16 bit words available in our HW msg buffer (minus 1 for the
@@ -250,7 +251,9 @@ static void e1000_update_mc_addr_list_vf(struct e1000_hw *hw,
mc_addr_list += ETH_ALEN;
}
- mbx->ops.write_posted(hw, msgbuf, E1000_VFMAILBOX_SIZE);
+ ret_val = mbx->ops.write_posted(hw, msgbuf, E1000_VFMAILBOX_SIZE);
+ if (!ret_val)
+ mbx->ops.read_posted(hw, msgbuf, 1);
}
/**
@@ -293,11 +296,14 @@ void e1000_rlpml_set_vf(struct e1000_hw *hw, u16 max_size)
{
struct e1000_mbx_info *mbx = &hw->mbx;
u32 msgbuf[2];
+ s32 ret_val;
msgbuf[0] = E1000_VF_SET_LPE;
msgbuf[1] = max_size;
- mbx->ops.write_posted(hw, msgbuf, 2);
+ ret_val = mbx->ops.write_posted(hw, msgbuf, 2);
+ if (!ret_val)
+ mbx->ops.read_posted(hw, msgbuf, 1);
}
/**
--
2.13.3
^ permalink raw reply related
* [net-next 08/12] e1000e: Initial Support for IceLake
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Sasha Neftin, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Sasha Neftin <sasha.neftin@intel.com>
i219 (8) and i219 (9) are the next LOM generations that will be available
on the next Intel Client platform (IceLake).
This patch provides the initial support for these devices
Signed-off-by: Sasha Neftin <sasha.neftin@intel.com>
Reviewed-by: Raanan Avargil <raanan.avargil@intel.com>
Reviewed-by: Dima Ruinskiy <dima.ruinskiy@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/e1000e/hw.h | 4 ++++
drivers/net/ethernet/intel/e1000e/netdev.c | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/intel/e1000e/hw.h b/drivers/net/ethernet/intel/e1000e/hw.h
index 66bd5060a65b..d803b1a12349 100644
--- a/drivers/net/ethernet/intel/e1000e/hw.h
+++ b/drivers/net/ethernet/intel/e1000e/hw.h
@@ -100,6 +100,10 @@ struct e1000_hw;
#define E1000_DEV_ID_PCH_CNP_I219_V6 0x15BE
#define E1000_DEV_ID_PCH_CNP_I219_LM7 0x15BB
#define E1000_DEV_ID_PCH_CNP_I219_V7 0x15BC
+#define E1000_DEV_ID_PCH_ICP_I219_LM8 0x15DF
+#define E1000_DEV_ID_PCH_ICP_I219_V8 0x15E0
+#define E1000_DEV_ID_PCH_ICP_I219_LM9 0x15E1
+#define E1000_DEV_ID_PCH_ICP_I219_V9 0x15E2
#define E1000_REVISION_4 4
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 2dcb5463d9b8..327dfe5bedc0 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -7544,6 +7544,10 @@ static const struct pci_device_id e1000_pci_tbl[] = {
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_CNP_I219_V6), board_pch_cnp },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_CNP_I219_LM7), board_pch_cnp },
{ PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_CNP_I219_V7), board_pch_cnp },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ICP_I219_LM8), board_pch_cnp },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ICP_I219_V8), board_pch_cnp },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ICP_I219_LM9), board_pch_cnp },
+ { PCI_VDEVICE(INTEL, E1000_DEV_ID_PCH_ICP_I219_V9), board_pch_cnp },
{ 0, 0, 0, 0, 0, 0, 0 } /* terminate list */
};
--
2.13.3
^ permalink raw reply related
* [net-next 07/12] igb: do not drop PF mailbox lock after read of VF message
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Greg Edwards, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Greg Edwards <gedwards@ddn.com>
When the PF receives a mailbox message from the VF, it grabs the mailbox
lock, reads the VF message from the mailbox, ACKs the message and drops
the lock.
While the PF is performing the action for the VF message, nothing
prevents another VF message from being posted to the mailbox. The
current code handles this condition by just dropping any new VF messages
without processing them. This results in a mailbox timeout in the VM
for posted messages waiting for an ACK, and the VF is reset by the
igbvf_watchdog_task in the VM.
Given the right sequence of VF messages and mailbox timeouts, this
condition can go on ad infinitum.
Modify the PF mailbox read method to take an 'unlock' argument that
optionally leaves the mailbox locked by the PF after reading the VF
message. This ensures another VF message is not posted to the mailbox
until after the PF has completed processing the VF message and written
its reply.
Signed-off-by: Greg Edwards <gedwards@ddn.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_hw.h | 3 ++-
drivers/net/ethernet/intel/igb/e1000_mbx.c | 18 ++++++++++++------
drivers/net/ethernet/intel/igb/e1000_mbx.h | 3 ++-
drivers/net/ethernet/intel/igb/igb_main.c | 14 ++++++++++----
4 files changed, 26 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h b/drivers/net/ethernet/intel/igb/e1000_hw.h
index 6076f258a0a5..6ea9f702ba0f 100644
--- a/drivers/net/ethernet/intel/igb/e1000_hw.h
+++ b/drivers/net/ethernet/intel/igb/e1000_hw.h
@@ -491,7 +491,8 @@ struct e1000_fc_info {
struct e1000_mbx_operations {
s32 (*init_params)(struct e1000_hw *hw);
- s32 (*read)(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
+ s32 (*read)(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id,
+ bool unlock);
s32 (*write)(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
s32 (*read_posted)(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
s32 (*write_posted)(struct e1000_hw *hw, u32 *msg, u16 size,
diff --git a/drivers/net/ethernet/intel/igb/e1000_mbx.c b/drivers/net/ethernet/intel/igb/e1000_mbx.c
index 6aa44723507b..bffd58f7b2a1 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mbx.c
+++ b/drivers/net/ethernet/intel/igb/e1000_mbx.c
@@ -32,7 +32,8 @@
*
* returns SUCCESS if it successfully read message from buffer
**/
-s32 igb_read_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id)
+s32 igb_read_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id,
+ bool unlock)
{
struct e1000_mbx_info *mbx = &hw->mbx;
s32 ret_val = -E1000_ERR_MBX;
@@ -42,7 +43,7 @@ s32 igb_read_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id)
size = mbx->size;
if (mbx->ops.read)
- ret_val = mbx->ops.read(hw, msg, size, mbx_id);
+ ret_val = mbx->ops.read(hw, msg, size, mbx_id, unlock);
return ret_val;
}
@@ -222,7 +223,7 @@ static s32 igb_read_posted_mbx(struct e1000_hw *hw, u32 *msg, u16 size,
ret_val = igb_poll_for_msg(hw, mbx_id);
if (!ret_val)
- ret_val = mbx->ops.read(hw, msg, size, mbx_id);
+ ret_val = mbx->ops.read(hw, msg, size, mbx_id, true);
out:
return ret_val;
}
@@ -423,13 +424,14 @@ static s32 igb_write_mbx_pf(struct e1000_hw *hw, u32 *msg, u16 size,
* @msg: The message buffer
* @size: Length of buffer
* @vf_number: the VF index
+ * @unlock: unlock the mailbox when done?
*
* This function copies a message from the mailbox buffer to the caller's
* memory buffer. The presumption is that the caller knows that there was
* a message due to a VF request so no polling for message is needed.
**/
static s32 igb_read_mbx_pf(struct e1000_hw *hw, u32 *msg, u16 size,
- u16 vf_number)
+ u16 vf_number, bool unlock)
{
s32 ret_val;
u16 i;
@@ -443,8 +445,12 @@ static s32 igb_read_mbx_pf(struct e1000_hw *hw, u32 *msg, u16 size,
for (i = 0; i < size; i++)
msg[i] = array_rd32(E1000_VMBMEM(vf_number), i);
- /* Acknowledge the message and release buffer */
- wr32(E1000_P2VMAILBOX(vf_number), E1000_P2VMAILBOX_ACK);
+ /* Acknowledge the message and release mailbox lock (or not) */
+ if (unlock)
+ wr32(E1000_P2VMAILBOX(vf_number), E1000_P2VMAILBOX_ACK);
+ else
+ wr32(E1000_P2VMAILBOX(vf_number),
+ E1000_P2VMAILBOX_ACK | E1000_P2VMAILBOX_PFU);
/* update stats */
hw->mbx.stats.msgs_rx++;
diff --git a/drivers/net/ethernet/intel/igb/e1000_mbx.h b/drivers/net/ethernet/intel/igb/e1000_mbx.h
index a98c5dc60afd..a62b08e1572e 100644
--- a/drivers/net/ethernet/intel/igb/e1000_mbx.h
+++ b/drivers/net/ethernet/intel/igb/e1000_mbx.h
@@ -67,7 +67,8 @@
#define E1000_PF_CONTROL_MSG 0x0100 /* PF control message */
-s32 igb_read_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
+s32 igb_read_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id,
+ bool unlock);
s32 igb_write_mbx(struct e1000_hw *hw, u32 *msg, u16 size, u16 mbx_id);
s32 igb_check_for_msg(struct e1000_hw *hw, u16 mbx_id);
s32 igb_check_for_ack(struct e1000_hw *hw, u16 mbx_id);
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index 1a99164d5d11..fd4a46b03cc8 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6675,32 +6675,33 @@ static void igb_rcv_msg_from_vf(struct igb_adapter *adapter, u32 vf)
struct vf_data_storage *vf_data = &adapter->vf_data[vf];
s32 retval;
- retval = igb_read_mbx(hw, msgbuf, E1000_VFMAILBOX_SIZE, vf);
+ retval = igb_read_mbx(hw, msgbuf, E1000_VFMAILBOX_SIZE, vf, false);
if (retval) {
/* if receive failed revoke VF CTS stats and restart init */
dev_err(&pdev->dev, "Error receiving message from VF\n");
vf_data->flags &= ~IGB_VF_FLAG_CTS;
if (!time_after(jiffies, vf_data->last_nack + (2 * HZ)))
- return;
+ goto unlock;
goto out;
}
/* this is a message we already processed, do nothing */
if (msgbuf[0] & (E1000_VT_MSGTYPE_ACK | E1000_VT_MSGTYPE_NACK))
- return;
+ goto unlock;
/* until the vf completes a reset it should not be
* allowed to start any configuration.
*/
if (msgbuf[0] == E1000_VF_RESET) {
+ /* unlocks mailbox */
igb_vf_reset_msg(adapter, vf);
return;
}
if (!(vf_data->flags & IGB_VF_FLAG_CTS)) {
if (!time_after(jiffies, vf_data->last_nack + (2 * HZ)))
- return;
+ goto unlock;
retval = -1;
goto out;
}
@@ -6741,7 +6742,12 @@ static void igb_rcv_msg_from_vf(struct igb_adapter *adapter, u32 vf)
else
msgbuf[0] |= E1000_VT_MSGTYPE_ACK;
+ /* unlocks mailbox */
igb_write_mbx(hw, msgbuf, 1, vf);
+ return;
+
+unlock:
+ igb_unlock_mbx(hw, vf);
}
static void igb_msg_task(struct igb_adapter *adapter)
--
2.13.3
^ permalink raw reply related
* [net-next 11/12] igbvf: convert msleep to mdelay in atomic context
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: Greg Edwards, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: Greg Edwards <gedwards@ddn.com>
This fixes a "scheduling while atomic" splat seen with
CONFIG_DEBUG_ATOMIC_SLEEP enabled.
Signed-off-by: Greg Edwards <gedwards@ddn.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igbvf/vf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c
index 1d3aa9adcaa8..9577ccf4b26a 100644
--- a/drivers/net/ethernet/intel/igbvf/vf.c
+++ b/drivers/net/ethernet/intel/igbvf/vf.c
@@ -149,7 +149,7 @@ static s32 e1000_reset_hw_vf(struct e1000_hw *hw)
msgbuf[0] = E1000_VF_RESET;
mbx->ops.write_posted(hw, msgbuf, 1);
- msleep(10);
+ mdelay(10);
/* set our "perm_addr" based on info provided by PF */
ret_val = mbx->ops.read_posted(hw, msgbuf, 3);
--
2.13.3
^ permalink raw reply related
* [net-next 12/12] igb: support BCM54616 PHY
From: Jeff Kirsher @ 2017-08-09 21:47 UTC (permalink / raw)
To: davem; +Cc: John W Linville, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <20170809214746.28139-1-jeffrey.t.kirsher@intel.com>
From: John W Linville <linville@tuxdriver.com>
The management port on an Edgecore AS7712-32 switch uses an igb MAC, but
it uses a BCM54616 PHY. Without a patch like this, loading the igb
module produces dmesg output like this:
[ 3.439125] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 3.439866] igb: probe of 0000:00:14.0 failed with error -2
Signed-off-by: John W Linville <linville@tuxdriver.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/igb/e1000_82575.c | 6 ++++++
drivers/net/ethernet/intel/igb/e1000_defines.h | 1 +
drivers/net/ethernet/intel/igb/e1000_hw.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index 4a50870e0fa7..c37cc8bccf47 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -340,6 +340,9 @@ static s32 igb_init_phy_params_82575(struct e1000_hw *hw)
phy->ops.set_d3_lplu_state = igb_set_d3_lplu_state_82580;
phy->ops.force_speed_duplex = igb_phy_force_speed_duplex_m88;
break;
+ case BCM54616_E_PHY_ID:
+ phy->type = e1000_phy_bcm54616;
+ break;
default:
ret_val = -E1000_ERR_PHY;
goto out;
@@ -1659,6 +1662,9 @@ static s32 igb_setup_copper_link_82575(struct e1000_hw *hw)
case e1000_phy_82580:
ret_val = igb_copper_link_setup_82580(hw);
break;
+ case e1000_phy_bcm54616:
+ ret_val = 0;
+ break;
default:
ret_val = -E1000_ERR_PHY;
break;
diff --git a/drivers/net/ethernet/intel/igb/e1000_defines.h b/drivers/net/ethernet/intel/igb/e1000_defines.h
index d8517779439b..1de82f247312 100644
--- a/drivers/net/ethernet/intel/igb/e1000_defines.h
+++ b/drivers/net/ethernet/intel/igb/e1000_defines.h
@@ -889,6 +889,7 @@
#define I210_I_PHY_ID 0x01410C00
#define M88E1543_E_PHY_ID 0x01410EA0
#define M88E1512_E_PHY_ID 0x01410DD0
+#define BCM54616_E_PHY_ID 0x03625D10
/* M88E1000 Specific Registers */
#define M88E1000_PHY_SPEC_CTRL 0x10 /* PHY Specific Control Register */
diff --git a/drivers/net/ethernet/intel/igb/e1000_hw.h b/drivers/net/ethernet/intel/igb/e1000_hw.h
index 6ea9f702ba0f..6c9485ab4b57 100644
--- a/drivers/net/ethernet/intel/igb/e1000_hw.h
+++ b/drivers/net/ethernet/intel/igb/e1000_hw.h
@@ -128,6 +128,7 @@ enum e1000_phy_type {
e1000_phy_ife,
e1000_phy_82580,
e1000_phy_i210,
+ e1000_phy_bcm54616,
};
enum e1000_bus_type {
--
2.13.3
^ permalink raw reply related
* (unknown),
From: helga.brickl @ 2017-08-09 22:05 UTC (permalink / raw)
To: netdev
[-- Attachment #1: 45779797.zip --]
[-- Type: application/zip, Size: 10199 bytes --]
^ permalink raw reply
* [PATCH iproute2 master] bpf: unbreak libelf linkage for bpf obj loader
From: Daniel Borkmann @ 2017-08-09 22:15 UTC (permalink / raw)
To: stephen; +Cc: netdev, Daniel Borkmann
Commit 69fed534a533 ("change how Config is used in Makefile's") moved
HAVE_MNL specific CFLAGS/LDLIBS for building with libmnl out of the
top level Makefile into sub-Makefiles. However, it also removed the
HAVE_ELF specific CFLAGS/LDLIBS entirely, which breaks the BPF object
loader for tc and ip with "No ELF library support compiled in." despite
having libelf detected in configure script. Fix it similarly as in
69fed534a533 for HAVE_ELF.
Fixes: 69fed534a533 ("change how Config is used in Makefile's")
Reported-by: Jeffrey Panneman <jeffrey.panneman@tno.nl>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
---
ip/Makefile | 4 ++++
lib/Makefile | 4 ++++
tc/Makefile | 4 ++++
3 files changed, 12 insertions(+)
diff --git a/ip/Makefile b/ip/Makefile
index 572604d..a754c04 100644
--- a/ip/Makefile
+++ b/ip/Makefile
@@ -19,6 +19,10 @@ ifeq ($(IP_CONFIG_SETNS),y)
CFLAGS += -DHAVE_SETNS
endif
+ifeq ($(HAVE_ELF),y)
+ CFLAGS += -DHAVE_ELF
+ LDLIBS += -lelf
+endif
ifeq ($(HAVE_MNL),y)
CFLAGS += -DHAVE_LIBMNL $(shell $(PKG_CONFIG) libmnl --cflags)
LDLIBS += $(shell $(PKG_CONFIG) libmnl --libs)
diff --git a/lib/Makefile b/lib/Makefile
index 637fe48..b7b1d56 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -4,6 +4,10 @@ ifeq ($(IP_CONFIG_SETNS),y)
CFLAGS += -DHAVE_SETNS
endif
+ifeq ($(HAVE_ELF),y)
+ CFLAGS += -DHAVE_ELF
+endif
+
ifeq ($(HAVE_MNL),y)
CFLAGS += -DHAVE_LIBMNL $(shell $(PKG_CONFIG) libmnl --cflags)
endif
diff --git a/tc/Makefile b/tc/Makefile
index c364a05..a9b4b8e 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -102,6 +102,10 @@ endif
TCOBJ += $(TCMODULES)
LDLIBS += -L. -lm
+ifeq ($(HAVE_ELF),y)
+ CFLAGS += -DHAVE_ELF
+ LDLIBS += -lelf
+endif
ifeq ($(HAVE_MNL),y)
CFLAGS += -DHAVE_LIBMNL $(shell $(PKG_CONFIG) libmnl --cflags)
LDLIBS += $(shell $(PKG_CONFIG) libmnl --libs)
--
1.9.3
^ permalink raw reply related
* Re: skb allocation from interrupt handler?
From: Francois Romieu @ 2017-08-09 22:29 UTC (permalink / raw)
To: Murali Karicheri; +Cc: David Miller, netdev
In-Reply-To: <598B3A14.5020507@ti.com>
Murali Karicheri <m-karicheri2@ti.com> :
[...]
> The internal memory or FIFO can store only up to 3 MTU sized packets. So that has to
> be processed before PRU gets another packets to send to CPU. So per above,
> it is not ideal to run NAPI for this scenario, right? Also for NetCP we use
> about 128 descriptors with MTU size buffers to handle 1Gbps Ethernet link.
> Based on that roughly we would need at least 10-12 buffers in the FIFO.
>
> Currently we have a NAPI implementation in use that gives throughput of 95Mbps for
> MTU sized packets, but our UDP iperf tests shows less than 1% packet loss for an
> offered traffic of 95Mbps with MTU sized packets. This is not good for industrial
> network using HSR/PRP protocol for network redundancy. We need to have zero packet
> loss for MTU sized packets at 95Mbps throughput. That is the problem description.
Imvho you should instrument the kernel to figure where the excess latency that
prevents NAPI processing to take place within 125 us of physical packet reception
comes from.
> As an experiment, I have moved the packet processing to irq handler to see if we
> can take advantage of CPU cycle to processing the packet instead of NAPI
> and to check if the firmware encounters buffer overflow. The result is positive
> with no buffer overflow seen at the firmware and no packet loss in the iperf test.
> But we want to do more testing as an experiment and ran into a uart console locks
> up after running traffic for about 2 minutes. So I tried enabling the DEBUG HACK
> options to get some clue on what is happening and ran into the trace I shared
> earlier. So what function can I use to allocate SKB from interrupt handler ?
Is your design also so tight on memory that you can't even refill your own
software skb pool from some non-irq context then only swap buffers in the
irq handler ?
--
Ueimor
^ permalink raw reply
* Help with debugging CPU stall
From: Joe Smith @ 2017-08-09 22:41 UTC (permalink / raw)
To: netdev
Hi,
I am debugging a system where rcu_sched detects cpu stall. The system
is running a test which runs fine if IPSec is not used. With IPSec it
stalls. I have tried reducing the value of netdev_budget to 100 but
that seems to have no impact. I have included two stack traces below.
How do I figure out where the system is looping/stuck.
Thanks for the help.
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410509]
[<ffffffff81510da9>] ? do_IRQ+0x69/0xe0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410513]
[<ffffffff81507053>] ? common_interrupt+0x13/0x13
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410520]
[<ffffffff8105822c>] ? sched_slice+0x4c/0x90
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410524]
[<ffffffff810dd8a2>] print_cpu_stall+0x42/0xa0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410528]
[<ffffffff810ddb2a>] check_cpu_stall+0xca/0xe0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410533]
[<ffffffff810ddb70>] __rcu_pending+0x30/0x140
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410537]
[<ffffffff810ddcb7>] rcu_pending+0x37/0x90
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410541]
[<ffffffff810dde95>] rcu_check_callbacks+0x85/0xa0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410546]
[<ffffffff8107e7b6>] update_process_times+0x46/0x90
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410553]
[<ffffffff810a31d6>] tick_sched_timer+0x66/0xd0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410557]
[<ffffffff810a3170>] ? tick_clock_notify+0x60/0x60
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410563]
[<ffffffff81095c63>] __run_hrtimer+0x83/0x1e0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410566]
[<ffffffff81095f76>] hrtimer_interrupt+0xe6/0x240
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410573]
[<ffffffff81033e6b>] local_apic_timer_interrupt+0x3b/0x70
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410578]
[<ffffffff81510e65>] smp_apic_timer_interrupt+0x45/0x5a
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410582]
[<ffffffff8150fcf3>] apic_timer_interrupt+0x13/0x20
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410586]
[<ffffffff81223a90>] shash_finup_unaligned+0x30/0x40
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410592]
[<ffffffffa05a163a>] ? dec128+0x742/0x818 [aes_x86_64]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410597]
[<ffffffffa05a1722>] ? aes_decrypt+0x12/0x30 [aes_x86_64]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410602]
[<ffffffffa05d5372>] ? crypto_cbc_decrypt_inplace+0xc2/0x120 [cbc]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410607]
[<ffffffffa05a1710>] ? dec128+0x818/0x818 [aes_x86_64]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410612]
[<ffffffffa05d553d>] ? crypto_cbc_decrypt+0x7d/0x90 [cbc]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410617]
[<ffffffff8122195d>] ? async_decrypt+0x3d/0x40
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410621]
[<ffffffffa0643e08>] ? crypto_authenc_decrypt+0xa8/0xb0 [authenc]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410626]
[<ffffffffa0578fc8>] ? esp_input+0x1e8/0x350 [esp4]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410630]
[<ffffffff814c3fe9>] ? xfrm_state_lookup+0x69/0x90
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410634]
[<ffffffff814c7c31>] ? xfrm_input+0x691/0x6e0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410639]
[<ffffffff814bb950>] ? xfrm4_rcv_encap+0x20/0x30
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410643]
[<ffffffff814bb9a4>] ? xfrm4_rcv+0x24/0x30
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410647]
[<ffffffff8146f399>] ? ip_local_deliver_finish+0x129/0x280
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410650]
[<ffffffff8146eef0>] ? ip_local_deliver+0x40/0xa0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410654]
[<ffffffff8146f669>] ? ip_rcv_finish+0x179/0x380
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410658]
[<ffffffff8146f172>] ? ip_rcv+0x222/0x320
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410662]
[<ffffffff814393ab>] ? __netif_receive_skb+0x25b/0x500
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410667]
[<ffffffff8143a58d>] ? netif_receive_skb+0x7d/0x90
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410671]
[<ffffffff8126aa7d>] ? swiotlb_sync_single+0x2d/0x70
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410675]
[<ffffffff8143a678>] ? napi_skb_finish+0x48/0x60
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410679]
[<ffffffff8143ab1b>] ? napi_gro_receive+0xfb/0x130
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410690]
[<ffffffffa01b5681>] ? ixgbe_rx_skb+0x41/0xd0 [ixgbe]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410701]
[<ffffffffa01b697c>] ? ixgbe_clean_rx_irq+0x10c/0x1d0 [ixgbe]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410712]
[<ffffffffa01b6f15>] ? ixgbe_poll+0xa5/0x130 [ixgbe]
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410716]
[<ffffffff8143ad6a>] ? net_rx_action+0x14a/0x230
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410721]
[<ffffffff810dd2e1>] ? rcu_check_quiescent_state+0x21/0x60
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410725]
[<ffffffff81075e09>] ? __do_softirq+0xb9/0x1d0
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410729]
[<ffffffff810dcdae>] ? rcu_irq_exit+0xe/0x10
Aug 8 15:37:38 scad01adm01 kernel: [ 1884.410733]
[<ffffffff8151053c>] ? call_softirq+0x1c/0x30
Another Trace:
Aug 9 14:12:05 scad01adm01 kernel: [82985.293794] Call Trace:
Aug 9 14:12:05 scad01adm01 kernel: [82985.293795] <IRQ>
Aug 9 14:12:05 scad01adm01 kernel: [82985.293800]
[<ffffffff8125c65d>] delay_tsc+0x4d/0x80
Aug 9 14:12:05 scad01adm01 kernel: [82985.293804]
[<ffffffff8125c5cf>] __delay+0xf/0x20
Aug 9 14:12:05 scad01adm01 kernel: [82985.293807]
[<ffffffff8125c60c>] __const_udelay+0x2c/0x30
Aug 9 14:12:05 scad01adm01 kernel: [82985.293814]
[<ffffffff8132b8b0>] wait_for_xmitr+0x30/0xa0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293818]
[<ffffffff8132b920>] ? wait_for_xmitr+0xa0/0xa0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293822]
[<ffffffff8132b946>] serial8250_console_putchar+0x26/0x40
Aug 9 14:12:05 scad01adm01 kernel: [82985.293826]
[<ffffffff8132742d>] uart_console_write+0x3d/0x70
Aug 9 14:12:05 scad01adm01 kernel: [82985.293831]
[<ffffffff8132d3a2>] serial8250_console_write+0xc2/0x150
Aug 9 14:12:05 scad01adm01 kernel: [82985.293839]
[<ffffffff8106f66e>] __call_console_drivers+0x8e/0xa0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293843]
[<ffffffff8106f6ca>] _call_console_drivers+0x4a/0x80
Aug 9 14:12:05 scad01adm01 kernel: [82985.293847]
[<ffffffff8106f9f2>] call_console_drivers+0x82/0x130
Aug 9 14:12:05 scad01adm01 kernel: [82985.293853]
[<ffffffff81506b84>] ? _raw_spin_lock_irqsave+0x34/0x50
Aug 9 14:12:05 scad01adm01 kernel: [82985.293858]
[<ffffffff8106fd4a>] console_unlock+0x5a/0x110
Aug 9 14:12:05 scad01adm01 kernel: [82985.293862]
[<ffffffff81070422>] vprintk+0x1a2/0x3a0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293872]
[<ffffffff810dcdae>] ? rcu_irq_exit+0xe/0x10
Aug 9 14:12:05 scad01adm01 kernel: [82985.293876]
[<ffffffff8107068c>] printk+0x6c/0x70
Aug 9 14:12:05 scad01adm01 kernel: [82985.293882]
[<ffffffff8122838a>] ? sha1_update+0xba/0x100
Aug 9 14:12:05 scad01adm01 kernel: [82985.293887]
[<ffffffff810dd8a2>] print_cpu_stall+0x42/0xa0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293891]
[<ffffffff810ddb2a>] check_cpu_stall+0xca/0xe0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293896]
[<ffffffff810ddb70>] __rcu_pending+0x30/0x140
Aug 9 14:12:05 scad01adm01 kernel: [82985.293900]
[<ffffffff810ddcb7>] rcu_pending+0x37/0x90
Aug 9 14:12:05 scad01adm01 kernel: [82985.293905]
[<ffffffff810dde95>] rcu_check_callbacks+0x85/0xa0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293914]
[<ffffffff8107e7b6>] update_process_times+0x46/0x90
Aug 9 14:12:05 scad01adm01 kernel: [82985.293923]
[<ffffffff810a31d6>] tick_sched_timer+0x66/0xd0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293927]
[<ffffffff810a3170>] ? tick_clock_notify+0x60/0x60
Aug 9 14:12:05 scad01adm01 kernel: [82985.293933]
[<ffffffff81095c63>] __run_hrtimer+0x83/0x1e0
Aug 9 14:12:05 scad01adm01 kernel: [82985.293937]
[<ffffffff81095f76>] hrtimer_interrupt+0xe6/0x240
Aug 9 14:12:05 scad01adm01 kernel: [82985.293945]
[<ffffffff81033e6b>] local_apic_timer_interrupt+0x3b/0x70
Aug 9 14:12:05 scad01adm01 kernel: [82985.293950]
[<ffffffff81510e65>] smp_apic_timer_interrupt+0x45/0x5a
Aug 9 14:12:05 scad01adm01 kernel: [82985.293953]
[<ffffffff8150fcf3>] apic_timer_interrupt+0x13/0x20
Aug 9 14:12:05 scad01adm01 kernel: [82985.293958]
[<ffffffff8125d33b>] ? memcpy+0xb/0x120
Aug 9 14:12:05 scad01adm01 kernel: [82985.293963]
[<ffffffff81220f76>] ? blkcipher_walk_done+0x196/0x240
Aug 9 14:12:05 scad01adm01 kernel: [82985.293969]
[<ffffffffa05a1710>] ? dec128+0x818/0x818 [aes_x86_64]
Aug 9 14:12:05 scad01adm01 kernel: [82985.293974]
[<ffffffffa05d551b>] ? crypto_cbc_decrypt+0x5b/0x90 [cbc]
Aug 9 14:12:05 scad01adm01 kernel: [82985.293978]
[<ffffffff8122195d>] ? async_decrypt+0x3d/0x40
Aug 9 14:12:05 scad01adm01 kernel: [82985.293983]
[<ffffffffa0643e08>] ? crypto_authenc_decrypt+0xa8/0xb0 [authenc]
Aug 9 14:12:05 scad01adm01 kernel: [82985.293989]
[<ffffffffa0578fc8>] ? esp_input+0x1e8/0x350 [esp4]
Aug 9 14:12:05 scad01adm01 kernel: [82985.293994]
[<ffffffff814c3fe9>] ? xfrm_state_lookup+0x69/0x90
Aug 9 14:12:05 scad01adm01 kernel: [82985.293998]
[<ffffffff814c7c31>] ? xfrm_input+0x691/0x6e0
Aug 9 14:12:05 scad01adm01 kernel: [82985.294003]
[<ffffffff814bb950>] ? xfrm4_rcv_encap+0x20/0x30
Aug 9 14:12:05 scad01adm01 kernel: [82985.294007]
[<ffffffff814bb9a4>] ? xfrm4_rcv+0x24/0x30
Aug 9 14:12:05 scad01adm01 kernel: [82985.294012]
[<ffffffff8146f399>] ? ip_local_deliver_finish+0x129/0x280
Aug 9 14:12:05 scad01adm01 kernel: [82985.294016]
[<ffffffff8146eef0>] ? ip_local_deliver+0x40/0xa0
Aug 9 14:12:05 scad01adm01 kernel: [82985.294019]
[<ffffffff8146f669>] ? ip_rcv_finish+0x179/0x380
Aug 9 14:12:05 scad01adm01 kernel: [82985.294023]
[<ffffffff8146f172>] ? ip_rcv+0x222/0x320
Aug 9 14:12:05 scad01adm01 kernel: [82985.294030]
[<ffffffff814393ab>] ? __netif_receive_skb+0x25b/0x500
Aug 9 14:12:05 scad01adm01 kernel: [82985.294035]
[<ffffffff8143a58d>] ? netif_receive_skb+0x7d/0x90
Aug 9 14:12:05 scad01adm01 kernel: [82985.294043]
[<ffffffff8126aa7d>] ? swiotlb_sync_single+0x2d/0x70
Aug 9 14:12:05 scad01adm01 kernel: [82985.294047]
[<ffffffff8143a678>] ? napi_skb_finish+0x48/0x60
Aug 9 14:12:05 scad01adm01 kernel: [82985.294051]
[<ffffffff8143ab1b>] ? napi_gro_receive+0xfb/0x130
Aug 9 14:12:05 scad01adm01 kernel: [82985.294073]
[<ffffffffa01b5681>] ? ixgbe_rx_skb+0x41/0xd0 [ixgbe]
Aug 9 14:12:05 scad01adm01 kernel: [82985.294085]
[<ffffffffa01b697c>] ? ixgbe_clean_rx_irq+0x10c/0x1d0 [ixgbe]
Aug 9 14:12:05 scad01adm01 kernel: [82985.294097]
[<ffffffffa01b6f15>] ? ixgbe_poll+0xa5/0x130 [ixgbe]
Aug 9 14:12:05 scad01adm01 kernel: [82985.294101]
[<ffffffff8143ad6a>] ? net_rx_action+0x14a/0x230
Aug 9 14:12:05 scad01adm01 kernel: [82985.294106]
[<ffffffff81075e09>] ? __do_softirq+0xb9/0x1d0
Aug 9 14:12:05 scad01adm01 kernel: [82985.294110]
[<ffffffff8151053c>] ? call_softirq+0x1c/0x30
Aug 9 14:12:05 scad01adm01 kernel: [82985.294112] <EOI>
--
JS
^ permalink raw reply
* Re: [PATCH v3 05/11] net: stmmac: dwmac-rk: Add internal phy support
From: Florian Fainelli @ 2017-08-09 22:42 UTC (permalink / raw)
To: Corentin Labbe, andrew, davem
Cc: David Wu, Heiko Stübner, Rob Herring, Mark Rutland,
Catalin Marinas, Will Deacon, Olof Johansson, Russell King,
Arnd Bergmann, Tao Huang, hwg, alexandre.torgue, devicetree,
netdev, linux-kernel, open list:ARM/Rockchip SoC...,
Giuseppe Cavallaro, linux-arm-kernel, wens
In-Reply-To: <20170809084541.GB7137@Red>
On August 9, 2017 1:45:41 AM PDT, Corentin Labbe <clabbe.montjoie@gmail.com> wrote:
>On Thu, Aug 03, 2017 at 07:06:33PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Aug 3, 2017 at 1:38 AM, Florian Fainelli
><f.fainelli@gmail.com> wrote:
>> > On 08/01/2017 11:21 PM, David Wu wrote:
>> >> To make internal phy work, need to configure the phy_clock,
>> >> phy cru_reset and related registers.
>> >>
>> >> Signed-off-by: David Wu <david.wu@rock-chips.com>
>> >> ---
>> >> .../devicetree/bindings/net/rockchip-dwmac.txt | 6 +-
>> >> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 81
>++++++++++++++++++++++
>> >> 2 files changed, 86 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git
>a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>> >> index 8f42755..ec39b31 100644
>> >> --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>> >> +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.txt
>> >> @@ -25,7 +25,8 @@ Required properties:
>> >> - clock-names: One name for each entry in the clocks property.
>> >> - phy-mode: See ethernet.txt file in the same directory.
>> >> - pinctrl-names: Names corresponding to the numbered pinctrl
>states.
>> >> - - pinctrl-0: pin-control mode. can be <&rgmii_pins> or
><&rmii_pins>.
>> >> + - pinctrl-0: pin-control mode. can be <&rgmii_pins>,
><&rmii_pins> or led pins
>> >> + for internal phy mode.
>> >> - clock_in_out: For RGMII, it must be "input", means main
>clock(125MHz)
>> >> is not sourced from SoC's PLL, but input from PHY; For RMII,
>"input" means
>> >> PHY provides the reference clock(50MHz), "output" means GMAC
>provides the
>> >> @@ -40,6 +41,9 @@ Optional properties:
>> >> - tx_delay: Delay value for TXD timing. Range value is 0~0x7F,
>0x30 as default.
>> >> - rx_delay: Delay value for RXD timing. Range value is 0~0x7F,
>0x10 as default.
>> >> - phy-supply: phandle to a regulator if the PHY needs one
>> >> + - clocks: <&cru MAC_PHY>: Clock selector for internal macphy
>> >> + - phy-is-internal: A boolean property allows us to know that MAC
>will connect to
>> >> + internal phy.
>> >
>> > This is incorrect in two ways:
>> >
>> > - this is a property of the PHY, so it should be documented as such
>in
>> > Documentation/devicetree/bindings/net/phy.txt so other bindings can
>> > re-use it
>> >
>> > - if it was specific to your MAC you would expect a vendor prefix
>to
>> > this property, which is not there
>> >
>> > An alternative way to implement the external/internal logic
>selection
>> > would be mandate that your Ethernet PHY node have a compatible
>string
>> > like this:
>> >
>> > phy@0 {
>> > compatible = "ethernet-phy-id1234.d400",
>"ethernet-phy-802.3-c22";
>> > };
>> >
>> > Then you don't need this phy-is-internal property, because you can
>> > locate the PHY node by the phy-handle (see more about that in a
>reply to
>> > patch 10) and you can determine ahead of time whether this PHY is
>> > internal or not based on its compatible string.
>>
>> This doesn't really work for us (sunxi). The "internal" PHY of the H3
>> is also available in the X-Powers AC200 combo chip, which would be
>> external. Same ID. So if someone were to be stupid and put the two
>> together, you wouldn't know which one it actually is. Generically
>> it doesn't make sense to match against the ID either. The PHY is
>> only integrated or inlined into the SoC, meaning it could be moved
>> elsewhere or even be a discreet part.
It actually makes a lot of sense to differentiate on the PHY ID because you are supposed to allocate an unique ID based on how the integration of the PHY is done. Not doing that is making a sloppy job at integrating HW blocks, but such is life and there is no shortage of creativity amongst HW engineers when they are not given feedback from SW people.
>>
>> The way I see it is more like a reversed pinmux. The system should
>> select either the internal set or external set of xMII pins to use.
>>
>> A phy-is-internal property in the PHY node would work for us. We
>> already need a PHY node to describe its clocks and resets.
>>
>> A side note to this solution is that, since the internal PHY is
>defined
>> at the .dtsi level, any external PHYs at the same address would need
>to
>> make sure to delete the property, which is kind of counterintuitive,
>but
>> it is how device tree works. One would want to put the internal PHY's
>> address, assuming it is configurable, on something that is rarely
>used.
>>
>
>Hello David, Florian, Andrew
>
>Could someone ack this ? or nack if you think that the chance for
>having two PHY id both internal and external is too low.
>Anyway, we need a choice.
Let's move forward with the 'phy-is-integrated' Boolean property ('phy-is-internal' is too close from the proprietary "internal" phy-mode IMHO). Andrew, does that also work for you?
--
Florian
^ permalink raw reply
* Re: [PATCH v4 05/12] Documentation: net: phy: Add phy-is-internal binding
From: Florian Fainelli @ 2017-08-09 22:47 UTC (permalink / raw)
To: David Wu, davem, heiko, andrew, robh+dt, mark.rutland,
catalin.marinas, will.deacon, olof, linux, arnd
Cc: peppe.cavallaro, alexandre.torgue, huangtao, hwg, netdev,
linux-arm-kernel, linux-rockchip, devicetree, linux-kernel
In-Reply-To: <1502280630-2254-1-git-send-email-david.wu@rock-chips.com>
On August 9, 2017 5:10:30 AM PDT, David Wu <david.wu@rock-chips.com> wrote:
>Add the documentation for internal phy. A boolean property
>indicates that a internal phy will be used.
>
>Signed-off-by: David Wu <david.wu@rock-chips.com>
>---
> Documentation/devicetree/bindings/net/phy.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/Documentation/devicetree/bindings/net/phy.txt
>b/Documentation/devicetree/bindings/net/phy.txt
>index b558576..942c892 100644
>--- a/Documentation/devicetree/bindings/net/phy.txt
>+++ b/Documentation/devicetree/bindings/net/phy.txt
>@@ -52,6 +52,9 @@ Optional Properties:
> Mark the corresponding energy efficient ethernet mode as broken and
> request the ethernet to stop advertising it.
>
>+- phy-is-internal: If set, indicates that phy will connect to the MAC
>as a
>+ internal phy.
Something along the lines of:
If set, indicates that the PHY is integrated into the same physical package as the Ethernet MAC.
Please always capitalize PHY.
--
Florian
^ permalink raw reply
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