* [patch net-next RFC 00/13] devlink: add support for configuration of shared buffers
From: Jiri Pirko @ 2016-03-17 17:13 UTC (permalink / raw)
To: netdev
Cc: davem, idosch, eladr, yotamg, ogerlitz, roopa, nikolay, jhs,
john.fastabend, rami.rosen, gospo, stephen, sfeldma
From: Jiri Pirko <jiri@mellanox.com>
This RFC implements support for configuring ASIC shared buffers.
ASICs implement shared buffer for packet forwarding purposes and enable
flexible partitioning of the shared buffer for different flows and ports,
enabling non-blocking progress of different flows as well as separation
of lossy traffic from loss-less traffic when using Per-Priority Flow
Control (PFC). The shared buffer optimizes the buffer utilization for better
absorption of packet bursts.
This patchset implements API which is based on the model SAI uses. That is
aligned with multiple ASIC vendors so this API should be vendor neutral.
Userspace counterpart patch for devlink iproute2 tool can be found here:
https://github.com/jpirko/iproute2_mlxsw/tree/devlink_sb_rfc
Couple of examples of usage:
$ devlink sb help
Usage: devlink sb show [ DEV [ sb SB_INDEX ] ]
devlink sb pool show [ DEV [ sb SB_INDEX ] pool POOL_INDEX ]
devlink sb pool set DEV [ sb SB_INDEX ] pool POOL_INDEX
size POOL_SIZE thtype { static | dynamic }
devlink sb port pool show [ DEV/PORT_INDEX [ sb SB_INDEX ]
pool POOL_INDEX ]
devlink sb port pool set DEV/PORT_INDEX [ sb SB_INDEX ]
pool POOL_INDEX th THRESHOLD
devlink sb tc bind show [ DEV/PORT_INDEX [ sb SB_INDEX ] tc TC_INDEX ]
devlink sb tc bind set DEV/PORT_INDEX [ sb SB_INDEX ] tc TC_INDEX
type { ingress | egress } pool POOL_INDEX
th THRESHOLD
$ devlink sb show
pci/0000:03:00.0: sb 0 size 16777216 ingress_pools 4 egress_pools 4 tcs 8
$ devlink sb pool show
pci/0000:03:00.0: sb 0 pool 0 type ingress size 12399936 thtype dynamic
pci/0000:03:00.0: sb 0 pool 1 type ingress size 0 thtype dynamic
pci/0000:03:00.0: sb 0 pool 2 type ingress size 0 thtype dynamic
pci/0000:03:00.0: sb 0 pool 3 type ingress size 0 thtype dynamic
pci/0000:03:00.0: sb 0 pool 4 type egress size 13219968 thtype dynamic
pci/0000:03:00.0: sb 0 pool 5 type egress size 0 thtype dynamic
pci/0000:03:00.0: sb 0 pool 6 type egress size 0 thtype dynamic
pci/0000:03:00.0: sb 0 pool 7 type egress size 13219968 thtype dynamic
$ devlink sb port pool show
pci/0000:03:00.0/1: sb 0 pool 0 threshold 255
pci/0000:03:00.0/1: sb 0 pool 1 threshold 0
pci/0000:03:00.0/1: sb 0 pool 2 threshold 0
pci/0000:03:00.0/1: sb 0 pool 3 threshold 0
pci/0000:03:00.0/1: sb 0 pool 4 threshold 7
pci/0000:03:00.0/1: sb 0 pool 5 threshold 0
pci/0000:03:00.0/1: sb 0 pool 6 threshold 0
pci/0000:03:00.0/1: sb 0 pool 7 threshold 0
...
pci/0000:03:00.0/63: sb 0 pool 0 threshold 255
pci/0000:03:00.0/63: sb 0 pool 1 threshold 0
pci/0000:03:00.0/63: sb 0 pool 2 threshold 0
pci/0000:03:00.0/63: sb 0 pool 3 threshold 0
pci/0000:03:00.0/63: sb 0 pool 4 threshold 7
pci/0000:03:00.0/63: sb 0 pool 5 threshold 0
pci/0000:03:00.0/63: sb 0 pool 6 threshold 0
pci/0000:03:00.0/63: sb 0 pool 7 threshold 0
$ devlink sb tc bind show
pci/0000:03:00.0/1: sb 0 tc 0 type ingress pool 0 threshold 8
pci/0000:03:00.0/1: sb 0 tc 0 type egress pool 4 threshold 9
pci/0000:03:00.0/1: sb 0 tc 1 type ingress pool 0 threshold 0
pci/0000:03:00.0/1: sb 0 tc 1 type egress pool 4 threshold 9
pci/0000:03:00.0/1: sb 0 tc 2 type ingress pool 0 threshold 0
pci/0000:03:00.0/1: sb 0 tc 2 type egress pool 4 threshold 9
pci/0000:03:00.0/1: sb 0 tc 3 type ingress pool 0 threshold 0
pci/0000:03:00.0/1: sb 0 tc 3 type egress pool 4 threshold 9
pci/0000:03:00.0/1: sb 0 tc 4 type ingress pool 0 threshold 0
pci/0000:03:00.0/1: sb 0 tc 4 type egress pool 4 threshold 9
pci/0000:03:00.0/1: sb 0 tc 5 type ingress pool 0 threshold 0
pci/0000:03:00.0/1: sb 0 tc 5 type egress pool 4 threshold 9
pci/0000:03:00.0/1: sb 0 tc 6 type ingress pool 0 threshold 0
pci/0000:03:00.0/1: sb 0 tc 6 type egress pool 4 threshold 9
pci/0000:03:00.0/1: sb 0 tc 7 type ingress pool 0 threshold 0
pci/0000:03:00.0/1: sb 0 tc 7 type egress pool 4 threshold 9
...
pci/0000:03:00.0/63: sb 0 tc 0 type ingress pool 0 threshold 8
pci/0000:03:00.0/63: sb 0 tc 0 type egress pool 4 threshold 9
pci/0000:03:00.0/63: sb 0 tc 1 type ingress pool 0 threshold 0
pci/0000:03:00.0/63: sb 0 tc 1 type egress pool 4 threshold 9
pci/0000:03:00.0/63: sb 0 tc 2 type ingress pool 0 threshold 0
pci/0000:03:00.0/63: sb 0 tc 2 type egress pool 4 threshold 9
pci/0000:03:00.0/63: sb 0 tc 3 type ingress pool 0 threshold 0
pci/0000:03:00.0/63: sb 0 tc 3 type egress pool 4 threshold 9
pci/0000:03:00.0/63: sb 0 tc 4 type ingress pool 0 threshold 0
pci/0000:03:00.0/63: sb 0 tc 4 type egress pool 4 threshold 9
pci/0000:03:00.0/63: sb 0 tc 5 type ingress pool 0 threshold 0
pci/0000:03:00.0/63: sb 0 tc 5 type egress pool 4 threshold 9
pci/0000:03:00.0/63: sb 0 tc 6 type ingress pool 0 threshold 0
pci/0000:03:00.0/63: sb 0 tc 6 type egress pool 4 threshold 9
pci/0000:03:00.0/63: sb 0 tc 7 type ingress pool 0 threshold 0
pci/0000:03:00.0/63: sb 0 tc 7 type egress pool 4 threshold 9
$ sudo devlink sb pool set pci/0000:03:00.0 pool 1 size 40000 thtype static
$ devlink sb pool show pci/0000:03:00.0 pool 1
pci/0000:03:00.0: sb 0 pool 1 type ingress size 40032 thtype static
$ sudo devlink sb port pool set pci/0000:03:00.0/1 pool 1 th 20000
$ devlink sb port pool show pci/0000:03:00.0/1 pool 1
pci/0000:03:00.0/1: sb 0 pool 1 threshold 20064
$ sudo devlink sb tc bind set pci/0000:03:00.0/1 tc 1 type ingress pool 1 th 10000
$ devlink sb tc bind show pci/0000:03:00.0/1 tc 1 type ingress
pci/0000:03:00.0/1: sb 0 tc 1 type ingress pool 1 threshold 10080
Jiri Pirko (13):
devlink: share user_ptr pointer for for both devlink and devlink_port
devlink: add shared buffer configuration
mlxsw: Move devlink port registration into common core code
mlxsw: Pass mlxsw_core as a param of mlxsw_core_skb_transmit*
mlxsw: Do not pass around driver_priv directly
mlxsw: reg: Share direction enum between SBPR, SBCM, SBPM
mlxsw: reg: Fix SBPM register name
mlxsw: core: Add devlink shared buffer callbacks
mlxsw: spectrum_buffers: Push out shared buffer register writes
mlxsw: spectrum_buffers: Push out indexes and direction out of SB
structs
mlxsw: spectrum_buffers: Rename "pool" to "pr" in initialization
mlxsw: spectrum_buffers: Cache shared buffer configuration
mlxsw: spectrum: Implement shared buffer configuration
drivers/net/ethernet/mellanox/mlxsw/core.c | 161 +++-
drivers/net/ethernet/mellanox/mlxsw/core.h | 55 +-
drivers/net/ethernet/mellanox/mlxsw/reg.h | 27 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 60 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 52 +-
.../net/ethernet/mellanox/mlxsw/spectrum_buffers.c | 698 ++++++++++-----
drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 42 +-
include/net/devlink.h | 46 +
include/uapi/linux/devlink.h | 41 +
net/core/devlink.c | 932 ++++++++++++++++++++-
10 files changed, 1773 insertions(+), 341 deletions(-)
--
2.5.0
^ permalink raw reply
* Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory
From: Arnd Bergmann @ 2016-03-17 17:11 UTC (permalink / raw)
To: Rob Herring
Cc: Yangbo Lu, devicetree, linux-arm-kernel, linux-kernel,
linuxppc-dev, linux-clk, linux-i2c, iommu, netdev, linux-mmc,
scott.wood, Russell King, Jochen Friedrich, Joerg Roedel,
Claudiu Manoil, ulf.hansson, Bhupesh Sharma, Zhao Qiang,
Kumar Gala, Santosh Shilimkar, leoyang.li, xiaobo.xie
In-Reply-To: <20160317170640.GB21009@rob-hp-laptop>
On Thursday 17 March 2016 12:06:40 Rob Herring wrote:
> > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> > similarity index 91%
> > rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> > rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
> > index b71b203..07adca9 100644
> > --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> > +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> > @@ -25,6 +25,9 @@ Recommended properties:
> > - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
> > registers, for those SOCs that have a PAMU device.
> >
> > + - little-endian : Indicates that the global utilities block is little
> > + endian. The default is big endian.
>
> The default is "the native endianness of the system".
This may be what is currently documented, but not what we are doing
in practice, as there is no "native endianess" for either PowerPC or
ARM -- both allow running big-endian or little-endian kernels and the
device registers are fixed.
I think the property here is fine.
Arnd
^ permalink raw reply
* Re: [PATCH] xfrm: don't segment UFO packets
From: Jiri Bohac @ 2016-03-17 17:08 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Herbert Xu, David S. Miller, netdev
In-Reply-To: <20160317102459.GG3347@gauss.secunet.com>
On Thu, Mar 17, 2016 at 11:24:59AM +0100, Steffen Klassert wrote:
> In IPv6 this check is missing, so this could be the
> problem if this is IPv6.
indeed, this patch also fixes my problem:
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1353,6 +1353,7 @@ emsgsize:
(skb && skb_is_gso(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->dst.dev->features & NETIF_F_UFO) &&
+ !rt->dst.header_len &&
(sk->sk_type == SOCK_DGRAM)) {
err = ip6_ufo_append_data(sk, queue, getfrag, from, length,
hh_len, fragheaderlen,
I can't say which is better. Herbert originally seemed to like
the fix inside xfrm_output().
The IPv4 part is fixed by commit
c146066ab80267c3305de5dda6a4083f06df9265 (ipv4: Don't use ufo
handling on later transformed packets)
Thanks,
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply
* Re: [v6, 3/5] dt: move guts devicetree doc out of powerpc directory
From: Rob Herring @ 2016-03-17 17:06 UTC (permalink / raw)
To: Yangbo Lu
Cc: devicetree, linux-arm-kernel, linux-kernel, linuxppc-dev,
linux-clk, linux-i2c, iommu, netdev, linux-mmc, scott.wood,
Russell King, Jochen Friedrich, Joerg Roedel, Claudiu Manoil,
ulf.hansson, Bhupesh Sharma, Zhao Qiang, Kumar Gala,
Santosh Shilimkar, leoyang.li, xiaobo.xie
In-Reply-To: <1457518131-11339-4-git-send-email-yangbo.lu@nxp.com>
On Wed, Mar 09, 2016 at 06:08:49PM +0800, Yangbo Lu wrote:
> Move guts devicetree doc to Documentation/devicetree/bindings/soc/fsl/
> since it's used by not only PowerPC but also ARM. And add a specification
> for 'little-endian' property.
>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> ---
> Changes for v2:
> - None
> Changes for v3:
> - None
> Changes for v4:
> - Added this patch
> Changes for v5:
> - Modified the description for little-endian property
> Changes for v6:
> - None
> ---
> Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt | 3 +++
> 1 file changed, 3 insertions(+)
> rename Documentation/devicetree/bindings/{powerpc => soc}/fsl/guts.txt (91%)
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> similarity index 91%
> rename from Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> rename to Documentation/devicetree/bindings/soc/fsl/guts.txt
> index b71b203..07adca9 100644
> --- a/Documentation/devicetree/bindings/powerpc/fsl/guts.txt
> +++ b/Documentation/devicetree/bindings/soc/fsl/guts.txt
> @@ -25,6 +25,9 @@ Recommended properties:
> - fsl,liodn-bits : Indicates the number of defined bits in the LIODN
> registers, for those SOCs that have a PAMU device.
>
> + - little-endian : Indicates that the global utilities block is little
> + endian. The default is big endian.
The default is "the native endianness of the system". So absence on an
ARM system would be LE. This property is valid for any simple-bus
device, so it isn't really required to document per device. You can, but
your description had better match the documented behaviour.
Rob
^ permalink raw reply
* Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
From: Arnd Bergmann @ 2016-03-17 17:06 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Zhao Qiang,
Russell King, Santosh Shilimkar, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kumar Gala,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Scott Wood,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Claudiu Manoil,
Yangbo Lu, Yang-Leo Li,
"linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" <linuxppc-dev
In-Reply-To: <20160317170101.GA21009@rob-hp-laptop>
On Thursday 17 March 2016 12:01:01 Rob Herring wrote:
> On Mon, Mar 14, 2016 at 05:45:43PM +0000, Scott Wood wrote:
> > >> This makes the driver non-portable. Better identify the specific
> > >> workarounds based on the compatible string for this device, or add a
> > >> boolean DT property for the quirk.
> > >>
> > >> Arnd
> > >
> > > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before.
> > > https://patchwork.kernel.org/patch/6834221/
> > >
> > > We don’t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one.
> > > In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed.
> > > See the link for details.
> > >
> > > So we decide to read SVR from the device-config/guts MMIO block other than using DTS.
> > > Thanks.
> >
> > Also note that this driver is already only for fsl-specific hardware,
> > and it will still work even if fsl_guts doesn't find anything to bind to
> > -- it just wouldn't be able to detect errata based on SVR in that case.
>
> IIRC, it is the same IP block as i.MX and Arnd's point is this won't
> even compile on !PPC. It is things like this that prevent sharing the
> driver.
I think the first four patches take care of building for ARM,
but the problem remains if you want to enable COMPILE_TEST as
we need for certain automated checking.
> Dealing with Si revs is a common problem. We should have a
> common solution. There is soc_device for this purpose.
Exactly. The last time this came up, I think we agreed to implement a
helper using glob_match() on the soc_device strings. Unfortunately
this hasn't happened then, but I'd still prefer that over yet another
vendor-specific way of dealing with the generic issue.
Arnd
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [BUG] bcmgenet tx path
From: Florian Fainelli @ 2016-03-17 17:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, opendmb
In-Reply-To: <1458137881.7353.9.camel@edumazet-glaptop3.roam.corp.google.com>
Hi Eric,
On 16/03/16 07:18, Eric Dumazet wrote:
> Hi Florian
>
> I was looking at drivers/net/ethernet/broadcom/genet/bcmgenet.c
> and found TX completion (__bcmgenet_tx_reclaim()) was freeing skb before
> frags were actually dma unmapped.
>
>
> Are you sure this is OK ? bnx2 and bnx2x actually do the reverse (unmap
> all frags before freeing skb)
It does not seem to be much of an issue right now because we put the skb
first, and the frags next in the order we want to transmit them, and we
reclaim in the same order, but it certainly makes more sense to revese
the operation.
>
> A second problem is the dma_unmap_single() uses tx_cb_ptr->skb->len for
> the length, while it really should be the same thing that was used in
> bcmgenet_xmit_single()
Yes, that is indeed a bug, surprisingly the DMA-API debugging did not
seem to complain about that (should look into why). FWIW, we do not turn
on SG by default, so AFAIR we are not even hitting this path.
Can you submit a formal patch for this and we look into reversing the
mapping of fragments?
Thanks!
>
> skb_len = skb_headlen(skb) < ETH_ZLEN ? ETH_ZLEN : skb_headlen(skb);
>
> So maybe something like :
>
> diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> index d7e01a7..9211b9c7 100644
> --- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> +++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
> @@ -1197,7 +1197,7 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
> dev->stats.tx_bytes += tx_cb_ptr->skb->len;
> dma_unmap_single(&dev->dev,
> dma_unmap_addr(tx_cb_ptr, dma_addr),
> - tx_cb_ptr->skb->len,
> + dma_unmap_len(tx_cb_ptr, dma_len),
> DMA_TO_DEVICE);
> bcmgenet_free_cb(tx_cb_ptr);
> } else if (dma_unmap_addr(tx_cb_ptr, dma_addr)) {
> @@ -1308,7 +1308,7 @@ static int bcmgenet_xmit_single(struct net_device *dev,
> }
>
> dma_unmap_addr_set(tx_cb_ptr, dma_addr, mapping);
> - dma_unmap_len_set(tx_cb_ptr, dma_len, skb->len);
> + dma_unmap_len_set(tx_cb_ptr, dma_len, skb_len);
> length_status = (skb_len << DMA_BUFLENGTH_SHIFT) | dma_desc_flags |
> (priv->hw_params->qtag_mask << DMA_TX_QTAG_SHIFT) |
> DMA_TX_APPEND_CRC;
>
>
--
Florian
^ permalink raw reply
* Re: [PATCH] net: phy: at803x: Add support to control PHY LEDs
From: Florian Fainelli @ 2016-03-17 16:59 UTC (permalink / raw)
To: Andrew Lunn, Vishal Thanki; +Cc: ujhelyi.m, netdev
In-Reply-To: <20160317145032.GB26019@lunn.ch>
On 17/03/16 07:50, Andrew Lunn wrote:
> On Thu, Mar 17, 2016 at 02:59:07PM +0100, Vishal Thanki wrote:
>> The LEDs can be turned on and off by a sysfs interface
>> now. Write 0 to "led_enable" file to turn off the LEDs
>> and write 1 to turn on. The support is experimental
>> and can be enabled by kernel configuration option.
>>
>> Signed-off-by: Vishal Thanki <vishalthanki@gmail.com>
>> ---
>> drivers/net/phy/Kconfig | 7 +++++
>> drivers/net/phy/at803x.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++
>
> Hi Vishal
>
> This solution seems specific to the at803. You should be thinking of a
> generic solution that all PHYs can use. eg add a new callback function
> to phy_driver, and put the sysfs handling code in phylib.
Indeed, maybe we should be considering using the existing LEDS subsystem
(drivers/leds/*) to expose the PHY LEDs to user-space in a standard way?
--
Florian
^ permalink raw reply
* Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-R1.0-R2.0
From: Rob Herring @ 2016-03-17 17:01 UTC (permalink / raw)
To: Scott Wood
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Zhao Qiang,
Russell King, Arnd Bergmann, Bhupesh Sharma,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Kumar Gala,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Yang-Leo Li,
Santosh Shilimkar,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Claudiu Manoil,
Yangbo Lu, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
In-Reply-To: <DB5PR0401MB19286B2D23D07F5C60DB799D91880-GXldUsIPo7Z/SeJcUcAJq43W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Mon, Mar 14, 2016 at 05:45:43PM +0000, Scott Wood wrote:
> On 03/14/2016 02:29 AM, Yangbo Lu wrote:
> >> -----Original Message-----
> >> From: Arnd Bergmann [mailto:arnd@arndb.de]
> >> Sent: Monday, March 14, 2016 6:26 AM
> >> To: linuxppc-dev@lists.ozlabs.org
> >> Cc: Yangbo Lu; devicetree@vger.kernel.org; linux-arm-
> >> kernel@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> >> clk@vger.kernel.org; linux-i2c@vger.kernel.org; iommu@lists.linux-
> >> foundation.org; netdev@vger.kernel.org; linux-mmc@vger.kernel.org;
> >> ulf.hansson@linaro.org; Zhao Qiang; Russell King; Bhupesh Sharma; Joerg
> >> Roedel; Santosh Shilimkar; Scott Wood; Rob Herring; Claudiu Manoil; Kumar
> >> Gala; Yang-Leo Li; Xiaobo Xie
> >> Subject: Re: [v6, 5/5] mmc: sdhci-of-esdhc: fix host version for T4240-
> >> R1.0-R2.0
> >>
> >> On Wednesday 09 March 2016 18:08:51 Yangbo Lu wrote:
> >>> @@ -567,10 +580,20 @@ static void esdhc_init(struct platform_device
> >> *pdev, struct sdhci_host *host)
> >>> struct sdhci_pltfm_host *pltfm_host;
> >>> struct sdhci_esdhc *esdhc;
> >>> u16 host_ver;
> >>> + u32 svr;
> >>>
> >>> pltfm_host = sdhci_priv(host);
> >>> esdhc = sdhci_pltfm_priv(pltfm_host);
> >>>
> >>> + fsl_guts_init();
> >>> + svr = fsl_guts_get_svr();
> >>> + if (svr) {
> >>> + esdhc->soc_ver = SVR_SOC_VER(svr);
> >>> + esdhc->soc_rev = SVR_REV(svr);
> >>> + } else {
> >>> + dev_err(&pdev->dev, "Failed to get SVR value!\n");
> >>> + }
> >>> +
> >>
> >> This makes the driver non-portable. Better identify the specific
> >> workarounds based on the compatible string for this device, or add a
> >> boolean DT property for the quirk.
> >>
> >> Arnd
> >
> > [Lu Yangbo-B47093] Hi Arnd, we did have a discussion about using DTS in v1 before.
> > https://patchwork.kernel.org/patch/6834221/
> >
> > We don’t have a separate DTS file for each revision of an SOC and if we did, we'd constantly have people using the wrong one.
> > In addition, the device tree is stable ABI and errata are often discovered after device tree are deployed.
> > See the link for details.
> >
> > So we decide to read SVR from the device-config/guts MMIO block other than using DTS.
> > Thanks.
>
> Also note that this driver is already only for fsl-specific hardware,
> and it will still work even if fsl_guts doesn't find anything to bind to
> -- it just wouldn't be able to detect errata based on SVR in that case.
IIRC, it is the same IP block as i.MX and Arnd's point is this won't
even compile on !PPC. It is things like this that prevent sharing the
driver. Dealing with Si revs is a common problem. We should have a
common solution. There is soc_device for this purpose.
OTOH, the integration differences may be enough that trying to have a
common driver with i.MX would not be worth it.
Rob
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
^ permalink raw reply
* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Dave Taht @ 2016-03-17 17:00 UTC (permalink / raw)
To: Michal Kazior
Cc: Jasmine Strong, Network Development, linux-wireless,
ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
codel-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org,
make-wifi-fast-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1
In-Reply-To: <CA+BoTQnFN6VANn=5EUvHc0Dbfh4Zv0HraOto2ySN3_HdOpD7Sg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Mar 17, 2016 at 1:55 AM, Michal Kazior <michal.kazior-++hxYGjEMp0AvxtiuMwx3w@public.gmane.org> wrote:
> I suspect the BK/BE latency difference has to do with the fact that
> there's bulk traffic going on BE queues (this isn't reflected
> explicitly in the plots). The `bursts` flent test includes short
> bursts of traffic on tid0 (BE) which is shared with ICMP and BE UDP_RR
> (seen as green and blue lines on the plot). Due to (intended) limited
> outflow (6mbps) BE queues build up and don't drain for the duration of
> the entire test creating more opportunities for aggregating BE traffic
> while other queues are near-empty and very short (time wise as well).
I agree with your explanation. Access to the media and queue length
are the two variables at play here.
I just committed a new flent test that should exercise the vo,vi,be,
and bk queues, "bursts_11e". I dropped the conventional ping from it
and just rely on netperf's udp_rr for each queue. It seems to "do the
right thing" on the ath9k....
And while I'm all in favor of getting 802.11e's behaviors more right,
and this seems like a good way to get there...
netperf's udp_rr is not how much traffic conventionally behaves. It
doesn't do tcp slow start or congestion control in particular...
In the case of the VO queue, for example, the (2004) intended behavior
was 1 isochronous packet per 10ms per voice sending station and one
from the ap, not a "ping". And at the time, VI was intended to be
unicast video. TCP was an afterthought. (wifi's original (1993) mac
was actually designed for ipx/spx!)
I long for regular "rrul" and "rrul_be" tests against the new stuff to
blow it up thoroughly as references along the way.
(tcp_upload, tcp_download, (and several of the rtt_fair tests also
between stations)). Will get formal about it here as soon as we end up
on the same kernel trees....
Furthermore 802.11e is not widely used - in particular, not much
internet bound/sourced traffic falls into more than BE and BK,
presently. and in some cases weirder - comcast remarks a very large
percentage of to the home inbound traffic as CS1 (BK), btw, and
stations tend to use CS0. Data comes in on BK, acks go out on BE.
I/we will try to come up with intermediate tests between the burst
tests and the rrul tests as we go along the way.
> If you consider Wi-Fi is half-duplex and latency in the entire stack
In the context of this test regime...
<pedantry>
Saying wifi is "half"-duplex is a misleading way to think about it in
many respects. it is a shared medium more like early, non-switched
ethernet, with a weird mac that governs what sort of packets get
access to (a txop) the medium first, across all stations co-operating
within EDCA.
Half or full duplex is something that mostly applied to p2p serial
connections (or p2p wifi), not P2MP. Additionally characteristics like
exponential backoff make no sense were wifi any form of duplex, full
or half.
Certainly much stuff within a txop (block acks for example) can be
considered half duplex in a microcosmic context.
I wish we actually had words that accurately described wifi's actual behavior.
</pedantry>
> (for processing ICMP and UDP_RR) is greater than 11e contention window
> timings you can get your BE flow responses with extra delay (since
> other queues might have responses ready quicker).
yes. always having a request pending for each of the 802.11e queues is
actually not the best idea, it is better to take advantage of better
aggregation afforded by 802.11n/ac, to only have one or two of the
queues in use against any given station and promote or demote traffic
into a more-right queue.
simple example of the damage having all 4 queues always contending is
exemplified by running the rrul and rrul_be tests against nearly any
given AP.
>
> I've modified traffic-gen and re-run tests with bursts on all tested
> tids/ACs (tid0, tid1, tid5). I'm attaching the results.
>
> With bursts on all tids you can clearly see BK has much higher latency than BE.
The long term goal here, of course, is for BK (or the other queues) to
not have seconds of queuing latency but something more bounded to 2x
media access time...
> (Note, I've changed my AP to QCA988X with oldie firmware 10.1.467 for
> this test; it doesn't have the weird hiccups I was seeing on QCA99X0
> and newer QCA988X firmware reports bogus expected throughput which is
> most likely a result of my sloppy proof-of-concept change in ath10k).
So I should avoid ben greer's firmware for now?
>
>
> Michał
>
> On 16 March 2016 at 20:48, Jasmine Strong <jas-K/XR6QsbQD0@public.gmane.org> wrote:
>> BK usually has 0 txop, so it doesn't do aggregation.
>>
>> On Wed, Mar 16, 2016 at 11:55 AM, Bob Copeland <me-aXfl/3sk2vNUbtYUoyoikg@public.gmane.org> wrote:
>>>
>>> On Wed, Mar 16, 2016 at 11:36:31AM -0700, Dave Taht wrote:
>>> > That is the sanest 802.11e queue behavior I have ever seen! (at both
>>> > 6 and 300mbit! in the ath10k patched mac test)
>>>
>>> Out of curiosity, why does BE have larger latency than BK in that chart?
>>> I'd have expected the opposite.
>>>
>>> --
>>> Bob Copeland %% http://bobcopeland.com/
>>>
>>> _______________________________________________
>>> ath10k mailing list
>>> ath10k-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>>> http://lists.infradead.org/mailman/listinfo/ath10k
>>
>>
--
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
* [PATCH net-next] net/mlx4_core: Fix backward compatibility on VFs
From: Eli Cohen @ 2016-03-17 16:49 UTC (permalink / raw)
To: davem; +Cc: linux-rdma, netdev, aik, Eli Cohen
Commit 85743f1eb345 ("net/mlx4_core: Set UAR page size to 4KB regardless
of system page size") introduced dependency where old VF drivers without
this fix fail to load if the PF driver runs with this commit.
To resolve this add a module parameter which disables that functionality
by default. If both the PF and VFs are running with a driver with that
commit the administrator may set the module param to true.
The module parameter is called enable_4k_uar.
Fixes: 85743f1eb345 ('net/mlx4_core: Set UAR page size to 4KB ...')
Signed-off-by: Eli Cohen <eli@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 24 ++++++++++++++++++------
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 503ec23e84cc..358f7230da58 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -105,6 +105,11 @@ module_param(enable_64b_cqe_eqe, bool, 0444);
MODULE_PARM_DESC(enable_64b_cqe_eqe,
"Enable 64 byte CQEs/EQEs when the FW supports this (default: True)");
+static bool enable_4k_uar;
+module_param(enable_4k_uar, bool, 0444);
+MODULE_PARM_DESC(enable_4k_uar,
+ "Enable using 4K UAR. Should not be enabled if have VFs which do not support 4K UARs (default: false)");
+
#define PF_CONTEXT_BEHAVIOUR_MASK (MLX4_FUNC_CAP_64B_EQE_CQE | \
MLX4_FUNC_CAP_EQE_CQE_STRIDE | \
MLX4_FUNC_CAP_DMFS_A0_STATIC)
@@ -423,7 +428,11 @@ static int mlx4_dev_cap(struct mlx4_dev *dev, struct mlx4_dev_cap *dev_cap)
/* Virtual PCI function needs to determine UAR page size from
* firmware. Only master PCI function can set the uar page size
*/
- dev->uar_page_shift = DEFAULT_UAR_PAGE_SHIFT;
+ if (enable_4k_uar)
+ dev->uar_page_shift = DEFAULT_UAR_PAGE_SHIFT;
+ else
+ dev->uar_page_shift = PAGE_SHIFT;
+
mlx4_set_num_reserved_uars(dev, dev_cap);
}
@@ -2233,11 +2242,14 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
dev->caps.max_fmr_maps = (1 << (32 - ilog2(dev->caps.num_mpts))) - 1;
- /* Always set UAR page size 4KB, set log_uar_sz accordingly */
- init_hca.log_uar_sz = ilog2(dev->caps.num_uars) +
- PAGE_SHIFT -
- DEFAULT_UAR_PAGE_SHIFT;
- init_hca.uar_page_sz = DEFAULT_UAR_PAGE_SHIFT - 12;
+ if (enable_4k_uar) {
+ init_hca.log_uar_sz = ilog2(dev->caps.num_uars) +
+ PAGE_SHIFT - DEFAULT_UAR_PAGE_SHIFT;
+ init_hca.uar_page_sz = DEFAULT_UAR_PAGE_SHIFT - 12;
+ } else {
+ init_hca.log_uar_sz = ilog2(dev->caps.num_uars);
+ init_hca.uar_page_sz = PAGE_SHIFT - 12;
+ }
init_hca.mw_enabled = 0;
if (dev->caps.flags & MLX4_DEV_CAP_FLAG_MEM_WINDOW ||
--
1.8.3.1
^ permalink raw reply related
* Re: Extreme slowness in IPIP tunnel when routing through kernel 3.18 and later
From: Tom Herbert @ 2016-03-17 16:47 UTC (permalink / raw)
To: Patrick Boutilier; +Cc: Linux Kernel Network Developers
In-Reply-To: <56EAB8F3.7060802@ednet.ns.ca>
On Thu, Mar 17, 2016 at 7:02 AM, Patrick Boutilier <boutilpj@ednet.ns.ca> wrote:
> I have an IPIP tunnel setup between two hosts in different buildings. The
> Linux router they route through causes extreme slowness in the tunnel when
> running kernels from 3.18 on . tcpdump shows many cksum errors which don't
> show up in the 3.17 and earlier kernels. Speed goes back to normal when
> rx-checksumming and tx-checksumming are turned off using ethtool on the
> Linux router . Would this be an effect of bulk network packet transmission
> that was introduced in 3.18 or some other issue?
>
If this is happening on a router then the only case where checksums
are pertinent should be if GSO/GRO is enabled. Please try disabling
these. Also, are these showing up as checksum errors on the receiver
(netstat -s).
>
> eth2
> driver: igb
> version: 5.2.15-k
> firmware-version: 1.5.1
> bus-info: 0000:06:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
>
> eth6
> driver: ixgbe
> version: 3.19.1-k
> firmware-version: 0x80000389
> bus-info: 0000:41:00.0
> supports-statistics: yes
> supports-test: yes
> supports-eeprom-access: yes
> supports-register-dump: yes
> supports-priv-flags: no
>
>
>
>
>
> Example of cksum from tcpdump:
>
> Flags [.], cksum 0x2237 (incorrect -> 0xbb02), seq 424119200:424120648, ack
> 1, win 115, options [nop,nop,TS val 303173784 ecr 3971495454], length 1448
>
>
>
>
>
> Results of nuttcp test with rx-checksumming and tx-checksumming on:
>
>
> Testing upload inside tunnel
>
>
>
> 0.0625 MB / 5.00 sec = 0.1048 Mbps 79 retrans
> 0.0625 MB / 5.00 sec = 0.1048 Mbps 59 retrans
> 0.0625 MB / 5.00 sec = 0.1049 Mbps 27 retrans
>
> 0.2096 MB / 16.11 sec = 0.1092 Mbps 0 %TX 0 %RX 186 retrans 0.47
> msRTT
>
>
>
> Testing download inside tunnel
>
>
>
> 0.5000 MB / 5.00 sec = 0.8389 Mbps 112 retrans
> 2.6250 MB / 5.00 sec = 4.4040 Mbps 412 retrans
> 0.8750 MB / 5.00 sec = 1.4680 Mbps 156 retrans
>
> 4.0243 MB / 15.48 sec = 2.1809 Mbps 0 %TX 0 %RX 705 retrans 0.47
> msRTT
>
>
> Testing upload outside tunnel
>
>
>
> 423.0000 MB / 5.00 sec = 709.4949 Mbps 275 retrans
> 442.0625 MB / 5.00 sec = 741.7008 Mbps 53 retrans
> 418.5625 MB / 5.00 sec = 702.1329 Mbps 133 retrans
>
> 1287.0080 MB / 15.08 sec = 715.9252 Mbps 1 %TX 30 %RX 461 retrans 0.43
> msRTT
>
>
>
> Testing download outside tunnel
>
>
>
> 552.4375 MB / 5.00 sec = 926.8347 Mbps 26 retrans
> 555.1875 MB / 5.00 sec = 931.4499 Mbps 17 retrans
> 553.0000 MB / 5.00 sec = 927.7802 Mbps 16 retrans
>
> 1664.2149 MB / 15.03 sec = 928.6737 Mbps 9 %TX 5 %RX 60 retrans 0.46
> msRTT
>
>
>
>
>
>
> Results of nuttcp test with rx-checksumming and tx-checksumming off:
>
>
>
> Testing upload inside tunnel
>
>
>
> 440.0000 MB / 5.00 sec = 738.0112 Mbps 117 retrans
> 433.0000 MB / 5.00 sec = 726.4892 Mbps 135 retrans
> 447.9375 MB / 5.00 sec = 751.5714 Mbps 112 retrans
>
> 1321.0069 MB / 15.04 sec = 736.7213 Mbps 3 %TX 21 %RX 364 retrans 0.51
> msRTT
>
>
>
> Testing download inside tunnel
>
>
>
> 494.0625 MB / 5.00 sec = 828.8973 Mbps 335 retrans
> 471.0000 MB / 5.00 sec = 790.2050 Mbps 219 retrans
> 469.8750 MB / 5.00 sec = 788.3174 Mbps 220 retrans
>
> 1435.1875 MB / 15.00 sec = 802.4203 Mbps 89 %TX 12 %RX 774 retrans 0.46
> msRTT
>
>
> Testing upload outside tunnel
>
>
>
> 431.2500 MB / 5.00 sec = 723.2808 Mbps 33 retrans
> 446.3750 MB / 5.00 sec = 748.9268 Mbps 10 retrans
> 475.4375 MB / 5.00 sec = 797.7044 Mbps 0 retrans
>
> 1355.0834 MB / 15.06 sec = 754.6438 Mbps 1 %TX 33 %RX 43 retrans 0.53
> msRTT
>
>
>
> Testing download outside tunnel
>
>
>
> 424.8125 MB / 5.00 sec = 712.7061 Mbps 102 retrans
> 456.5625 MB / 5.00 sec = 765.9872 Mbps 80 retrans
> 454.0000 MB / 5.00 sec = 761.6935 Mbps 116 retrans
>
> 1335.7823 MB / 15.01 sec = 746.6959 Mbps 4 %TX 5 %RX 298 retrans 0.55
> msRTT
^ permalink raw reply
* [RFD] workqueue: WQ_MEM_RECLAIM usage in network drivers
From: Tejun Heo @ 2016-03-17 16:45 UTC (permalink / raw)
To: David S. Miller, Trond Myklebust, J. Bruce Fields, Jeff Layton,
Anna Schumaker
Cc: netdev, linux-kernel, linux-nfs, Amitoj Kaur Chawla, kernel-team,
Johannes Weiner, Johannes Berg, Eva Rachel Retuya,
Bhaktipriya Shridhar, linux-wireless
Hello,
Years ago, workqueue got reimplemented to use common worker pools
across different workqueues and a new set of more expressive workqueue
creation APIs, alloc_*workqueue() were introduced. The old
create_*workqueue() became simple wrappers around alloc_*workqueue()
with the most conservative parameters. The plan has always been to
examine each usage and convert to the new interface with parameters
actually required for the use case.
One important flag to decide upon is WQ_MEM_RECLAIM, which declares
that the workqueue may be depended upon during memory reclaim and thus
must be able to make forward-progress even when further memory can't
be allocated without reclaiming some. Of the network drivers which
already use alloc_*workqueue() interface, some specify this flag and
I'm wondering what the guidelines should be here.
* Are network devices expected to be able to serve as a part of
storage stack which is depended upon for memory reclamation?
* If so, are all the pieces in place for that to work for all (or at
least most) network devices? If it's only for a subset of NICs, how
can one tell whether a given driver needs forward progress guarantee
or not?
* I assume that wireless drivers aren't and can't be used in this
fashion. Is that a correction assumption?
Thanks.
--
tejun
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-03-14
From: Jes Sorensen @ 2016-03-17 16:30 UTC (permalink / raw)
To: Kalle Valo
Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <87twk8kxdx.fsf-HodKDYzPHsUD5k0oWYwrnHL1okKdlPRT@public.gmane.org>
Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> writes:
> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
>
>> From: Kalle Valo <kvalo-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Date: Mon, 14 Mar 2016 10:31:48 +0200
>>
>>> I know I'm late now that merge window was opened yesterday but here's
>>> one more set of patches I would like to get to 4.6 still. There isn't
>>> anything controversial so I hope this should be still safe to pull. The
>>> patches have been in linux-next since Friday and I haven't seen any
>>> reports about issues. But if you think it's too late just let me know
>>> and I'll resubmit these for 4.7.
>>>
>>> The most notable part here of course is rtl8xxxu with over 100 patches.
>>> As the driver is new and under heavy development I think they are ok to
>>> take still. Otherwise there are mostly fixes with an exception of adding
>>> a new debugfs file to wl18xx.
>>>
>>> Please let me know if you have any problems.
>>
>> Pulled, thanks.
>
> Great, thanks a lot.
>
>> I really like Jes's work and I wish you had integrated it several
>> months ago, instead of sloshing him needlessly through a non-stop
>> cycle of very nit-picky issues, just FYI.
>
> I also like his work and I'm sorry for being too nit-picky. I have tried
> to be extra careful with the patches I send to you, especially with new
> drivers, and I guess I have been too pedantic. I'll try to lower the bar
> to a more reasonable level.
>
> But I actually started to wonder what you actually mean and checked the
> dates of initial rtl8xxxu submission from patchwork:
>
> 2015-08-29 v1
> 2015-08-30 v2
> 2015-10-15 v3
> 2015-10-21 applied 26f1fad29ad9 to w-d-next for v4.4
>
> Two months is quite long for a good driver like this but IIRC the
> initial commit was pending wireless-drivers directory reorganisation,
> and that just took too long on my side.
With all the trying to break down the patches and reorganizing them into
smaller blocks (disentangling 8723bu and 8192eu) to be submitted
independently, I have now ended up with a tree that simply is
unmergeable. I have spent about three days trying to roll back merges
and pop off my devel changes to allow it to merge, and I give up.
As a result I have created a new branch off wireless-drivers-next and
cherry picked all my devel patches on top of this. The new branch is
rtl8xxxu-devel. The old branch rtl8xxxu-nextgen I am going to let go
stale, but I will keep it in place as it contains all the old devel
history for the original driver prior to the initial upstream submission
of rtl8xxxu.
For anyone following rtl8xxxu development and/or submitting patches,
please submit against the new branch from now on.
Thanks,
Jes
--
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 0/2] ovs: refresh a flow via netlink
From: Samuel Gauthier @ 2016-03-17 16:24 UTC (permalink / raw)
To: Jesse Gross
Cc: Pravin Shelar, David S. Miller, Linux Kernel Network Developers,
ovs dev
In-Reply-To: <CAEh+42jMSpPr8yUmmO355D=auKa-cGTwOZu0CSf-0=rczu4zwg@mail.gmail.com>
2016-03-17 0:23 GMT+01:00 Jesse Gross <jesse@kernel.org>:
> On Wed, Mar 16, 2016 at 8:07 AM, Samuel Gauthier
> <samuel.gauthier@6wind.com> wrote:
>> This patchset adds a netlink api to refresh an existing flow in
>> openvswitch.
>>
>> When a packet is sent in the openvswitch kernel datapath and no
>> flow is found, the packet is sent to the ovs-vswitchd daemon,
>> which will process the packet, and ask the kernel to create a new
>> flow. The next packets for this flow will be processed by the
>> kernel datapath. If a flow is not used for a (configurable)
>> period of time, ovs-vswitchd removes the flow from the kernel.
>>
>> As a result, it can be tricky to test the kernel datapath against
>> packets, as the first packets of each flow will have to go
>> through the ovs-vswitchd daemon. For instance, to do a zeroloss
>> performance test, you establish the flows, and then you have to
>> perform your zeroloss test before the flow is removed by
>> ovs-vswitchd.
>>
>> It is possible to configure a flow timeout in ovs-vswitchd (using
>> other_config:max-idle option), but it changes the behavior for
>> all the flows, which is not always what you want.
>
> It seems to me that it would be preferable to implement the necessary
> behavior in userspace to handle this directly. The logic that is
> removing the flow is in userspace, so rather than asking the kernel to
> lie about the current state of things, we can just modify the logic to
> handle this case.
It seemed like a problem limited to the kernel datapath (i.e.: not to
the other ovs datapaths), so it made sense to me to fix it by a
netlink API.
The idea was to do something similar to the OVS_FLOW_ATTR_CLEAR
attribute (which sets the flow statistics and used field to 0).
This said, I could have a look to a pure userland solution, but I am
not sure how to do it. Could you elaborate what you have in mind?
Thanks.
^ permalink raw reply
* Re: [PATCH] qmi_wwan: Added support for Gemalto's Cinterion PHxx WWAN interface
From: Bjørn Mork @ 2016-03-17 16:23 UTC (permalink / raw)
To: Schemmel Hans-Christoph; +Cc: netdev@vger.kernel.org, linux-usb@vger.kernel.org
In-Reply-To: <1978E4F2CF12DD4A899FA7487323EB11010836882A@A1GTOEMBXV004.gto.a3c.atos.net>
Schemmel Hans-Christoph <Hans-Christoph.Schemmel@gemalto.com> writes:
> Added support for Gemalto's Cinterion PHxx WWAN interfaces
> by adding QMI_FIXED_INTF with Cinterion's VID and PID.
>
> PHxx can have:
> 2 RmNet Interfaces (PID 0x0082) or
> 1 RmNet + 1 USB Audio interface (PID 0x0083).
>
> Signed-off-by: Hans-Christoph Schemmel <hans-christoph.schemmel@gemalto.com>
> ---
> patch is against linux-4.5
> --- linux/drivers/net/usb/qmi_wwan.c.orig 2016-03-14 12:18:07.153497489 +0100
> +++ linux/drivers/net/usb/qmi_wwan.c 2016-03-14 12:21:37.722541644 +0100
> @@ -881,6 +881,9 @@ static const struct usb_device_id produc
> {QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */
> {QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */
> {QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */
> + {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)}, /* Cinterion PHxx,PXxx (2 RmNet) */
> + {QMI_FIXED_INTF(0x1e2d, 0x0082, 5)}, /* Cinterion PHxx,PXxx (2 RmNet) */
> + {QMI_FIXED_INTF(0x1e2d, 0x0083, 4)}, /* Cinterion PHxx,PXxx (1 RmNet + USB Audio)*/
> {QMI_FIXED_INTF(0x413c, 0x81a2, 8)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */
> {QMI_FIXED_INTF(0x413c, 0x81a3, 8)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */
> {QMI_FIXED_INTF(0x413c, 0x81a4, 8)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
Perfect. Thanks.
Acked-by: Bjørn Mork <bjorn@mork.no>
^ permalink raw reply
* [PATCH v2] iwlwifi: dvm: use alloc_ordered_workqueue()
From: Eva Rachel Retuya @ 2016-03-17 16:19 UTC (permalink / raw)
To: outreachy-kernel
Cc: johannes.berg, emmanuel.grumbach, linuxwifi, kvalo,
linux-wireless, netdev, linux-kernel, tj, Eva Rachel Retuya
Use alloc_ordered_workqueue() to allocate the workqueue instead of
create_singlethread_workqueue() since the latter is deprecated and is scheduled
for removal.
There are work items doing related operations that shouldn't be swapped when
queued in a certain order hence preserve the strict execution ordering of a
single threaded (ST) workqueue by switching to alloc_ordered_workqueue().
WQ_MEM_RECLAIM flag is not needed since the worker is not supposed to free
memory.
Signed-off-by: Eva Rachel Retuya <eraretuya@gmail.com>
---
Changes in v2:
* switch from alloc_workqueue() to alloc_ordered_workqueue()
* remove unneeded flags: WQ_MEM_RECLAIM and WQ_HIGHPRI
* update commit message to reflect change
drivers/net/wireless/intel/iwlwifi/dvm/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/main.c b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
index f62c2d7..14396d8 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/main.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/main.c
@@ -1071,7 +1071,7 @@ static void iwl_bg_restart(struct work_struct *data)
static void iwl_setup_deferred_work(struct iwl_priv *priv)
{
- priv->workqueue = create_singlethread_workqueue(DRV_NAME);
+ priv->workqueue = alloc_ordered_workqueue(DRV_NAME, 0);
INIT_WORK(&priv->restart, iwl_bg_restart);
INIT_WORK(&priv->beacon_update, iwl_bg_beacon_update);
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/2] Revert "vsock: Fix blocking ops call in prepare_to_wait"
From: Claudio Imbrenda @ 2016-03-17 16:12 UTC (permalink / raw)
To: davem; +Cc: labbott, netdev, linux-kernel
In-Reply-To: <1458231156-18845-1-git-send-email-imbrenda@linux.vnet.ibm.com>
This reverts commit 5988818008257ca42010d6b43a3e0e48afec9898 ("vsock: Fix
blocking ops call in prepare_to_wait")
Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
---
net/vmw_vsock/af_vsock.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index bbe65dc..7fd1220 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1557,6 +1557,8 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
if (err < 0)
goto out;
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+
while (total_written < len) {
ssize_t written;
@@ -1576,9 +1578,7 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
goto out_wait;
release_sock(sk);
- prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
timeout = schedule_timeout(timeout);
- finish_wait(sk_sleep(sk), &wait);
lock_sock(sk);
if (signal_pending(current)) {
err = sock_intr_errno(timeout);
@@ -1588,6 +1588,8 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
goto out_wait;
}
+ prepare_to_wait(sk_sleep(sk), &wait,
+ TASK_INTERRUPTIBLE);
}
/* These checks occur both as part of and after the loop
@@ -1633,6 +1635,7 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
out_wait:
if (total_written > 0)
err = total_written;
+ finish_wait(sk_sleep(sk), &wait);
out:
release_sock(sk);
return err;
@@ -1713,6 +1716,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
if (err < 0)
goto out;
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
while (1) {
s64 ready = vsock_stream_has_data(vsk);
@@ -1723,7 +1727,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
*/
err = -ENOMEM;
- goto out;
+ goto out_wait;
} else if (ready > 0) {
ssize_t read;
@@ -1746,7 +1750,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
vsk, target, read,
!(flags & MSG_PEEK), &recv_data);
if (err < 0)
- goto out;
+ goto out_wait;
if (read >= target || flags & MSG_PEEK)
break;
@@ -1769,9 +1773,7 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
break;
release_sock(sk);
- prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
timeout = schedule_timeout(timeout);
- finish_wait(sk_sleep(sk), &wait);
lock_sock(sk);
if (signal_pending(current)) {
@@ -1781,6 +1783,9 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
err = -EAGAIN;
break;
}
+
+ prepare_to_wait(sk_sleep(sk), &wait,
+ TASK_INTERRUPTIBLE);
}
}
@@ -1811,6 +1816,8 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
err = copied;
}
+out_wait:
+ finish_wait(sk_sleep(sk), &wait);
out:
release_sock(sk);
return err;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 2/2] AF_VSOCK: Shrink the area influenced by prepare_to_wait
From: Claudio Imbrenda @ 2016-03-17 16:12 UTC (permalink / raw)
To: davem; +Cc: labbott, netdev, linux-kernel
In-Reply-To: <1458231156-18845-1-git-send-email-imbrenda@linux.vnet.ibm.com>
When a thread is prepared for waiting by calling prepare_to_wait, sleeping
is not allowed until either the wait has taken place or finish_wait has
been called. The existing code in af_vsock imposed unnecessary no-sleep
assumptions to a broad list of backend functions.
This patch shrinks the influence of prepare_to_wait to the area where it
is strictly needed, therefore relaxing the no-sleep restriction there.
Signed-off-by: Claudio Imbrenda <imbrenda@linux.vnet.ibm.com>
---
net/vmw_vsock/af_vsock.c | 158 +++++++++++++++++++++++++----------------------
1 file changed, 85 insertions(+), 73 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index 7fd1220..3dce53e 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1209,10 +1209,14 @@ static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
if (signal_pending(current)) {
err = sock_intr_errno(timeout);
- goto out_wait_error;
+ sk->sk_state = SS_UNCONNECTED;
+ sock->state = SS_UNCONNECTED;
+ goto out_wait;
} else if (timeout == 0) {
err = -ETIMEDOUT;
- goto out_wait_error;
+ sk->sk_state = SS_UNCONNECTED;
+ sock->state = SS_UNCONNECTED;
+ goto out_wait;
}
prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
@@ -1220,20 +1224,17 @@ static int vsock_stream_connect(struct socket *sock, struct sockaddr *addr,
if (sk->sk_err) {
err = -sk->sk_err;
- goto out_wait_error;
- } else
+ sk->sk_state = SS_UNCONNECTED;
+ sock->state = SS_UNCONNECTED;
+ } else {
err = 0;
+ }
out_wait:
finish_wait(sk_sleep(sk), &wait);
out:
release_sock(sk);
return err;
-
-out_wait_error:
- sk->sk_state = SS_UNCONNECTED;
- sock->state = SS_UNCONNECTED;
- goto out_wait;
}
static int vsock_accept(struct socket *sock, struct socket *newsock, int flags)
@@ -1270,18 +1271,20 @@ static int vsock_accept(struct socket *sock, struct socket *newsock, int flags)
listener->sk_err == 0) {
release_sock(listener);
timeout = schedule_timeout(timeout);
+ finish_wait(sk_sleep(listener), &wait);
lock_sock(listener);
if (signal_pending(current)) {
err = sock_intr_errno(timeout);
- goto out_wait;
+ goto out;
} else if (timeout == 0) {
err = -EAGAIN;
- goto out_wait;
+ goto out;
}
prepare_to_wait(sk_sleep(listener), &wait, TASK_INTERRUPTIBLE);
}
+ finish_wait(sk_sleep(listener), &wait);
if (listener->sk_err)
err = -listener->sk_err;
@@ -1301,19 +1304,15 @@ static int vsock_accept(struct socket *sock, struct socket *newsock, int flags)
*/
if (err) {
vconnected->rejected = true;
- release_sock(connected);
- sock_put(connected);
- goto out_wait;
+ } else {
+ newsock->state = SS_CONNECTED;
+ sock_graft(connected, newsock);
}
- newsock->state = SS_CONNECTED;
- sock_graft(connected, newsock);
release_sock(connected);
sock_put(connected);
}
-out_wait:
- finish_wait(sk_sleep(listener), &wait);
out:
release_sock(listener);
return err;
@@ -1557,11 +1556,11 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
if (err < 0)
goto out;
- prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
while (total_written < len) {
ssize_t written;
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
while (vsock_stream_has_space(vsk) == 0 &&
sk->sk_err == 0 &&
!(sk->sk_shutdown & SEND_SHUTDOWN) &&
@@ -1570,27 +1569,33 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
/* Don't wait for non-blocking sockets. */
if (timeout == 0) {
err = -EAGAIN;
- goto out_wait;
+ finish_wait(sk_sleep(sk), &wait);
+ goto out_err;
}
err = transport->notify_send_pre_block(vsk, &send_data);
- if (err < 0)
- goto out_wait;
+ if (err < 0) {
+ finish_wait(sk_sleep(sk), &wait);
+ goto out_err;
+ }
release_sock(sk);
timeout = schedule_timeout(timeout);
lock_sock(sk);
if (signal_pending(current)) {
err = sock_intr_errno(timeout);
- goto out_wait;
+ finish_wait(sk_sleep(sk), &wait);
+ goto out_err;
} else if (timeout == 0) {
err = -EAGAIN;
- goto out_wait;
+ finish_wait(sk_sleep(sk), &wait);
+ goto out_err;
}
prepare_to_wait(sk_sleep(sk), &wait,
TASK_INTERRUPTIBLE);
}
+ finish_wait(sk_sleep(sk), &wait);
/* These checks occur both as part of and after the loop
* conditional since we need to check before and after
@@ -1598,16 +1603,16 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
*/
if (sk->sk_err) {
err = -sk->sk_err;
- goto out_wait;
+ goto out_err;
} else if ((sk->sk_shutdown & SEND_SHUTDOWN) ||
(vsk->peer_shutdown & RCV_SHUTDOWN)) {
err = -EPIPE;
- goto out_wait;
+ goto out_err;
}
err = transport->notify_send_pre_enqueue(vsk, &send_data);
if (err < 0)
- goto out_wait;
+ goto out_err;
/* Note that enqueue will only write as many bytes as are free
* in the produce queue, so we don't need to ensure len is
@@ -1620,7 +1625,7 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
len - total_written);
if (written < 0) {
err = -ENOMEM;
- goto out_wait;
+ goto out_err;
}
total_written += written;
@@ -1628,14 +1633,13 @@ static int vsock_stream_sendmsg(struct socket *sock, struct msghdr *msg,
err = transport->notify_send_post_enqueue(
vsk, written, &send_data);
if (err < 0)
- goto out_wait;
+ goto out_err;
}
-out_wait:
+out_err:
if (total_written > 0)
err = total_written;
- finish_wait(sk_sleep(sk), &wait);
out:
release_sock(sk);
return err;
@@ -1716,21 +1720,61 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
if (err < 0)
goto out;
- prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
while (1) {
- s64 ready = vsock_stream_has_data(vsk);
+ s64 ready;
- if (ready < 0) {
- /* Invalid queue pair content. XXX This should be
- * changed to a connection reset in a later change.
- */
+ prepare_to_wait(sk_sleep(sk), &wait, TASK_INTERRUPTIBLE);
+ ready = vsock_stream_has_data(vsk);
- err = -ENOMEM;
- goto out_wait;
- } else if (ready > 0) {
+ if (ready == 0) {
+ if (sk->sk_err != 0 ||
+ (sk->sk_shutdown & RCV_SHUTDOWN) ||
+ (vsk->peer_shutdown & SEND_SHUTDOWN)) {
+ finish_wait(sk_sleep(sk), &wait);
+ break;
+ }
+ /* Don't wait for non-blocking sockets. */
+ if (timeout == 0) {
+ err = -EAGAIN;
+ finish_wait(sk_sleep(sk), &wait);
+ break;
+ }
+
+ err = transport->notify_recv_pre_block(
+ vsk, target, &recv_data);
+ if (err < 0) {
+ finish_wait(sk_sleep(sk), &wait);
+ break;
+ }
+ release_sock(sk);
+ timeout = schedule_timeout(timeout);
+ lock_sock(sk);
+
+ if (signal_pending(current)) {
+ err = sock_intr_errno(timeout);
+ finish_wait(sk_sleep(sk), &wait);
+ break;
+ } else if (timeout == 0) {
+ err = -EAGAIN;
+ finish_wait(sk_sleep(sk), &wait);
+ break;
+ }
+ } else {
ssize_t read;
+ finish_wait(sk_sleep(sk), &wait);
+
+ if (ready < 0) {
+ /* Invalid queue pair content. XXX This should
+ * be changed to a connection reset in a later
+ * change.
+ */
+
+ err = -ENOMEM;
+ goto out;
+ }
+
err = transport->notify_recv_pre_dequeue(
vsk, target, &recv_data);
if (err < 0)
@@ -1750,42 +1794,12 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
vsk, target, read,
!(flags & MSG_PEEK), &recv_data);
if (err < 0)
- goto out_wait;
+ goto out;
if (read >= target || flags & MSG_PEEK)
break;
target -= read;
- } else {
- if (sk->sk_err != 0 || (sk->sk_shutdown & RCV_SHUTDOWN)
- || (vsk->peer_shutdown & SEND_SHUTDOWN)) {
- break;
- }
- /* Don't wait for non-blocking sockets. */
- if (timeout == 0) {
- err = -EAGAIN;
- break;
- }
-
- err = transport->notify_recv_pre_block(
- vsk, target, &recv_data);
- if (err < 0)
- break;
-
- release_sock(sk);
- timeout = schedule_timeout(timeout);
- lock_sock(sk);
-
- if (signal_pending(current)) {
- err = sock_intr_errno(timeout);
- break;
- } else if (timeout == 0) {
- err = -EAGAIN;
- break;
- }
-
- prepare_to_wait(sk_sleep(sk), &wait,
- TASK_INTERRUPTIBLE);
}
}
@@ -1816,8 +1830,6 @@ vsock_stream_recvmsg(struct socket *sock, struct msghdr *msg, size_t len,
err = copied;
}
-out_wait:
- finish_wait(sk_sleep(sk), &wait);
out:
release_sock(sk);
return err;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 0/2] AF_VSOCK: Shrink the area influenced by prepare_to_wait
From: Claudio Imbrenda @ 2016-03-17 16:12 UTC (permalink / raw)
To: davem; +Cc: labbott, netdev, linux-kernel
I'm resending as requested.
This patchset applies on net-next.
And sorry for the mis-formatting of the previous message.
Claudio Imbrenda (2):
Revert "vsock: Fix blocking ops call in prepare_to_wait"
AF_VSOCK: Shrink the area influenced by prepare_to_wait
net/vmw_vsock/af_vsock.c | 155 ++++++++++++++++++++++++++---------------------
1 file changed, 87 insertions(+), 68 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [PATCH] rtlwifi: fix gcc-6 indentation warning
From: Larry Finger @ 2016-03-17 16:09 UTC (permalink / raw)
To: Arnd Bergmann, Chaoming Li, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <1458209066-3979295-1-git-send-email-arnd@arndb.de>
On 03/17/2016 05:03 AM, Arnd Bergmann wrote:
> The rtl8821ae_dm_txpower_tracking_callback_thermalmeter function
> contains a call to RT_TRACE() that is indented in a misleading
> way, as pointed out by a gcc-6 warning:
>
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c: In function 'rtl8821ae_dm_txpower_tracking_callback_thermalmeter':
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2491:4: error: statement is indented as if it were guarded by...
> RT_TRACE(rtlpriv, COMP_POWER_TRACKING, DBG_LOUD,
> ^~~~~~~~
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c:2488:3: note: ...this 'for' clause, but it is not
> for (p = RF90_PATH_A; p < MAX_PATH_NUM_8821A; p++)
> ^~~
>
> It is clear from the context that the call was not meant to be
> part of the loop and only the indentation is wrong, so this
> removes the extra tabs.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
> index 95dcbff4673b..6a8245c4ea48 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/dm.c
> @@ -2488,9 +2488,9 @@ void rtl8821ae_dm_txpower_tracking_callback_thermalmeter(
> for (p = RF90_PATH_A; p < MAX_PATH_NUM_8821A; p++)
> rtldm->swing_idx_ofdm_base[p] = rtldm->swing_idx_ofdm[p];
>
> - RT_TRACE(rtlpriv, COMP_POWER_TRACKING, DBG_LOUD,
> - "pDM_Odm->RFCalibrateInfo.ThermalValue = %d ThermalValue= %d\n",
> - rtldm->thermalvalue, thermal_value);
> + RT_TRACE(rtlpriv, COMP_POWER_TRACKING, DBG_LOUD,
> + "pDM_Odm->RFCalibrateInfo.ThermalValue = %d ThermalValue= %d\n",
> + rtldm->thermalvalue, thermal_value);
> /*Record last Power Tracking Thermal Value*/
> rtldm->thermalvalue = thermal_value;
> }
>
This change looks good to me.
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Thanks,
Larry
^ permalink raw reply
* Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
From: Yegor Yefremov @ 2016-03-17 15:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: shaohui ???, netdev, David Miller, Shaohui Xie, Florian Fainelli,
N, Mugunthan V, drivshin
In-Reply-To: <20160317152836.GE26019@lunn.ch>
On Thu, Mar 17, 2016 at 4:28 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> > You should however consider writing a DSA driver for the switch.
>>
>> Do you mean SWITCHDEV or is this more or less the same? From time to
>> time I'm looking at DSA/switchdev patches in the mailing list, but
>> there seems to be not so many example in kernel. What are the latest
>> slides, papers aside from Documentation/networking/switchdev.txt?
>
> I don't have access to the datasheet for this device. So i've no idea
> how easy/hard it would be.
>
> Documentation/networking/switchdev.txt and
> Documentation/networking/dsa/dsa.txt would be a good place to start.
>
> The mv88e6060.c is the simplest driver and gives you the minimum you
> need to start with. Looking at the marketing brief, it looks like the
> device can do more. But it is best to start simple, get the minimal
> accepted, and then incrementally add more.
Will do. Thanks.
Yegor
^ permalink raw reply
* Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
From: Andrew Lunn @ 2016-03-17 15:28 UTC (permalink / raw)
To: Yegor Yefremov
Cc: shaohui ???, netdev, David Miller, Shaohui Xie, Florian Fainelli,
N, Mugunthan V, drivshin
In-Reply-To: <CAGm1_kt+d7HooYi5JgHvkVYEKO0JLn=1nBgdUd1bSG08+ZLiRg@mail.gmail.com>
> > You should however consider writing a DSA driver for the switch.
>
> Do you mean SWITCHDEV or is this more or less the same? From time to
> time I'm looking at DSA/switchdev patches in the mailing list, but
> there seems to be not so many example in kernel. What are the latest
> slides, papers aside from Documentation/networking/switchdev.txt?
I don't have access to the datasheet for this device. So i've no idea
how easy/hard it would be.
Documentation/networking/switchdev.txt and
Documentation/networking/dsa/dsa.txt would be a good place to start.
The mv88e6060.c is the simplest driver and gives you the minimum you
need to start with. Looking at the marketing brief, it looks like the
device can do more. But it is best to start simple, get the minimal
accepted, and then incrementally add more.
Andrew
^ permalink raw reply
* Re: [PATCH net] vlan: propagate gso_max_segs
From: Eric Dumazet @ 2016-03-17 15:26 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <1458190789.7353.33.camel@edumazet-glaptop3.roam.corp.google.com>
On Wed, 2016-03-16 at 21:59 -0700, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> vlan drivers lack proper propagation of gso_max_segs from
> lower device.
>
BTW, I suspect bridge code needs an update too.
This might be the time to add IFLA_MAX_GSO_SEGS and IFLA_MAX_GSO_SIZE to
help debugging these issues with "ip link show"
^ permalink raw reply
* Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
From: Yegor Yefremov @ 2016-03-17 15:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: shaohui ???, netdev, David Miller, Shaohui Xie, Florian Fainelli,
N, Mugunthan V, drivshin
In-Reply-To: <20160317151240.GD26019@lunn.ch>
On Thu, Mar 17, 2016 at 4:12 PM, Andrew Lunn <andrew@lunn.ch> wrote:
>> After changing cpsw_emac0 entry to:
>>
>> &cpsw_emac0 {
>> phy-mode = "rmii";
>> dual_emac_res_vlan = <1>;
>> fixed-link {
>> speed = <100>;
>> full-duplex;
>> };
>> };
>>
>> I've got packets running in both directions.
>
> Great.
>
>> Now I have another problem: I cannot disable ICPlus IP175D ports via
>> SIOCSMIIREG as I could do previously. I get not ioctl errors [1], but
>> the ports are always on.
>>
>> [1] https://github.com/visionsystemsgmbh/libonrisc/blob/master/src/onrisc.c#L83
>
> The MDIO bus is now logically not connected to eth0. Instead you have
> the fixed-link mdio device connected to eth0. So SIOCSMIIREG calls on
> eth0 now try to manipulate the fixed link phys.
>
> However, i think you can still access the MDIO bus, just use eth1 in
> your ioctl call.
Good trick :-)
> You should however consider writing a DSA driver for the switch.
Do you mean SWITCHDEV or is this more or less the same? From time to
time I'm looking at DSA/switchdev patches in the mailing list, but
there seems to be not so many example in kernel. What are the latest
slides, papers aside from Documentation/networking/switchdev.txt?
Yegor
^ permalink raw reply
* Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
From: Andrew Lunn @ 2016-03-17 15:12 UTC (permalink / raw)
To: Yegor Yefremov
Cc: shaohui ???, netdev, David Miller, Shaohui Xie, Florian Fainelli,
N, Mugunthan V, drivshin
In-Reply-To: <CAGm1_kvJn0Pq38iqOmOcyNpe62EEUmq_s5G2_HXps4Gx+xB_=Q@mail.gmail.com>
> After changing cpsw_emac0 entry to:
>
> &cpsw_emac0 {
> phy-mode = "rmii";
> dual_emac_res_vlan = <1>;
> fixed-link {
> speed = <100>;
> full-duplex;
> };
> };
>
> I've got packets running in both directions.
Great.
> Now I have another problem: I cannot disable ICPlus IP175D ports via
> SIOCSMIIREG as I could do previously. I get not ioctl errors [1], but
> the ports are always on.
>
> [1] https://github.com/visionsystemsgmbh/libonrisc/blob/master/src/onrisc.c#L83
The MDIO bus is now logically not connected to eth0. Instead you have
the fixed-link mdio device connected to eth0. So SIOCSMIIREG calls on
eth0 now try to manipulate the fixed link phys.
However, i think you can still access the MDIO bus, just use eth1 in
your ioctl call.
You should however consider writing a DSA driver for the switch.
Andrew
^ 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