* [PATCH] net: phy: at803x: only the AT8030 needs a hardware reset on link change
From: Timur Tabi @ 2016-04-26 17:44 UTC (permalink / raw)
To: netdev, Florian Fainelli, davem, marek.belisko, ujhelyi.m, zonque
Commit 13a56b44 ("at803x: Add support for hardware reset") added a
work-around for a hardware bug on the AT8030. However, the work-around
was being called for all 803x PHYs, even those that don't need it.
Function at803x_link_change_notify() checks to make sure that it only
resets the PHY on the 8030, but it makes more sense to not call that
function at all if it isn't needed.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/phy/at803x.c | 40 ++++++++++++++++++----------------------
1 file changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/net/phy/at803x.c b/drivers/net/phy/at803x.c
index b3ffaee..f279a89 100644
--- a/drivers/net/phy/at803x.c
+++ b/drivers/net/phy/at803x.c
@@ -359,27 +359,25 @@ static void at803x_link_change_notify(struct phy_device *phydev)
* in the FIFO. In such cases, the FIFO enters an error mode it
* cannot recover from by software.
*/
- if (phydev->drv->phy_id == ATH8030_PHY_ID) {
- if (phydev->state == PHY_NOLINK) {
- if (priv->gpiod_reset && !priv->phy_reset) {
- struct at803x_context context;
-
- at803x_context_save(phydev, &context);
-
- gpiod_set_value(priv->gpiod_reset, 1);
- msleep(1);
- gpiod_set_value(priv->gpiod_reset, 0);
- msleep(1);
-
- at803x_context_restore(phydev, &context);
-
- phydev_dbg(phydev, "%s(): phy was reset\n",
- __func__);
- priv->phy_reset = true;
- }
- } else {
- priv->phy_reset = false;
+ if (phydev->state == PHY_NOLINK) {
+ if (priv->gpiod_reset && !priv->phy_reset) {
+ struct at803x_context context;
+
+ at803x_context_save(phydev, &context);
+
+ gpiod_set_value(priv->gpiod_reset, 1);
+ msleep(1);
+ gpiod_set_value(priv->gpiod_reset, 0);
+ msleep(1);
+
+ at803x_context_restore(phydev, &context);
+
+ phydev_dbg(phydev, "%s(): phy was reset\n",
+ __func__);
+ priv->phy_reset = true;
}
+ } else {
+ priv->phy_reset = false;
}
}
@@ -391,7 +389,6 @@ static struct phy_driver at803x_driver[] = {
.phy_id_mask = 0xffffffef,
.probe = at803x_probe,
.config_init = at803x_config_init,
- .link_change_notify = at803x_link_change_notify,
.set_wol = at803x_set_wol,
.get_wol = at803x_get_wol,
.suspend = at803x_suspend,
@@ -427,7 +424,6 @@ static struct phy_driver at803x_driver[] = {
.phy_id_mask = 0xffffffef,
.probe = at803x_probe,
.config_init = at803x_config_init,
- .link_change_notify = at803x_link_change_notify,
.set_wol = at803x_set_wol,
.get_wol = at803x_get_wol,
.suspend = at803x_suspend,
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply related
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Andrew Lunn @ 2016-04-26 17:45 UTC (permalink / raw)
To: Florian Fainelli
Cc: Pramod Kumar, Mark Rutland, devicetree, Arnd Bergmann, Pawel Moll,
Suzuki K Poulose, Catalin Marinas, Punit Agrawal, Will Deacon,
linux-kernel, Masahiro Yamada, Chen-Yu Tsai, Rob Herring,
BCM Kernel Feedback, netdev, linux-arm-kernel, Anup Patel
In-Reply-To: <571FA3F6.7000903@gmail.com>
> I am not clear on how common a shared MDIO bus is on other SoCs, but the
> other Broadcom SoCs I am familiar with have dedicated MDIO buses
> instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
> a ton easier.
I don't actually see this shared bus being an issue, once the mux it
implemented. With the mux, you see N MDIO busses, each acting like a
normal MDIO bus. I've used the GPIO variety and had no issues:
http://marc.info/?l=linux-arm-kernel&m=145910090401796&w=2
Andrew
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Arnd Bergmann @ 2016-04-26 17:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, Andrew Lunn, Punit Agrawal, Anup Patel, Pawel Moll,
devicetree, Catalin Marinas, Suzuki K Poulose, Will Deacon,
Chen-Yu Tsai, linux-kernel, Masahiro Yamada, Pramod Kumar,
Rob Herring, BCM Kernel Feedback, netdev, Kishon Vijay Abraham I,
linux-arm-kernel
In-Reply-To: <571FA3F6.7000903@gmail.com>
On Tuesday 26 April 2016 10:23:02 Florian Fainelli wrote:
> On 26/04/16 05:13, Andrew Lunn wrote:
> >> 4. Apart from these, by using MDIO mux framework we are making our
> >> non-ethernet PHYs dependent on Linux network drivers which is not
> >> acceptable. What if some product line does not need network subsystem at
> >> all?
> >
> > This is your only valid point. However, does Broadcom have a product
> > line which does not include networking? Is not Broadcom a network SoC
> > vendor?
>
> But even with that, there is no reason why we could not decouple the
> PHYLIB MDIO framework from PHYLIB and make it available as a more
> standalone subsystem which can be utilized when you have a mix of MDIO
> devices like here.
[adding Kishon Vijay Abraham]
We should also consider how this fits in with drivers/phy/, which is
the generic framework for all PHY devices that are not for ethernet.
The most straightforward way that you mention would be to allow
generic PHY devices to be probed on an MIO bus or mux. This should
just work using mdio_module_driver(), as Andrew already explained.
A more complex problem would be having a PHY driver for a device
that can be either an ethernet phy or some other phy. With today's
frameworks that would require two separate drivers, one in drivers/phy
and one in drivers/net/phy/. If that turns out to be a common problem,
we might want to come up with a way to nest one on top of the other,
or merge two two device structures (struct phy_device and struct phy).
> I am not clear on how common a shared MDIO bus is on other SoCs, but the
> other Broadcom SoCs I am familiar with have dedicated MDIO buses
> instances per type of PHY (PCIe, BUSB, Ethernet), thus making the split
> a ton easier.
I think most commonly, the other PHYs are not on MDIO at all, but are
integrated inside of the SoC as an MMIO based device.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 0/3] qed: Bandwidth configuration support
From: David Miller @ 2016-04-26 17:56 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Ariel.Elior, Yuval.Mintz
In-Reply-To: <1461682570-745-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Tue, 26 Apr 2016 10:56:07 -0400
> This series adds support in driver for min/max bandwidth configuration
> for the PF on the link change notification or on explicit request of
> bandwidth update from the MFW [management firmware].
>
> The same infrastructure would later be used by user based flows
> [for example, rate shaping for the VFs]
>
> Please consider applying this series to "net-next"
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Andrew Lunn @ 2016-04-26 18:23 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Pramod Kumar, Rob Herring, Catalin Marinas,
Will Deacon, Masahiro Yamada, Chen-Yu Tsai, Mark Rutland,
devicetree, Pawel Moll, Suzuki K Poulose, netdev, Punit Agrawal,
linux-kernel, BCM Kernel Feedback, linux-arm-kernel, Anup Patel,
Kishon Vijay Abraham I
In-Reply-To: <5167289.0a4LBoWhyX@wuerfel>
> A more complex problem would be having a PHY driver for a device
> that can be either an ethernet phy or some other phy.
I doubt that ever happens. You can have up to 32 different devices on
an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
completely different things, why would a hardware engineer place them
on the same address? It is like saying your ATA controller and VGA
controller share the same slot on the PCI bus...
Andrew
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag
From: Sergei Shtylyov @ 2016-04-26 18:25 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-kernel, linux-arm-kernel, Gregory Clement,
Alexandre Belloni, netdev, Andrew Lunn, David Miller
In-Reply-To: <1461666272-10107-1-git-send-email-nicolas.ferre@atmel.com>
Hello.
On 04/26/2016 01:24 PM, Nicolas Ferre wrote:
> Fix gpio active flag for the phy reset-gpios property. The line is
> active low instead of active high.
> Actually, this flags was never used by the macb driver.
>
> Reported-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> Hi,
>
> Thanks for having reported this bug to me.
And thank you for beating me to it and doing the patch. I'm still busy
with other stuff. :-(
> I hope that we will be able to move forward for changing the phy
> reset code in the macb driver.
I meant to delete it entirely.
> I plan to queue this patch through arm-soc for 4.7.
Hm, that way we get that board broken if my phylib/macb patches get merged
before your patch. Perhaps it would be better to merge this patch thru DaveM's
tree (before my patches) to keep the kernel bisectable?
> Thanks, best regards,
> Nicolas
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] ARM: dts: at91: VInCo: fix phy reset gpio flag
From: Sergei Shtylyov @ 2016-04-26 18:27 UTC (permalink / raw)
To: David Miller, nicolas.ferre
Cc: linux-kernel, linux-arm-kernel, gregory.clement,
alexandre.belloni, netdev, andrew
In-Reply-To: <20160426.131750.433048061726795876.davem@davemloft.net>
On 04/26/2016 08:17 PM, David Miller wrote:
>> I plan to queue this patch through arm-soc for 4.7.
>
> Ok.
How about this patch going thru your net-next repo instead?
I'd like to keep the kernel bisectable... if my phylib/macb patches get merged
earlier than this one, that board would be broken...
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] netem: Segment GSO packets on enqueue.
From: Eric Dumazet @ 2016-04-26 18:49 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Jamal Hadi Salim, David S. Miller, netem
In-Reply-To: <1461692618-21333-1-git-send-email-nhorman@tuxdriver.com>
On Tue, 2016-04-26 at 13:43 -0400, Neil Horman wrote:
> This was recently reported to me, and reproduced on the latest net kernel, when
> attempting to run netperf from a host that had a netem qdisc attached to the
> egress interface:
..
> The problem occurs because netem is not prepared to handle GSO packets (as it
> uses skb_checksum_help in its enqueue path, which cannot manipulate these
> frames).
>
> The solution I think is to simply segment the skb in a simmilar fashion to the
> way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
> segment, instead of only when the interface needs us to do it. This allows
> netem to properly drop/mangle/pass/etc the correct percentages of frames as per
> its qdisc configuration, and avoid failing its checksum operations
>
> tested successfully by myself on the latest net kernel, to whcih this applies
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> CC: Jamal Hadi Salim <jhs@mojatatu.com>
> CC: "David S. Miller" <davem@davemloft.net>
> CC: netem@lists.linux-foundation.org
> ---
> net/sched/sch_netem.c | 34 +++++++++++++++++++++++++++++++++-
> 1 file changed, 33 insertions(+), 1 deletion(-)
This is not correct.
I want my TSO packets being still TSO after netem traversal.
Some of us use netem at 40Gbit speed ;)
^ permalink raw reply
* [PATCH] Fixes buffer allocation size and the actual packet length;
From: Petko Manolov @ 2016-04-26 18:50 UTC (permalink / raw)
To: netdev; +Cc: davem, petkan
As noticed by Lincoln Ramsay <a1291762@gmail.com> some old (usb 1.1) Pegasus
based devices may actually return more bytes than the specified in the datasheet
amount. That would not be a problem if the allocated space for the SKB was
equal to the parameter passed to usb_fill_bulk_urb(). Some poor bugger (i
really hope it was not me, but 'git blame' is useless in this case, so anyway)
decided to add '+ 8' to the buffer length parameter. Sometimes the usb transfer
overflows and corrupts the socket structure, leading to kernel panic.
The above doesn't seem to happen for newer (Pegasus2 based) devices which did
help this bug to hide for so long.
Nearly all Pegasus devices may append the RX status to the end of the received
packet. It is the default setup for the driver. The actual ethernet packet is
4 bytes shorter. Why and when 'pkt_len -= 4' became 'pkt_len -= 8' is again
hidden in the mists of time. There might have been a good reason to do so, but
multiple reads of the datasheet did not point me to any.
The patch is against v4.6-rc5 and was tested on ADM8515 device by transferring
multiple gigabytes of data over a couple of days without any complains from the
kernel.
Petko Manolov (1):
Fixes buffer allocation size and the actual packet length;
drivers/net/usb/pegasus.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--
2.8.0.rc3
^ permalink raw reply
* [PATCH] Fixes buffer allocation size and the actual packet length;
From: Petko Manolov @ 2016-04-26 18:50 UTC (permalink / raw)
To: netdev; +Cc: davem, petkan
In-Reply-To: <1461696624-5373-1-git-send-email-petkan@mip-labs.com>
usb_fill_bulk_urb() receives buffer length parameter 8 bytes larger
than what's allocated by alloc_skb(); This seems to be a problem with
older (pegasus usb-1.1) devices, which may silently return more data
than the maximal packet length.
Going through the chip's documentation i figured out the ethernet
packet is appended with 4 bytes of status data. That's why we now
subtract 4 instead of 8 bytes from the reported packet length.
Reported-by: Lincoln Ramsay <a1291762@gmail.com>
Signed-off-by: Petko Manolov <petkan@mip-labs.com>
---
drivers/net/usb/pegasus.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index f840802..780c217 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -497,7 +497,7 @@ static void read_bulk_callback(struct urb *urb)
pkt_len = buf[count - 3] << 8;
pkt_len += buf[count - 4];
pkt_len &= 0xfff;
- pkt_len -= 8;
+ pkt_len -= 4;
}
/*
@@ -528,7 +528,7 @@ static void read_bulk_callback(struct urb *urb)
goon:
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
rx_status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
if (rx_status == -ENODEV)
@@ -569,7 +569,7 @@ static void rx_fixup(unsigned long data)
}
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
try_again:
status = usb_submit_urb(pegasus->rx_urb, GFP_ATOMIC);
@@ -823,7 +823,7 @@ static int pegasus_open(struct net_device *net)
usb_fill_bulk_urb(pegasus->rx_urb, pegasus->usb,
usb_rcvbulkpipe(pegasus->usb, 1),
- pegasus->rx_skb->data, PEGASUS_MTU + 8,
+ pegasus->rx_skb->data, PEGASUS_MTU,
read_bulk_callback, pegasus);
if ((res = usb_submit_urb(pegasus->rx_urb, GFP_KERNEL))) {
if (res == -ENODEV)
--
2.8.0.rc3
^ permalink raw reply related
* Re: [PATCH] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Saeed Mahameed @ 2016-04-26 18:50 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <23978128.X7F5UHGaYZ@wuerfel>
On Tue, Apr 26, 2016 at 6:49 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> On Tuesday 26 April 2016 17:41:45 Saeed Mahameed wrote:
>> On Tue, Apr 26, 2016 at 4:53 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
>> >
>> > Sure, do you want to just edit this when you forward the patch, or
>> > do you need me to do it?
>> >
>>
>> Well, I won't say no if you want to do it
>>
>
> All I want is to get rid of the patch in my queue. I guess it's
> worth the 10 minute of work ;-)
>
> v2 coming
>
> Arnd
Thank you Arnd, Appreciated.
Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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 v2] net/mlx5e: avoid stack overflow in mlx5e_open_channels
From: Saeed Mahameed @ 2016-04-26 18:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Saeed Mahameed, Matan Barak, Leon Romanovsky, David S. Miller,
Achiad Shochat, Or Gerlitz, Amir Vadai, Tariq Toukan,
Linux Netdev List, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1461685993-1049370-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
On Tue, Apr 26, 2016 at 6:52 PM, Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org> wrote:
> struct mlx5e_channel_param is a large structure that is allocated
> on the stack of mlx5e_open_channels, and with a recent change
> it has grown beyond the warning size for the maximum stack
> that a single function should use:
>
> mellanox/mlx5/core/en_main.c: In function 'mlx5e_open_channels':
> mellanox/mlx5/core/en_main.c:1325:1: error: the frame size of 1072 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> The function is already using dynamic allocation and is not in
> a fast path, so the easiest workaround is to use another kzalloc
> for allocating the channel parameters.
>
> Signed-off-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
> Fixes: d3c9bc2743dc ("net/mlx5e: Added ICO SQs")
Acked-by: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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] macvlan: fix failure during registration v3
From: Mahesh Bandewar @ 2016-04-26 18:54 UTC (permalink / raw)
To: Francesco Ruggeri; +Cc: linux-netdev, Eric W. Biederman, David S. Miller
In-Reply-To: <1461449012-7401-1-git-send-email-fruggeri@arista.com>
On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A similar problem may exist in the ipvlan driver.
That is correct! The problem exists in ipvlan driver also. I'll cook a
patch to fix this in ipvlan driver.
> This patch consolidates modifications to port->count into macvlan_init
> and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
>
> v3: remove macvtap specific bits.
>
> Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
> ---
> drivers/net/macvlan.c | 10 ++++------
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> index 2bcf1f3..cb01023 100644
> --- a/drivers/net/macvlan.c
> +++ b/drivers/net/macvlan.c
> @@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
> {
> struct macvlan_dev *vlan = netdev_priv(dev);
> const struct net_device *lowerdev = vlan->lowerdev;
> + struct macvlan_port *port = vlan->port;
>
> dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
> (lowerdev->state & MACVLAN_STATE_MASK);
> @@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
> if (!vlan->pcpu_stats)
> return -ENOMEM;
>
> + port->count += 1;
> +
> return 0;
> }
>
> @@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> return err;
> }
>
> - port->count += 1;
> err = register_netdevice(dev);
> if (err < 0)
> - goto destroy_port;
> + return err;
>
> dev->priv_flags |= IFF_MACVLAN;
> err = netdev_upper_dev_link(lowerdev, dev);
> @@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
>
> unregister_netdev:
> unregister_netdevice(dev);
> -destroy_port:
> - port->count -= 1;
> - if (!port->count)
> - macvlan_port_destroy(lowerdev);
I think you still need this when it fails netdev_upper_dev_link(). The
only thing you should remove is the label.
>
> return err;
> }
> --
> 1.8.1.4
>
^ permalink raw reply
* Re: [PATCH] netem: Segment GSO packets on enqueue.
From: Neil Horman @ 2016-04-26 19:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, Jamal Hadi Salim, David S. Miller, netem
In-Reply-To: <1461696598.5535.35.camel@edumazet-glaptop3.roam.corp.google.com>
On Tue, Apr 26, 2016 at 11:49:58AM -0700, Eric Dumazet wrote:
> On Tue, 2016-04-26 at 13:43 -0400, Neil Horman wrote:
> > This was recently reported to me, and reproduced on the latest net kernel, when
> > attempting to run netperf from a host that had a netem qdisc attached to the
> > egress interface:
>
> ..
>
> > The problem occurs because netem is not prepared to handle GSO packets (as it
> > uses skb_checksum_help in its enqueue path, which cannot manipulate these
> > frames).
> >
> > The solution I think is to simply segment the skb in a simmilar fashion to the
> > way we do in __dev_queue_xmit (via validate_xmit_skb), except here we always
> > segment, instead of only when the interface needs us to do it. This allows
> > netem to properly drop/mangle/pass/etc the correct percentages of frames as per
> > its qdisc configuration, and avoid failing its checksum operations
> >
> > tested successfully by myself on the latest net kernel, to whcih this applies
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> > CC: Jamal Hadi Salim <jhs@mojatatu.com>
> > CC: "David S. Miller" <davem@davemloft.net>
> > CC: netem@lists.linux-foundation.org
> > ---
> > net/sched/sch_netem.c | 34 +++++++++++++++++++++++++++++++++-
> > 1 file changed, 33 insertions(+), 1 deletion(-)
>
>
> This is not correct.
>
> I want my TSO packets being still TSO after netem traversal.
>
> Some of us use netem at 40Gbit speed ;)
>
I can understand that, but that raises two questions in my mind:
1) Doesn't that make all the statistical manipulation for netem wrong? That is
to say, if netem drops 5% of packets, and it happens to drop a GSO packet, its
actually dropping several, instead of the single one required.
2) How are you getting netem to work with GSO at all? The warning is triggered
for me on every GSO packet, which I think would impact throughput :)
Neil
^ permalink raw reply
* Re: [PATCH net-next] macvlan: fix failure during registration v3
From: Francesco Ruggeri @ 2016-04-26 19:07 UTC (permalink / raw)
To: Mahesh Bandewar; +Cc: linux-netdev, Eric W. Biederman, David S. Miller
In-Reply-To: <CAF2d9jh98MGYorJ=btvx04==EsjP5_ivUEimf0TJ1NUPDzG4nw@mail.gmail.com>
On Tue, Apr 26, 2016 at 11:54 AM, Mahesh Bandewar <maheshb@google.com> wrote:
>
> On Sat, Apr 23, 2016 at 3:03 PM, Francesco Ruggeri <fruggeri@arista.com> wrote:
> > If macvlan_common_newlink fails in register_netdevice after macvlan_init
> > then it decrements port->count twice, first in macvlan_uninit (from
> > register_netdevice or rollback_registered) and then again in
> > macvlan_common_newlink.
> > A similar problem may exist in the ipvlan driver.
> That is correct! The problem exists in ipvlan driver also. I'll cook a
> patch to fix this in ipvlan driver.
>
> > This patch consolidates modifications to port->count into macvlan_init
> > and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
> >
> > v3: remove macvtap specific bits.
> >
> > Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
> > ---
> > drivers/net/macvlan.c | 10 ++++------
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
> > index 2bcf1f3..cb01023 100644
> > --- a/drivers/net/macvlan.c
> > +++ b/drivers/net/macvlan.c
> > @@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
> > {
> > struct macvlan_dev *vlan = netdev_priv(dev);
> > const struct net_device *lowerdev = vlan->lowerdev;
> > + struct macvlan_port *port = vlan->port;
> >
> > dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
> > (lowerdev->state & MACVLAN_STATE_MASK);
> > @@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
> > if (!vlan->pcpu_stats)
> > return -ENOMEM;
> >
> > + port->count += 1;
> > +
> > return 0;
> > }
> >
> > @@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> > return err;
> > }
> >
> > - port->count += 1;
> > err = register_netdevice(dev);
> > if (err < 0)
> > - goto destroy_port;
> > + return err;
> >
> > dev->priv_flags |= IFF_MACVLAN;
> > err = netdev_upper_dev_link(lowerdev, dev);
> > @@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
> >
> > unregister_netdev:
> > unregister_netdevice(dev);
> > -destroy_port:
> > - port->count -= 1;
> > - if (!port->count)
> > - macvlan_port_destroy(lowerdev);
> I think you still need this when it fails netdev_upper_dev_link(). The
> only thing you should remove is the label.
I don't think so. I think the double decrement also occurred in this case.
unregister_netdevice invokes rollback_registered/macvlan_uninit
which does the decrement.
Thanks,
Francesco
> >
> > return err;
> > }
> > --
> > 1.8.1.4
> >
^ permalink raw reply
* Re: [PATCH] can: m_can: fix bitrate setup on latest silicon
From: Oliver Hartkopp @ 2016-04-26 19:11 UTC (permalink / raw)
To: Florian Vallee, Wolfgang Grandegger, Marc Kleine-Budde
Cc: linux-can, netdev, linux-kernel, ebenard
In-Reply-To: <1461678379-28257-1-git-send-email-fvallee@eukrea.fr>
On 04/26/2016 03:46 PM, Florian Vallee wrote:
> According to the m_can user manual changelog the BTP register layout was
> updated with core revision 3.1.0
Hello Florian,
nice to see a real v3.1.0 user emerging on the mailing list :-)
I wonder whether this small change covers the updates made between
v3.0.1 and v3.1.0.
IIRC
v3.0.1:
NON_ISO operation / general CAN/CANFD and BRS switch in register CCCR
v3.1.0:
ISO operation / per frame CAN/CANFD switch (FDF/BRS bit in TX/RX buffer)
v3.2.x:
Ability to switch ISO/NON_ISO operation (NISO bit on register CCCR)
updated range of NBTP.NTSEG2
The current v3.0.1 driver is fixed to tell to be a NON_ISO controller:
https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/diff/drivers/net/can/m_can/m_can.c?h=testing
The v3.1.0 is a fixed ISO controller and additional it does not make
sense anymore to configure the CCCR register each time, before sending a
frame:
https://git.kernel.org/cgit/linux/kernel/git/mkl/linux-can-next.git/tree/drivers/net/can/m_can/m_can.c?h=testing&id=885cc17abad6c3064f266099a6ded2d357012380#n1075
Just as the new TX/RX buffer layout contains a FDF and BRS bits for this
reason.
> +static inline int m_can_read_core_rev(const struct m_can_priv *priv)
> +{
> + u32 reg = m_can_read(priv, M_CAN_CREL);
> +
> + return ((reg >> CRR_REL_SHIFT) & CRR_REL_MASK);
> +}
> +
> static void m_can_read_fifo(struct net_device *dev, u32 rxfs)
> {
> struct net_device_stats *stats = &dev->stats;
> @@ -814,8 +838,16 @@ static int m_can_set_bittiming(struct net_device *dev)
> sjw = bt->sjw - 1;
> tseg1 = bt->prop_seg + bt->phase_seg1 - 1;
> tseg2 = bt->phase_seg2 - 1;
> - reg_btp = (brp << BTR_BRP_SHIFT) | (sjw << BTR_SJW_SHIFT) |
> - (tseg1 << BTR_TSEG1_SHIFT) | (tseg2 << BTR_TSEG2_SHIFT);
> +
> + if (m_can_read_core_rev(priv) < M_CAN_COREREL_3_1_0)
Your patch looks very good so far. I would appreciate if you could
update the other register changes too as I don't have a hardware to
test. I can provide the ISO/NON_ISO config for the netlink interface
updates then :-)
Best regards,
Oliver
^ permalink raw reply
* Re: [PATCH net-next] ravb: Remove rx buffer ALIGN
From: Sergei Shtylyov @ 2016-04-26 19:14 UTC (permalink / raw)
To: Yoshihiro Kaneko, netdev
Cc: David S. Miller, Simon Horman, Magnus Damm, linux-renesas-soc
In-Reply-To: <1461514567-23444-1-git-send-email-ykaneko0929@gmail.com>
Hello.
On 04/24/2016 07:16 PM, Yoshihiro Kaneko wrote:
> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>
> Aligning the reception data size is not required.
OK, the gen 2/3 manuals indeed don't require this. I assume the patch has
been tested...
> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
I have a few comments though...
> diff --git a/drivers/net/ethernet/renesas/ravb_main.c b/drivers/net/ethernet/renesas/ravb_main.c
> index 238b56f..66ed80c 100644
> --- a/drivers/net/ethernet/renesas/ravb_main.c
> +++ b/drivers/net/ethernet/renesas/ravb_main.c
> @@ -246,10 +246,10 @@ static void ravb_ring_format(struct net_device *ndev, int q)
> for (i = 0; i < priv->num_rx_ring[q]; i++) {
> /* RX descriptor */
> rx_desc = &priv->rx_ring[q][i];
> - /* The size of the buffer should be on 16-byte boundary. */
> - rx_desc->ds_cc = cpu_to_le16(ALIGN(PKT_BUF_SZ, 16));
> - dma_addr = dma_map_single(ndev->dev.parent, priv->rx_skb[q][i]->data,
> - ALIGN(PKT_BUF_SZ, 16),
> + rx_desc->ds_cc = cpu_to_le16(PKT_BUF_SZ);
> + dma_addr = dma_map_single(ndev->dev.parent,
> + priv->rx_skb[q][i]->data,
Please don't reformat the lines above.
> + PKT_BUF_SZ,
> DMA_FROM_DEVICE);
> /* We just set the data size to 0 for a failed mapping which
> * should prevent DMA from happening...
> @@ -557,8 +557,9 @@ static bool ravb_rx(struct net_device *ndev, int *quota, int q)
>
> skb = priv->rx_skb[q][entry];
> priv->rx_skb[q][entry] = NULL;
> - dma_unmap_single(ndev->dev.parent, le32_to_cpu(desc->dptr),
> - ALIGN(PKT_BUF_SZ, 16),
> + dma_unmap_single(ndev->dev.parent,
> + le32_to_cpu(desc->dptr),
Same here.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next] macvlan: fix failure during registration v3
From: David Miller @ 2016-04-26 19:19 UTC (permalink / raw)
To: fruggeri; +Cc: netdev, ebiederm, maheshb
In-Reply-To: <1461449012-7401-1-git-send-email-fruggeri@arista.com>
From: Francesco Ruggeri <fruggeri@arista.com>
Date: Sat, 23 Apr 2016 15:03:32 -0700
> If macvlan_common_newlink fails in register_netdevice after macvlan_init
> then it decrements port->count twice, first in macvlan_uninit (from
> register_netdevice or rollback_registered) and then again in
> macvlan_common_newlink.
> A similar problem may exist in the ipvlan driver.
> This patch consolidates modifications to port->count into macvlan_init
> and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
>
> v3: remove macvtap specific bits.
>
> Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] macvtap: check minor when unregistering
From: David Miller @ 2016-04-26 19:19 UTC (permalink / raw)
To: fruggeri; +Cc: netdev, ebiederm
In-Reply-To: <1461449071-7499-1-git-send-email-fruggeri@arista.com>
From: Francesco Ruggeri <fruggeri@arista.com>
Date: Sat, 23 Apr 2016 15:04:31 -0700
> macvtap_device_event(NETDEV_UNREGISTER) should check vlan->minor to
> determine if it is being invoked in the context of a macvtap_newlink
> that failed, for example in this code sequence:
>
> macvtap_newlink
> macvlan_common_newlink
> register_netdevice
> call_netdevice_notifiers(NETDEV_REGISTER, dev)
> macvtap_device_event(NETDEV_REGISTER)
> <fail here, vlan->minor = 0>
> rollback_registered(dev);
> rollback_registered_many
> call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
> macvtap_device_event(NETDEV_UNREGISTER)
> <nothing to clean up here>
>
> Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] sctp: sctp_diag should fill RMEM_ALLOC with asoc->rmem_alloc when rcvbuf_policy is set
From: David Miller @ 2016-04-26 19:19 UTC (permalink / raw)
To: lucien.xin
Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel,
eric.dumazet
In-Reply-To: <f21861d502b04cf3752dce4cde8cd3f5f1806571.1461511282.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Sun, 24 Apr 2016 23:21:22 +0800
> For sctp assoc, when rcvbuf_policy is set, it will has it's own
> rmem_alloc, when we dump asoc info in sctp_diag, we should use that
> value on RMEM_ALLOC as well, just like WMEM_ALLOC.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] sh_eth: get rid of the 2nd parameter to sh_eth_dev_init()
From: David Miller @ 2016-04-26 19:22 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: netdev, linux-renesas-soc
In-Reply-To: <1615196.r6Bb3HFTJZ@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 24 Apr 2016 19:11:07 +0300
> sh_eth_dev_init() is now always called with 'true' as the 2nd argument,
> so that there's no more sense in having 2 parameters to this function...
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Arnd Bergmann @ 2016-04-26 19:24 UTC (permalink / raw)
To: Andrew Lunn
Cc: Florian Fainelli, Pramod Kumar, Rob Herring, Catalin Marinas,
Will Deacon, Masahiro Yamada, Chen-Yu Tsai, Mark Rutland,
devicetree, Pawel Moll, Suzuki K Poulose, netdev, Punit Agrawal,
linux-kernel, BCM Kernel Feedback, linux-arm-kernel, Anup Patel,
Kishon Vijay Abraham I
In-Reply-To: <20160426182335.GE30107@lunn.ch>
On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote:
> > A more complex problem would be having a PHY driver for a device
> > that can be either an ethernet phy or some other phy.
>
> I doubt that ever happens. You can have up to 32 different devices on
> an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
> completely different things, why would a hardware engineer place them
> on the same address? It is like saying your ATA controller and VGA
> controller share the same slot on the PCI bus...
To clarify: what I meant is a device that is designed as a PHY for
similar hardware (e.g. SATA, USB3 and PCIe) and that has a common
register set and a single driver, but that driver can operate
in multiple modes. You typically have multiple instances of
such hardware, with each instance linked to exactly one host
device, but one driver for all of them.
See Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
and drivers/phy/phy-xgene.c for one such example.
Arnd
^ permalink raw reply
* Re: [PATCH 1/6] bus: Add shared MDIO bus framework
From: Andrew Lunn @ 2016-04-26 19:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Florian Fainelli, Pramod Kumar, Rob Herring, Catalin Marinas,
Will Deacon, Masahiro Yamada, Chen-Yu Tsai, Mark Rutland,
devicetree, Pawel Moll, Suzuki K Poulose, netdev, Punit Agrawal,
linux-kernel, BCM Kernel Feedback, linux-arm-kernel, Anup Patel,
Kishon Vijay Abraham I
In-Reply-To: <9424602.Vqb0FY56gH@wuerfel>
On Tue, Apr 26, 2016 at 09:24:34PM +0200, Arnd Bergmann wrote:
> On Tuesday 26 April 2016 20:23:35 Andrew Lunn wrote:
> > > A more complex problem would be having a PHY driver for a device
> > > that can be either an ethernet phy or some other phy.
> >
> > I doubt that ever happens. You can have up to 32 different devices on
> > an MDIO bus. Since an Ethernet PHY and a "some other sort of PHY" are
> > completely different things, why would a hardware engineer place them
> > on the same address? It is like saying your ATA controller and VGA
> > controller share the same slot on the PCI bus...
>
> To clarify: what I meant is a device that is designed as a PHY for
> similar hardware (e.g. SATA, USB3 and PCIe) and that has a common
> register set and a single driver, but that driver can operate
> in multiple modes. You typically have multiple instances of
> such hardware, with each instance linked to exactly one host
> device, but one driver for all of them.
>
> See Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
> and drivers/phy/phy-xgene.c for one such example.
Interesting. Also, that this lists SGMII. I assume this is a phy in
the MAC in order to talk to the Ethernet PHY.
I still don't see it being a big problem if a phy driver implements an
Ethernet PHY. It just needs to call phy_device_create() and
phy_device_register().
Andrew
^ permalink raw reply
* Re: [PATCH 0/5] Don't return NULL from get_phy_device() anymore
From: David Miller @ 2016-04-26 19:41 UTC (permalink / raw)
To: sergei.shtylyov; +Cc: f.fainelli, netdev, arnd
In-Reply-To: <56219623.1S7UfcqQqc@wasted.cogentembedded.com>
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Date: Sun, 24 Apr 2016 20:23:03 +0300
> Here's the set of 5 patches against DaveM's 'net-next.git' repo. The first
> patch makes get_phy_device() return only error values on error, the rest of
> the patches clean up the callers of that function...
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] Fixes buffer allocation size and the actual packet length;
From: David Miller @ 2016-04-26 19:45 UTC (permalink / raw)
To: petkan; +Cc: netdev
In-Reply-To: <1461696624-5373-1-git-send-email-petkan@mip-labs.com>
Submitting a cover letter and the patch itself with identical Subject lines
is not correct.
You must also use proper "[PATCH $(TREE) X/Y] " prefixes in your Subject
lines as well.
Please format your Subject lines correctly and resubmit, thank you.
^ 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