* Re: pull-request: mac80211 2016-04-27
From: David Miller @ 2016-04-28 20:55 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1461747447-11287-1-git-send-email-johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Wed, 27 Apr 2016 10:57:26 +0200
> While writing some new code yesterday, I found and fixed a per-CPU memory
> leak, this pull request has just a single patch addressing that.
>
> Let me know if there's any problem.
Pulled, thanks a lot.
--
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: [PATCHv2] netem: Segment GSO packets on enqueue.
From: Eric Dumazet @ 2016-04-28 20:58 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, Jamal Hadi Salim, David S. Miller, netem
In-Reply-To: <1461874148-14937-1-git-send-email-nhorman@tuxdriver.com>
On Thu, 2016-04-28 at 16:09 -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:
>
> - return NET_XMIT_SUCCESS;
> +finish_segs:
> + while (segs) {
> + skb2 = segs->next;
> + segs->next = NULL;
> + qdisc_skb_cb(segs)->pkt_len = segs->len;
> + rc = qdisc_enqueue(segs, sch);
> + if (rc != NET_XMIT_SUCCESS) {
> + if (net_xmit_drop_count(rc))
> + qdisc_qstats_drop(sch);
> + }
> + segs = skb2;
> + }
> + return rc;
> }
It seems you missed the qdisc_tree_reduce_backlog() call ?
^ permalink raw reply
* Re: [PATCH v6 2/6] Documentation: Bindings: Add STM32 DWMAC glue
From: Rob Herring @ 2016-04-28 20:59 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Giuseppe Cavallaro,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
manabian-Re5JQEeQqe8AvxtiuMwx3w, wens-jdAy2FN1RRM
In-Reply-To: <1461585242-32401-3-git-send-email-alexandre.torgue-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Apr 25, 2016 at 01:53:58PM +0200, Alexandre TORGUE wrote:
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
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 v3 0/2] gre: fix lwtunnel support
From: David Miller @ 2016-04-28 21:03 UTC (permalink / raw)
To: jbenc; +Cc: netdev, pshelar, tgraf, simon.horman
In-Reply-To: <cover.1461747398.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Wed, 27 Apr 2016 11:29:05 +0200
> This patchset fixes a few bugs in ipgre metadata mode implementation.
>
> As an example, in this setup:
>
> ip a a 192.168.1.1/24 dev eth0
> ip l a gre1 type gre external
> ip l s gre1 up
> ip a a 192.168.99.1/24 dev gre1
> ip r a 192.168.99.2/32 encap ip dst 192.168.1.2 ttl 10 dev gre1
> ping 192.168.99.2
>
> the traffic does not go through before this patchset and does as expected
> with it applied.
>
> v3: Back to v1 in order not to break existing users. Dropped patch 3, will
> be fixed in iproute2 instead.
> v2: Rejecting invalid configuration, added patch 3, dropped patch for
> ETH_P_TEB (will target net-next).
Series applied, thanks Jiri.
^ permalink raw reply
* Re: [PATCH v2] net: macb: do not scan PHYs manually
From: Josh Cartwright @ 2016-04-28 21:03 UTC (permalink / raw)
To: Andrew Lunn
Cc: Nathan Sullivan, Nicolas Ferre, netdev, linux-kernel,
Florian Fainelli, Alexandre Belloni
In-Reply-To: <20160428185932.GU29024@lunn.ch>
[-- Attachment #1: Type: text/plain, Size: 1410 bytes --]
On Thu, Apr 28, 2016 at 08:59:32PM +0200, Andrew Lunn wrote:
> On Thu, Apr 28, 2016 at 01:55:27PM -0500, Nathan Sullivan wrote:
> > On Thu, Apr 28, 2016 at 08:43:03PM +0200, Andrew Lunn wrote:
> > > > I agree that is a valid fix for AT91, however it won't solve our problem, since
> > > > we have no children on the second ethernet MAC in our devices' device trees. I'm
> > > > starting to feel like our second MAC shouldn't even really register the MDIO bus
> > > > since it isn't being used - maybe adding a DT property to not have a bus is a
> > > > better option?
> > >
> > > status = "disabled"
> > >
> > > would be the unusual way.
> > >
> > > Andrew
> >
> > Oh, sorry, I meant we use both MACs on Zynq, however the PHYs are on the MDIO
> > bus of the first MAC. So, the second MAC is used for ethernet but not for MDIO,
> > and so it does not have any PHYs under its DT node. It would be nice if there
> > were a way to tell macb not to bother with MDIO for the second MAC, since that's
> > handled by the first MAC.
>
> Yes, exactly, add support for status = "disabled" in the mdio node.
Unfortunately, the 'macb' doesn't have a "mdio node", or alternatively:
the node representing the mdio bus is the same node which represents the
macb instance itself. Setting 'status = "disabled"' on this node will
just prevent the probing of the macb instance.
Josh
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] fq: split out backlog update logic
From: David Miller @ 2016-04-28 21:04 UTC (permalink / raw)
To: michal.kazior; +Cc: netdev, johannes
In-Reply-To: <1461754753-18051-1-git-send-email-michal.kazior@tieto.com>
From: Michal Kazior <michal.kazior@tieto.com>
Date: Wed, 27 Apr 2016 12:59:13 +0200
> mac80211 (which will be the first user of the
> fq.h) recently started to support software A-MSDU
> aggregation. It glues skbuffs together into a
> single one so the backlog accounting needs to be
> more fine-grained.
>
> To avoid backlog sorting logic duplication split
> it up for re-use.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Applied, thanks.
^ permalink raw reply
* [PATCH v2 net] soreuseport: Fix TCP listener hash collision
From: Craig Gallek @ 2016-04-28 21:07 UTC (permalink / raw)
To: davem; +Cc: netdev
From: Craig Gallek <kraig@google.com>
I forgot to include a check for listener port equality when deciding
if two sockets should belong to the same reuseport group. This was
not caught previously because it's only necessary when two listening
sockets for the same user happen to hash to the same listener bucket.
This change also includes a check for network namespace equality.
The same error does not exist in the UDP path.
Fixes: c125e80b8868("soreuseport: fast reuseport TCP socket selection")
Signed-off-by: Craig Gallek <kraig@google.com>
---
v2 Changes
- Suggestions from Eric Dumazet to include network namespace equality
check and to avoid a dreference by simply checking inet_bind_bucket
pointer equality.
---
net/ipv4/inet_hashtables.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index bc68eced0105..5c5658268d5e 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -470,15 +470,19 @@ static int inet_reuseport_add_sock(struct sock *sk,
const struct sock *sk2,
bool match_wildcard))
{
+ struct inet_bind_bucket *tb = inet_csk(sk)->icsk_bind_hash;
+ struct net *net = sock_net(sk);
struct sock *sk2;
struct hlist_nulls_node *node;
kuid_t uid = sock_i_uid(sk);
sk_nulls_for_each_rcu(sk2, node, &ilb->head) {
- if (sk2 != sk &&
+ if (net_eq(sock_net(sk2), net) &&
+ sk2 != sk &&
sk2->sk_family == sk->sk_family &&
ipv6_only_sock(sk2) == ipv6_only_sock(sk) &&
sk2->sk_bound_dev_if == sk->sk_bound_dev_if &&
+ inet_csk(sk2)->icsk_bind_hash == tb &&
sk2->sk_reuseport && uid_eq(uid, sock_i_uid(sk2)) &&
saddr_same(sk, sk2, false))
return reuseport_add_sock(sk, sk2);
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [PATCH v3 0/2] pegasus: correct buffer & packet sizes
From: David Miller @ 2016-04-28 21:09 UTC (permalink / raw)
To: petkan; +Cc: netdev, a1291762, johannes
In-Reply-To: <1461756290-27421-1-git-send-email-petkan@mip-labs.com>
From: Petko Manolov <petkan@mip-labs.com>
Date: Wed, 27 Apr 2016 14:24:48 +0300
> 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.
>
> The new default is to not include the CRC at the end of each received package.
> So far CRC has been ignored which makes no sense to do it in a first place.
>
> 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 complaints from the
> kernel. Please apply it to whatever net tree you deem fit.
>
> Changes since v1:
>
> - split the patch in two parts;
> - corrected the subject lines;
>
> Changes since v2:
>
> - do not append CRC by default (based on a discussion with Johannes Berg);
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] gre: reject GUE and FOU in collect metadata mode
From: David Miller @ 2016-04-28 21:10 UTC (permalink / raw)
To: jbenc; +Cc: netdev, pshelar, tgraf, tom
In-Reply-To: <7280f5aa7ec83653cdf7f0484fb9e696bc8c89e8.1461758705.git.jbenc@redhat.com>
From: Jiri Benc <jbenc@redhat.com>
Date: Wed, 27 Apr 2016 14:08:01 +0200
> The collect metadata mode does not support GUE nor FOU. This might be
> implemented later; until then, we should reject such config.
>
> I think this is okay to be changed. It's unlikely anyone has such
> configuration (as it doesn't work anyway) and we may need a way to
> distinguish whether it's supported or not by the kernel later.
>
> For backwards compatibility with iproute2, it's not possible to just check
> the attribute presence (iproute2 always includes the attribute), the actual
> value has to be checked, too.
>
> Fixes: 2e15ea390e6f4 ("ip_gre: Add support to collect tunnel metadata.")
> Signed-off-by: Jiri Benc <jbenc@redhat.com>
> ---
> Discovered this only after I already sent v3 of the previous gre set.
> Submitting this patch on its own, it's an indepent fix anyway (though fixing
> the same commit).
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 1/2] net: nps_enet: Sync access to packet sent flag
From: David Miller @ 2016-04-28 21:11 UTC (permalink / raw)
To: eladkan; +Cc: noamca, linux-kernel, abrodkin, talz, netdev
In-Reply-To: <1461763110-15263-2-git-send-email-eladkan@mellanox.com>
From: Elad Kanfi <eladkan@mellanox.com>
Date: Wed, 27 Apr 2016 16:18:29 +0300
> From: Elad Kanfi <eladkan@mellanox.com>
>
> Below is a description of a possible problematic
> sequence. CPU-A is sending a frame and CPU-B handles
> the interrupt that indicates the frame was sent. CPU-B
> reads an invalid value of tx_packet_sent.
>
> CPU-A CPU-B
> ----- -----
> nps_enet_send_frame
> .
> .
> tx_packet_sent = true
> order HW to start tx
> .
> .
> HW complete tx
> ------> get tx complete interrupt
> .
> .
> if(tx_packet_sent == true)
>
> end memory transaction
> (tx_packet_sent actually
> written)
>
> Problem solution:
>
> Add a memory barrier after setting tx_packet_sent,
> in order to make sure that it is written before
> the packet is sent.
>
> Signed-off-by: Elad Kanfi <eladkan@mellanox.com>
>
> Acked-by: Noam Camus <noamca@mellanox.com>
Please address the feedback about memory barrier pairing.
Also, for both patches, do not put empty lines between the various
tags at the end of the commit message. They should all be together
in one continuous group.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: net: Change maintainer for GRETH 10/100/1G Ethernet MAC device driver
From: David Miller @ 2016-04-28 21:12 UTC (permalink / raw)
To: andreas; +Cc: netdev, linux-kernel, sam, software
In-Reply-To: <1461768370-3011-1-git-send-email-andreas@gaisler.com>
From: Andreas Larsson <andreas@gaisler.com>
Date: Wed, 27 Apr 2016 16:46:10 +0200
> Signed-off-by: Andreas Larsson <andreas@gaisler.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: give prequeue mode some care
From: David Miller @ 2016-04-28 21:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1461777145.5535.77.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 27 Apr 2016 10:12:25 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP prequeue goal is to defer processing of incoming packets
> to user space thread currently blocked in a recvmsg() system call.
>
> Intent is to spend less time processing these packets on behalf
> of softirq handler, as softirq handler is unfair to normal process
> scheduler decisions, as it might interrupt threads that do not
> even use networking.
>
> Current prequeue implementation has following issues :
>
> 1) It only checks size of the prequeue against sk_rcvbuf
>
> It was fine 15 years ago when sk_rcvbuf was in the 64KB vicinity.
> But we now have ~8MB values to cope with modern networking needs.
> We have to add sk_rmem_alloc in the equation, since out of order
> packets can definitely use up to sk_rcvbuf memory themselves.
>
> 2) Even with a fixed memory truesize check, prequeue can be filled
> by thousands of packets. When prequeue needs to be flushed, either
> from sofirq context (in tcp_prequeue() or timer code), or process
> context (in tcp_prequeue_process()), this adds a latency spike
> which is often not desirable.
> I added a fixed limit of 32 packets, as this translated to a max
> flush time of 60 us on my test hosts.
>
> Also note that all packets in prequeue are not accounted for tcp_mem,
> since they are not charged against sk_forward_alloc at this point.
> This is probably not a big deal.
>
> Note that this might increase LINUX_MIB_TCPPREQUEUEDROPPED counts,
> which is misnamed, as packets are not dropped at all, but rather pushed
> to the stack (where they can be either consumed or dropped)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
There was a conflict due to the stats macro renaming, but that was trivial
to resolve so I did it.
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: Provide CPU port statistics to master netdev
From: David Miller @ 2016-04-28 21:16 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, andrew, vivien.didelot
In-Reply-To: <1461782714-13471-1-git-send-email-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Wed, 27 Apr 2016 11:45:14 -0700
> This patch overloads the DSA master netdev, aka CPU Ethernet MAC to also
> include switch-side statistics, which is useful for debugging purposes,
> when the switch is not properly connected to the Ethernet MAC (duplex
> mismatch, (RG)MII electrical issues etc.).
>
> We accomplish this by retaining the original copy of the master netdev's
> ethtool_ops, and just overload the 3 operations we care about:
> get_sset_count, get_strings and get_ethtool_stats so as to intercept
> these calls and call into the original master_netdev ethtool_ops, plus
> our own.
>
> We take this approach as opposed to providing a set of DSA helper
> functions that would retrive the CPU port's statistics, because the
> entire purpose of DSA is to allow unmodified Ethernet MAC drivers to be
> used as CPU conduit interfaces, therefore, statistics overlay in such
> drivers would simply not scale.
>
> The new ethtool -S <iface> output would therefore look like this now:
> <iface> statistics
> p<2 digits cpu port number>_<switch MIB counter names>
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Applied, thanks Florian.
^ permalink raw reply
* Re: [PATCH net-next 0/6] net: make TCP preemptible
From: Marcelo Ricardo Leitner @ 2016-04-28 21:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S . Miller, netdev, Eric Dumazet
In-Reply-To: <1461821152-23200-1-git-send-email-edumazet@google.com>
On Wed, Apr 27, 2016 at 10:25:46PM -0700, Eric Dumazet wrote:
> Most of TCP stack assumed it was running from BH handler.
>
> This is great for most things, as TCP behavior is very sensitive
> to scheduling artifacts.
>
> However, the prequeue and backlog processing are problematic,
> as they need to be flushed with BH being blocked.
>
> To cope with modern needs, TCP sockets have big sk_rcvbuf values,
> in the order of 16 MB.
> This means that backlog can hold thousands of packets, and things
> like TCP coalescing or collapsing on this amount of packets can
> lead to insane latency spikes, since BH are blocked for too long.
And due to that, it may potentially lead to packet drops on NIC ring
buffers. Great, thanks Eric.
> It is time to make UDP/TCP stacks preemptible.
>
> Note that fast path still runs from BH handler.
>
> Eric Dumazet (6):
> tcp: do not assume TCP code is non preemptible
> tcp: do not block bh during prequeue processing
> dccp: do not assume DCCP code is non preemptible
> udp: prepare for non BH masking at backlog processing
> sctp: prepare for socket backlog behavior change
> net: do not block BH while processing socket backlog
>
> net/core/sock.c | 22 +++------
> net/dccp/input.c | 2 +-
> net/dccp/ipv4.c | 4 +-
> net/dccp/ipv6.c | 4 +-
> net/dccp/options.c | 2 +-
> net/ipv4/tcp.c | 6 +--
> net/ipv4/tcp_cdg.c | 20 ++++----
> net/ipv4/tcp_cubic.c | 20 ++++----
> net/ipv4/tcp_fastopen.c | 12 ++---
> net/ipv4/tcp_input.c | 126 +++++++++++++++++++----------------------------
> net/ipv4/tcp_ipv4.c | 14 ++++--
> net/ipv4/tcp_minisocks.c | 2 +-
> net/ipv4/tcp_output.c | 7 ++-
> net/ipv4/tcp_recovery.c | 4 +-
> net/ipv4/tcp_timer.c | 10 ++--
> net/ipv4/udp.c | 4 +-
> net/ipv6/tcp_ipv6.c | 12 ++---
> net/ipv6/udp.c | 4 +-
> net/sctp/inqueue.c | 2 +
> 19 files changed, 124 insertions(+), 153 deletions(-)
>
> --
> 2.8.0.rc3.226.g39d4020
>
^ permalink raw reply
* Re: [PATCH v3 2/2] net: Add Qualcomm IPC router
From: David Miller @ 2016-04-28 21:19 UTC (permalink / raw)
To: bjorn.andersson
Cc: andy.gross, linux-kernel, netdev, linux-arm-msm, courtney.cavin,
bjorn.andersson
In-Reply-To: <1461784383-2978-2-git-send-email-bjorn.andersson@linaro.org>
From: Bjorn Andersson <bjorn.andersson@linaro.org>
Date: Wed, 27 Apr 2016 12:13:03 -0700
> From: Courtney Cavin <courtney.cavin@sonymobile.com>
>
> Add an implementation of Qualcomm's IPC router protocol, used to
> communicate with service providing remote processors.
>
> Signed-off-by: Courtney Cavin <courtney.cavin@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
> [bjorn: Cope with 0 being a valid node id and implement RTM_NEWADDR]
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
>
> Changes since v2:
> - Altered Kconfig dependency for QRTR_SMD to be compile testable
>
> Changes since v1:
> - Made node 0 (normally the Qualcomm modem) a valid node
> - Implemented RTM_NEWADDR for specifying the local node id
Please adjust this so that CONFIG_QRTR can be modular.
^ permalink raw reply
* Re: [PATCH net-next #2 1/1] pch_gbe: replace private tx ring lock with common netif_tx_lock
From: David Miller @ 2016-04-28 21:21 UTC (permalink / raw)
To: romieu; +Cc: netdev, nikolay, dvhart, andy.cress, bryan
In-Reply-To: <20160427212944.GB10269@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 27 Apr 2016 23:29:44 +0200
> pch_gbe_tx_ring.tx_lock is only used in the hard_xmit handler and
> in the transmit completion reaper called from NAPI context.
>
> Compile-tested only. Potential victims Cced.
>
> Someone more knowledgeable may check if pch_gbe_tx_queue could
> have some use for a mmiowb.
>
> Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
> Cc: Darren Hart <dvhart@infradead.org>
> Cc: Andy Cress <andy.cress@us.kontron.com>
> Cc: bryan@fossetcon.org
>
> ---
> Includes Nikolay's fix.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] net: macb: do not scan PHYs manually
From: Andrew Lunn @ 2016-04-28 21:23 UTC (permalink / raw)
To: Josh Cartwright
Cc: Nathan Sullivan, Nicolas Ferre, netdev, linux-kernel,
Florian Fainelli, Alexandre Belloni
In-Reply-To: <20160428210357.GB30217@jcartwri.amer.corp.natinst.com>
On Thu, Apr 28, 2016 at 04:03:57PM -0500, Josh Cartwright wrote:
> On Thu, Apr 28, 2016 at 08:59:32PM +0200, Andrew Lunn wrote:
> > On Thu, Apr 28, 2016 at 01:55:27PM -0500, Nathan Sullivan wrote:
> > > On Thu, Apr 28, 2016 at 08:43:03PM +0200, Andrew Lunn wrote:
> > > > > I agree that is a valid fix for AT91, however it won't solve our problem, since
> > > > > we have no children on the second ethernet MAC in our devices' device trees. I'm
> > > > > starting to feel like our second MAC shouldn't even really register the MDIO bus
> > > > > since it isn't being used - maybe adding a DT property to not have a bus is a
> > > > > better option?
> > > >
> > > > status = "disabled"
> > > >
> > > > would be the unusual way.
> > > >
> > > > Andrew
> > >
> > > Oh, sorry, I meant we use both MACs on Zynq, however the PHYs are on the MDIO
> > > bus of the first MAC. So, the second MAC is used for ethernet but not for MDIO,
> > > and so it does not have any PHYs under its DT node. It would be nice if there
> > > were a way to tell macb not to bother with MDIO for the second MAC, since that's
> > > handled by the first MAC.
> >
> > Yes, exactly, add support for status = "disabled" in the mdio node.
>
> Unfortunately, the 'macb' doesn't have a "mdio node", or alternatively:
> the node representing the mdio bus is the same node which represents the
> macb instance itself. Setting 'status = "disabled"' on this node will
> just prevent the probing of the macb instance.
:-(
It is very common to have an mdio node within the MAC node, for example imx6sx-sdb.dtsi
&fec1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet1>;
phy-supply = <®_enet_3v3>;
phy-mode = "rgmii";
phy-handle = <ðphy1>;
status = "okay";
mdio {
#address-cells = <1>;
#size-cells = <0>;
ethphy1: ethernet-phy@1 {
reg = <1>;
};
ethphy2: ethernet-phy@2 {
reg = <2>;
};
};
};
&fec2 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_enet2>;
phy-mode = "rgmii";
phy-handle = <ðphy2>;
status = "okay";
};
This even has the two phys on one bus, as you described...
Andrew
^ permalink raw reply
* Re: [PATCH next v2] ipvlan: Fix failure path in dev registration during link creation
From: David Miller @ 2016-04-28 21:23 UTC (permalink / raw)
To: mahesh; +Cc: maheshb, edumazet, netdev, ebiederm
In-Reply-To: <1461794367-39825-1-git-send-email-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Wed, 27 Apr 2016 14:59:27 -0700
> From: Mahesh Bandewar <maheshb@google.com>
>
> When newlink creation fails at device-registration, the port->count
> is decremented twice. Francesco Ruggeri (fruggeri@arista.com) found
> this issue in Macvlan and the same exists in IPvlan driver too.
>
> While fixing this issue I noticed another issue of missing unregister
> in case of failure, so adding it to the fix which is similar to the
> macvlan fix by Francesco in commit 308379607548 ("macvlan: fix failure
> during registration v3")
>
> Reported-by: Francesco Ruggeri <fruggeri@arista.com>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v3 0/5] drivers: net: cpsw: phy-handle fixes
From: David Miller @ 2016-04-28 21:27 UTC (permalink / raw)
To: drivshin.allworx
Cc: netdev, linux-omap, linux-arm-kernel, devicetree, linux-kernel,
mugunthanvnm, grygorii.strashko, andrew.goodbody,
systemprogrammierung.brunner, kwizart
In-Reply-To: <1461805808-4102-1-git-send-email-drivshin.allworx@gmail.com>
From: "David Rivshin (Allworx)" <drivshin.allworx@gmail.com>
Date: Wed, 27 Apr 2016 21:10:03 -0400
> This series fixes a number of related issues around using phy-handle
> properties in cpsw emac nodes.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net 0/3] bpf: fix several bugs
From: David Miller @ 2016-04-28 21:30 UTC (permalink / raw)
To: ast; +Cc: daniel, jannh, torvalds, netdev, kernel-team
In-Reply-To: <1461808582-1452466-1-git-send-email-ast@fb.com>
From: Alexei Starovoitov <ast@fb.com>
Date: Wed, 27 Apr 2016 18:56:19 -0700
> First two patches address bugs found by Jann Horn.
> Last patch is a minor samples fix spotted during the testing.
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH] net: davinci_mdio: Set of_node in the mdio bus
From: J.D. Schroeder @ 2016-04-28 21:39 UTC (permalink / raw)
To: David Miller
Cc: linux-kernel, netdev, Grygorii.Strashko, jay.schroeder,
ben.mccauley
In-Reply-To: <20160428.154410.1087934312951322476.davem@davemloft.net>
On 04/28/2016 02:44 PM, David Miller wrote:
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -343,6 +343,7 @@ static int davinci_mdio_probe(struct platform_device *pdev)
>> if (davinci_mdio_probe_dt(&data->pdata, pdev))
>> data->pdata = default_pdata;
>> snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s", pdev->name);
>> + data->bus->dev.of_node = dev->of_node;
>> } else {
>> data->pdata = pdata ? (*pdata) : default_pdata;
>> snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s-%x",
>
> You can't do this.
>
> First of all, of_node objects are reference counted. So even if this was a
> legal thing to do you would have to drop the reference to the existing of_node
> pointer and gain a reference to dev->of_node.
>
> But even more importantly, it is the job of the bus driver to set that
> bus->dev.of_node correctly, you should never override it in a driver like
> this.
David, thanks for your review. I understand your point about the reference count.
One thing to note is that it is always null for the davinci mdio bus when
going through this path. I'm not trying to override it. I'm trying to make
sure it has a way to find the davinci mdio bus. Do you see the problem I'm
trying to solve?
Is there another way to be able to make the of_mdio_find_bus() call be able to
find the davinci mdio bus?
Thanks,
JD
^ permalink raw reply
* Re: [PATCH] net: davinci_mdio: Set of_node in the mdio bus
From: David Miller @ 2016-04-28 21:48 UTC (permalink / raw)
To: Linux.HWI
Cc: linux-kernel, netdev, Grygorii.Strashko, jay.schroeder,
ben.mccauley
In-Reply-To: <57228318.90600@garmin.com>
From: "J.D. Schroeder" <Linux.HWI@garmin.com>
Date: Thu, 28 Apr 2016 16:39:36 -0500
> On 04/28/2016 02:44 PM, David Miller wrote:
>>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>>> @@ -343,6 +343,7 @@ static int davinci_mdio_probe(struct platform_device *pdev)
>>> if (davinci_mdio_probe_dt(&data->pdata, pdev))
>>> data->pdata = default_pdata;
>>> snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s", pdev->name);
>>> + data->bus->dev.of_node = dev->of_node;
>>> } else {
>>> data->pdata = pdata ? (*pdata) : default_pdata;
>>> snprintf(data->bus->id, MII_BUS_ID_SIZE, "%s-%x",
>>
>> You can't do this.
>>
>> First of all, of_node objects are reference counted. So even if this was a
>> legal thing to do you would have to drop the reference to the existing of_node
>> pointer and gain a reference to dev->of_node.
>>
>> But even more importantly, it is the job of the bus driver to set that
>> bus->dev.of_node correctly, you should never override it in a driver like
>> this.
>
> David, thanks for your review. I understand your point about the reference count.
>
> One thing to note is that it is always null for the davinci mdio bus when
> going through this path. I'm not trying to override it. I'm trying to make
> sure it has a way to find the davinci mdio bus. Do you see the problem I'm
> trying to solve?
>
> Is there another way to be able to make the of_mdio_find_bus() call be able to
> find the davinci mdio bus?
You should reference the device which actually has an OF node attached with it,
rather than pretending that the MDIO bus does.
Don't fake this stuff, reference the proper device to get the OF node.
Thanks.
^ permalink raw reply
* [PATCH net-next] of: of_mdio: Check if MDIO bus controller is available
From: Florian Fainelli @ 2016-04-28 21:55 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: davem-fT/PcQaiUtIeIZ0/mPfg9Q, andrew-g2DYL2Zd6BY,
nathan.sullivan-acOepvfBmUk, nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w,
Florian Fainelli, Rob Herring, Frank Rowand, Grant Likely,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE, open list
Add a check whether the 'struct device_node' pointer passed to
of_mdiobus_register() is an available (aka enabled) node in the Device
Tree.
Rationale for doing this are cases where an Ethernet MAC provides a MDIO
bus controller and node, and an additional Ethernet MAC might be
connecting its PHY/switches to that first MDIO bus controller, while
still embedding one internally which is therefore marked as "disabled".
Instead of sprinkling checks like these in callers of
of_mdiobus_register(), do this in a central location.
Signed-off-by: Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/of/of_mdio.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/of/of_mdio.c b/drivers/of/of_mdio.c
index b622b33dbf93..2f497790be1b 100644
--- a/drivers/of/of_mdio.c
+++ b/drivers/of/of_mdio.c
@@ -209,6 +209,10 @@ int of_mdiobus_register(struct mii_bus *mdio, struct device_node *np)
bool scanphys = false;
int addr, rc;
+ /* Do not continue if the node is disabled */
+ if (!of_device_is_available(np))
+ return -EINVAL;
+
/* Mask out all PHYs from auto probing. Instead the PHYs listed in
* the device tree are populated after the bus has been registered */
mdio->phy_mask = ~0;
--
2.1.0
--
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 related
* Re: [PATCH v2 net] soreuseport: Fix TCP listener hash collision
From: Eric Dumazet @ 2016-04-28 21:59 UTC (permalink / raw)
To: Craig Gallek; +Cc: davem, netdev
In-Reply-To: <1461877661-21282-1-git-send-email-kraigatgoog@gmail.com>
On Thu, 2016-04-28 at 17:07 -0400, Craig Gallek wrote:
> From: Craig Gallek <kraig@google.com>
>
> I forgot to include a check for listener port equality when deciding
> if two sockets should belong to the same reuseport group. This was
> not caught previously because it's only necessary when two listening
> sockets for the same user happen to hash to the same listener bucket.
> This change also includes a check for network namespace equality.
> The same error does not exist in the UDP path.
>
> Fixes: c125e80b8868("soreuseport: fast reuseport TCP socket selection")
> Signed-off-by: Craig Gallek <kraig@google.com>
> ---
> v2 Changes
> - Suggestions from Eric Dumazet to include network namespace equality
> check and to avoid a dreference by simply checking inet_bind_bucket
> pointer equality.
> ---
> net/ipv4/inet_hashtables.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
> index bc68eced0105..5c5658268d5e 100644
> --- a/net/ipv4/inet_hashtables.c
> +++ b/net/ipv4/inet_hashtables.c
> @@ -470,15 +470,19 @@ static int inet_reuseport_add_sock(struct sock *sk,
> const struct sock *sk2,
> bool match_wildcard))
> {
> + struct inet_bind_bucket *tb = inet_csk(sk)->icsk_bind_hash;
> + struct net *net = sock_net(sk);
> struct sock *sk2;
> struct hlist_nulls_node *node;
> kuid_t uid = sock_i_uid(sk);
>
> sk_nulls_for_each_rcu(sk2, node, &ilb->head) {
> - if (sk2 != sk &&
> + if (net_eq(sock_net(sk2), net) &&
> + sk2 != sk &&
> sk2->sk_family == sk->sk_family &&
> ipv6_only_sock(sk2) == ipv6_only_sock(sk) &&
> sk2->sk_bound_dev_if == sk->sk_bound_dev_if &&
> + inet_csk(sk2)->icsk_bind_hash == tb &&
> sk2->sk_reuseport && uid_eq(uid, sock_i_uid(sk2)) &&
> saddr_same(sk, sk2, false))
> return reuseport_add_sock(sk, sk2);
Note that I suggested to only use "inet_csk(sk2)->icsk_bind_hash == tb"
If test is true, it means that sockets share same name space and same
port ;)
Therefore the added net_eq(sock_net(sk2), net) test is redundant.
No strong opinion, as this patch works, and this is not fast path
anyway.
Acked-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH net-next] tcp: give prequeue mode some care
From: Eric Dumazet @ 2016-04-28 22:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20160428.171514.1303373912379094235.davem@davemloft.net>
On Thu, 2016-04-28 at 17:15 -0400, David Miller wrote:
> There was a conflict due to the stats macro renaming, but that was trivial
> to resolve so I did it.
>
> Applied, thanks Eric.
Ah great, I was preparing a V2, you were fast David.
Thanks
^ 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