* [PATCH 1/5] net: xfrm: allow clearing socket xfrm policies.
From: Steffen Klassert @ 2017-12-15 12:19 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20171215121952.20745-1-steffen.klassert@secunet.com>
From: Lorenzo Colitti <lorenzo@google.com>
Currently it is possible to add or update socket policies, but
not clear them. Therefore, once a socket policy has been applied,
the socket cannot be used for unencrypted traffic.
This patch allows (privileged) users to clear socket policies by
passing in a NULL pointer and zero length argument to the
{IP,IPV6}_{IPSEC,XFRM}_POLICY setsockopts. This results in both
the incoming and outgoing policies being cleared.
The simple approach taken in this patch cannot clear socket
policies in only one direction. If desired this could be added
in the future, for example by continuing to pass in a length of
zero (which currently is guaranteed to return EMSGSIZE) and
making the policy be a pointer to an integer that contains one
of the XFRM_POLICY_{IN,OUT} enum values.
An alternative would have been to interpret the length as a
signed integer and use XFRM_POLICY_IN (i.e., 0) to clear the
input policy and -XFRM_POLICY_OUT (i.e., -1) to clear the output
policy.
Tested: https://android-review.googlesource.com/539816
Signed-off-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/xfrm/xfrm_policy.c | 2 +-
net/xfrm/xfrm_state.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 9542975eb2f9..3263662fb20a 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -1251,7 +1251,7 @@ EXPORT_SYMBOL(xfrm_policy_delete);
int xfrm_sk_policy_insert(struct sock *sk, int dir, struct xfrm_policy *pol)
{
- struct net *net = xp_net(pol);
+ struct net *net = sock_net(sk);
struct xfrm_policy *old_pol;
#ifdef CONFIG_XFRM_SUB_POLICY
diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
index 065d89606888..1b7856be3eeb 100644
--- a/net/xfrm/xfrm_state.c
+++ b/net/xfrm/xfrm_state.c
@@ -2048,6 +2048,13 @@ int xfrm_user_policy(struct sock *sk, int optname, u8 __user *optval, int optlen
struct xfrm_mgr *km;
struct xfrm_policy *pol = NULL;
+ if (!optval && !optlen) {
+ xfrm_sk_policy_insert(sk, XFRM_POLICY_IN, NULL);
+ xfrm_sk_policy_insert(sk, XFRM_POLICY_OUT, NULL);
+ __sk_dst_reset(sk);
+ return 0;
+ }
+
if (optlen <= 0 || optlen > PAGE_SIZE)
return -EMSGSIZE;
--
2.14.1
^ permalink raw reply related
* [PATCH 2/5] xfrm: add documentation for xfrm device offload api
From: Steffen Klassert @ 2017-12-15 12:19 UTC (permalink / raw)
To: David Miller; +Cc: Herbert Xu, Steffen Klassert, netdev
In-Reply-To: <20171215121952.20745-1-steffen.klassert@secunet.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Add a writeup on how to use the XFRM device offload API, and
mention this new file in the index.
Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
---
Documentation/networking/00-INDEX | 2 +
Documentation/networking/xfrm_device.txt | 132 +++++++++++++++++++++++++++++++
2 files changed, 134 insertions(+)
create mode 100644 Documentation/networking/xfrm_device.txt
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 7a79b3587dd3..f5d642c01dd3 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -228,6 +228,8 @@ x25.txt
- general info on X.25 development.
x25-iface.txt
- description of the X.25 Packet Layer to LAPB device interface.
+xfrm_device.txt
+ - description of XFRM offload API
xfrm_proc.txt
- description of the statistics package for XFRM.
xfrm_sync.txt
diff --git a/Documentation/networking/xfrm_device.txt b/Documentation/networking/xfrm_device.txt
new file mode 100644
index 000000000000..2d9d588cd34b
--- /dev/null
+++ b/Documentation/networking/xfrm_device.txt
@@ -0,0 +1,132 @@
+
+===============================================
+XFRM device - offloading the IPsec computations
+===============================================
+Shannon Nelson <shannon.nelson@oracle.com>
+
+
+Overview
+========
+
+IPsec is a useful feature for securing network traffic, but the
+computational cost is high: a 10Gbps link can easily be brought down
+to under 1Gbps, depending on the traffic and link configuration.
+Luckily, there are NICs that offer a hardware based IPsec offload which
+can radically increase throughput and decrease CPU utilization. The XFRM
+Device interface allows NIC drivers to offer to the stack access to the
+hardware offload.
+
+Userland access to the offload is typically through a system such as
+libreswan or KAME/raccoon, but the iproute2 'ip xfrm' command set can
+be handy when experimenting. An example command might look something
+like this:
+
+ ip x s add proto esp dst 14.0.0.70 src 14.0.0.52 spi 0x07 mode transport \
+ reqid 0x07 replay-window 32 \
+ aead 'rfc4106(gcm(aes))' 0x44434241343332312423222114131211f4f3f2f1 128 \
+ sel src 14.0.0.52/24 dst 14.0.0.70/24 proto tcp \
+ offload dev eth4 dir in
+
+Yes, that's ugly, but that's what shell scripts and/or libreswan are for.
+
+
+
+Callbacks to implement
+======================
+
+/* from include/linux/netdevice.h */
+struct xfrmdev_ops {
+ int (*xdo_dev_state_add) (struct xfrm_state *x);
+ void (*xdo_dev_state_delete) (struct xfrm_state *x);
+ void (*xdo_dev_state_free) (struct xfrm_state *x);
+ bool (*xdo_dev_offload_ok) (struct sk_buff *skb,
+ struct xfrm_state *x);
+};
+
+The NIC driver offering ipsec offload will need to implement these
+callbacks to make the offload available to the network stack's
+XFRM subsytem. Additionally, the feature bits NETIF_F_HW_ESP and
+NETIF_F_HW_ESP_TX_CSUM will signal the availability of the offload.
+
+
+
+Flow
+====
+
+At probe time and before the call to register_netdev(), the driver should
+set up local data structures and XFRM callbacks, and set the feature bits.
+The XFRM code's listener will finish the setup on NETDEV_REGISTER.
+
+ adapter->netdev->xfrmdev_ops = &ixgbe_xfrmdev_ops;
+ adapter->netdev->features |= NETIF_F_HW_ESP;
+ adapter->netdev->hw_enc_features |= NETIF_F_HW_ESP;
+
+When new SAs are set up with a request for "offload" feature, the
+driver's xdo_dev_state_add() will be given the new SA to be offloaded
+and an indication of whether it is for Rx or Tx. The driver should
+ - verify the algorithm is supported for offloads
+ - store the SA information (key, salt, target-ip, protocol, etc)
+ - enable the HW offload of the SA
+
+The driver can also set an offload_handle in the SA, an opaque void pointer
+that can be used to convey context into the fast-path offload requests.
+
+ xs->xso.offload_handle = context;
+
+
+When the network stack is preparing an IPsec packet for an SA that has
+been setup for offload, it first calls into xdo_dev_offload_ok() with
+the skb and the intended offload state to ask the driver if the offload
+will serviceable. This can check the packet information to be sure the
+offload can be supported (e.g. IPv4 or IPv6, no IPv4 options, etc) and
+return true of false to signify its support.
+
+When ready to send, the driver needs to inspect the Tx packet for the
+offload information, including the opaque context, and set up the packet
+send accordingly.
+
+ xs = xfrm_input_state(skb);
+ context = xs->xso.offload_handle;
+ set up HW for send
+
+The stack has already inserted the appropriate IPsec headers in the
+packet data, the offload just needs to do the encryption and fix up the
+header values.
+
+
+When a packet is received and the HW has indicated that it offloaded a
+decryption, the driver needs to add a reference to the decoded SA into
+the packet's skb. At this point the data should be decrypted but the
+IPsec headers are still in the packet data; they are removed later up
+the stack in xfrm_input().
+
+ find and hold the SA that was used to the Rx skb
+ get spi, protocol, and destination IP from packet headers
+ xs = find xs from (spi, protocol, dest_IP)
+ xfrm_state_hold(xs);
+
+ store the state information into the skb
+ skb->sp = secpath_dup(skb->sp);
+ skb->sp->xvec[skb->sp->len++] = xs;
+ skb->sp->olen++;
+
+ indicate the success and/or error status of the offload
+ xo = xfrm_offload(skb);
+ xo->flags = CRYPTO_DONE;
+ xo->status = crypto_status;
+
+ hand the packet to napi_gro_receive() as usual
+
+
+When the SA is removed by the user, the driver's xdo_dev_state_delete()
+is asked to disable the offload. Later, xdo_dev_state_free() is called
+from a garbage collection routine after all reference counts to the state
+have been removed and any remaining resources can be cleared for the
+offload state. How these are used by the driver will depend on specific
+hardware needs.
+
+As a netdev is set to DOWN the XFRM stack's netdev listener will call
+xdo_dev_state_delete() and xdo_dev_state_free() on any remaining offloaded
+states.
+
+
--
2.14.1
^ permalink raw reply related
* Re: [RFT/RFC net-next 0/2] net: dsa: Plug in PHYLINK support
From: Andrew Lunn @ 2017-12-15 12:48 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Florian Fainelli, netdev, sean.wang, john, kernel, privat,
Woojung.Huh, vivien.didelot
In-Reply-To: <20171215120831.GS10595@n2100.armlinux.org.uk>
> 1. s/WARN_ON(!lockdep_rtnl_is_held())/ASSERT_RTNL()/ in phylink.c -
> probably wouldn't have been noticed if it wasn't for the lockdep
> splat with DSA's interrupt handling during boot that's been there
> since -rc1. (Andrew mentioned that it's known, so I haven't
> reported that.)
Hi Russell
https://lkml.org/lkml/2017/12/2/260
This should fix that splat. I hope it will get picked up at some
point. It is probably getting on time to repost it.
Andrew
^ permalink raw reply
* Re: [PATCH bpf-next 0/5] nfp: bpf: adjust head support
From: Daniel Borkmann @ 2017-12-15 13:21 UTC (permalink / raw)
To: Jakub Kicinski, netdev; +Cc: oss-drivers, alexei.starovoitov
In-Reply-To: <20171215052919.18343-1-jakub.kicinski@netronome.com>
On 12/15/2017 06:29 AM, Jakub Kicinski wrote:
> Hi!
>
> This small set adds support for bpf_xdp_adjust_head() to the offload.
> Since we have access to unmodified BPF bytecode translating calls is
> pretty trivial. First part of the series adds handling of BPF
> capabilities included in the FW in TLV format. The last two patches
> add adjust head support in the nfp verifier and jit, and a small
> optimization in case we can guarantee the constant adjustment
> will always meet adjustment constaints.
Series applied to bpf-next, thanks Jakub!
^ permalink raw reply
* [patch net] mlxsw: spectrum: Disable MAC learning for ovs port
From: Jiri Pirko @ 2017-12-15 13:26 UTC (permalink / raw)
To: netdev; +Cc: davem, yuvalm, idosch, mlxsw
From: Yuval Mintz <yuvalm@mellanox.com>
Learning is currently enabled for ports which are OVS slaves -
even though OVS doesn't need this indication.
Since we're not associating a fid with the port, HW would continuously
notify driver of learned [& aged] MACs which would be logged as errors.
Fixes: 2b94e58df58c ("mlxsw: spectrum: Allow ports to work under OVS master")
Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
index 2d0897b..9bd8d28 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.c
@@ -4300,6 +4300,7 @@ static int mlxsw_sp_port_stp_set(struct mlxsw_sp_port *mlxsw_sp_port,
static int mlxsw_sp_port_ovs_join(struct mlxsw_sp_port *mlxsw_sp_port)
{
+ u16 vid = 1;
int err;
err = mlxsw_sp_port_vp_mode_set(mlxsw_sp_port, true);
@@ -4312,8 +4313,19 @@ static int mlxsw_sp_port_ovs_join(struct mlxsw_sp_port *mlxsw_sp_port)
true, false);
if (err)
goto err_port_vlan_set;
+
+ for (; vid <= VLAN_N_VID - 1; vid++) {
+ err = mlxsw_sp_port_vid_learning_set(mlxsw_sp_port,
+ vid, false);
+ if (err)
+ goto err_vid_learning_set;
+ }
+
return 0;
+err_vid_learning_set:
+ for (vid--; vid >= 1; vid--)
+ mlxsw_sp_port_vid_learning_set(mlxsw_sp_port, vid, true);
err_port_vlan_set:
mlxsw_sp_port_stp_set(mlxsw_sp_port, false);
err_port_stp_set:
@@ -4323,6 +4335,12 @@ static int mlxsw_sp_port_ovs_join(struct mlxsw_sp_port *mlxsw_sp_port)
static void mlxsw_sp_port_ovs_leave(struct mlxsw_sp_port *mlxsw_sp_port)
{
+ u16 vid;
+
+ for (vid = VLAN_N_VID - 1; vid >= 1; vid--)
+ mlxsw_sp_port_vid_learning_set(mlxsw_sp_port,
+ vid, true);
+
mlxsw_sp_port_vlan_set(mlxsw_sp_port, 2, VLAN_N_VID - 1,
false, false);
mlxsw_sp_port_stp_set(mlxsw_sp_port, false);
--
2.9.5
^ permalink raw reply related
* [PATCH net-next] net: dsa: lan9303: lan9303_csr_reg_wait cleanups
From: Egil Hjelmeland @ 2017-12-15 13:28 UTC (permalink / raw)
To: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
Non-functional cleanups in lan9303_csr_reg_wait():
- Change type of param 'mask' from int to u32.
- Remove param 'value' (will probably never be used)
- Reduced retries from 1000 to 25, consistent with lan9303_read_wait.
- Corrected comments
Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
---
drivers/net/dsa/lan9303-core.c | 15 +++++++--------
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
index f412aad58253..209882075e3b 100644
--- a/drivers/net/dsa/lan9303-core.c
+++ b/drivers/net/dsa/lan9303-core.c
@@ -249,7 +249,7 @@ static int lan9303_read(struct regmap *regmap, unsigned int offset, u32 *reg)
return -EIO;
}
-/* Wait a while until mask & reg == value. Otherwise return timeout. */
+/* Wait a while until mask & reg == 0. Otherwise return timeout. */
static int lan9303_read_wait(struct lan9303 *chip, int offset, u32 mask)
{
int i;
@@ -541,20 +541,20 @@ lan9303_alr_cache_find_mac(struct lan9303 *chip, const u8 *mac_addr)
return NULL;
}
-/* Wait a while until mask & reg == value. Otherwise return timeout. */
-static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno,
- int mask, char value)
+/* Wait a while until mask & reg == 0. Otherwise return timeout. */
+static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno, u32 mask)
{
int i;
- for (i = 0; i < 0x1000; i++) {
+ for (i = 0; i < 25; i++) {
u32 reg;
lan9303_read_switch_reg(chip, regno, ®);
- if ((reg & mask) == value)
+ if (!(reg & mask))
return 0;
usleep_range(1000, 2000);
}
+
return -ETIMEDOUT;
}
@@ -564,8 +564,7 @@ static int lan9303_alr_make_entry_raw(struct lan9303 *chip, u32 dat0, u32 dat1)
lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_WR_DAT_1, dat1);
lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD,
LAN9303_ALR_CMD_MAKE_ENTRY);
- lan9303_csr_reg_wait(chip, LAN9303_SWE_ALR_CMD_STS, ALR_STS_MAKE_PEND,
- 0);
+ lan9303_csr_reg_wait(chip, LAN9303_SWE_ALR_CMD_STS, ALR_STS_MAKE_PEND);
lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
return 0;
--
2.14.1
^ permalink raw reply related
* Re: [PATCH bpf] xdp: linearize skb in netif_receive_generic_xdp()
From: Daniel Borkmann @ 2017-12-15 13:39 UTC (permalink / raw)
To: Song Liu, netdev; +Cc: kernel-team, Alexei Starovoitov
In-Reply-To: <20171215011756.573758-1-songliubraving@fb.com>
On 12/15/2017 02:17 AM, Song Liu wrote:
> In netif_receive_generic_xdp(), it is necessary to linearize all
> nonlinear skb. However, in current implementation, skb with
> troom <= 0 are not linearized. This patch fixes this by calling
> skb_linearize() for all nonlinear skb.
>
> Fixes: de8f3a83b0a0 ("bpf: add meta pointer for direct access")
> Signed-off-by: Song Liu <songliubraving@fb.com>
> Acked-by: Martin KaFai Lau <kafai@fb.com>
> Cc: Daniel Borkmann <daniel@iogearbox.net>
> Cc: Alexei Starovoitov <ast@kernel.org>
Agree, applied to bpf, thanks Song!
^ permalink raw reply
* Re: [PATCH v2 iproute2 1/1] ss: add missing path MTU parameter
From: Roman Mashak @ 2017-12-15 13:58 UTC (permalink / raw)
To: Stefano Brivio; +Cc: stephen, netdev, jhs
In-Reply-To: <20171215094515.386f8e6f@elisabeth>
Stefano Brivio <sbrivio@redhat.com> writes:
> On Thu, 14 Dec 2017 14:59:11 -0500
> Roman Mashak <mrv@mojatatu.com> wrote:
>
>> @@ -1959,6 +1960,8 @@ static void tcp_stats_print(struct tcpstat *s)
>>
>> if (s->mss)
>> printf(" mss:%d", s->mss);
>> + if (s->pmtu)
>> + printf(" pmtu:%u", s->pmtu);
>
> You'll simply need to change this to out() now, as this print will be
> buffered.
Oh I see why it does not apply, I'll resubmit. Thanks Stefano.
^ permalink raw reply
* Re: [PATCH 2/4] sctp: Add ip option support
From: Paul Moore @ 2017-12-15 14:02 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Richard Haines, selinux, netdev, linux-sctp,
linux-security-module, Vlad Yasevich, nhorman, Stephen Smalley,
Eric Paris
In-Reply-To: <20171214210422.GQ3532@localhost.localdomain>
On December 14, 2017 4:04:28 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
> On Tue, Dec 12, 2017 at 05:24:46PM -0500, Paul Moore wrote:
>> On Tue, Dec 12, 2017 at 4:56 PM, Marcelo Ricardo Leitner
>> <marcelo.leitner@gmail.com> wrote:
>> > On Tue, Dec 12, 2017 at 04:33:03PM -0500, Paul Moore wrote:
>> >> On Tue, Dec 12, 2017 at 11:08 AM, Marcelo Ricardo Leitner
>> >> <marcelo.leitner@gmail.com> wrote:
>> >> > Hi Richard,
>> >> >
>> >> > On Mon, Nov 27, 2017 at 07:31:21PM +0000, Richard Haines wrote:
>> >> > ...
>> >> >> --- a/net/sctp/socket.c
>> >> >> +++ b/net/sctp/socket.c
>> >> >> @@ -3123,8 +3123,10 @@ static int sctp_setsockopt_maxseg(struct sock
>> *sk, char __user *optval, unsigned
>> >> >>
>> >> >> if (asoc) {
>> >> >> if (val == 0) {
>> >> >> + struct sctp_af *af = sp->pf->af;
>> >> >> val = asoc->pathmtu;
>> >> >> - val -= sp->pf->af->net_header_len;
>> >> >> + val -= af->ip_options_len(asoc->base.sk);
>> >> >> + val -= af->net_header_len;
>> >> >> val -= sizeof(struct sctphdr) +
>> >> >> sizeof(struct sctp_data_chunk);
>> >> >> }
>> >> >
>> >> > Right below here there is a call to sctp_frag_point(). That function
>> >> > also needs this tweak.
>> >> >
>> >> > Yes, we should simplify all these calculations. I have a patch to use
>> >> > sctp_frag_point on where it is currently recalculating it on
>> >> > sctp_datamsg_from_user(), but probably should include other places as
>> >> > well.
>> >>
>> >> FYI: Richard let me know he is occupied with another project at the
>> >> moment and likely won't be able to do another respin until next week
>> >> at the earliest.
>> >
>> > Okay, thanks. I can do a follow-up patch if it helps.
>>
>> I'll leave that up to you, I think your comments are pretty
>> straightforward and should be easy for Richard to incorporate, and
>> there is a lot to be said for including the fix in the original patch,
>> but if you would prefer to send a separate patch I think that's fine
>> too.
>
> This patchset conflicts with the stream schedulers patchset (on
> sctp.h) and will also conflict with the stream interleaving patchsets
> from Xin (other files).
>
> I rebased the patchset upon current crypto tree but the last patchset
> on stream interleaving is still to be accepted via net-next.
>
> I'm unsure on how to proceed here. Please advise.
>
> Thanks,
> Marcelo
I still believe the right course of action is to merge this via the SELinux
tree (based on Linus' tree). Due to the nature of SELinux we often have to
deal with conflicts like this; I haven't seen the conflicts your talking
about (I'm currently traveling with limited access) but Linus should be
able to handle the trivial fixes, if it is more complex we can provide
guidance about how to resolve it.
^ permalink raw reply
* Re: [PATCH v2 net-next 1/3] net: dsa: mediatek: add VLAN support for MT7530
From: kbuild test robot @ 2017-12-15 14:13 UTC (permalink / raw)
To: sean.wang
Cc: kbuild-all, davem, andrew, f.fainelli, vivien.didelot, netdev,
linux-kernel, linux-mediatek, Sean Wang
In-Reply-To: <72a0a9f2748193bc02fed5e74c343aa5397348b7.1513136754.git.sean.wang@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 8625 bytes --]
Hi Sean,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/sean-wang-mediatek-com/add-VLAN-support-to-DSA-MT7530/20171215-214450
config: i386-randconfig-x019-201750 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/net/dsa/mt7530.c: In function 'mt7530_port_vlan_add':
drivers/net/dsa/mt7530.c:1131:6: warning: unused variable 'ret' [-Wunused-variable]
int ret;
^~~
drivers/net/dsa/mt7530.c: At top level:
>> drivers/net/dsa/mt7530.c:1324:23: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.port_vlan_prepare = mt7530_port_vlan_prepare,
^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/dsa/mt7530.c:1324:23: note: (near initialization for 'mt7530_switch_ops.port_vlan_prepare')
drivers/net/dsa/mt7530.c:1325:20: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.port_vlan_add = mt7530_port_vlan_add,
^~~~~~~~~~~~~~~~~~~~
drivers/net/dsa/mt7530.c:1325:20: note: (near initialization for 'mt7530_switch_ops.port_vlan_add')
cc1: some warnings being treated as errors
vim +1324 drivers/net/dsa/mt7530.c
1121
1122 static void
1123 mt7530_port_vlan_add(struct dsa_switch *ds, int port,
1124 const struct switchdev_obj_port_vlan *vlan,
1125 struct switchdev_trans *trans)
1126 {
1127 bool untagged = vlan->flags & BRIDGE_VLAN_INFO_UNTAGGED;
1128 bool pvid = vlan->flags & BRIDGE_VLAN_INFO_PVID;
1129 struct mt7530_hw_vlan_entry new_entry;
1130 struct mt7530_priv *priv = ds->priv;
> 1131 int ret;
1132 u16 vid;
1133
1134 /* The port is kept as VLAN-unaware if bridge with vlan_filtering not
1135 * being set.
1136 */
1137 if (!priv->ports[port].vlan_filtering)
1138 return;
1139
1140 mutex_lock(&priv->reg_mutex);
1141
1142 for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
1143 mt7530_hw_vlan_entry_init(&new_entry, port, untagged);
1144 mt7530_hw_vlan_update(priv, vid, &new_entry,
1145 mt7530_hw_vlan_add);
1146 }
1147
1148 if (pvid) {
1149 mt7530_rmw(priv, MT7530_PPBV1_P(port), G0_PORT_VID_MASK,
1150 G0_PORT_VID(vlan->vid_end));
1151 priv->ports[port].pvid = vlan->vid_end;
1152 }
1153
1154 mutex_unlock(&priv->reg_mutex);
1155 }
1156
1157 static int
1158 mt7530_port_vlan_del(struct dsa_switch *ds, int port,
1159 const struct switchdev_obj_port_vlan *vlan)
1160 {
1161 struct mt7530_hw_vlan_entry target_entry;
1162 struct mt7530_priv *priv = ds->priv;
1163 u16 vid, pvid;
1164
1165 /* The port is kept as VLAN-unaware if bridge with vlan_filtering not
1166 * being set.
1167 */
1168 if (!priv->ports[port].vlan_filtering)
1169 return 0;
1170
1171 mutex_lock(&priv->reg_mutex);
1172
1173 pvid = priv->ports[port].pvid;
1174 for (vid = vlan->vid_begin; vid <= vlan->vid_end; ++vid) {
1175 mt7530_hw_vlan_entry_init(&target_entry, port, 0);
1176 mt7530_hw_vlan_update(priv, vid, &target_entry,
1177 mt7530_hw_vlan_del);
1178
1179 /* PVID is being restored to the default whenever the PVID port
1180 * is being removed from the VLAN.
1181 */
1182 if (pvid == vid)
1183 pvid = G0_PORT_VID_DEF;
1184 }
1185
1186 mt7530_rmw(priv, MT7530_PPBV1_P(port), G0_PORT_VID_MASK, pvid);
1187 priv->ports[port].pvid = pvid;
1188
1189 mutex_unlock(&priv->reg_mutex);
1190
1191 return 0;
1192 }
1193
1194 static enum dsa_tag_protocol
1195 mtk_get_tag_protocol(struct dsa_switch *ds, int port)
1196 {
1197 struct mt7530_priv *priv = ds->priv;
1198
1199 if (port != MT7530_CPU_PORT) {
1200 dev_warn(priv->dev,
1201 "port not matched with tagging CPU port\n");
1202 return DSA_TAG_PROTO_NONE;
1203 } else {
1204 return DSA_TAG_PROTO_MTK;
1205 }
1206 }
1207
1208 static int
1209 mt7530_setup(struct dsa_switch *ds)
1210 {
1211 struct mt7530_priv *priv = ds->priv;
1212 int ret, i;
1213 u32 id, val;
1214 struct device_node *dn;
1215 struct mt7530_dummy_poll p;
1216
1217 /* The parent node of master netdev which holds the common system
1218 * controller also is the container for two GMACs nodes representing
1219 * as two netdev instances.
1220 */
1221 dn = ds->ports[MT7530_CPU_PORT].master->dev.of_node->parent;
1222 priv->ethernet = syscon_node_to_regmap(dn);
1223 if (IS_ERR(priv->ethernet))
1224 return PTR_ERR(priv->ethernet);
1225
1226 regulator_set_voltage(priv->core_pwr, 1000000, 1000000);
1227 ret = regulator_enable(priv->core_pwr);
1228 if (ret < 0) {
1229 dev_err(priv->dev,
1230 "Failed to enable core power: %d\n", ret);
1231 return ret;
1232 }
1233
1234 regulator_set_voltage(priv->io_pwr, 3300000, 3300000);
1235 ret = regulator_enable(priv->io_pwr);
1236 if (ret < 0) {
1237 dev_err(priv->dev, "Failed to enable io pwr: %d\n",
1238 ret);
1239 return ret;
1240 }
1241
1242 /* Reset whole chip through gpio pin or memory-mapped registers for
1243 * different type of hardware
1244 */
1245 if (priv->mcm) {
1246 reset_control_assert(priv->rstc);
1247 usleep_range(1000, 1100);
1248 reset_control_deassert(priv->rstc);
1249 } else {
1250 gpiod_set_value_cansleep(priv->reset, 0);
1251 usleep_range(1000, 1100);
1252 gpiod_set_value_cansleep(priv->reset, 1);
1253 }
1254
1255 /* Waiting for MT7530 got to stable */
1256 INIT_MT7530_DUMMY_POLL(&p, priv, MT7530_HWTRAP);
1257 ret = readx_poll_timeout(_mt7530_read, &p, val, val != 0,
1258 20, 1000000);
1259 if (ret < 0) {
1260 dev_err(priv->dev, "reset timeout\n");
1261 return ret;
1262 }
1263
1264 id = mt7530_read(priv, MT7530_CREV);
1265 id >>= CHIP_NAME_SHIFT;
1266 if (id != MT7530_ID) {
1267 dev_err(priv->dev, "chip %x can't be supported\n", id);
1268 return -ENODEV;
1269 }
1270
1271 /* Reset the switch through internal reset */
1272 mt7530_write(priv, MT7530_SYS_CTRL,
1273 SYS_CTRL_PHY_RST | SYS_CTRL_SW_RST |
1274 SYS_CTRL_REG_RST);
1275
1276 /* Enable Port 6 only; P5 as GMAC5 which currently is not supported */
1277 val = mt7530_read(priv, MT7530_MHWTRAP);
1278 val &= ~MHWTRAP_P6_DIS & ~MHWTRAP_PHY_ACCESS;
1279 val |= MHWTRAP_MANUAL;
1280 mt7530_write(priv, MT7530_MHWTRAP, val);
1281
1282 /* Enable and reset MIB counters */
1283 mt7530_mib_reset(ds);
1284
1285 mt7530_clear(priv, MT7530_MFC, UNU_FFP_MASK);
1286
1287 for (i = 0; i < MT7530_NUM_PORTS; i++) {
1288 /* Disable forwarding by default on all ports */
1289 mt7530_rmw(priv, MT7530_PCR_P(i), PCR_MATRIX_MASK,
1290 PCR_MATRIX_CLR);
1291
1292 if (dsa_is_cpu_port(ds, i))
1293 mt7530_cpu_port_enable(priv, i);
1294 else
1295 mt7530_port_disable(ds, i, NULL);
1296 }
1297
1298 /* Flush the FDB table */
1299 ret = mt7530_fdb_cmd(priv, MT7530_FDB_FLUSH, 0);
1300 if (ret < 0)
1301 return ret;
1302
1303 return 0;
1304 }
1305
1306 static const struct dsa_switch_ops mt7530_switch_ops = {
1307 .get_tag_protocol = mtk_get_tag_protocol,
1308 .setup = mt7530_setup,
1309 .get_strings = mt7530_get_strings,
1310 .phy_read = mt7530_phy_read,
1311 .phy_write = mt7530_phy_write,
1312 .get_ethtool_stats = mt7530_get_ethtool_stats,
1313 .get_sset_count = mt7530_get_sset_count,
1314 .adjust_link = mt7530_adjust_link,
1315 .port_enable = mt7530_port_enable,
1316 .port_disable = mt7530_port_disable,
1317 .port_stp_state_set = mt7530_stp_state_set,
1318 .port_bridge_join = mt7530_port_bridge_join,
1319 .port_bridge_leave = mt7530_port_bridge_leave,
1320 .port_fdb_add = mt7530_port_fdb_add,
1321 .port_fdb_del = mt7530_port_fdb_del,
1322 .port_fdb_dump = mt7530_port_fdb_dump,
1323 .port_vlan_filtering = mt7530_port_vlan_filtering,
> 1324 .port_vlan_prepare = mt7530_port_vlan_prepare,
1325 .port_vlan_add = mt7530_port_vlan_add,
1326 .port_vlan_del = mt7530_port_vlan_del,
1327 };
1328
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 33639 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/2] nfp: fix rtsym and XDP register handling in debug dump
From: Simon Horman @ 2017-12-15 14:18 UTC (permalink / raw)
To: David Miller, Jakub Kicinski; +Cc: netdev, oss-drivers, Carl Heymann
In-Reply-To: <20171214095026.11665-1-simon.horman@netronome.com>
On Thu, Dec 14, 2017 at 10:50:24AM +0100, Simon Horman wrote:
> Hi,
>
> this series resolves two problems in the recently added debug dump facility.
>
> * Correctly handle reading absolute rtysms
> * Correctly handle special-case PB register reads
>
> These fixes are for code only present in net-next.
Hi Dave,
It seems that I made a thinko in the title of the cover letter. s/XDP/XPB/
These changes do not relate to XDP.
> Carl Heymann (2):
> nfp: fix absolute rtsym handling in debug dump
> nfp: fix XPB register reads in debug dump
>
> .../net/ethernet/netronome/nfp/nfp_net_debugdump.c | 57 +++++++++++++++-------
> 1 file changed, 39 insertions(+), 18 deletions(-)
>
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH v3 iproute2 1/1] ss: add missing path MTU parameter
From: Roman Mashak @ 2017-12-15 14:27 UTC (permalink / raw)
To: stephen; +Cc: netdev, jhs, Roman Mashak
v3:
Rebase and use out() instead of printf().
v2:
Print the path MTU immediately after the MSS, as it is easier to parse
for humans (suggested by Neal Cardwell).
Signed-off-by: Roman Mashak <mrv@mojatatu.com>
---
man/man8/ss.8 | 4 ++++
misc/ss.c | 4 ++++
2 files changed, 8 insertions(+)
diff --git a/man/man8/ss.8 b/man/man8/ss.8
index 6d06383..0d52673 100644
--- a/man/man8/ss.8
+++ b/man/man8/ss.8
@@ -184,6 +184,10 @@ max segment size
congestion window size
.P
.TP
+.B pmtu:<pmtu>
+path MTU value
+.P
+.TP
.B ssthresh:<ssthresh>
tcp congestion window slow start threshold
.P
diff --git a/misc/ss.c b/misc/ss.c
index 9d21ed7..1abf43d 100644
--- a/misc/ss.c
+++ b/misc/ss.c
@@ -790,6 +790,7 @@ struct tcpstat {
int mss;
int rcv_mss;
int advmss;
+ unsigned int pmtu;
unsigned int cwnd;
unsigned int lastsnd;
unsigned int lastrcv;
@@ -2360,6 +2361,8 @@ static void tcp_stats_print(struct tcpstat *s)
if (s->mss)
out(" mss:%d", s->mss);
+ if (s->pmtu)
+ out(" pmtu:%u", s->pmtu);
if (s->rcv_mss)
out(" rcvmss:%d", s->rcv_mss);
if (s->advmss)
@@ -2707,6 +2710,7 @@ static void tcp_show_info(const struct nlmsghdr *nlh, struct inet_diag_msg *r,
s.reordering = info->tcpi_reordering;
s.rcv_ssthresh = info->tcpi_rcv_ssthresh;
s.cwnd = info->tcpi_snd_cwnd;
+ s.pmtu = info->tcpi_pmtu;
if (info->tcpi_snd_ssthresh < 0xFFFF)
s.ssthresh = info->tcpi_snd_ssthresh;
--
2.7.4
^ permalink raw reply related
* [PATCH] net: qcom/emac: Reduce timeout for mdio read/write
From: Hemanth Puranik @ 2017-12-15 14:35 UTC (permalink / raw)
To: netdev, linux-kernel; +Cc: Timur Tabi, Hemanth Puranik
Currently mdio read/write takes around ~115us as the timeout
between status check is set to 100us.
By reducing the timeout to 1us mdio read/write takes ~15us to
complete. This improves the link up event response.
Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index 18461fc..53dbf1e 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -47,6 +47,7 @@
#define MDIO_CLK_25_28 7
#define MDIO_WAIT_TIMES 1000
+#define MDIO_STATUS_DELAY_TIME 1
static int emac_mdio_read(struct mii_bus *bus, int addr, int regnum)
{
@@ -65,7 +66,7 @@ static int emac_mdio_read(struct mii_bus *bus, int addr, int regnum)
if (readl_poll_timeout(adpt->base + EMAC_MDIO_CTRL, reg,
!(reg & (MDIO_START | MDIO_BUSY)),
- 100, MDIO_WAIT_TIMES * 100))
+ MDIO_STATUS_DELAY_TIME, MDIO_WAIT_TIMES * 100))
return -EIO;
return (reg >> MDIO_DATA_SHFT) & MDIO_DATA_BMSK;
@@ -88,8 +89,8 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
writel(reg, adpt->base + EMAC_MDIO_CTRL);
if (readl_poll_timeout(adpt->base + EMAC_MDIO_CTRL, reg,
- !(reg & (MDIO_START | MDIO_BUSY)), 100,
- MDIO_WAIT_TIMES * 100))
+ !(reg & (MDIO_START | MDIO_BUSY)),
+ MDIO_STATUS_DELAY_TIME, MDIO_WAIT_TIMES * 100))
return -EIO;
return 0;
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Re: [PATCH net-next] net: dsa: lan9303: lan9303_csr_reg_wait cleanups
From: Vivien Didelot @ 2017-12-15 14:49 UTC (permalink / raw)
To: Egil Hjelmeland, andrew, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20171215132859.4553-1-privat@egil-hjelmeland.no>
Hi Egil,
Egil Hjelmeland <privat@egil-hjelmeland.no> writes:
> Non-functional cleanups in lan9303_csr_reg_wait():
> - Change type of param 'mask' from int to u32.
> - Remove param 'value' (will probably never be used)
> - Reduced retries from 1000 to 25, consistent with lan9303_read_wait.
> - Corrected comments
>
> Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
> ---
> drivers/net/dsa/lan9303-core.c | 15 +++++++--------
> 1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c
> index f412aad58253..209882075e3b 100644
> --- a/drivers/net/dsa/lan9303-core.c
> +++ b/drivers/net/dsa/lan9303-core.c
> @@ -249,7 +249,7 @@ static int lan9303_read(struct regmap *regmap, unsigned int offset, u32 *reg)
> return -EIO;
> }
>
> -/* Wait a while until mask & reg == value. Otherwise return timeout. */
> +/* Wait a while until mask & reg == 0. Otherwise return timeout. */
I'd remove this comment completely. The related code below is quite
explicit and speaks for itself, no need for an extra comment IMO.
for (...)
if (!(mask & reg))
return 0;
return -ETIMEOUT;
> static int lan9303_read_wait(struct lan9303 *chip, int offset, u32 mask)
> {
> int i;
> @@ -541,20 +541,20 @@ lan9303_alr_cache_find_mac(struct lan9303 *chip, const u8 *mac_addr)
> return NULL;
> }
>
> -/* Wait a while until mask & reg == value. Otherwise return timeout. */
> -static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno,
> - int mask, char value)
> +/* Wait a while until mask & reg == 0. Otherwise return timeout. */
Same here, no need to add some code in a comment.
> +static int lan9303_csr_reg_wait(struct lan9303 *chip, int regno, u32 mask)
> {
> int i;
>
> - for (i = 0; i < 0x1000; i++) {
> + for (i = 0; i < 25; i++) {
> u32 reg;
>
> lan9303_read_switch_reg(chip, regno, ®);
> - if ((reg & mask) == value)
> + if (!(reg & mask))
> return 0;
> usleep_range(1000, 2000);
> }
> +
> return -ETIMEDOUT;
> }
>
> @@ -564,8 +564,7 @@ static int lan9303_alr_make_entry_raw(struct lan9303 *chip, u32 dat0, u32 dat1)
> lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_WR_DAT_1, dat1);
> lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD,
> LAN9303_ALR_CMD_MAKE_ENTRY);
> - lan9303_csr_reg_wait(chip, LAN9303_SWE_ALR_CMD_STS, ALR_STS_MAKE_PEND,
> - 0);
> + lan9303_csr_reg_wait(chip, LAN9303_SWE_ALR_CMD_STS, ALR_STS_MAKE_PEND);
> lan9303_write_switch_reg(chip, LAN9303_SWE_ALR_CMD, 0);
The rest of the patch makes sense.
Thanks,
Vivien
^ permalink raw reply
* net-next lan9303 and CONFIG_NET_DSA_LEGACY
From: Egil Hjelmeland @ 2017-12-15 14:51 UTC (permalink / raw)
To: andrew, Vivien Didelot, Florian Fainelli; +Cc: netdev
Hi
I found that our lan9303 board is unable to receive network data unless
CONFIG_NET_DSA_LEGACY is set. Is that a problem with the driver, or our
DTS? (imx28)
ahb@80080000 {
mac0: ethernet@800f0000 {
clocks = <&clks 57>, <&clks 57>, <&clks 64>;
clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
status = "okay";
fixed-link {
speed = <100>;
full-duplex;
};
mdio {
#address-cells = <1>;
#size-cells = <0>;
switch: switch-phy@0 {
compatible = "smsc,lan9303-mdio";
reg = <0>;
reset-gpios = <&gpio2 7 GPIO_ACTIVE_LOW >;
reset-duration = <10>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
label = "cpu";
ethernet = <&mac0>;
phy-mode = "rmii";
fixed-link {
speed = <100>;
full-duplex;
};
};
port@1 { /* external port 1 */
reg = <1>;
label = "sw1";
phy-mode = "rmii";
};
port@2 { /* external port 2 */
reg = <2>;
label = "sw2";
phy-mode = "rmii";
};
};
};
};
};
};
Any advise would be appreciated.
Egil
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Reduce timeout for mdio read/write
From: Timur Tabi @ 2017-12-15 15:20 UTC (permalink / raw)
To: Hemanth Puranik, netdev, linux-kernel
In-Reply-To: <1513348558-10906-1-git-send-email-hpuranik@codeaurora.org>
On 12/15/2017 08:35 AM, Hemanth Puranik wrote:
> Currently mdio read/write takes around ~115us as the timeout
> between status check is set to 100us.
> By reducing the timeout to 1us mdio read/write takes ~15us to
> complete. This improves the link up event response.
>
> Signed-off-by: Hemanth Puranik<hpuranik@codeaurora.org>
Acked-by: Timur Tabi <timur@codeaurora.org>
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/3] add VLAN support to DSA MT7530
From: David Miller @ 2017-12-15 15:35 UTC (permalink / raw)
To: sean.wang
Cc: andrew, f.fainelli, vivien.didelot, netdev, linux-kernel,
linux-mediatek
In-Reply-To: <cover.1513312600.git.sean.wang@mediatek.com>
From: <sean.wang@mediatek.com>
Date: Fri, 15 Dec 2017 12:46:59 +0800
> From: Sean Wang <sean.wang@mediatek.com>
>
> Changes sicne v2:
> update to the latest code base from net-next and fix up all building
> errors with -Werror.
>
> Changes since v1:
> - fix up the typo
> - prefer ordering declarations longest to shortest
> - update that vlan_prepare callback should not change any state
> - use lower case letter for function naming
>
> The patchset extends DSA MT7530 to VLAN support through filling required
> callbacks in patch 1 and merging the special tag with VLAN tag in patch 2
> for allowing that the hardware can handle these packets with VID from the
> CPU port.
This one builds :-) Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x
From: Russell King - ARM Linux @ 2017-12-15 15:45 UTC (permalink / raw)
To: David Miller; +Cc: andrew, f.fainelli, jon, netdev
In-Reply-To: <20171213.161423.1305694719573286723.davem@davemloft.net>
On Wed, Dec 13, 2017 at 04:14:23PM -0500, David Miller wrote:
> From: Russell King <rmk+kernel@armlinux.org.uk>
> Date: Wed, 13 Dec 2017 09:22:09 +0000
>
> > @@ -924,6 +924,16 @@ static int m88e1510_config_init(struct phy_device *phydev)
> > err = marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
> > if (err < 0)
> > return err;
> > +
> > + /* There appears to be a bug in the 88e1512 when used in
> > + * SGMII to copper mode, where the AN advertisment register
> > + * clears the pause bits each time a negotiation occurs.
> > + * This means we can never be truely sure what was advertised,
> > + * so disable Pause support.
> > + */
> > + pause = SUPPORTED_Pause | SUPPORTED_Asym_Pause;
> > + phydev->supported &= ~pause;
> > + phydev->advertising &= ~pause;
> > }
> >
>
> This function doesn't have a local 'pause' variable in any of my trees.
>
> I wonder what you generated this against, and even more importantly, what
> tree the reviewers were considering when looking at this patch :)
Sorry about that, not quite sure how that happened, but here's a
replacement patch. I assume patchwork will do the right thing by
including the patch in this mail...
8<====
From: Russell King <rmk+kernel@armlinux.org.uk>
Subject: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for
88e151x
Observed on the 88e1512 in SGMII-to-Copper mode, negotiating pause
is unreliable. While the pause bits can be set in the advertisment
register, they clear shortly after negotiation with a link partner
commences irrespective of the cause of the negotiation.
While these bits may be correctly conveyed to the link partner on the
first negotiation, a subsequent negotiation (eg, due to negotiation
restart by the link partner, or reconnection of the cable) will result
in the link partner seeing these bits as zero, while the kernel
believes that it has advertised pause modes.
This leads to the local kernel evaluating (eg) symmetric pause mode,
while the remote end evaluates that we have no pause mode capability.
Since we can't guarantee the advertisment, disable pause mode support
with this PHY when used in SGMII-to-Copper mode.
The 88e1510 in RGMII-to-Copper mode appears to behave correctly.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
---
drivers/net/phy/marvell.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index b5a8f750e433..2510acc0feb0 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -879,6 +879,8 @@ static int m88e1510_config_init(struct phy_device *phydev)
/* SGMII-to-Copper mode initialization */
if (phydev->interface == PHY_INTERFACE_MODE_SGMII) {
+ u32 pause;
+
/* Select page 18 */
err = marvell_set_page(phydev, 18);
if (err < 0)
@@ -902,6 +904,16 @@ static int m88e1510_config_init(struct phy_device *phydev)
err = marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
if (err < 0)
return err;
+
+ /* There appears to be a bug in the 88e1512 when used in
+ * SGMII to copper mode, where the AN advertisment register
+ * clears the pause bits each time a negotiation occurs.
+ * This means we can never be truely sure what was advertised,
+ * so disable Pause support.
+ */
+ pause = SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+ phydev->supported &= ~pause;
+ phydev->advertising &= ~pause;
}
return m88e1121_config_init(phydev);
--
2.7.4
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up
^ permalink raw reply related
* Re: [PATCH] net: phy: marvell: enable a errata for 88E1145
From: David Miller @ 2017-12-15 15:47 UTC (permalink / raw)
To: qiang.zhao; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <20171215061332.42133-1-qiang.zhao@nxp.com>
From: Zhao Qiang <qiang.zhao@nxp.com>
Date: Fri, 15 Dec 2017 14:13:32 +0800
> The patch below
> commit f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
> limit a errata's scope to 88E1101.
> However, 88E1145 also need this errata, set config_aneg to
> m88e1101_config_aneg for 88E1145
>
> Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
The proper way to say that a patch fixes a particular commit it to
reference it in a "Fixes: " tag, like this:
====================
Fixes: f2899788353c ("net: phy: marvell: Limit errata to 88m1101")
Signed-off-by: Zhao Qiang <qiang.zhao@nxp.com>
====================
And then you don't need to reference it explicitly in your commit
message, you can just instead say:
Limit 88m1101 autoneg errata to 88E1145 as well.
Please fix up your submission like this and resubmit.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: Reduce timeout for mdio read/write
From: Andrew Lunn @ 2017-12-15 15:47 UTC (permalink / raw)
To: Hemanth Puranik; +Cc: netdev, linux-kernel, Timur Tabi
In-Reply-To: <1513348558-10906-1-git-send-email-hpuranik@codeaurora.org>
On Fri, Dec 15, 2017 at 08:05:58PM +0530, Hemanth Puranik wrote:
> Currently mdio read/write takes around ~115us as the timeout
> between status check is set to 100us.
> By reducing the timeout to 1us mdio read/write takes ~15us to
> complete. This improves the link up event response.
>
> Signed-off-by: Hemanth Puranik <hpuranik@codeaurora.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [patch net] mlxsw: spectrum: Disable MAC learning for ovs port
From: David Miller @ 2017-12-15 15:48 UTC (permalink / raw)
To: jiri; +Cc: netdev, yuvalm, idosch, mlxsw
In-Reply-To: <20171215074421.2776-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Fri, 15 Dec 2017 08:44:21 +0100
> From: Yuval Mintz <yuvalm@mellanox.com>
>
> Learning is currently enabled for ports which are OVS slaves -
> even though OVS doesn't need this indication.
> Since we're not associating a fid with the port, HW would continuously
> notify driver of learned [& aged] MACs which would be logged as errors.
>
> Fixes: 2b94e58df58c ("mlxsw: spectrum: Allow ports to work under OVS master")
> Signed-off-by: Yuval Mintz <yuvalm@mellanox.com>
> Reviewed-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: phy: marvell: avoid pause mode on SGMII-to-Copper for 88e151x
From: Andrew Lunn @ 2017-12-15 15:48 UTC (permalink / raw)
To: Russell King - ARM Linux; +Cc: David Miller, f.fainelli, jon, netdev
In-Reply-To: <20171215154540.GT10595@n2100.armlinux.org.uk>
> Sorry about that, not quite sure how that happened, but here's a
> replacement patch. I assume patchwork will do the right thing by
> including the patch in this mail...
Hi Russell
No, it does not. You need to submit a whole new patch.
Andrew
^ permalink raw reply
* Re: v4.15-rc2 on thinkpad x60: ethernet stopped working
From: David Miller @ 2017-12-15 15:52 UTC (permalink / raw)
To: pavel
Cc: nix.or.die, bpoirier, lsorense, aaron.f.brown, jeffrey.t.kirsher,
linux-kernel, intel-wired-lan, netdev
In-Reply-To: <20171215092849.GB15090@amd>
From: Pavel Machek <pavel@ucw.cz>
Date: Fri, 15 Dec 2017 10:28:49 +0100
> Hi!
>
>> >In v4.15-rc2+, network manager can not see my ethernet card, and
>> >manual attempts to ifconfig it up did not really help, either.
>> >
>> >Card is:
>> >
>> >02:00.0 Ethernet controller: Intel Corporation 82573L Gigabit Ethernet
>> >Controller
> ....
>> >Any ideas ?
>>
>> Yes , 19110cfbb34d4af0cdfe14cd243f3b09dc95b013 broke it.
>>
>> See:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198047
>>
>> Fix there :
>> https://marc.info/?l=linux-kernel&m=151272209903675&w=2
>
> I don't see the patch in latest mainline. Not having ethernet
> is... somehow annoying. What is going on there?
Generally speaking, e1000 maintainence has been handled very poorly over
the past few years, I have to say.
Fixes take forever to propagate even when someone other than the
maintainer provides a working and tested fix, just like this case.
Jeff, please take e1000 maintainence seriously and get these critical
bug fixes propagated.
Thank you.
^ permalink raw reply
* Re: [RFT/RFC net-next 0/2] net: dsa: Plug in PHYLINK support
From: Egil Hjelmeland @ 2017-12-15 15:51 UTC (permalink / raw)
To: Florian Fainelli, netdev
Cc: rmk+kernel, sean.wang, john, kernel, Woojung.Huh, vivien.didelot,
andrew
In-Reply-To: <20171215002850.27862-1-f.fainelli@gmail.com>
Hi
Den 15. des. 2017 01:28, skrev Florian Fainelli:
> Hi all,
>
> This patch series replaces the existing PHYLIB integration with PHYLINK which
> is a superior solution since we need to support a collection of fixed links,
> integrated PHYs, SFP, non-pluggable SFPs etc.
>
> I am expecting quite a lot of breakage, for a number of reasons:
>
> - PHYLINK does not create a PHY device for fixed links (MLO_AN_FIXED), which
> means that user-facing port (not DSA, not CPU) need to be explicitly handled
> with phylink_mac_ops now
>
FWIW: We (zenitel) does not use fixed-link on user-port. I gave the
patches a spin on our board with lan9303. As expected: no breakage.
Egil
^ permalink raw reply
* Re: ixgbe tuning reset when XDP is setup
From: David Miller @ 2017-12-15 15:53 UTC (permalink / raw)
To: eric; +Cc: netdev, xdp-newbies, pmanev
In-Reply-To: <1513333486.28703.9.camel@regit.org>
From: Eric Leblond <eric@regit.org>
Date: Fri, 15 Dec 2017 11:24:46 +0100
> Hello,
>
> When using an ixgbe card with Suricata we are using the following
> commands to get a symmetric hash on RSS load balancing:
>
> ./set_irq_affinity 0-15 eth3
> ethtool -X eth3 hkey 6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A:6D:5A equal 16
> ethtool -x eth3
> ethtool -n eth3
>
> Then we start Suricata.
>
> In my current experiment on XDP, I have Suricata that inject the eBPF
> program when starting. The consequence of that when using an ixgbe card
> is that the load balancing get reset and all interrupts are reaching
> the first core.
This definitely should _not_ be a side effect of enabling XDP on a device.
^ 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