* [RFC PATCH 0/2] selinux: avoid nf hooks overhead when not needed
From: Paolo Abeni @ 2016-04-06 9:51 UTC (permalink / raw)
To: linux-security-module
Cc: David S. Miller, James Morris, Paul Moore, Andreas Gruenbacher,
Stephen Smalley, Florian Westphal, netdev
Currently, selinux always registers iptables POSTROUTING hooks regarless of
the running policy needs for any action to be performed by them.
Even the socket_sock_rcv_skb() is always registered, but it can result in a no-op
depending on the current policy configuration.
The above invocations in the kernel datapath are cause of measurable
overhead in networking performance test.
This patch series adds explicit notification for netlabel status change
(other relevant status change, like xfrm and secmark, are already notified to
LSM) and use this information in selinux to register the above hooks only when
the current status makes them relevant, deregistering them when no-op
Avoiding the LSM hooks overhead, in netperf UDP_STREAM test with small packets,
gives about 5% performance improvement on rx and about 8% on tx.
Paolo Abeni (2):
security: add hook for netlabel status change notification
selinux: implement support for dynamic net hook [de-]registration
include/linux/lsm_hooks.h | 6 ++++
include/linux/security.h | 5 +++
net/netlabel/netlabel_cipso_v4.c | 8 +++--
net/netlabel/netlabel_unlabeled.c | 5 ++-
security/security.c | 7 ++++
security/selinux/hooks.c | 72 +++++++++++++++++++++++++++++++------
security/selinux/include/security.h | 1 +
security/selinux/ss/services.c | 1 +
security/selinux/xfrm.c | 4 +++
9 files changed, 96 insertions(+), 13 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: NETLINK_URELEASE non-bound socket problem (was: [PATCH] Fix local DoS in cfg80211 subsystem)
From: Johannes Berg @ 2016-04-06 9:34 UTC (permalink / raw)
To: Dmitrijs Ivanovs
Cc: linux-wireless, netdev, samuel, Pablo Neira Ayuso, Thomas Graf
In-Reply-To: <CAFSVvRcMQx1Vjv=Qwyb525Qq5DzBBD6c=n=-i+pWFFVqHRyAxQ@mail.gmail.com>
On Wed, 2016-04-06 at 11:20 +0300, Dmitrijs Ivanovs wrote:
> Hi Johannes!
>
> I will prepare patch which does not send NETLINK_URELEASE for unbound
> sockets as you suggest. But I think protocol check in nl80211 is
> still needed because port_id is unique per-protocol.
>
Yes, good point. Can you please send that as a separate patch? That one
should have a
Fixes: 026331c4d9b5 ("cfg80211/mac80211: allow registering for and sending action frames")
tag. I'll apply this one right away, but the other one should probably
go through Dave's tree.
Thanks,
johannes
^ permalink raw reply
* [PATCH v2 11/30] sunrpc: use parity8
From: zengzhaoxiu @ 2016-04-06 9:27 UTC (permalink / raw)
To: bfields, jlayton, trond.myklebust, anna.schumaker, davem, herbert
Cc: linux-nfs, netdev, linux-kernel, Zhaoxiu Zeng
In-Reply-To: <57031D9D.801@gmail.com>
From: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
Signed-off-by: Zhaoxiu Zeng <zhaoxiu.zeng@gmail.com>
---
net/sunrpc/auth_gss/gss_krb5_keys.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/net/sunrpc/auth_gss/gss_krb5_keys.c b/net/sunrpc/auth_gss/gss_krb5_keys.c
index 8701331..c41b389 100644
--- a/net/sunrpc/auth_gss/gss_krb5_keys.c
+++ b/net/sunrpc/auth_gss/gss_krb5_keys.c
@@ -243,16 +243,12 @@ err_return:
return ret;
}
-#define smask(step) ((1<<step)-1)
-#define pstep(x, step) (((x)&smask(step))^(((x)>>step)&smask(step)))
-#define parity_char(x) pstep(pstep(pstep((x), 4), 2), 1)
-
static void mit_des_fixup_key_parity(u8 key[8])
{
int i;
for (i = 0; i < 8; i++) {
key[i] &= 0xfe;
- key[i] |= 1^parity_char(key[i]);
+ key[i] |= !parity8(key[i]);
}
}
--
2.5.0
^ permalink raw reply related
* Re: AF_VSOCK status
From: Stefan Hajnoczi @ 2016-04-06 9:26 UTC (permalink / raw)
To: Antoine Martin; +Cc: netdev
In-Reply-To: <5703B0F3.7050700@nagafix.co.uk>
[-- Attachment #1: Type: text/plain, Size: 2785 bytes --]
On Tue, Apr 05, 2016 at 07:34:59PM +0700, Antoine Martin wrote:
> Forgive me if these questions are obvious, I am not a kernel developer.
> From what I am reading here:
> http://lists.linuxfoundation.org/pipermail/virtualization/2015-December/030935.html
> The code has been removed from mainline, is it queued for 4.6? If not,
> when are you planning on re-submitting it?
The patches are on the list (latest version sent last week):
http://comments.gmane.org/gmane.linux.kernel.virtualization/27455
They are only "Request For Comments" because the VIRTIO specification
changes have not been approved yet. Once the spec is approved then the
patches can be seriously considered for merging.
There will definitely be a v6 with Claudio Imbrenda's locking fixes.
> We now have a vsock transport merged into xpra, which works very well
> with the kernel and qemu versions found here:
> http://qemu-project.org/Features/VirtioVsock
> Congratulations on making this easy to use!
> Is the upcoming revised interface likely to cause incompatibilities with
> existing binaries?
Userspace applications should not notice a difference.
> It seems impossible for the host to connect to a guest: the guest has to
> initiate the connection. Is this a feature / known limitation or am I
> missing something? For some of our use cases, it would be more practical
> to connect in the other direction.
host->guest connections have always been allowed. I just checked that
it works with the latest code in my repo:
guest# nc-vsock -l 1234
host# nc-vsock 3 1234
> In terms of raw performance, I am getting about 10Gbps on an Intel
> Skylake i7 (the data stream arrives from the OS socket recv syscall
> split into 256KB chunks), that's good but not much faster than
> virtio-net and since the packets are avoiding all sorts of OS layer
> overheads I was hoping to get a little bit closer to the ~200Gbps memory
> bandwidth that this CPU+RAM are capable of. Am I dreaming or just doing
> it wrong?
virtio-vsock is not yet optimized but the priority is not to make
something faster than virtio-net. virtio-vsock is not for applications
who are trying to squeeze out every last drop of performance. Instead
the goal is to have a transport for guest<->hypervisor services that
need to be zero-configuration.
> How hard would it be to introduce a virtio mmap-like transport of some
> sort so that the guest and host could share some memory region?
> I assume this would give us the best possible performance when
> transferring large amounts of data? (we already have a local mmap
> transport we could adapt)
Shared memory is beyond the scope of virtio-vsock and it's unlikely to
be added. There are a few existing ways to achieve that without
involving virtio-vsock: vhost-user or ivshmem.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* RE: [PATCH net-next V3 03/16] net: fec: return IRQ_HANDLED if fec_ptp_check_pps_event handled it
From: Fugang Duan @ 2016-04-06 9:12 UTC (permalink / raw)
To: Troy Kisky, netdev@vger.kernel.org, davem@davemloft.net,
lznuaa@gmail.com
Cc: Fabio Estevam, l.stach@pengutronix.de, andrew@lunn.ch,
tremyfr@gmail.com, gerg@uclinux.org,
linux-arm-kernel@lists.infradead.org, johannes@sipsolutions.net,
stillcompiling@gmail.com, sergei.shtylyov@cogentembedded.com,
arnd@arndb.de
In-Reply-To: <1459909562-22865-4-git-send-email-troy.kisky@boundarydevices.com>
From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Wednesday, April 06, 2016 10:26 AM
> To: netdev@vger.kernel.org; davem@davemloft.net; Fugang Duan
> <fugang.duan@nxp.com>; lznuaa@gmail.com
> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> kernel@lists.infradead.org; johannes@sipsolutions.net;
> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> arnd@arndb.de; Troy Kisky <troy.kisky@boundarydevices.com>
> Subject: [PATCH net-next V3 03/16] net: fec: return IRQ_HANDLED if
> fec_ptp_check_pps_event handled it
>
> fec_ptp_check_pps_event will return 1 if FEC_T_TF_MASK caused an interrupt.
> Don't return IRQ_NONE in this case.
>
> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>
> ---
> v3: New patch, came from feedback from another patch.
> ---
> drivers/net/ethernet/freescale/fec_main.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec_main.c
> b/drivers/net/ethernet/freescale/fec_main.c
> index a011719..7993040 100644
> --- a/drivers/net/ethernet/freescale/fec_main.c
> +++ b/drivers/net/ethernet/freescale/fec_main.c
> @@ -1579,8 +1579,8 @@ fec_enet_interrupt(int irq, void *dev_id)
> }
>
> if (fep->ptp_clock)
> - fec_ptp_check_pps_event(fep);
> -
> + if (fec_ptp_check_pps_event(fep))
> + ret = IRQ_HANDLED;
> return ret;
> }
>
> --
> 2.5.0
Acked-by: Fugang Duan <fugang.duan@nxp.com>
^ permalink raw reply
* Re: [PATCH v2] ARC: axs10x - add Ethernet PHY description in .dts
From: Vineet Gupta @ 2016-04-06 9:12 UTC (permalink / raw)
To: Alexey Brodkin, linux-snps-arc
Cc: Rob Herring, Sergei Shtylyov, netdev, linux-kernel,
Giuseppe CAVALLARO, Phil Reid, David S. Miller, Gabriel Fernandez
In-Reply-To: <1458207712-29435-1-git-send-email-abrodkin@synopsys.com>
Hi,
On Thursday 17 March 2016 03:11 PM, Alexey Brodkin wrote:
> Following commit broke DW GMAC functionality on AXS10x boards:
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e34d65696d2ef13dc32f2a162556c86c461ed763
>
> That's what happens on eth0 up:
> --------------------------->8------------------------
> libphy: PHY stmmac-0:ffffffff not found
> eth0: Could not attach to PHY
> stmmac_open: Cannot attach to PHY (error: -19)
> --------------------------->8------------------------
>
> Simplest solution is to add PHY description in board's .dts.
> And so we do here.
>
> Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Phil Reid <preid@electromag.com.au>
> Cc: David S. Miller <davem@davemloft.net>
> Cc: linux-kernel@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: stable@vger.kernel.org # 4.5.x
> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> ---
>
> Changes v1 -> v2:
> * PHY node name changed to match real PHY number being used (Sergei)
>
> arch/arc/boot/dts/axs10x_mb.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
> index 44a578c..ab5d570 100644
> --- a/arch/arc/boot/dts/axs10x_mb.dtsi
> +++ b/arch/arc/boot/dts/axs10x_mb.dtsi
> @@ -47,6 +47,14 @@
> clocks = <&apbclk>;
> clock-names = "stmmaceth";
> max-speed = <100>;
> + mdio0 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "snps,dwmac-mdio";
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> + };
> };
>
> ehci@0x40000 {
So above DT fix for ARC went into 4.6-rc1 and ethernet was still broken on axs103
board.
---------->8-------------
libphy: PHY stmmac-0:ffffffff not found
eth0: Could not attach to PHY
stmmac_open: Cannot attach to PHY (error: -19)
---------->8-------------
On 4.6-rc2 if I revert the DT change, ethernet works again.
@Giuseppe, @Phil, @Gabriel, I see you have made changes in that area. I presume
that above revert is the right/sufficient thing or do we need to do something else
as well.
TIA,
-Vineet
^ permalink raw reply
* RE: [PATCH net-next V3 02/16] net: fec: remove unused interrupt FEC_ENET_TS_TIMER
From: Fugang Duan @ 2016-04-06 9:10 UTC (permalink / raw)
To: Troy Kisky, netdev@vger.kernel.org, davem@davemloft.net,
lznuaa@gmail.com
Cc: andrew@lunn.ch, stillcompiling@gmail.com, arnd@arndb.de,
sergei.shtylyov@cogentembedded.com, gerg@uclinux.org,
Fabio Estevam, johannes@sipsolutions.net, l.stach@pengutronix.de,
linux-arm-kernel@lists.infradead.org, tremyfr@gmail.com
In-Reply-To: <1459909562-22865-3-git-send-email-troy.kisky@boundarydevices.com>
From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Wednesday, April 06, 2016 10:26 AM
> To: netdev@vger.kernel.org; davem@davemloft.net; Fugang Duan
> <fugang.duan@nxp.com>; lznuaa@gmail.com
> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> kernel@lists.infradead.org; johannes@sipsolutions.net;
> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> arnd@arndb.de; Troy Kisky <troy.kisky@boundarydevices.com>
> Subject: [PATCH net-next V3 02/16] net: fec: remove unused interrupt
> FEC_ENET_TS_TIMER
>
> FEC_ENET_TS_TIMER is not checked in the interrupt routine so there is no need
> to enable it.
>
> Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
>
> ---
> v3: New patch
>
> Frank Li said "TS_TIMER should never be triggered."
> when discussing another patch.
> ---
> drivers/net/ethernet/freescale/fec.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/fec.h
> b/drivers/net/ethernet/freescale/fec.h
> index 195122e..6dd0ba8 100644
> --- a/drivers/net/ethernet/freescale/fec.h
> +++ b/drivers/net/ethernet/freescale/fec.h
> @@ -374,8 +374,8 @@ struct bufdesc_ex {
> #define FEC_ENET_TS_AVAIL ((uint)0x00010000)
> #define FEC_ENET_TS_TIMER ((uint)0x00008000)
>
> -#define FEC_DEFAULT_IMASK (FEC_ENET_TXF | FEC_ENET_RXF | FEC_ENET_MII
> | FEC_ENET_TS_TIMER)
> -#define FEC_NAPI_IMASK (FEC_ENET_MII | FEC_ENET_TS_TIMER)
> +#define FEC_DEFAULT_IMASK (FEC_ENET_TXF | FEC_ENET_RXF | FEC_ENET_MII)
> +#define FEC_NAPI_IMASK FEC_ENET_MII
> #define FEC_RX_DISABLED_IMASK (FEC_DEFAULT_IMASK & (~FEC_ENET_RXF))
>
> /* ENET interrupt coalescing macro define */
> --
> 2.5.0
Acked-by: Fugang Duan <fugang.duan@nxp.com>
^ permalink raw reply
* RE: [PATCH net-next 1/3] net: bcmgenet: cleanup for bcmgenet_xmit()
From: David Laight @ 2016-04-06 8:57 UTC (permalink / raw)
To: 'Petri Gynther', netdev@vger.kernel.org
Cc: davem@davemloft.net, f.fainelli@gmail.com, jaedon.shin@gmail.com
In-Reply-To: <1459815001-91703-1-git-send-email-pgynther@google.com>
From: Petri Gynther
> Sent: 05 April 2016 01:10
...
> 2. Readability: Add parentheses around nr_frags + 1.
...
> - if (ring->free_bds <= nr_frags + 1) {
...
> + if (ring->free_bds <= (nr_frags + 1)) {
The extra () are not needed and do not improve readability.
David
^ permalink raw reply
* RE: [PATCH net-next V3 00/16] net: fec: cleanup and fixes
From: Fugang Duan @ 2016-04-06 8:51 UTC (permalink / raw)
To: Troy Kisky, netdev@vger.kernel.org, davem@davemloft.net,
lznuaa@gmail.com
Cc: Fabio Estevam, l.stach@pengutronix.de, andrew@lunn.ch,
tremyfr@gmail.com, gerg@uclinux.org,
linux-arm-kernel@lists.infradead.org, johannes@sipsolutions.net,
stillcompiling@gmail.com, sergei.shtylyov@cogentembedded.com,
arnd@arndb.de
In-Reply-To: <1459909562-22865-1-git-send-email-troy.kisky@boundarydevices.com>
From: Troy Kisky <troy.kisky@boundarydevices.com> Sent: Wednesday, April 06, 2016 10:26 AM
> To: netdev@vger.kernel.org; davem@davemloft.net; Fugang Duan
> <fugang.duan@nxp.com>; lznuaa@gmail.com
> Cc: Fabio Estevam <fabio.estevam@nxp.com>; l.stach@pengutronix.de;
> andrew@lunn.ch; tremyfr@gmail.com; gerg@uclinux.org; linux-arm-
> kernel@lists.infradead.org; johannes@sipsolutions.net;
> stillcompiling@gmail.com; sergei.shtylyov@cogentembedded.com;
> arnd@arndb.de; Troy Kisky <troy.kisky@boundarydevices.com>
> Subject: [PATCH net-next V3 00/16] net: fec: cleanup and fixes
>
> V3 has
>
> 1 dropped patch "net: fec: print more debug info in fec_timeout"
> 2 new patches
> 0002-net-fec-remove-unused-interrupt-FEC_ENET_TS_TIMER.patch
> 0003-net-fec-return-IRQ_HANDLED-if-fec_ptp_check_pps_even.patch
>
> 1 combined patch
> 0004-net-fec-pass-rxq-txq-to-fec_enet_rx-tx_queue-instead.patch
>
> The changes are noted on individual patches
>
> My measured performance of this series is
>
> before patch set
> 365 Mbits/sec Tx/407 RX
>
> after patch set
> 374 Tx/427 Rx
>
I doubt the performance data, I validate it on i.MX6q sabresd board on the latest commit(4da46cebbd3b) in net tree.
The test log as below:
root@imx6qdlsolo:~# uname -a
Linux imx6qdlsolo 4.6.0-rc1-00318-g4da46ce #180 SMP Wed Apr 6 16:24:09 CST 2016 armv7l GNU/Linux
root@imx6qdlsolo:~# cat /sys/devices/soc0/soc_id
i.MX6Q
root@imx6qdlsolo:~# echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
root@imx6qdlsolo:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
996000
root@imx6qdlsolo:~# iperf -s &
[1] 891
root@imx6qdlsolo:~# ------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
root@imx6qdlsolo:~# [ 4] local 10.192.242.107 port 5001 connected with 10.192.242.248 port 38409
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-20.0 sec 1.40 GBytes 602 Mbits/sec
root@imx6qdlsolo:~# iperf -c 10.192.242.248 -t 20
------------------------------------------------------------
Client connecting to 10.192.242.248, TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ 3] local 10.192.242.107 port 52124 connected with 10.192.242.248 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-20.0 sec 776 MBytes 325 Mbits/sec
TCP RX performance is 602Mbps, TX is only 325Mbps, TX path has some performance issue in net tree.
I will dig out it.
>
> Troy Kisky (16):
> net: fec: only check queue 0 if RXF_0/TXF_0 interrupt is set
> net: fec: remove unused interrupt FEC_ENET_TS_TIMER
> net: fec: return IRQ_HANDLED if fec_ptp_check_pps_event handled it
> net: fec: pass rxq/txq to fec_enet_rx/tx_queue instead of queue_id
> net: fec: reduce interrupts
> net: fec: split off napi routine with 3 queues
> net: fec: don't clear all rx queue bits when just one is being checked
> net: fec: set cbd_sc without relying on previous value
> net: fec: eliminate calls to fec_enet_get_prevdesc
> net: fec: move restart test for efficiency
> net: fec: clear cbd_sc after transmission to help with debugging
> net: fec: dump all tx queues in fec_dump
> net: fec: detect tx int lost
> net: fec: create subroutine reset_tx_queue
> net: fec: call dma_unmap_single on mapped tx buffers at restart
> net: fec: don't set cbd_bufaddr unless no mapping error
>
> drivers/net/ethernet/freescale/fec.h | 10 +-
> drivers/net/ethernet/freescale/fec_main.c | 410 ++++++++++++++++------------
> --
> 2 files changed, 218 insertions(+), 202 deletions(-)
>
> --
> 2.5.0
^ permalink raw reply
* Re: [RFC PATCH 6/6] ppp: add rtnetlink device creation support
From: Guillaume Nault @ 2016-04-06 8:21 UTC (permalink / raw)
To: walter harms; +Cc: netdev, linux-ppp, Paul Mackerras, David Miller
In-Reply-To: <5704C2B0.6020504@bfs.de>
On Wed, Apr 06, 2016 at 10:02:56AM +0200, walter harms wrote:
>
>
> Am 05.04.2016 23:22, schrieb Guillaume Nault:
> > On Tue, Apr 05, 2016 at 07:18:14PM +0200, walter harms wrote:
> >>
> >>
> >> Am 05.04.2016 02:56, schrieb Guillaume Nault:
> >>> @@ -1043,12 +1048,39 @@ static int ppp_dev_configure(struct net *src_net, struct net_device *dev,
> >>> const struct ppp_config *conf)
> >>> {
> >>> struct ppp *ppp = netdev_priv(dev);
> >>> + struct file *file;
> >>> int indx;
> >>> + int err;
> >>> +
> >>> + if (conf->fd < 0) {
> >>> + file = conf->file;
> >>> + if (!file) {
> >>> + err = -EBADF;
> >>> + goto out;
> >>
> >> why not just return -EBADF;
> >>
> >>> + }
> >>> + } else {
> >>> + file = fget(conf->fd);
> >>> + if (!file) {
> >>> + err = -EBADF;
> >>> + goto out;
> >>
> >> why not just return -EBADF;
> >>
> > Just because the 'out' label is declared anyway and because this
> > centralises the return point. But I agree returning -EBADF directly
> > could be more readable. I don't have strong opinion.
>
> in this special case i would go for readable. People tend to miss these
> if
> if
> if
> constructs.
>
Ok, I'll do that in v3.
^ permalink raw reply
* Re: NETLINK_URELEASE non-bound socket problem (was: [PATCH] Fix local DoS in cfg80211 subsystem)
From: Dmitrijs Ivanovs @ 2016-04-06 8:20 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA, netdev, samuel,
Pablo Neira Ayuso, Thomas Graf
In-Reply-To: <1459850188.18188.38.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Hi Johannes!
I will prepare patch which does not send NETLINK_URELEASE for unbound
sockets as you suggest. But I think protocol check in nl80211 is still
needed because port_id is unique per-protocol.
On Tue, Apr 5, 2016 at 12:56 PM, Johannes Berg
<johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> wrote:
> Hi Dmitrijs,
>
> Thanks for reporting this problem.
>
>> The patch below corrects this problem in kernel space.
>
> I don't think that this is correct, there are four more users of
> NETLINK_URELEASE (nfnetlink, NFC), and afaict all of them have the same
> bug as nl80211.
>
> Rather than fix all of them, I think we should simply not report
> NETLINK_URELEASE for netlink sockets that weren't bound; if any user
> comes up that requires them later we could add a new event instead.
>
> I can't find what commit introduced this code, it goes back before git
> history, so I don't have the commit log. Maybe it was done for
> nfnetlink log/queue? Certainly both nl80211 and NFC are much newer.
>
>> Also, it is
>> recommended to ensure that user-space applications are not using
>> user-supplied port_id for netlink sockets (which is default in
>> libnl-tiny for example).
>
> This I think we should remove from the commit log - it's misleading and
> there's no point.
>
> johannes
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [v7, 0/5] Fix eSDHC host version register bug
From: Ulf Hansson @ 2016-04-06 8:14 UTC (permalink / raw)
To: Yangbo Lu, Scott Wood
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Zhao Qiang,
Russell King, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Santosh Shilimkar,
linux-mmc, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jochen Friedrich, Xiaobo Xie,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Claudiu Manoil, Kumar Gala, Yang-Leo Li,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-arm-kernel-IAPFreCvJWM1dQTEkxZZdg@public.gmane.org
In-Reply-To: <HE1PR04MB0889D75DC56E180D3508E7A1F89F0-6LN7OEpIatX1kPMWxTxe+c9NdZoXdze2vxpqHgZTriW3zl9H0oFU5g@public.gmane.org>
>>
>> I was about to queue this for next, when I noticed that checkpatch is
>> complaining/warning lots about these patches. Can you please a round of
>> checkpatch and fix what makes sense.
>>
>> Kind regards
>> Uffe
>
> [Lu Yangbo-B47093] Sorry about this, Uffe...
No worries!
> Should I ignore the warnings that update MAINTAINERS?
drivers/soc/fsl/guts.c isn't part of the MAINTAINERS file, it should be.
I also realize that the FREESCALE QUICC ENGINE LIBRARY section
drivers/soc/fsl/qe/* also need an active maintainer, as it's currently
orphan.
Perhaps we should have create a new section for drivers/soc/fsl/*
instead that covers all of the above? Maybe you or Scott are
interested to pick it up?
I also noted that, "include/linux/fsl/" isn't present in MAINTAINERS,
please add that as well.
> Regarding the 'undocumented' warning, I will added a patch updates doc before all the patches, Ok?
Yes, good!
>
> Thanks a lot :)
>
Kind regards
Uffe
^ permalink raw reply
* Re: [RFC PATCH 6/6] ppp: add rtnetlink device creation support
From: walter harms @ 2016-04-06 8:02 UTC (permalink / raw)
To: Guillaume Nault; +Cc: netdev, linux-ppp, Paul Mackerras, David Miller
In-Reply-To: <20160405212222.GD1305@alphalink.fr>
Am 05.04.2016 23:22, schrieb Guillaume Nault:
> On Tue, Apr 05, 2016 at 07:18:14PM +0200, walter harms wrote:
>>
>>
>> Am 05.04.2016 02:56, schrieb Guillaume Nault:
>>> @@ -1043,12 +1048,39 @@ static int ppp_dev_configure(struct net *src_net, struct net_device *dev,
>>> const struct ppp_config *conf)
>>> {
>>> struct ppp *ppp = netdev_priv(dev);
>>> + struct file *file;
>>> int indx;
>>> + int err;
>>> +
>>> + if (conf->fd < 0) {
>>> + file = conf->file;
>>> + if (!file) {
>>> + err = -EBADF;
>>> + goto out;
>>
>> why not just return -EBADF;
>>
>>> + }
>>> + } else {
>>> + file = fget(conf->fd);
>>> + if (!file) {
>>> + err = -EBADF;
>>> + goto out;
>>
>> why not just return -EBADF;
>>
> Just because the 'out' label is declared anyway and because this
> centralises the return point. But I agree returning -EBADF directly
> could be more readable. I don't have strong opinion.
in this special case i would go for readable. People tend to miss these
if
if
if
constructs.
NTL its up to you.
re,
wh
^ permalink raw reply
* Darlehen anbieten
From: QUALITY LOAN SERVICE CORPORATION @ 2016-04-06 7:51 UTC (permalink / raw)
Schönen Tag,
Benötigen Sie eine finanzielle Unterstützung? ein berechtigtes Kredit für Zinsen nötig? Sie benötigen einen Business-Darlehen? Sie benötigen ein Darlehen ein Haus, Auto zu kaufen, um Ihre Rechnungen und Schulden zu bezahlen? Brauchen Sie Geld Probleme zu lösen? Wenn so freundlich für ein Darlehen mit uns um 3% Zinssatz gelten, gelten nun durch die folgenden Details und Rückkehr zu uns per E-Mail: qualityloanservicecorporation@gmail.com
erforderlichen Informationen, um
Deine Namen:
Adresse: ...........
Telefon: ...........
Benötigte Menge: .......
Dauer: ...............
Beruf: ...........
Monatliches Einkommen Level: ......
Geschlecht: ..............
Geburtsdatum: .......
Bundesland: ...............
Land: .........
Zweck: .........
Vielen dank für ihr Verständnis
Dringende Antwort von Ihnen benötigt jetzt
Mit freundlichen Grüßen
Frau Isabelle Morgan
^ permalink raw reply
* RE: [PATCH] wlcore: spi: add wl18xx support
From: Reizer, Eyal @ 2016-04-06 7:28 UTC (permalink / raw)
To: Eyal Reizer, kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1459343218-24536-1-git-send-email-eyalr-l0cyMroinI0@public.gmane.org>
Ping on this patch
> -----Original Message-----
> From: Eyal Reizer [mailto:eyalreizer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org]
> Sent: Wednesday, March 30, 2016 4:07 PM
> To: kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: Reizer, Eyal
> Subject: [PATCH] wlcore: spi: add wl18xx support
>
> Add support for using with both wl12xx and wl18xx.
>
> - all wilink family needs special init command for entering wspi mode.
> extra clock cycles should be sent after the spi init command while the
> cs pin is high.
> - switch to controling the cs pin from the spi driver for achieveing the
> above.
> - the selected cs gpio is read from the spi device-tree node using the
> cs-gpios field and setup as a gpio.
> - See the example below for specifying the cs gpio using the cs-gpios entry
>
> &spi0 {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&spi0_pins>;
> cs-gpios = <&gpio0 5 0>;
> #address-cells = <1>;
> #size-cells = <0>;
> wlcore: wlcore@0 {
> compatible = "ti,wl1835";
> vwlan-supply = <&wlan_en_reg>;
> spi-max-frequency = <48000000>;
> reg = <0>; /* chip select 0 on spi0, ie spi0.0 */
> interrupt-parent = <&gpio0>;
> interrupts = <27 IRQ_TYPE_EDGE_RISING>;
> };
> };
>
> Signed-off-by: Eyal Reizer <eyalr-l0cyMroinI0@public.gmane.org>
> ---
> drivers/net/wireless/ti/wlcore/spi.c | 176
> ++++++++++++++++++++++++++++++----
> 1 file changed, 157 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/net/wireless/ti/wlcore/spi.c
> b/drivers/net/wireless/ti/wlcore/spi.c
> index 96d9c9d..6c5a369 100644
> --- a/drivers/net/wireless/ti/wlcore/spi.c
> +++ b/drivers/net/wireless/ti/wlcore/spi.c
> @@ -32,6 +32,7 @@
> #include <linux/platform_device.h>
> #include <linux/of_irq.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/gpio.h>
>
> #include "wlcore.h"
> #include "wl12xx_80211.h"
> @@ -70,16 +71,30 @@
> #define WSPI_MAX_CHUNK_SIZE 4092
>
> /*
> - * only support SPI for 12xx - this code should be reworked when 18xx
> - * support is introduced
> + * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared
> + to
> + * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for
> + wl18xx
> */
> -#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
> +#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)
>
> /* Maximum number of SPI write chunks */ #define
> WSPI_MAX_NUM_OF_CHUNKS \
> ((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
>
>
> +struct wilink_familiy_data {
> + char name[8];
> +};
> +
> +const struct wilink_familiy_data *wilink_data;
> +
> +static const struct wilink_familiy_data wl18xx_data = {
> + .name = "wl18xx",
> +};
> +
> +static const struct wilink_familiy_data wl12xx_data = {
> + .name = "wl12xx",
> +};
> +
> struct wl12xx_spi_glue {
> struct device *dev;
> struct platform_device *core;
> @@ -120,6 +135,8 @@ static void wl12xx_spi_init(struct device *child)
> struct spi_transfer t;
> struct spi_message m;
> u8 *cmd = kzalloc(WSPI_INIT_CMD_LEN, GFP_KERNEL);
> + struct spi_device *spi = (struct spi_device *)glue->dev;
> + struct spi_master *master = spi->master;
>
> if (!cmd) {
> dev_err(child->parent,
> @@ -127,6 +144,15 @@ static void wl12xx_spi_init(struct device *child)
> return;
> }
>
> + if (!master->cs_gpios) {
> + dev_err(child->parent,
> + "spi chip select pin missing in platform data!\n");
> + return;
> + }
> +
> + /* Drive CS line low */
> + gpio_direction_output(master->cs_gpios[0], 0);
> +
> memset(&t, 0, sizeof(t));
> spi_message_init(&m);
>
> @@ -163,6 +189,26 @@ static void wl12xx_spi_init(struct device *child)
> spi_message_add_tail(&t, &m);
>
> spi_sync(to_spi_device(glue->dev), &m);
> +
> + /* Send extra clocks with CS high. this is required by the wilink
> + * family in order for successfully enter WSPI mode
> + */
> + gpio_direction_output(master->cs_gpios[0], 1);
> +
> + memset(&m, 0, sizeof(m));
> + spi_message_init(&m);
> +
> + cmd[0] = 0xff;
> + cmd[1] = 0xff;
> + cmd[2] = 0xff;
> + cmd[3] = 0xff;
> + swab32s((u32 *)cmd);
> +
> + t.tx_buf = cmd;
> + t.len = 4;
> + spi_message_add_tail(&t, &m);
> + spi_sync(to_spi_device(glue->dev), &m);
> +
> kfree(cmd);
> }
>
> @@ -213,6 +259,16 @@ static int __must_check
> wl12xx_spi_raw_read(struct device *child, int addr,
> u32 *busy_buf;
> u32 *cmd;
> u32 chunk_len;
> + struct spi_device *spi = (struct spi_device *)glue->dev;
> + struct spi_master *master = spi->master;
> +
> + if (!master->cs_gpios) {
> + dev_err(child->parent,
> + "spi chip select pin missing in platform data!\n");
> + return -EINVAL;
> + }
> + /* Drive CS line low */
> + gpio_direction_output(master->cs_gpios[0], 0);
>
> while (len > 0) {
> chunk_len = min_t(size_t, WSPI_MAX_CHUNK_SIZE, len); @@
> -267,25 +323,44 @@ static int __must_check wl12xx_spi_raw_read(struct
> device *child, int addr,
> len -= chunk_len;
> }
>
> + /* Drive CS line high */
> + gpio_direction_output(master->cs_gpios[0], 1);
> return 0;
> }
>
> -static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
> - void *buf, size_t len, bool fixed)
> +static int __wl12xx_spi_raw_write(struct device *child, int addr,
> + void *buf, size_t len, bool fixed)
> {
> struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
> - /* SPI write buffers - 2 for each chunk */
> - struct spi_transfer t[2 * WSPI_MAX_NUM_OF_CHUNKS];
> + struct spi_transfer *t;
> struct spi_message m;
> u32 commands[WSPI_MAX_NUM_OF_CHUNKS]; /* 1 command per
> chunk */
> u32 *cmd;
> u32 chunk_len;
> int i;
> + struct spi_device *spi = (struct spi_device *)glue->dev;
> + struct spi_master *master = spi->master;
> +
> + if (!master->cs_gpios) {
> + dev_err(child->parent,
> + "spi chip select pin missing in platform data!\n");
> + return -EINVAL;
> + }
> +
> + /* SPI write buffers - 2 for each chunk */
> + t = kzalloc(sizeof(*t) * 2 * WSPI_MAX_NUM_OF_CHUNKS,
> GFP_KERNEL);
> + if (!t) {
> + dev_err(child->parent,
> + "could not allocate spi write buffer\n");
> + return -ENOMEM;
> + }
> +
> + /* Drive CS line low */
> + gpio_direction_output(master->cs_gpios[0], 0);
>
> WARN_ON(len > SPI_AGGR_BUFFER_SIZE);
>
> spi_message_init(&m);
> - memset(t, 0, sizeof(t));
>
> cmd = &commands[0];
> i = 0;
> @@ -318,9 +393,29 @@ static int __must_check
> wl12xx_spi_raw_write(struct device *child, int addr,
>
> spi_sync(to_spi_device(glue->dev), &m);
>
> + /* Drive CS line high */
> + gpio_direction_output(master->cs_gpios[0], 1);
> +
> + kfree(t);
> return 0;
> }
>
> +static int __must_check wl12xx_spi_raw_write(struct device *child, int addr,
> + void *buf, size_t len, bool fixed) {
> + int ret;
> +
> + /* The ELP wakeup write may fail the first time due to internal
> + * hardware latency. It is safer to send the wakeup command twice to
> + * avoid unexpected failures.
> + */
> + if (addr == HW_ACCESS_ELP_CTRL_REG)
> + ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
> + ret = __wl12xx_spi_raw_write(child, addr, buf, len, fixed);
> +
> + return ret;
> +}
> +
> /**
> * wl12xx_spi_set_power - power on/off the wl12xx unit
> * @child: wl12xx device handle.
> @@ -349,17 +444,38 @@ static int wl12xx_spi_set_power(struct device
> *child, bool enable)
> return ret;
> }
>
> +/**
> + * wl12xx_spi_set_block_size
> + *
> + * This function is not needed for spi mode, but need to be present.
> + * Without it defined the wlcore fallback to use the wrong packet
> + * allignment on tx.
> + */
> +static void wl12xx_spi_set_block_size(struct device *child,
> + unsigned int blksz)
> +{
> +}
> +
> static struct wl1271_if_operations spi_ops = {
> .read = wl12xx_spi_raw_read,
> .write = wl12xx_spi_raw_write,
> .reset = wl12xx_spi_reset,
> .init = wl12xx_spi_init,
> .power = wl12xx_spi_set_power,
> - .set_block_size = NULL,
> + .set_block_size = wl12xx_spi_set_block_size,
> };
>
> static const struct of_device_id wlcore_spi_of_match_table[] = {
> - { .compatible = "ti,wl1271" },
> + { .compatible = "ti,wl1271", .data = &wl12xx_data},
> + { .compatible = "ti,wl1273", .data = &wl12xx_data},
> + { .compatible = "ti,wl1281", .data = &wl12xx_data},
> + { .compatible = "ti,wl1283", .data = &wl12xx_data},
> + { .compatible = "ti,wl1801", .data = &wl18xx_data},
> + { .compatible = "ti,wl1805", .data = &wl18xx_data},
> + { .compatible = "ti,wl1807", .data = &wl18xx_data},
> + { .compatible = "ti,wl1831", .data = &wl18xx_data},
> + { .compatible = "ti,wl1835", .data = &wl18xx_data},
> + { .compatible = "ti,wl1837", .data = &wl18xx_data},
> { }
> };
> MODULE_DEVICE_TABLE(of, wlcore_spi_of_match_table); @@ -375,18
> +491,24 @@ static int wlcore_probe_of(struct spi_device *spi, struct
> wl12xx_spi_glue *glue,
> struct wlcore_platdev_data *pdev_data) {
> struct device_node *dt_node = spi->dev.of_node;
> - int ret;
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_node(wlcore_spi_of_match_table, dt_node);
> + if (!of_id)
> + return -ENODEV;
> +
> + wilink_data = of_id->data;
> + dev_info(&spi->dev, "selected chip familiy is %s\n",
> + wilink_data->name);
>
> if (of_find_property(dt_node, "clock-xtal", NULL))
> pdev_data->ref_clock_xtal = true;
>
> - ret = of_property_read_u32(dt_node, "ref-clock-frequency",
> - &pdev_data->ref_clock_freq);
> - if (IS_ERR_VALUE(ret)) {
> - dev_err(glue->dev,
> - "can't get reference clock frequency (%d)\n", ret);
> - return ret;
> - }
> + /* optional clock frequency params */
> + of_property_read_u32(dt_node, "ref-clock-frequency",
> + &pdev_data->ref_clock_freq);
> + of_property_read_u32(dt_node, "tcxo-clock-frequency",
> + &pdev_data->tcxo_clock_freq);
>
> return 0;
> }
> @@ -397,6 +519,7 @@ static int wl1271_probe(struct spi_device *spi)
> struct wlcore_platdev_data pdev_data;
> struct resource res[1];
> int ret;
> + struct spi_master *master = spi->master;
>
> memset(&pdev_data, 0x00, sizeof(pdev_data));
>
> @@ -410,6 +533,12 @@ static int wl1271_probe(struct spi_device *spi)
>
> glue->dev = &spi->dev;
>
> + if (!master->cs_gpios) {
> + dev_err(glue->dev,
> + "spi chip select pin missing in platform data!\n");
> + return -EINVAL;
> + }
> +
> spi_set_drvdata(spi, glue);
>
> /* This is the only SPI value that we need to set here, the rest @@ -
> 431,15 +560,21 @@ static int wl1271_probe(struct spi_device *spi)
> return ret;
> }
>
> + if (gpio_request(master->cs_gpios[0], "spi1-cs0"))
> + return -EINVAL;
> +
> ret = spi_setup(spi);
> if (ret < 0) {
> dev_err(glue->dev, "spi_setup failed\n");
> + gpio_free(master->cs_gpios[0]);
> return ret;
> }
>
> - glue->core = platform_device_alloc("wl12xx",
> PLATFORM_DEVID_AUTO);
> + glue->core = platform_device_alloc(wilink_data->name,
> + PLATFORM_DEVID_AUTO);
> if (!glue->core) {
> dev_err(glue->dev, "can't allocate platform_device\n");
> + gpio_free(master->cs_gpios[0]);
> return -ENOMEM;
> }
>
> @@ -474,14 +609,17 @@ static int wl1271_probe(struct spi_device *spi)
>
> out_dev_put:
> platform_device_put(glue->core);
> + gpio_free(master->cs_gpios[0]);
> return ret;
> }
>
> static int wl1271_remove(struct spi_device *spi) {
> struct wl12xx_spi_glue *glue = spi_get_drvdata(spi);
> + struct spi_master *master = spi->master;
>
> platform_device_unregister(glue->core);
> + gpio_free(master->cs_gpios[0]);
>
> return 0;
> }
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 1/6] net: skbuff: don't use union for napi_id and sender_cpu
From: Jason Wang @ 2016-04-06 6:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, mst, netdev, linux-kernel
In-Reply-To: <1459515859.6473.277.camel@edumazet-glaptop3.roam.corp.google.com>
On 04/01/2016 09:04 PM, Eric Dumazet wrote:
> On Fri, 2016-04-01 at 12:49 +0800, Jason Wang wrote:
>> On 04/01/2016 10:55 AM, Eric Dumazet wrote:
>>> On Fri, 2016-04-01 at 10:13 +0800, Jason Wang wrote:
>>>
>>>
>>>> The problem is we want to support busy polling for tun. This needs
>>>> napi_id to be passed to tun socket by sk_mark_napi_id() during
>>>> tun_net_xmit(). But before reaching this, XPS will set sender_cpu will
>>>> make us can't see correct napi_id.
>>>>
>>> Looks like napi_id should have precedence then ?
>> But then when busy polling is enabled, we may still hit the issue before
>> commit 2bd82484bb4c5db1d5dc983ac7c409b2782e0154? So looks like sometimes
>> (e.g for tun), we need both two fields.
> You did not clearly show me the path you take where both fields would be
> needed. If you expect me to do that, it wont happen.
Right, since tun does not use XPS. But the stacked device on top of tun
does not know this which may still try to set sender_cpu.
>
>>> Only forwarding should allow the field to be cleared to allow XPS to do
>>> its job.
>>>
>>> Maybe skb_sender_cpu_clear() was removed too early (commit
>>> 64d4e3431e686dc37ce388ba531c4c4e866fb141)
>> Not sure I get you, but this will clear napi_id too.
> Only when allowed. In your case it would not be called.
Looks like I miss something, there used to be a skb_sender_cpu_clear()
in br_dev_queue_push_xmit() which will be called before tun_net_xmit().
>
> Some people do not use tun, and want to forward or cook millions of
> packets per second. sk_buff size is critical.
>
> If busy polling gives you 5 % of performance improvement, but cost
> everyone else a performance decrease, this is a serious problem.
>
> XPS is a sender problem, NAPI is a receiver problem. Fields should be
> shared.
>
How about introduce a napi_id field in softnet_data to record the napi
that is being polled, then sk_mark_napi_id() can fetch napi_id from it
instead of skb?
^ permalink raw reply
* RE: [v7, 0/5] Fix eSDHC host version register bug
From: Yangbo Lu @ 2016-04-06 6:12 UTC (permalink / raw)
To: Ulf Hansson
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Zhao Qiang,
Russell King, Claudiu Manoil, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Santosh Shilimkar,
linux-mmc, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Scott Wood, Xiaobo Xie,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Rob Herring, linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jochen Friedrich, Kumar Gala, Yang-Leo Li,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAPDyKFqgMCvbqMYZ-uM-rTnVvfJkCYbhv2kucCRyNyc9FWoR=Q@mail.gmail.com>
> -----Original Message-----
> From: Ulf Hansson [mailto:ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
> Sent: Tuesday, April 05, 2016 7:28 PM
> To: Yangbo Lu
> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-
> clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-mmc; Rob Herring; Scott
> Wood; Russell King; Jochen Friedrich; Joerg Roedel; Claudiu Manoil;
> Bhupesh Sharma; Zhao Qiang; Kumar Gala; Santosh Shilimkar; Yang-Leo Li;
> Xiaobo Xie
> Subject: Re: [v7, 0/5] Fix eSDHC host version register bug
>
> On 1 April 2016 at 05:07, Yangbo Lu <yangbo.lu-3arQi8VN3Tc@public.gmane.org> wrote:
> > This patchset is used to fix a host version register bug in the
> > T4240-R1.0-R2.0 eSDHC controller. To get the SoC version and revision,
> > it's needed to add the GUTS driver to access the global utilities
> registers.
> >
> > So, the first three patches are to add the GUTS driver.
> > The following two patches are to enable GUTS driver support to get SVR
> > in eSDHC driver and fix host version for T4240.
> >
> > Yangbo Lu (5):
> > ARM64: dts: ls2080a: add device configuration node
> > soc: fsl: add GUTS driver for QorIQ platforms
> > dt: move guts devicetree doc out of powerpc directory
> > powerpc/fsl: move mpc85xx.h to include/linux/fsl
> > mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
> >
> > .../bindings/{powerpc => soc}/fsl/guts.txt | 3 +
> > arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi | 6 ++
> > arch/powerpc/kernel/cpu_setup_fsl_booke.S | 2 +-
> > drivers/clk/clk-qoriq.c | 3 +-
> > drivers/i2c/busses/i2c-mpc.c | 2 +-
> > drivers/iommu/fsl_pamu.c | 3 +-
> > drivers/mmc/host/Kconfig | 1 +
> > drivers/mmc/host/sdhci-of-esdhc.c | 23 ++++
> > drivers/net/ethernet/freescale/gianfar.c | 2 +-
> > drivers/soc/Kconfig | 2 +-
> > drivers/soc/fsl/Kconfig | 8 ++
> > drivers/soc/fsl/Makefile | 1 +
> > drivers/soc/fsl/guts.c | 119
> +++++++++++++++++++++
> > include/linux/fsl/guts.h | 98 ++++++++-----
> ----
> > .../asm/mpc85xx.h => include/linux/fsl/svr.h | 4 +-
> > 15 files changed, 219 insertions(+), 58 deletions(-) rename
> > Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
> > create mode 100644 drivers/soc/fsl/Kconfig create mode 100644
> > drivers/soc/fsl/guts.c rename arch/powerpc/include/asm/mpc85xx.h =>
> > include/linux/fsl/svr.h (97%)
> >
> > --
> > 2.1.0.27.g96db324
> >
>
> I was about to queue this for next, when I noticed that checkpatch is
> complaining/warning lots about these patches. Can you please a round of
> checkpatch and fix what makes sense.
>
> Kind regards
> Uffe
[Lu Yangbo-B47093] Sorry about this, Uffe...
Should I ignore the warnings that update MAINTAINERS?
Regarding the 'undocumented' warning, I will added a patch updates doc before all the patches, Ok?
Thanks a lot :)
^ permalink raw reply
* Re: [RFC PATCH 4/5] mlx4: add support for fast rx drop bpf program
From: Brenden Blanco @ 2016-04-06 4:05 UTC (permalink / raw)
To: Or Gerlitz
Cc: Alexei Starovoitov, Eric Dumazet, Jesper Dangaard Brouer, davem,
netdev, tom, daniel, john.fastabend, Eran Ben Elisha,
Rana Shahout, Matan Barak
In-Reply-To: <5703C878.7050307@mellanox.com>
On Tue, Apr 05, 2016 at 05:15:20PM +0300, Or Gerlitz wrote:
> On 4/4/2016 9:50 PM, Alexei Starovoitov wrote:
> >On Mon, Apr 04, 2016 at 08:22:03AM -0700, Eric Dumazet wrote:
> >>A single flow is able to use 40Gbit on those 40Gbit NIC, so there is not
> >>a single 10GB trunk used for a given flow.
> >>
> >>This 14Mpps thing seems to be a queue limitation on mlx4.
> >yeah, could be queueing related. Multiple cpus can send ~30Mpps of the same 64 byte packet,
> >but mlx4 can only receive 14.5Mpps. Odd.
> >
> >Or (and other mellanox guys), what is really going on inside 40G nic?
>
> Hi Alexei,
>
> Not that I know everything that goes inside there, and not that if I
> knew it all I could have posted that here (I heard HWs sometimes
> have IP)... but, anyway, as for your questions:
>
> ConnectX3 40Gbs NIC can receive > 10Gbs packet-worthy (14.5M) in
> single ring and Mellanox
> 100Gbs NICs can receive > 25Gbs packet-worthy (37.5M) in single
> ring, people that use DPDK (...) even see this numbers and AFAIU we
> now attempt to see that in the kernel with XDP :)
>
> I realize that we might have some issues in the mlx4 driver
> reporting on HW drops. Eran (cc-ed) and Co are looking on that.
Thanks!
>
> In parallel to doing so, I would suggest you to do some experiments
> that might shed some more light, if on the TX side you do
>
> $ ./pktgen_sample03_burst_single_flow.sh -i $DEV -d $IP -m $MAC -t 4
>
> On the RX side, skip RSS and force the packets that match that
> traffic pattern to go to (say) ring (==action) 0
>
> $ ethtool -U $DEV flow-type ip4 dst-mac $MAC dst-ip $IP action 0 loc 0
I added the module parameter:
options mlx4_core log_num_mgm_entry_size=-1
And with this I was able to reach to >20 Mpps. This is actually
regardless of the ethtool settings mentioned above.
25.31% ksoftirqd/0 [mlx4_en] [k] mlx4_en_process_rx_cq
20.18% ksoftirqd/0 [mlx4_en] [k] mlx4_en_alloc_frags
8.42% ksoftirqd/0 [mlx4_en] [k] mlx4_en_free_frag
5.59% swapper [kernel.vmlinux] [k] poll_idle
5.38% ksoftirqd/0 [kernel.vmlinux] [k] get_page_from_freelist
3.06% ksoftirqd/0 [mlx4_en] [k] mlx4_call_bpf
2.73% ksoftirqd/0 [mlx4_en] [k] 0x000000000001cf94
2.72% ksoftirqd/0 [kernel.vmlinux] [k] free_pages_prepare
2.19% ksoftirqd/0 [kernel.vmlinux] [k] percpu_array_map_lookup_elem
2.08% ksoftirqd/0 [kernel.vmlinux] [k] sk_load_byte_positive_offset
1.72% ksoftirqd/0 [kernel.vmlinux] [k] free_one_page
1.59% ksoftirqd/0 [kernel.vmlinux] [k] bpf_map_lookup_elem
1.30% ksoftirqd/0 [mlx4_en] [k] 0x000000000001cfc1
1.07% ksoftirqd/0 [kernel.vmlinux] [k] __alloc_pages_nodemask
1.00% ksoftirqd/0 [mlx4_en] [k] mlx4_alloc_pages.isra.23
>
> to go back to RSS remove the rule
>
> $ ethtool -U $DEV delete action 0
>
> FWIW (not that I see how it helps you now), you can do HW drop on
> the RX side with ring -1
>
> $ ethtool -U $DEV flow-type ip4 dst-mac $MAC dst-ip $IP action -1 loc 0
>
> Or.
>
Here also is the output from the two machines using a tool to get
ethtool delta stats at 1 second intervals:
----------- sender -----------
tx_packets: 20,246,059
tx_bytes: 1,214,763,540 bps = 9,267.91 Mbps
xmit_more: 19,463,226
queue_stopped: 36,982
wake_queue: 36,982
rx_pause: 6,351
tx_pause_duration: 124,974
tx_pause_transition: 3,176
tx_novlan_packets: 20,244,344
tx_novlan_bytes: 1,295,629,440 bps = 9,884.86 Mbps
tx0_packets: 5,151,029
tx0_bytes: 309,061,680 bps = 2,357.95 Mbps
tx1_packets: 5,094,532
tx1_bytes: 305,671,920 bps = 2,332.9 Mbps
tx2_packets: 5,130,996
tx2_bytes: 307,859,760 bps = 2,348.78 Mbps
tx3_packets: 5,135,513
tx3_bytes: 308,130,780 bps = 2,350.85 Mbps
UP 0: 9,389.68 Mbps = 100.00%
UP 0: 20,512,070 Tran/sec = 100.00%
----------- receiver -----------
rx_packets: 20,207,929
rx_bytes: 1,212,475,740 bps = 9,250.45 Mbps
rx_dropped: 236,604
rx_pause_duration: 128,436
rx_pause_transition: 3,258
tx_pause: 6,516
rx_novlan_packets: 20,208,906
rx_novlan_bytes: 1,293,369,984 bps = 9,867.62 Mbps
rx0_packets: 20,444,526
rx0_bytes: 1,226,671,560 bps = 9,358.76 Mbps
^ permalink raw reply
* [net-next 06/14] i40e: Make VF resets more reliable
From: Jeff Kirsher @ 2016-04-06 3:36 UTC (permalink / raw)
To: davem; +Cc: Mitch Williams, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1459913769-56510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
Clear the VFLR bit immediately after triggering a reset instead of
waiting until after cleanup is complete. Make sure to trigger a reset
every time, not just if the PF is up.
These changes fix a problem where VF resets would get lost by the PF,
preventing the VF driver from initializing.
Change-ID: I5945cf2884095b7b0554867c64df8617e71d9d29
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 150002e..169c256 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -937,6 +937,10 @@ void i40e_reset_vf(struct i40e_vf *vf, bool flr)
wr32(hw, I40E_VPGEN_VFRTRIG(vf->vf_id), reg);
i40e_flush(hw);
}
+ /* clear the VFLR bit in GLGEN_VFLRSTAT */
+ reg_idx = (hw->func_caps.vf_base_id + vf->vf_id) / 32;
+ bit_idx = (hw->func_caps.vf_base_id + vf->vf_id) % 32;
+ wr32(hw, I40E_GLGEN_VFLRSTAT(reg_idx), BIT(bit_idx));
if (i40e_quiesce_vf_pci(vf))
dev_err(&pf->pdev->dev, "VF %d PCI transactions stuck\n",
@@ -989,10 +993,6 @@ complete_reset:
/* tell the VF the reset is done */
wr32(hw, I40E_VFGEN_RSTAT1(vf->vf_id), I40E_VFR_VFACTIVE);
- /* clear the VFLR bit in GLGEN_VFLRSTAT */
- reg_idx = (hw->func_caps.vf_base_id + vf->vf_id) / 32;
- bit_idx = (hw->func_caps.vf_base_id + vf->vf_id) % 32;
- wr32(hw, I40E_GLGEN_VFLRSTAT(reg_idx), BIT(bit_idx));
i40e_flush(hw);
clear_bit(__I40E_VF_DISABLE, &pf->state);
}
@@ -2296,11 +2296,9 @@ int i40e_vc_process_vflr_event(struct i40e_pf *pf)
/* read GLGEN_VFLRSTAT register to find out the flr VFs */
vf = &pf->vf[vf_id];
reg = rd32(hw, I40E_GLGEN_VFLRSTAT(reg_idx));
- if (reg & BIT(bit_idx)) {
+ if (reg & BIT(bit_idx))
/* i40e_reset_vf will clear the bit in GLGEN_VFLRSTAT */
- if (!test_bit(__I40E_DOWN, &pf->state))
- i40e_reset_vf(vf, true);
- }
+ i40e_reset_vf(vf, true);
}
return 0;
--
2.5.5
^ permalink raw reply related
* [net-next 13/14] i40e/i40evf: Bump patch from 1.5.1 to 1.5.2
From: Jeff Kirsher @ 2016-04-06 3:36 UTC (permalink / raw)
To: davem; +Cc: Avinash Dayanand, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1459913769-56510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Avinash Dayanand <avinash.dayanand@intel.com>
Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index d2c0106..d6147f8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -46,7 +46,7 @@ static const char i40e_driver_string[] =
#define DRV_VERSION_MAJOR 1
#define DRV_VERSION_MINOR 5
-#define DRV_VERSION_BUILD 1
+#define DRV_VERSION_BUILD 2
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) DRV_KERN
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 2d1fe56..f4dada0 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -38,7 +38,7 @@ static const char i40evf_driver_string[] =
#define DRV_VERSION_MAJOR 1
#define DRV_VERSION_MINOR 5
-#define DRV_VERSION_BUILD 1
+#define DRV_VERSION_BUILD 2
#define DRV_VERSION __stringify(DRV_VERSION_MAJOR) "." \
__stringify(DRV_VERSION_MINOR) "." \
__stringify(DRV_VERSION_BUILD) \
--
2.5.5
^ permalink raw reply related
* [net-next 12/14] i40e: Request PHY media event at reset time
From: Jeff Kirsher @ 2016-04-06 3:36 UTC (permalink / raw)
To: davem; +Cc: Shannon Nelson, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1459913769-56510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Shannon Nelson <shannon.nelson@intel.com>
Add the Media Not Available flag to the link event mask. It seems
that event comes first if you have a DA cable pulled out, but there's no
follow-up event for Link Down; if you're not looking for MEDIA_NA you will
get no event, even though there's now no Link.
Change-ID: cb3340a2849805bb881f64f6f2ae810eef46eba7
Signed-off-by: Shannon Nelson <shannon.nelson@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 184f3f9..d2c0106 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -6859,6 +6859,7 @@ static void i40e_reset_and_rebuild(struct i40e_pf *pf, bool reinit)
*/
ret = i40e_aq_set_phy_int_mask(&pf->hw,
~(I40E_AQ_EVENT_LINK_UPDOWN |
+ I40E_AQ_EVENT_MEDIA_NA |
I40E_AQ_EVENT_MODULE_QUAL_FAIL), NULL);
if (ret)
dev_info(&pf->pdev->dev, "set phy mask fail, err %s aq_err %s\n",
@@ -11070,6 +11071,7 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
*/
err = i40e_aq_set_phy_int_mask(&pf->hw,
~(I40E_AQ_EVENT_LINK_UPDOWN |
+ I40E_AQ_EVENT_MEDIA_NA |
I40E_AQ_EVENT_MODULE_QUAL_FAIL), NULL);
if (err)
dev_info(&pf->pdev->dev, "set phy mask fail, err %s aq_err %s\n",
--
2.5.5
^ permalink raw reply related
* [net-next 14/14] i40e/i40evf: Fix TSO checksum pseudo-header adjustment
From: Jeff Kirsher @ 2016-04-06 3:36 UTC (permalink / raw)
To: davem; +Cc: Alexander Duyck, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1459913769-56510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Alexander Duyck <aduyck@mirantis.com>
With IPv4 and IPv6 now using the same format for checksums based on the
length of the frame we need to update the i40e and i40evf drivers so that
they correctly account for lengths greater than or equal to 64K.
With this patch the driver should now correctly update checksums for frames
up to 16776960 in length which should be more than large enough for all
possible TSO frames in the near future.
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 11 ++++-------
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 11 ++++-------
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index 5bef5b0..5d5fa53 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2304,10 +2304,8 @@ static int i40e_tso(struct i40e_ring *tx_ring, struct sk_buff *skb,
l4_offset = l4.hdr - skb->data;
/* remove payload length from outer checksum */
- paylen = (__force u16)l4.udp->check;
- paylen += ntohs((__force __be16)1) *
- (u16)~(skb->len - l4_offset);
- l4.udp->check = ~csum_fold((__force __wsum)paylen);
+ paylen = skb->len - l4_offset;
+ csum_replace_by_diff(&l4.udp->check, htonl(paylen));
}
/* reset pointers to inner headers */
@@ -2327,9 +2325,8 @@ static int i40e_tso(struct i40e_ring *tx_ring, struct sk_buff *skb,
l4_offset = l4.hdr - skb->data;
/* remove payload length from inner checksum */
- paylen = (__force u16)l4.tcp->check;
- paylen += ntohs((__force __be16)1) * (u16)~(skb->len - l4_offset);
- l4.tcp->check = ~csum_fold((__force __wsum)paylen);
+ paylen = skb->len - l4_offset;
+ csum_replace_by_diff(&l4.tcp->check, htonl(paylen));
/* compute length of segmentation header */
*hdr_len = (l4.tcp->doff * 4) + l4_offset;
diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
index 570348d..04aabc5 100644
--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
@@ -1571,10 +1571,8 @@ static int i40e_tso(struct i40e_ring *tx_ring, struct sk_buff *skb,
l4_offset = l4.hdr - skb->data;
/* remove payload length from outer checksum */
- paylen = (__force u16)l4.udp->check;
- paylen += ntohs((__force __be16)1) *
- (u16)~(skb->len - l4_offset);
- l4.udp->check = ~csum_fold((__force __wsum)paylen);
+ paylen = skb->len - l4_offset;
+ csum_replace_by_diff(&l4.udp->check, htonl(paylen));
}
/* reset pointers to inner headers */
@@ -1594,9 +1592,8 @@ static int i40e_tso(struct i40e_ring *tx_ring, struct sk_buff *skb,
l4_offset = l4.hdr - skb->data;
/* remove payload length from inner checksum */
- paylen = (__force u16)l4.tcp->check;
- paylen += ntohs((__force __be16)1) * (u16)~(skb->len - l4_offset);
- l4.tcp->check = ~csum_fold((__force __wsum)paylen);
+ paylen = skb->len - l4_offset;
+ csum_replace_by_diff(&l4.tcp->check, htonl(paylen));
/* compute length of segmentation header */
*hdr_len = (l4.tcp->doff * 4) + l4_offset;
--
2.5.5
^ permalink raw reply related
* [net-next 11/14] i40e: Lower some message levels
From: Jeff Kirsher @ 2016-04-06 3:36 UTC (permalink / raw)
To: davem; +Cc: Mitch Williams, netdev, nhorman, sassmann, jogreene, Jeff Kirsher
In-Reply-To: <1459913769-56510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Mitch Williams <mitch.a.williams@intel.com>
These conditions can happen any time VFs are enabled or disabled and are
not really indicative of fatal problems unless they happen continuously.
Lower the log level so that people don't get scared.
Change-ID: I1ceb4adbd10d03cbeed54d1f5b7f20d60328351d
Signed-off-by: Mitch Williams <mitch.a.williams@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index 169c256..9924503 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -1232,8 +1232,8 @@ static int i40e_vc_send_msg_to_vf(struct i40e_vf *vf, u32 v_opcode,
/* single place to detect unsuccessful return values */
if (v_retval) {
vf->num_invalid_msgs++;
- dev_err(&pf->pdev->dev, "VF %d failed opcode %d, error: %d\n",
- vf->vf_id, v_opcode, v_retval);
+ dev_info(&pf->pdev->dev, "VF %d failed opcode %d, retval: %d\n",
+ vf->vf_id, v_opcode, v_retval);
if (vf->num_invalid_msgs >
I40E_DEFAULT_NUM_INVALID_MSGS_ALLOWED) {
dev_err(&pf->pdev->dev,
@@ -1251,9 +1251,9 @@ static int i40e_vc_send_msg_to_vf(struct i40e_vf *vf, u32 v_opcode,
aq_ret = i40e_aq_send_msg_to_vf(hw, abs_vf_id, v_opcode, v_retval,
msg, msglen, NULL);
if (aq_ret) {
- dev_err(&pf->pdev->dev,
- "Unable to send the message to VF %d aq_err %d\n",
- vf->vf_id, pf->hw.aq.asq_last_status);
+ dev_info(&pf->pdev->dev,
+ "Unable to send the message to VF %d aq_err %d\n",
+ vf->vf_id, pf->hw.aq.asq_last_status);
return -EIO;
}
--
2.5.5
^ permalink raw reply related
* [net-next 10/14] i40e: Fix for supported link modes in 10GBaseT PHY's
From: Jeff Kirsher @ 2016-04-06 3:36 UTC (permalink / raw)
To: davem; +Cc: Avinash Dayanand, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1459913769-56510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Avinash Dayanand <avinash.dayanand@intel.com>
100baseT/Full is now listed and supported link mode for 10GBaseT PHY.
This is a fix to list all the supported link modes of 10GBaseT PHY.
Change-ID: If2be3212ef0fef85fd5d6e4550c7783de2f915e9
Signed-off-by: Avinash Dayanand <avinash.dayanand@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
index 410d237..8a83d45 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_ethtool.c
@@ -313,6 +313,13 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
ecmd->advertising |= ADVERTISED_10000baseT_Full;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_1GB)
ecmd->advertising |= ADVERTISED_1000baseT_Full;
+ /* adding 100baseT support for 10GBASET_PHY */
+ if (pf->flags & I40E_FLAG_HAVE_10GBASET_PHY) {
+ ecmd->supported |= SUPPORTED_100baseT_Full;
+ ecmd->advertising |= ADVERTISED_100baseT_Full |
+ ADVERTISED_1000baseT_Full |
+ ADVERTISED_10000baseT_Full;
+ }
break;
case I40E_PHY_TYPE_1000BASE_T_OPTICAL:
ecmd->supported = SUPPORTED_Autoneg |
@@ -325,6 +332,15 @@ static void i40e_get_settings_link_up(struct i40e_hw *hw,
SUPPORTED_100baseT_Full;
if (hw_link_info->requested_speeds & I40E_LINK_SPEED_100MB)
ecmd->advertising |= ADVERTISED_100baseT_Full;
+ /* firmware detects 10G phy as 100M phy at 100M speed */
+ if (pf->flags & I40E_FLAG_HAVE_10GBASET_PHY) {
+ ecmd->supported |= SUPPORTED_10000baseT_Full |
+ SUPPORTED_1000baseT_Full;
+ ecmd->advertising |= ADVERTISED_Autoneg |
+ ADVERTISED_100baseT_Full |
+ ADVERTISED_1000baseT_Full |
+ ADVERTISED_10000baseT_Full;
+ }
break;
case I40E_PHY_TYPE_10GBASE_CR1_CU:
case I40E_PHY_TYPE_10GBASE_CR1:
--
2.5.5
^ permalink raw reply related
* [net-next 09/14] i40evf: Fix get_rss_aq
From: Jeff Kirsher @ 2016-04-06 3:36 UTC (permalink / raw)
To: davem; +Cc: Catherine Sullivan, netdev, nhorman, sassmann, jogreene,
Jeff Kirsher
In-Reply-To: <1459913769-56510-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Catherine Sullivan <catherine.sullivan@intel.com>
We were passing in the seed where we should just be passing false
because we want the VSI table not the pf table.
Change-ID: I9b633ab06eb59468087f0c0af8539857e99f9495
Signed-off-by: Catherine Sullivan <catherine.sullivan@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index 6561a33..2d1fe56 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1341,7 +1341,7 @@ static int i40evf_get_rss_aq(struct i40e_vsi *vsi, const u8 *seed,
}
if (lut) {
- ret = i40evf_aq_get_rss_lut(hw, vsi->id, seed, lut, lut_size);
+ ret = i40evf_aq_get_rss_lut(hw, vsi->id, false, lut, lut_size);
if (ret) {
dev_err(&adapter->pdev->dev,
"Cannot get RSS lut, err %s aq_err %s\n",
--
2.5.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox