* Re: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help
From: Nicolas Pitre @ 2016-10-26 23:41 UTC (permalink / raw)
To: Paul Bolle
Cc: John Stultz, Richard Cochran, Michal Marek, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <1477523669.2121.8.camel@tiscali.nl>
On Thu, 27 Oct 2016, Paul Bolle wrote:
> On Tue, 2016-10-25 at 22:28 -0400, Nicolas Pitre wrote:
> > From: Nicolas Pitre <nicolas.pitre@linaro.org>
> > Subject: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help
>
> This doesn't work. I received this message with an empty subject.
Hmmm... must have dome something stupid with git send-patch.
> If you'll have to send another update don't bother including Yann. Yann
> hasn't be heard of in years. MAINTAINERS doesn't reflect reality for
> kconfig.
What about updating it then?
Nicolas
^ permalink raw reply
* Re: [PATCH v2 1/5] kconfig: introduce the "imply" keyword
From: Paul Bolle @ 2016-10-26 23:28 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Richard Cochran, Michal Marek, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <1477448931-29051-2-git-send-email-nicolas.pitre@linaro.org>
On Tue, 2016-10-25 at 22:28 -0400, Nicolas Pitre wrote:
> SUBSYSTEM_X can still be configured out, and it can be set as a
> module when none of the drivers are selected or all of them are also
> modular.
Short note, to highlight a pet peeve: "select" (and therefor
"selected") has a special meaning in kconfig land. I guess you meant
something neutral like "set" here. Is that correct?
By the way: "also" makes this sentence hard to parse.
Paul Bolle
^ permalink raw reply
* Re: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help
From: Paul Bolle @ 2016-10-26 23:14 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Richard Cochran, Michal Marek, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <1477448931-29051-1-git-send-email-nicolas.pitre@linaro.org>
On Tue, 2016-10-25 at 22:28 -0400, Nicolas Pitre wrote:
> From: Nicolas Pitre <nicolas.pitre@linaro.org>
> Subject: [PATCH v2 0/5] make POSIX timers optional with some Kconfig help
This doesn't work. I received this message with an empty subject.
If you'll have to send another update don't bother including Yann. Yann
hasn't be heard of in years. MAINTAINERS doesn't reflect reality for
kconfig.
Paul Bolle
^ permalink raw reply
* Re: [PATCH] drivers/net/usb/r8152 fix broken rx checksums
From: Mark Lord @ 2016-10-26 22:54 UTC (permalink / raw)
To: nic_swsd, netdev, Linux Kernel; +Cc: stable
In-Reply-To: <987cfbab-2b48-e28c-1706-967cb2051d63@pobox.com>
On 16-10-26 06:36 PM, Mark Lord wrote:
> The r8152 driver has been broken since (approx) 3.6.16,
Correction: broken since 3.16.xx.
> when support was added for hardware rx checksum on newer chip versions.
> Symptoms include random segfaults and silent data corruption over NFS.
>
> This does not work on the VER_02 dongle I have here
> when used with a slow embedded system CPU.
> Google reveals others reporting similar issues on Raspberry Pi.
>
> So, disable hardware rx checksum for VER_02, and fix
> an obvious coding error for IPV6 checksums in the same function.
>
> Because this bug results in silent data corruption,
> it is a good candidate for back-porting to -stable >= 3.16.xx.
> Patch attached (to deal with buggy mailer) and also below for review.
>
> Signed-off-by: Mark Lord <mlord@pobox.com>
>
> --- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.000000000 -0400
> +++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400
> @@ -1645,7 +1645,7 @@
> u8 checksum = CHECKSUM_NONE;
> u32 opts2, opts3;
>
> - if (tp->version == RTL_VER_01)
> + if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
> goto return_result;
>
> opts2 = le32_to_cpu(rx_desc->opts2);
> @@ -1660,7 +1660,7 @@
> checksum = CHECKSUM_NONE;
> else
> checksum = CHECKSUM_UNNECESSARY;
> - } else if (RD_IPV6_CS) {
> + } else if (opts2 & RD_IPV6_CS) {
> if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
> checksum = CHECKSUM_UNNECESSARY;
> else if ((opts2 & RD_TCP_CS) && !(opts3 & TCPF))
--
Mark Lord
Real-Time Remedies Inc.
mlord@pobox.com
^ permalink raw reply
* Re: [PATCH v2 5/5] posix-timers: make it configurable
From: Nicolas Pitre @ 2016-10-26 22:49 UTC (permalink / raw)
To: Richard Cochran
Cc: John Stultz, Yann E. MORIN, Michal Marek, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <20161026201828.GA25143@localhost.localdomain>
On Wed, 26 Oct 2016, Richard Cochran wrote:
> On Wed, Oct 26, 2016 at 09:56:13AM -0400, Nicolas Pitre wrote:
> > So if my Fedora usage doesn't need them, we can infer that
> > the number of embedded systems also not needing them might tend towards
> > a high percentage.
>
> (I wouldn't call Fedora an embedded distro, but heh...)
Indeed it is not. Non-embedded distros usually make more extensive usage
of the kernel. Still, disabling POSIX timers doesn't affect it.
> > But let's be conservative and say "some".
>
> Sounds good to me.
Does the PTP related part of this series also sounds good to you?
May I have your ACK?
Nicolas
^ permalink raw reply
* [PATCH] drivers/net/usb/r8152 fix broken rx checksums
From: Mark Lord @ 2016-10-26 22:36 UTC (permalink / raw)
To: nic_swsd, netdev, Linux Kernel; +Cc: stable
[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]
The r8152 driver has been broken since (approx) 3.6.16,
when support was added for hardware rx checksum on newer chip versions.
Symptoms include random segfaults and silent data corruption over NFS.
This does not work on the VER_02 dongle I have here
when used with a slow embedded system CPU.
Google reveals others reporting similar issues on Raspberry Pi.
So, disable hardware rx checksum for VER_02, and fix
an obvious coding error for IPV6 checksums in the same function.
Because this bug results in silent data corruption,
it is a good candidate for back-porting to -stable >= 3.16.xx.
Patch attached (to deal with buggy mailer) and also below for review.
Signed-off-by: Mark Lord <mlord@pobox.com>
--- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.000000000 -0400
+++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400
@@ -1645,7 +1645,7 @@
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
- if (tp->version == RTL_VER_01)
+ if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
goto return_result;
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -1660,7 +1660,7 @@
checksum = CHECKSUM_NONE;
else
checksum = CHECKSUM_UNNECESSARY;
- } else if (RD_IPV6_CS) {
+ } else if (opts2 & RD_IPV6_CS) {
if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
checksum = CHECKSUM_UNNECESSARY;
else if ((opts2 & RD_TCP_CS) && !(opts3 & TCPF))
[-- Attachment #2: drivers_net_usb_r8152_checksums.patch --]
[-- Type: text/x-patch, Size: 1306 bytes --]
The r8152 driver has been broken since (approx) 3.6.16,
when support was added for hardware rx checksum on newer chip versions.
Symptoms include random segfaults and silent data corruption over NFS.
This does not work on the VER_02 dongle I have here
when used with a slow embedded system CPU.
Google reveals others reporting similar issues on Raspberry Pi.
So, disable hardware rx checksum for VER_02, and fix
an obvious coding error for IPV6 checksums in the same function.
Because this bug results in silent data corruption,
it is a good candidate for back-porting to -stable >= 3.16.xx.
Signed-off-by: Mark Lord <mlord@pobox.com>
--- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.000000000 -0400
+++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400
@@ -1645,7 +1645,7 @@
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
- if (tp->version == RTL_VER_01)
+ if (tp->version == RTL_VER_01 || tp->version == RTL_VER_02)
goto return_result;
opts2 = le32_to_cpu(rx_desc->opts2);
@@ -1660,7 +1660,7 @@
checksum = CHECKSUM_NONE;
else
checksum = CHECKSUM_UNNECESSARY;
- } else if (RD_IPV6_CS) {
+ } else if (opts2 & RD_IPV6_CS) {
if ((opts2 & RD_UDP_CS) && !(opts3 & UDPF))
checksum = CHECKSUM_UNNECESSARY;
else if ((opts2 & RD_TCP_CS) && !(opts3 & TCPF))
^ permalink raw reply
* Re: iproute: ss truncates abstract unix domain socket embedding null
From: Stephen Hemminger @ 2016-10-26 22:22 UTC (permalink / raw)
To: Isaac Boukris; +Cc: netdev
In-Reply-To: <CAC-fF8SuSWabeCW-nBUwn6VsgFyMfQF9s1f0XZhdjAgiSGzVTw@mail.gmail.com>
On Wed, 26 Oct 2016 21:49:35 +0300
Isaac Boukris <iboukris@gmail.com> wrote:
> Hi Stephen, thanks for looking into this.
>
> On Wed, Oct 26, 2016 at 8:15 PM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> > On Tue, 18 Oct 2016 21:46:48 +0300
> > Isaac Boukris <iboukris@gmail.com> wrote:
> >
> >> Hi again,
> >>
> >> On Sun, Oct 16, 2016 at 11:43 PM, Isaac Boukris <iboukris@gmail.com> wrote:
> >> > Hello,
> >> >
> >> > The unix(7) man page says that null have no special meaning in
> >> > abstract unix domain socket address (the length is specified
> >> > therefore).
> >> >
> >> > However, when such name (embedding null) is used, ss (and netstat)
> >> > will only show up to the first null occurrence (second technically, if
> >> > we count the null prefix).
> >> > e.g. the name "\0/tmp/fo\0.sock" is displayed as: "@/tmp/fo" (whilst
> >> > strace tool shows it as: sun_path=@"/tmp/fo\0.sock").
> >> >
> >> > Would it be more useful if it printed the whole name and escaped the null?
> >> > If so, would '\0' be ok for escaping the null?
> >>
> >>
> >> Meanwhile, I've got it to escape the null character with with '\0' as suggested.
> >> Can anyone take a look and advise if I'm on the right track? Thanks!
> >
> > I did a little investigation and current ss behavior matches the output
> > of other commands (netstat and lsof). Therefore I really can't see the motivation
> > to fix this.
>
> The motivation behind the fix is because the usage of abstract unix
> domain socket is somewhat tricky.
> I've seen it being used incorrectly where for example the addrlen was
> specified as 'sizeof(struct sockaddr_un)' which is ok for regular unix
> sockets because their names are null-terminated, but with abstract
> sockets it causes extra null padding which leads to interoperability
> problems.
> On another occasion, addrlen was incremented to account for an
> additional null-termination byte.
>
> I was thinking therefore, it could help if the diagnostic tools would
> show all the significant bytes of the name in order to make it clear
> and easy to distinguish.
>
> On the other hand, I think I've complicated it a little bit with the
> '\0' escaping.
> Perhaps it would suffice to substitute each null character with an '@'
> sign, the same way we do for the null prefix.
>
> As regarding netstat, I have in fact made a patch for it, but then I
> realized it perhaps isn't its fault as it prints what it reads from
> '/proc/net/unix' which prints the null prefix as '@' but leaves
> subsequent nulls as is (literally, can be seen with 'cat -A').
> So I'm trying to see if '/proc/net/unix' can be fixed to translate all
> null occurrences to '@' sign (not only the prefix).
> This should fix netstat and also (I think) the alternative 'proc' base
> implementation in ss (unix_use_proc).
>
> What do you think?
Just translating all null characters to @ seems the most consistent and
logical. Also translating other all non-printing characters to something (maybe '?')
might be wise. It would be nice if all utilities output the same thing.
^ permalink raw reply
* Re: [PATCH 4/5] net: ethernet: bgmac: add NS2 support
From: Florian Fainelli @ 2016-10-26 21:50 UTC (permalink / raw)
To: Jon Mason, David Miller, Rob Herring, Mark Rutland
Cc: rafal-g1n6cQUeyibVItvQsEIGlw,
bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477510561-17035-5-git-send-email-jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
On 10/26/2016 12:36 PM, Jon Mason wrote:
> Add support for the variant of amac hardware present in the Broadcom
> Northstar2 based SoCs. Northstar2 requires an additional register to be
> configured with the port speed/duplexity (NICPM). This can be added to
> the link callback to hide it from the instances that do not use this.
> Also, the bgmac_chip_reset() was intentionally removed to prevent the
> resetting of the chip to the default values on open. Finally, clearing
> of the pending interrupts on init is required due to observed issues on
> some platforms.
>
> Signed-off-by: Jon Mason <jon.mason-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> ---
> +static void bgmac_nicpm_speed_set(struct net_device *net_dev)
> +{
> + struct bgmac *bgmac = netdev_priv(net_dev);
> + u32 val;
> +
> + if (!bgmac->plat.nicpm_base)
> + return;
> +
> + val = NICPM_IOMUX_CTRL_INIT_VAL;
> + switch (bgmac->net_dev->phydev->speed) {
> + default:
> + pr_err("Unsupported speed. Defaulting to 1000Mb\n");
> + case SPEED_1000:
> + val |= NICPM_IOMUX_CTRL_SPD_1000M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_100:
> + val |= NICPM_IOMUX_CTRL_SPD_100M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + case SPEED_10:
> + val |= NICPM_IOMUX_CTRL_SPD_10M << NICPM_IOMUX_CTRL_SPD_SHIFT;
> + break;
> + }
> +
> + writel(val, bgmac->plat.nicpm_base + NICPM_IOMUX_CTRL);
> +
> + usleep_range(10, 100);
Does not seem like a good idea, do you need that sleep?
> +
> + bgmac_adjust_link(bgmac->net_dev);
> +}
> +
> static int platform_phy_connect(struct bgmac *bgmac)
> {
> struct phy_device *phy_dev;
>
> - phy_dev = of_phy_get_and_connect(bgmac->net_dev, bgmac->dev->of_node,
> - bgmac_adjust_link);
> + if (bgmac->plat.nicpm_base)
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_nicpm_speed_set);
> + else
> + phy_dev = of_phy_get_and_connect(bgmac->net_dev,
> + bgmac->dev->of_node,
> + bgmac_adjust_link);
> if (!phy_dev) {
> dev_err(bgmac->dev, "Phy connect failed\n");
> return -ENODEV;
> }
>
> + if (bgmac->feature_flags & BGMAC_FEAT_LANE_SWAP)
> + phy_dev->dev_flags |= PHY_BRCM_EXP_LANE_SWAP;
> +
> return 0;
> }
>
> @@ -140,6 +188,9 @@ static int bgmac_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, bgmac);
>
> + if (of_property_read_bool(np, "brcm,enet-phy-lane-swap"))
> + bgmac->feature_flags |= BGMAC_FEAT_LANE_SWAP;
> +
> /* Set the features of the 4707 family */
> bgmac->feature_flags |= BGMAC_FEAT_CLKCTLST;
> bgmac->feature_flags |= BGMAC_FEAT_NO_RESET;
> @@ -182,6 +233,14 @@ static int bgmac_probe(struct platform_device *pdev)
> if (IS_ERR(bgmac->plat.idm_base))
> return PTR_ERR(bgmac->plat.idm_base);
>
> + regs = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nicpm_base");
> + if (regs) {
> + bgmac->plat.nicpm_base = devm_ioremap_resource(&pdev->dev,
> + regs);
> + if (IS_ERR(bgmac->plat.nicpm_base))
> + return PTR_ERR(bgmac->plat.nicpm_base);
> + }
> +
> bgmac->read = platform_bgmac_read;
> bgmac->write = platform_bgmac_write;
> bgmac->idm_read = platform_bgmac_idm_read;
> @@ -213,6 +272,7 @@ static int bgmac_remove(struct platform_device *pdev)
> static const struct of_device_id bgmac_of_enet_match[] = {
> {.compatible = "brcm,amac",},
> {.compatible = "brcm,nsp-amac",},
> + {.compatible = "brcm,ns2-amac",},
> {},
> };
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 38876ec..1796208 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -1082,6 +1082,9 @@ static void bgmac_enable(struct bgmac *bgmac)
> /* http://bcm-v4.sipsolutions.net/mac-gbit/gmac/chipinit */
> static void bgmac_chip_init(struct bgmac *bgmac)
> {
> + /* Clear any erroneously pending interrupts */
> + bgmac_write(bgmac, BGMAC_INT_STATUS, ~0);
> +
> /* 1 interrupt per received frame */
> bgmac_write(bgmac, BGMAC_INT_RECV_LAZY, 1 << BGMAC_IRL_FC_SHIFT);
>
> @@ -1158,8 +1161,6 @@ static int bgmac_open(struct net_device *net_dev)
> struct bgmac *bgmac = netdev_priv(net_dev);
> int err = 0;
>
> - bgmac_chip_reset(bgmac);
> -
Is this removal intentional? Maybe it should be special cased with
checking for a NS2 BGMAC instance and not do it in that case?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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] udp: fix IP_CHECKSUM handling
From: David Miller @ 2016-10-26 21:34 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, samanthakumar, willemb, tom
In-Reply-To: <1477270986.7065.102.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 23 Oct 2016 18:03:06 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> First bug was added in commit ad6f939ab193 ("ip: Add offset parameter to
> ip_cmsg_recv") : Tom missed that ipv4 udp messages could be received on
> AF_INET6 socket. ip_cmsg_recv(msg, skb) should have been replaced by
> ip_cmsg_recv_offset(msg, skb, sizeof(struct udphdr));
>
> Then commit e6afc8ace6dd ("udp: remove headers from UDP packets before
> queueing") forgot to adjust the offsets now UDP headers are pulled
> before skb are put in receive queue.
>
> Fixes: ad6f939ab193 ("ip: Add offset parameter to ip_cmsg_recv")
> Fixes: e6afc8ace6dd ("udp: remove headers from UDP packets before queueing")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* Re: [PATCH net] sctp: fix the panic caused by route update
From: David Miller @ 2016-10-26 21:32 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, daniel
In-Reply-To: <a0659fd9a23fc95fe9a586be4b57c8032c8a6060.1477242069.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 24 Oct 2016 01:01:09 +0800
> Commit 7303a1475008 ("sctp: identify chunks that need to be fragmented
> at IP level") made the chunk be fragmented at IP level in the next round
> if it's size exceed PMTU.
>
> But there still is another case, PMTU can be updated if transport's dst
> expires and transport's pmtu_pending is set in sctp_packet_transmit. If
> the new PMTU is less than the chunk, the same issue with that commit can
> be triggered.
>
> So we should drop this packet and let it retransmit in another round
> where it would be fragmented at IP level.
>
> This patch is to fix it by checking the chunk size after PMTU may be
> updated and dropping this packet if it's size exceed PMTU.
>
> Fixes: 90017accff61 ("sctp: Add GSO support")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied, and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH net] doc: update docbook annotations for socket and skb
From: David Miller @ 2016-10-26 21:31 UTC (permalink / raw)
To: stephen; +Cc: netdev
In-Reply-To: <20161023092829.3c2bc1f2@xeon-e3>
From: Stephen Hemminger <stephen@networkplumber.org>
Date: Sun, 23 Oct 2016 09:28:29 -0700
> From: Stephen Hemminger <sthemmin@microsoft.com>
>
> The skbuff and sock structure both had missing parameter annotation
> values.
>
> Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Applied, thanks.
^ permalink raw reply
* Re: [patch net-next] devlink: Prevent port_type_set() callback when it's not needed
From: David Miller @ 2016-10-26 21:30 UTC (permalink / raw)
To: jiri; +Cc: netdev, eladr
In-Reply-To: <1477237385-1991-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sun, 23 Oct 2016 17:43:05 +0200
> From: Elad Raz <eladr@mellanox.com>
>
> When a port_type_set() is been called and the new port type set is the same
> as the old one, just return success.
>
> Signed-off-by: Elad Raz <eladr@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 2/2] firewire: net: set initial MTU = 1500 unconditionally, fix IPv6 on some CardBus cards
From: David Miller @ 2016-10-26 21:29 UTC (permalink / raw)
To: stefanr; +Cc: netdev, linux1394-devel, linux-kernel, jarod
In-Reply-To: <20161023163056.6bc38610@kant>
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Sun, 23 Oct 2016 16:30:56 +0200
> firewire-net, like the older eth1394 driver, reduced the initial MTU to
> less than 1500 octets if the local link layer controller's asynchronous
> packet reception limit was lower.
>
> This is bogus, since this reception limit does not have anything to do
> with the transmission limit. Neither did this reduction affect the TX
> path positively, nor could it prevent link fragmentation at the RX path.
>
> Many FireWire CardBus cards have a max_rec of 9, causing an initial MTU
> of 1024 - 16 = 1008. RFC 2734 and RFC 3146 allow a minimum max_rec = 8,
> which would result in an initial MTU of 512 - 16 = 496. On such cards,
> IPv6 could only be employed if the MTU was manually increased to 1280 or
> more, i.e. IPv6 would not work without intervention from userland.
>
> We now always initialize the MTU to 1500, which is the default according
> to RFC 2734 and RFC 3146.
>
> On a VIA VT6316 based CardBus card which was affected by this, changing
> the MTU from 1008 to 1500 also increases TX bandwidth by 6 %.
> RX remains unaffected.
>
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Applied.
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
^ permalink raw reply
* Re: [PATCH net-next 1/2] firewire: net: fix maximum possible MTU
From: David Miller @ 2016-10-26 21:29 UTC (permalink / raw)
To: stefanr; +Cc: netdev, linux1394-devel, linux-kernel, jarod
In-Reply-To: <20161023162903.4166a35d@kant>
From: Stefan Richter <stefanr@s5r6.in-berlin.de>
Date: Sun, 23 Oct 2016 16:29:03 +0200
> Commit b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> mistakenly introduced an upper limit for firewire-net's MTU based on the
> local link layer controller's reception capability. Revert this. Neither
> RFC 2734 nor our implementation impose any particular upper limit.
>
> Actually, to be on the safe side and to make the code explicit, set
> ETH_MAX_MTU = 65535 as upper limit now.
>
> (I replaced sizeof(struct rfc2734_header) by the equivalent
> RFC2374_FRAG_HDR_SIZE in order to avoid distracting long/int conversions.)
>
> Fixes: b3e3893e1253('net: use core MTU range checking in misc drivers')
> CC: netdev@vger.kernel.org
> CC: linux1394-devel@lists.sourceforge.net
> CC: Jarod Wilson <jarod@redhat.com>
> Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Applied.
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
^ permalink raw reply
* Re: [PATCH v1 1/1] ISDN: eicon: replace custom hex_dump_to_buffer()
From: David Miller @ 2016-10-26 21:27 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: mac, netdev, isdn
In-Reply-To: <20161022173705.170520-1-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Sat, 22 Oct 2016 20:37:05 +0300
> Instead of custom approach re-use generic helper to convert bytes to hex
> format.
>
> The output is slightly changed, namely string starts from the first dword
> value.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
This adds a warning.
Really, if you're not even going to check if the compiler warns
when you try to "clean up" such ancient drivers like this one,
don't even bother.
drivers/isdn/hardware/eicon/message.c: In function ‘dump_c_ind_mask’:
drivers/isdn/hardware/eicon/message.c:1156:22: warning: passing argument 1 of ‘hex_dump_to_buffer’ makes pointer from integer without a cast [-Wint-conversion]
hex_dump_to_buffer(plci->c_ind_mask_table[i], j, 16, 4, buf, sizeof(buf), false);
^~~~
In file included from ./include/linux/kernel.h:13:0,
from ./include/linux/list.h:8,
from ./include/linux/module.h:9,
from drivers/isdn/hardware/eicon/platform.h:21,
from drivers/isdn/hardware/eicon/message.c:30:
./include/linux/printk.h:457:12: note: expected ‘const void *’ but argument is of type ‘u32 {aka unsigned int}’
extern int hex_dump_to_buffer(const void *buf, size_t len, int rowsize,
^~~~~~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH -next] net: netcp: drop kfree for memory allocated with devm_kzalloc
From: David Miller @ 2016-10-26 21:25 UTC (permalink / raw)
To: weiyj.lk; +Cc: w-kwok2, m-karicheri2, weiyongjun1, netdev
In-Reply-To: <1477139524-26359-1-git-send-email-weiyj.lk@gmail.com>
None of your patches apply to the net-next tree.
I'm getting extremely troubled by the quality of your submissions and
the effort you are not putting into making sure you submit patches
which will apply cleanly against the net-next tree.
I think I'm at the point where it is extremely fair for me to warn you
that if this continues any further I reserve the right to start
ignoring your submissions completely because they are having a
negative effect on my ability to process the pending patch queue for
networking.
You have been warned, and so please do not make any excuses or be
surprised in the future if less attention is paid to your submissions.
Thank you.
^ permalink raw reply
* Re: [PATCH -next] rocker: fix error return code in rocker_world_check_init()
From: David Miller @ 2016-10-26 21:21 UTC (permalink / raw)
To: jiri; +Cc: weiyj.lk, weiyongjun1, netdev
In-Reply-To: <20161022153429.GA3657@nanopsycho.orion>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sat, 22 Oct 2016 17:34:29 +0200
> Sat, Oct 22, 2016 at 04:31:06PM CEST, weiyj.lk@gmail.com wrote:
>>From: Wei Yongjun <weiyongjun1@huawei.com>
>>
>>Fix to return error code -EINVAL from the error handling
>>case instead of 0, as done elsewhere in this function.
>>
>>Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fixes: e420114eef4a ("rocker: introduce worlds infrastructure")
> Acked-by: Jiri Pirko <jiri@mellanox.com>
>
> Dave, you can queue this to -net.
Done, thanks.
^ permalink raw reply
* Re: [PATCH] batman-adv: Revert "use core MTU range checking in misc drivers"
From: David Miller @ 2016-10-26 21:20 UTC (permalink / raw)
To: sven; +Cc: netdev, b.a.t.m.a.n, linux-kernel, jarod
In-Reply-To: <20161022074624.30033-1-sven@narfation.org>
From: Sven Eckelmann <sven@narfation.org>
Date: Sat, 22 Oct 2016 09:46:24 +0200
> The maximum MTU is defined via the slave devices of an batman-adv
> interface. Thus it is not possible to calculate the max_mtu during the
> creation of the batman-adv device when no slave devices are attached. Doing
> so would for example break non-fragmentation setups which then
> (incorrectly) allow an MTU of 1500 even when underlying device cannot
> transport 1500 bytes + batman-adv headers.
>
> Checking the dynamically calculated max_mtu via the minimum of the slave
> devices MTU during .ndo_change_mtu is also used by the bridge interface.
>
> Cc: Jarod Wilson <jarod@redhat.com>
> Fixes: b3e3893e1253 ("net: use core MTU range checking in misc drivers")
> Signed-off-by: Sven Eckelmann <sven@narfation.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 0/2] Broadcom BCM54612E support
From: David Miller @ 2016-10-26 21:16 UTC (permalink / raw)
To: xow; +Cc: f.fainelli, jaedon.shin, netdev, linux-kernel, openbmc, joel
In-Reply-To: <1477070413-92621-1-git-send-email-xow@google.com>
From: Xo Wang <xow@google.com>
Date: Fri, 21 Oct 2016 10:20:11 -0700
> This series is based on tip of torvalds/master.
>
> The first patch adds register definitions from Broadcom docs.
>
> The second patch adds the BCM54612E PHY ID, flags, and device-specific
> RGMII internal delay initialization.
>
> I tested on a custom board with an Aspeed AST2500 SOC with its second
> MAC connected to this PHY.
Series applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH net-next] sch_htb: do not report fake rate estimators
From: David Miller @ 2016-10-26 21:14 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jikos, jhs
In-Reply-To: <1477065763.7065.84.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 21 Oct 2016 09:02:43 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> When I prepared commit d250a5f90e53 ("pkt_sched: gen_estimator: Dont
> report fake rate estimators"), htb still had an implicit rate estimator
> for all its classes.
>
> Then later, I made this rate estimator optional in commit 64153ce0a7b6
> ("net_sched: htb: do not setup default rate estimators"), but I forgot
> to update htb use of gnet_stats_copy_rate_est()
>
> After this patch, "tc -s qdisc ..." no longer report fake rate
> estimators for HTB classes.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] net: bonding: use new api ethtool_{get|set}_link_ksettings
From: Philippe Reynes @ 2016-10-26 21:12 UTC (permalink / raw)
To: Jay Vosburgh
Cc: vfalico, Andy Gospodarek, David S. Miller, netdev, linux-kernel
In-Reply-To: <11572.1477504825@famine>
Hi Jay,
On Wed, Oct 26, 2016 at 8:00 PM, Jay Vosburgh
<jay.vosburgh@canonical.com> wrote:
> Philippe Reynes <tremyfr@gmail.com> wrote:
>
>>The ethtool api {get|set}_settings is deprecated.
>>We move this driver to new api {get|set}_link_ksettings.
>
> This is just an API change, i.e., no change to functionality?
Yes, it's juste an API change.
Philippe
> -J
>
>>Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
>>---
>> drivers/net/bonding/bond_main.c | 16 ++++++++--------
>> 1 files changed, 8 insertions(+), 8 deletions(-)
>>
>>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>>index c9944d8..5708f17 100644
>>--- a/drivers/net/bonding/bond_main.c
>>+++ b/drivers/net/bonding/bond_main.c
>>@@ -4080,16 +4080,16 @@ static netdev_tx_t bond_start_xmit(struct sk_buff *skb, struct net_device *dev)
>> return ret;
>> }
>>
>>-static int bond_ethtool_get_settings(struct net_device *bond_dev,
>>- struct ethtool_cmd *ecmd)
>>+static int bond_ethtool_get_link_ksettings(struct net_device *bond_dev,
>>+ struct ethtool_link_ksettings *cmd)
>> {
>> struct bonding *bond = netdev_priv(bond_dev);
>> unsigned long speed = 0;
>> struct list_head *iter;
>> struct slave *slave;
>>
>>- ecmd->duplex = DUPLEX_UNKNOWN;
>>- ecmd->port = PORT_OTHER;
>>+ cmd->base.duplex = DUPLEX_UNKNOWN;
>>+ cmd->base.port = PORT_OTHER;
>>
>> /* Since bond_slave_can_tx returns false for all inactive or down slaves, we
>> * do not need to check mode. Though link speed might not represent
>>@@ -4100,12 +4100,12 @@ static int bond_ethtool_get_settings(struct net_device *bond_dev,
>> if (bond_slave_can_tx(slave)) {
>> if (slave->speed != SPEED_UNKNOWN)
>> speed += slave->speed;
>>- if (ecmd->duplex == DUPLEX_UNKNOWN &&
>>+ if (cmd->base.duplex == DUPLEX_UNKNOWN &&
>> slave->duplex != DUPLEX_UNKNOWN)
>>- ecmd->duplex = slave->duplex;
>>+ cmd->base.duplex = slave->duplex;
>> }
>> }
>>- ethtool_cmd_speed_set(ecmd, speed ? : SPEED_UNKNOWN);
>>+ cmd->base.speed = speed ? : SPEED_UNKNOWN;
>>
>> return 0;
>> }
>>@@ -4121,8 +4121,8 @@ static void bond_ethtool_get_drvinfo(struct net_device *bond_dev,
>>
>> static const struct ethtool_ops bond_ethtool_ops = {
>> .get_drvinfo = bond_ethtool_get_drvinfo,
>>- .get_settings = bond_ethtool_get_settings,
>> .get_link = ethtool_op_get_link,
>>+ .get_link_ksettings = bond_ethtool_get_link_ksettings,
>> };
>>
>> static const struct net_device_ops bond_netdev_ops = {
>>--
>>1.7.4.4
>
> ---
> -Jay Vosburgh, jay.vosburgh@canonical.com
^ permalink raw reply
* Re: [PATCH net-next] net: dev: Fix non-RCU based lower dev walker
From: Ido Schimmel @ 2016-10-26 20:46 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, idosch
In-Reply-To: <1477513293-10117-1-git-send-email-dsa@cumulusnetworks.com>
On Wed, Oct 26, 2016 at 01:21:33PM -0700, David Ahern wrote:
> netdev_walk_all_lower_dev is not properly walking the lower device
> list. Commit 1a3f060c1a47 made netdev_walk_all_lower_dev similar
> to netdev_walk_all_upper_dev_rcu and netdev_walk_all_lower_dev_rcu
> but failed to update its netdev_next_lower_dev iterator. This patch
> fixes that.
>
> Fixes: 1a3f060c1a47 ("net: Introduce new api for walking upper and
> lower devices")
> Reported-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Tested-by: Ido Schimmel <idosch@mellanox.com>
Thanks David.
^ permalink raw reply
* Re: [PATCH net-next 2/3] bpf: Add new cgroups prog type to enable sock modifications
From: David Ahern @ 2016-10-26 20:42 UTC (permalink / raw)
To: Mahesh Bandewar (महेश बंडेवार),
Daniel Borkmann
Cc: linux-netdev, daniel, ast
In-Reply-To: <CAF2d9jhE0OHgWrDfHwYzRk2tDbnmK_=ZdgFd2-ccpbTjdQzqmQ@mail.gmail.com>
On 10/26/16 2:31 PM, Mahesh Bandewar (महेश बंडेवार) wrote:
> The hook insertion in sk_alloc() may not solve all control-path checks as not much can be done (probably apart for changing sk_bound_dev_if) during allocation but hooks in bind(), listen(), setsockopt() etc. (not a complete list) will be needed. Also pushing this change (changing sk_bound_dev_if) later (than sk_alloc()) you might avoid the case dumazet@ has mentioned.
For v2 I moved the running of the filter to the end of inet{6}_create.
^ permalink raw reply
* [PATCH net-next] net: dev: Fix non-RCU based lower dev walker
From: David Ahern @ 2016-10-26 20:21 UTC (permalink / raw)
To: netdev; +Cc: idosch, David Ahern
netdev_walk_all_lower_dev is not properly walking the lower device
list. Commit 1a3f060c1a47 made netdev_walk_all_lower_dev similar
to netdev_walk_all_upper_dev_rcu and netdev_walk_all_lower_dev_rcu
but failed to update its netdev_next_lower_dev iterator. This patch
fixes that.
Fixes: 1a3f060c1a47 ("net: Introduce new api for walking upper and
lower devices")
Reported-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
net/core/dev.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index f55fb4536016..6aa43cd8cbb5 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5400,12 +5400,12 @@ static struct net_device *netdev_next_lower_dev(struct net_device *dev,
{
struct netdev_adjacent *lower;
- lower = list_entry(*iter, struct netdev_adjacent, list);
+ lower = list_entry((*iter)->next, struct netdev_adjacent, list);
if (&lower->list == &dev->adj_list.lower)
return NULL;
- *iter = lower->list.next;
+ *iter = &lower->list;
return lower->dev;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH v2 5/5] posix-timers: make it configurable
From: Richard Cochran @ 2016-10-26 20:18 UTC (permalink / raw)
To: Nicolas Pitre
Cc: John Stultz, Yann E. MORIN, Michal Marek, Thomas Gleixner,
Josh Triplett, Edward Cree, netdev, linux-kbuild, linux-kernel
In-Reply-To: <alpine.LFD.2.20.1610260941520.14694@knanqh.ubzr>
On Wed, Oct 26, 2016 at 09:56:13AM -0400, Nicolas Pitre wrote:
> So if my Fedora usage doesn't need them, we can infer that
> the number of embedded systems also not needing them might tend towards
> a high percentage.
(I wouldn't call Fedora an embedded distro, but heh...)
> But let's be conservative and say "some".
Sounds good to me.
Thanks,
Richard
^ 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