* Re: [net-next v2] openvswitch: Simplify do_execute_actions().
From: David Miller @ 2017-01-30 0:00 UTC (permalink / raw)
To: azhou; +Cc: netdev
In-Reply-To: <1485553528-16248-1-git-send-email-azhou@ovn.org>
From: Andy Zhou <azhou@ovn.org>
Date: Fri, 27 Jan 2017 13:45:28 -0800
> do_execute_actions() implements a worthwhile optimization: in case
> an output action is the last action in an action list, skb_clone()
> can be avoided by outputing the current skb. However, the
> implementation is more complicated than necessary. This patch
> simplify this logic.
>
> Signed-off-by: Andy Zhou <azhou@ovn.org>
> ---
> v1->v2: drop skb NULL check in do_output()
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2] net: adaptec: starfire: add checks for dma mapping errors
From: David Miller @ 2017-01-30 0:06 UTC (permalink / raw)
To: khoroshilov; +Cc: ionut, netdev, linux-kernel, ldv-project
In-Reply-To: <1485554850-7726-1-git-send-email-khoroshilov@ispras.ru>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Sat, 28 Jan 2017 01:07:30 +0300
> init_ring(), refill_rx_ring() and start_tx() don't check
> if mapping dma memory succeed.
> The patch adds the checks and failure handling.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Applied.
^ permalink raw reply
* Re: [PATCH 0/5] [net-next] net: qcom/emac:
From: David Miller @ 2017-01-30 0:07 UTC (permalink / raw)
To: timur; +Cc: netdev
In-Reply-To: <1485557028-32510-1-git-send-email-timur@codeaurora.org>
From: Timur Tabi <timur@codeaurora.org>
Date: Fri, 27 Jan 2017 16:43:42 -0600
> Although not related, these patches affect the same files, so they should
> be applied in order.
>
> The first patch cleans up logging of when the the phy driver is attached.
>
> The second patch always configures the SGMII to use autonegotiation mode.
>
> The third patch removes a redundant call to emac_mac_start().
>
> The fourth patch removes some extraneous non-functioning WOL code.
>
> The fifth patch adds an error handler for the SGMII block.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] tcp: record pkts sent and retransmistted
From: David Miller @ 2017-01-30 0:17 UTC (permalink / raw)
To: ycheng; +Cc: netdev, ncardwell, edumazet, soheil
In-Reply-To: <20170128002439.128487-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Fri, 27 Jan 2017 16:24:38 -0800
> Add two stats in SCM_TIMESTAMPING_OPT_STATS:
>
> TCP_NLA_DATA_SEGS_OUT: total data packets sent including retransmission
> TCP_NLA_TOTAL_RETRANS: total data packets retransmitted
>
> The names are picked to be consistent with corresponding fields in
> TCP_INFO. This allows applications that are using the timestamping
> API to measure latency stats to also retrive retransmission rate
> of application write.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] tcp: include locally failed retries in retransmission stats
From: David Miller @ 2017-01-30 0:17 UTC (permalink / raw)
To: ycheng; +Cc: netdev, ncardwell, edumazet, soheil
In-Reply-To: <20170128002439.128487-2-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Fri, 27 Jan 2017 16:24:39 -0800
> Currently the retransmission stats are not incremented if the
> retransmit fails locally. But we always increment the other packet
> counters that track total packet/bytes sent. Awkwardly while we
> don't count these failed retransmits in RETRANSSEGS, we do count
> them in FAILEDRETRANS.
>
> If the qdisc is dropping many packets this could under-estimate
> TCP retransmission rate substantially from both SNMP or per-socket
> TCP_INFO stats. This patch changes this by always incrementing
> retransmission stats on retransmission attempts and failures.
>
> Another motivation is to properly track retransmists in
> SCM_TIMESTAMPING_OPT_STATS. Since SCM_TSTAMP_SCHED collection is
> triggered in tcp_transmit_skb(), If tp->total_retrans is incremented
> after the function, we'll always mis-count by the amount of the
> latest retransmission.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com>
> Acked-by: Neal Cardwell <ncardwell@google.com>
> Acked-by: Eric Dumazet <edumazet@google.com>
Also applied, thank you.
^ permalink raw reply
* Re: [PATCH 0/2] pull request for net-next: batman-adv 2017-01-28
From: David Miller @ 2017-01-30 0:22 UTC (permalink / raw)
To: sw; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <20170128105651.3061-1-sw@simonwunderlich.de>
From: Simon Wunderlich <sw@simonwunderlich.de>
Date: Sat, 28 Jan 2017 11:56:49 +0100
> here is another pull request for batman-adv in net-next. One of them fixes
> a regression introduced by a patch in the previous pull request two days ago.
>
> Please pull or let me know of any problem!
Pulled, thanks Simon.
^ permalink raw reply
* Re: [PATCH net-next] net: add devm version of alloc_etherdev_mqs function
From: David Miller @ 2017-01-30 0:24 UTC (permalink / raw)
To: zajec5
Cc: pablo, andrew, joe, tom, aduyck, brouer, jarod, sd, netdev,
linux-kernel, rafal
In-Reply-To: <20170128141542.9676-1-zajec5@gmail.com>
From: Rafał Miłecki <zajec5@gmail.com>
Date: Sat, 28 Jan 2017 15:15:42 +0100
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This patch adds devm_alloc_etherdev_mqs function and devm_alloc_etherdev
> macro. These can be used for simpler netdev allocation without having to
> care about calling free_netdev.
>
> Thanks to this change drivers, their error paths and removal paths may
> get simpler by a bit.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
This looks fine, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: David Ahern @ 2017-01-30 1:29 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev, nicolas.dichtel
In-Reply-To: <588E80DB.3070209@cumulusnetworks.com>
On 1/29/17 4:55 PM, Roopa Prabhu wrote:
> On 1/29/17, 10:02 AM, David Ahern wrote:
>> On 1/28/17 6:00 PM, Roopa Prabhu wrote:
>>>> 4. Route Appends
>>>> - IPv6 allows nexthops to be appended to an existing route. In this
>>>> case one notification is sent per nexthop added
>>> thanks for listing all of these...I think you mentioned this case to me..
>>> but I don't remember now why this notification is
>>> sent per nexthop added. This is an update to an existing multipath route.
>>> so seems like the notification should be a RTM_NEWROUTE with the full RTA_MULTIPATH route
>>> (similar to route add)
>> It could be; it's a question of what should userspace get -- the full route or the change? Append to me suggests the latter - userspace is told what changed. It is simpler kernel code wise to send the full new route. The append changes were done after our conversation. ;-)
> ok, yeah. you listing all the cases here made it more simpler to understand in the context of other notifications :). I would prefer all
> RTM_NEWLINK notifications (ie new add or update to an existing route..replace/append), contain the full route via RTA_MULTIPATH.
Ok. I will send a v4 in a day or 2 (wait for more comments) with APPEND only generating 1 notification. Below response is based on this change.
>
>>
>>> Same holds for replace, I know the code might be tricky here...but the route replace
>>> is also an update to an existing multipath route and hence should be a RTM_NEWROUTE
>>> with the full multipath route (RTA_MULTIPATH) that changed (from userspace semantics POV)
>> It is. The only change on a replace is the encoding of all routes in RTA_MULTIPATH which is the point of this patch set. On successful replace, only 1 notification is sent with the full route.
> ok, good.
>>
>>> I don't have a better solution, but with the above still being different, wondering
>>> if its worth the risk changing the api for just a few notifications.
>> Data centers are moving to L3, and multipath is a big part of that. Anyone who looks at ip -6 route enough knows it gets painful mentally pulling the individual routes into a single one. In addition, using RTA_MULTIPATH is more efficient at scale.
>>
>> Furthermore, I have a follow on patch set that returns the route matched on an ip route get lookup. Returning the full multipath route is an important part to understanding the full context of the route to an address.
>
> ok, sure. If we are moving to RTA_MULTIPATH, I just want to make sure all the notifications consistently move to multipath.
>
> so, to summarize and to get on the same page as you,
> - all RTM_NEWLINK notifications will contain RTA_MULTIPATH when the route in the kernel is a multipath route:
> - since ipv6 allows add/append of a single nexthop, the notification for the first nexthop may go out without a RTA_MULTIPATH
No. I notification for all cases - new, replace, append.
> - RTM_DELETE will also contain RTA_MULTIPATH when the user tries to delete the full route with RTA_MULTIPATH
> - since ipv6 allows deleting of a single nexthop, RTM_DELETE may contain a single nexthop delete ie without RTA_MULTIPATH (this is just to continue
> supporting the single nexthop delete support that ipv6 has)
Let's give an example for each case:
1. Add - full multipath route
This route command:
ip -6 ro add vrf red 2001:db8:200::/120 nexthop via 2001:db8:1::2 nexthop via 2001:db8:2::2
generates this notification (ip -t mon ro):
2001:db8:200::/120 table red metric 1024
nexthop via 2001:db8:1::2 dev eth1 weight 1
nexthop via 2001:db8:2::2 dev eth2 weight 1
2. Delete - 1 notification for each hop for all combinations of delete commands
3. Replace - full multipath route
This route command (with the one from Add case already in place):
ip -6 ro replace vrf red 2001:db8:200::/120 nexthop via 2001:db8:1::16 nexthop via 2001:db8:2::16
generates a single notification:
Replaced 2001:db8:200::/120 table red metric 1024
nexthop via 2001:db8:1::16 dev eth1 weight 1
nexthop via 2001:db8:2::16 dev eth2 weight 1
4. Append - 1 route after all hops are appended
This append command (starting with the one installed from the Replace case):
ip -6 ro append vrf red 2001:db8:200::/120 nexthop via 2001:db8:2::20 nexthop via 2001:db8:1::20
generates a single notification:
Append 2001:db8:200::/120 table red metric 1024
nexthop via 2001:db8:2::20 dev eth2 weight 1
nexthop via 2001:db8:1::20 dev eth1 weight 1
nexthop via 2001:db8:1::16 dev eth1 weight 1
nexthop via 2001:db8:2::16 dev eth2 weight 1
(The Replaced and Append annotations are due to a local iproute2 patch; iproute2 does
not currently distinguish NEWROUTE cases.)
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: Roopa Prabhu @ 2017-01-30 2:20 UTC (permalink / raw)
To: David Ahern; +Cc: netdev, nicolas.dichtel
In-Reply-To: <71e661bd-e26d-2629-06bb-888f6a09b06d@cumulusnetworks.com>
On 1/29/17, 5:29 PM, David Ahern wrote:
[snip]
> Let's give an example for each case:
>
> 1. Add - full multipath route
>
> This route command:
> ip -6 ro add vrf red 2001:db8:200::/120 nexthop via 2001:db8:1::2 nexthop via 2001:db8:2::2
>
> generates this notification (ip -t mon ro):
>
> 2001:db8:200::/120 table red metric 1024
> nexthop via 2001:db8:1::2 dev eth1 weight 1
> nexthop via 2001:db8:2::2 dev eth2 weight 1
>
ack,
> 2. Delete - 1 notification for each hop for all combinations of delete commands
here I was trying to say, for people deleting the full multipath route, you should send a RTA_MULTIPATH.
For the odd case of ipv6 single nexthop delete, you can continue to send a single nexthop delete (like today ..without RTA_MULTIPATH)
because there is no other way to notify a single nexthop delete with a RTM_DELROUTE.
The reason I say this is because: keeping future in mind, this will make things consistent for majority of people who will
start using RTA_MULTIPATH for both ipv4 and ipv6 for adds and deletes (requests/notifications and dumps) the same way.
single next hop delete will just be around because of fear of breaking existing applications.
>
>
> 3. Replace - full multipath route
>
> This route command (with the one from Add case already in place):
> ip -6 ro replace vrf red 2001:db8:200::/120 nexthop via 2001:db8:1::16 nexthop via 2001:db8:2::16
>
> generates a single notification:
>
> Replaced 2001:db8:200::/120 table red metric 1024
> nexthop via 2001:db8:1::16 dev eth1 weight 1
> nexthop via 2001:db8:2::16 dev eth2 weight 1
ack,
>
> 4. Append - 1 route after all hops are appended
>
> This append command (starting with the one installed from the Replace case):
> ip -6 ro append vrf red 2001:db8:200::/120 nexthop via 2001:db8:2::20 nexthop via 2001:db8:1::20
>
> generates a single notification:
>
> Append 2001:db8:200::/120 table red metric 1024
> nexthop via 2001:db8:2::20 dev eth2 weight 1
> nexthop via 2001:db8:1::20 dev eth1 weight 1
> nexthop via 2001:db8:1::16 dev eth1 weight 1
> nexthop via 2001:db8:2::16 dev eth2 weight 1
>
> (The Replaced and Append annotations are due to a local iproute2 patch; iproute2 does
> not currently distinguish NEWROUTE cases.)
>
ack,
thanks
^ permalink raw reply
* Re: [PATCH 0/2] xen/net: limit number of tx/rx queues
From: Boris Ostrovsky @ 2017-01-30 2:55 UTC (permalink / raw)
To: Juergen Gross, linux-kernel, xen-devel, netdev; +Cc: paul.durrant, wei.liu2
In-Reply-To: <20170110133252.5346-1-jgross@suse.com>
On 01/10/2017 08:32 AM, Juergen Gross wrote:
> The Xen network frontend/backend supports multiple tx/rx queues for one
> virtual interface. The number of queues supported by the backend is
> set to the number of cpus of the backend driver domain (usually dom0)
> and the number of queues requested by the frontend is limited by the
> number of vcpus of the related guest.
>
> On large systems this can lead to ridiculous large number of queues
> exhausting the required number of grant pages rather quick.
>
> To avoid this limit the default maximum on both sides to 8. Both
> frontend and backend maximum can be individually tuned via module
> parameters.
>
> Juergen Gross (2):
> xen/netfront: set default upper limit of tx/rx queues to 8
> xen/netback: set default upper limit of tx/rx queues to 8
>
> drivers/net/xen-netback/netback.c | 6 ++++--
> drivers/net/xen-netfront.c | 6 ++++--
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
Applied to for-linus-4.11
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH net-next v3 0/4] net: ipv6: Improve user experience with multipath routes
From: David Ahern @ 2017-01-30 2:57 UTC (permalink / raw)
To: Roopa Prabhu; +Cc: netdev, nicolas.dichtel
In-Reply-To: <588EA2E8.2040302@cumulusnetworks.com>
On 1/29/17 7:20 PM, Roopa Prabhu wrote:
>> 2. Delete - 1 notification for each hop for all combinations of delete commands
>
> here I was trying to say, for people deleting the full multipath route, you should send a RTA_MULTIPATH.
The only way to do that is to call inet6_rt_notify() *before* the route delete work has been done in fib6_del_route. Right now it is called at the end - after all sibling associations have been dropped, a time in which it can no longer fill in RTA_MULTIPATH.
fib6_del_route function does not have any failure paths and is called with the write lock held, so moving the notification might be ok. But it also means ignoring all subsequent failures from fib6_del, again which might be ok since the only failure is ENOENT which can not happen if we are walking the sibling list.
> For the odd case of ipv6 single nexthop delete, you can continue to send a single nexthop delete (like today ..without RTA_MULTIPATH)
> because there is no other way to notify a single nexthop delete with a RTM_DELROUTE.
>
> The reason I say this is because: keeping future in mind, this will make things consistent for majority of people who will
> start using RTA_MULTIPATH for both ipv4 and ipv6 for adds and deletes (requests/notifications and dumps) the same way.
> single next hop delete will just be around because of fear of breaking existing applications.
Single next hop delete will be around because IPv6 allows it -- and because IPv4 needs to support it.
^ permalink raw reply
* [PATCH net] ipv6: Paritially checksum full MTU frames
From: Vladislav Yasevich @ 2017-01-30 3:52 UTC (permalink / raw)
To: netdev; +Cc: Vladislav Yasevich
IPv6 will mark data that is smaller that mtu - headersize as
CHECKSUM_PARTIAL, but if the data will completely fill the mtu,
the packet checksum will be computed in software instead.
Extend the conditional to include the data that fills the mtu
as well.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
---
net/ipv6/ip6_output.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 2c0df09..b6a94ff 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1344,7 +1344,7 @@ static int __ip6_append_data(struct sock *sk,
*/
if (transhdrlen && sk->sk_protocol == IPPROTO_UDP &&
headersize == sizeof(struct ipv6hdr) &&
- length < mtu - headersize &&
+ length <= mtu - headersize &&
!(flags & MSG_MORE) &&
rt->dst.dev->features & (NETIF_F_IPV6_CSUM | NETIF_F_HW_CSUM))
csummode = CHECKSUM_PARTIAL;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2 iproute2] f_flower: don't set TCA_FLOWER_KEY_ETH_TYPE for "protocol all"
From: Stephen Hemminger @ 2017-01-30 4:24 UTC (permalink / raw)
To: Benjamin LaHaise; +Cc: Jamal Hadi Salim, netdev, bcrl
In-Reply-To: <20170120190738.GA17163@nvt-d.home.kvack.org>
On Fri, 20 Jan 2017 14:07:38 -0500
Benjamin LaHaise <benjamin.lahaise@netronome.com> wrote:
> v2 - update to address changes in 00697ca19ae3e1118f2af82c3b41ac4335fe918b.
>
> When using the tc flower filter, rules marked with "protocol all" do not
> actually match all packets. This is due to a bug in f_flower.c that passes
> in ETH_P_ALL in the TCA_FLOWER_KEY_ETH_TYPE attribute when adding a rule.
> Fix this by omitting TCA_FLOWER_KEY_ETH_TYPE if the protocol is set to
> ETH_P_ALL.
>
> Fixes: 488b41d020fb ("tc: flower no need to specify the ethertype")
> Cc: Jamal Hadi Salim <jhs@mojatatu.com>
> Signed-off-by: Benjamin LaHaise <benjamin.lahaise@netronome.com>
> Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
Applied, thanks.
^ permalink raw reply
* Re: [iproute PATCH v2] man: tc-csum.8: Fix example
From: Stephen Hemminger @ 2017-01-30 4:26 UTC (permalink / raw)
To: Phil Sutter; +Cc: netdev
In-Reply-To: <20170128115910.1127-1-phil@nwl.cc>
On Sat, 28 Jan 2017 12:59:10 +0100
Phil Sutter <phil@nwl.cc> wrote:
> This fixes two issues with the provided example:
>
> - Add missing 'dev' keyword to second command.
> - Use a real IPv4 address instead of a bogus hex value since that will
> be rejected by get_addr_ipv4().
>
> Fixes: dbfb17a67f9c7 ("man: tc-csum.8: Add an example")
> Reported-by: Davide Caratti <dcaratti@redhat.com>
> Signed-off-by: Phil Sutter <phil@nwl.cc>
> ---
> Changes since v1:
> - Instead of using potentially valid IP addresses, use RFC 5737 ones.
Applied thanks
^ permalink raw reply
* [PATCH net-next v4 0/4] net: dsa: Port mirroring support
From: Florian Fainelli @ 2017-01-30 4:30 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, jiri, Florian Fainelli
Hi all,
This patch series adds support for port mirroring in the two
Broadcom switch drivers. The major part of the functional are actually with
the plumbing between tc and the drivers.
David, this will most likely conflict a little bit with my other series:
net: dsa: bcm_sf2: CFP support, so just let me know if that happens, and
I will provide a rebased version. Thanks!
Changes in v4:
- rebased against latest net-next/master after Vivien's changes
Changes in v3:
- removed multiline comments from added structures
- simplify error handling in dsa_slave_add_cls_matchall
Changes in v2:
- fixed filter removal logic to disable the ingress or egress mirroring
when there are no longer ports being monitored in ingress or egress
- removed a stray list_head in dsa_port structure that is not used
Tested using the two iproute2 examples:
# ingress
tc qdisc add dev eth1 handle ffff: ingress
tc filter add dev eth1 parent ffff: \
matchall skip_sw \
action mirred egress mirror \
dev eth2
# egress
tc qdisc add dev eth1 handle 1: root prio
tc filter add dev eth1 parent 1: \
matchall skip_sw \
action mirred egress mirror \
dev eth2
Florian Fainelli (4):
net: dsa: Add plumbing for port mirroring
net: dsa: b53: Add mirror capture register definitions
net: dsa: b53: Add support for port mirroring
net: dsa: bcm_sf2: Add support for port mirroring
drivers/net/dsa/b53/b53_common.c | 67 +++++++++++++++++++
drivers/net/dsa/b53/b53_priv.h | 4 ++
drivers/net/dsa/b53/b53_regs.h | 32 ++++++++++
drivers/net/dsa/bcm_sf2.c | 2 +
include/net/dsa.h | 33 ++++++++++
net/dsa/dsa_priv.h | 3 +
net/dsa/slave.c | 135 ++++++++++++++++++++++++++++++++++++++-
7 files changed, 275 insertions(+), 1 deletion(-)
--
2.9.3
^ permalink raw reply
* [PATCH net-next v4 1/4] net: dsa: Add plumbing for port mirroring
From: Florian Fainelli @ 2017-01-30 4:30 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, jiri, Florian Fainelli
In-Reply-To: <20170130043026.28867-1-f.fainelli@gmail.com>
Add necessary plumbing at the slave network device level to have switch
drivers implement ndo_setup_tc() and most particularly the cls_matchall
classifier. We add support for two switch operations:
port_add_mirror and port_del_mirror() which configure, on a per-port
basis the mirror parameters requested from the cls_matchall classifier.
Code is largely borrowed from the Mellanox Spectrum switch driver.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
include/net/dsa.h | 33 +++++++++++++
net/dsa/dsa_priv.h | 3 ++
net/dsa/slave.c | 137 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 172 insertions(+), 1 deletion(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index b951e2ebda75..f97f13617957 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -20,6 +20,8 @@
#include <linux/phy_fixed.h>
#include <linux/ethtool.h>
+struct tc_action;
+
enum dsa_tag_protocol {
DSA_TAG_PROTO_NONE = 0,
DSA_TAG_PROTO_DSA,
@@ -139,6 +141,28 @@ struct dsa_switch_tree {
const struct dsa_device_ops *tag_ops;
};
+/* TC matchall action types, only mirroring for now */
+enum dsa_port_mall_action_type {
+ DSA_PORT_MALL_MIRROR,
+};
+
+/* TC mirroring entry */
+struct dsa_mall_mirror_tc_entry {
+ u8 to_local_port;
+ bool ingress;
+};
+
+/* TC matchall entry */
+struct dsa_mall_tc_entry {
+ struct list_head list;
+ unsigned long cookie;
+ enum dsa_port_mall_action_type type;
+ union {
+ struct dsa_mall_mirror_tc_entry mirror;
+ };
+};
+
+
struct dsa_port {
struct dsa_switch *ds;
unsigned int index;
@@ -377,6 +401,15 @@ struct dsa_switch_ops {
int (*port_mdb_dump)(struct dsa_switch *ds, int port,
struct switchdev_obj_port_mdb *mdb,
int (*cb)(struct switchdev_obj *obj));
+
+ /*
+ * TC integration
+ */
+ int (*port_mirror_add)(struct dsa_switch *ds, int port,
+ struct dsa_mall_mirror_tc_entry *mirror,
+ bool ingress);
+ void (*port_mirror_del)(struct dsa_switch *ds, int port,
+ struct dsa_mall_mirror_tc_entry *mirror);
};
struct dsa_switch_driver {
diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 3022f2e42cdc..a5509b765fc0 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -41,6 +41,9 @@ struct dsa_slave_priv {
#ifdef CONFIG_NET_POLL_CONTROLLER
struct netpoll *netpoll;
#endif
+
+ /* TC context */
+ struct list_head mall_tc_list;
};
/* dsa.c */
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 08725286f79d..92cced9aa220 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -16,12 +16,17 @@
#include <linux/of_net.h>
#include <linux/of_mdio.h>
#include <linux/mdio.h>
+#include <linux/list.h>
#include <net/rtnetlink.h>
#include <net/switchdev.h>
+#include <net/pkt_cls.h>
+#include <net/tc_act/tc_mirred.h>
#include <linux/if_bridge.h>
#include <linux/netpoll.h>
#include "dsa_priv.h"
+static bool dsa_slave_dev_check(struct net_device *dev);
+
/* slave mii_bus handling ***************************************************/
static int dsa_slave_phy_read(struct mii_bus *bus, int addr, int reg)
{
@@ -995,6 +1000,133 @@ static int dsa_slave_get_phys_port_name(struct net_device *dev,
return 0;
}
+static struct dsa_mall_tc_entry *
+dsa_slave_mall_tc_entry_find(struct dsa_slave_priv *p,
+ unsigned long cookie)
+{
+ struct dsa_mall_tc_entry *mall_tc_entry;
+
+ list_for_each_entry(mall_tc_entry, &p->mall_tc_list, list)
+ if (mall_tc_entry->cookie == cookie)
+ return mall_tc_entry;
+
+ return NULL;
+}
+
+static int dsa_slave_add_cls_matchall(struct net_device *dev,
+ __be16 protocol,
+ struct tc_cls_matchall_offload *cls,
+ bool ingress)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_mall_tc_entry *mall_tc_entry;
+ struct dsa_switch *ds = p->dp->ds;
+ struct net *net = dev_net(dev);
+ struct dsa_slave_priv *to_p;
+ struct net_device *to_dev;
+ const struct tc_action *a;
+ int err = -EOPNOTSUPP;
+ LIST_HEAD(actions);
+ int ifindex;
+
+ if (!ds->ops->port_mirror_add)
+ return err;
+
+ if (!tc_single_action(cls->exts))
+ return err;
+
+ tcf_exts_to_list(cls->exts, &actions);
+ a = list_first_entry(&actions, struct tc_action, list);
+
+ if (is_tcf_mirred_egress_mirror(a) && protocol == htons(ETH_P_ALL)) {
+ struct dsa_mall_mirror_tc_entry *mirror;
+
+ ifindex = tcf_mirred_ifindex(a);
+ to_dev = __dev_get_by_index(net, ifindex);
+ if (!to_dev)
+ return -EINVAL;
+
+ if (!dsa_slave_dev_check(to_dev))
+ return -EOPNOTSUPP;
+
+ mall_tc_entry = kzalloc(sizeof(*mall_tc_entry), GFP_KERNEL);
+ if (!mall_tc_entry)
+ return -ENOMEM;
+
+ mall_tc_entry->cookie = cls->cookie;
+ mall_tc_entry->type = DSA_PORT_MALL_MIRROR;
+ mirror = &mall_tc_entry->mirror;
+
+ to_p = netdev_priv(to_dev);
+
+ mirror->to_local_port = to_p->dp->index;
+ mirror->ingress = ingress;
+
+ err = ds->ops->port_mirror_add(ds, p->dp->index, mirror,
+ ingress);
+ if (err) {
+ kfree(mall_tc_entry);
+ return err;
+ }
+
+ list_add_tail(&mall_tc_entry->list, &p->mall_tc_list);
+ }
+
+ return 0;
+}
+
+static void dsa_slave_del_cls_matchall(struct net_device *dev,
+ struct tc_cls_matchall_offload *cls)
+{
+ struct dsa_slave_priv *p = netdev_priv(dev);
+ struct dsa_mall_tc_entry *mall_tc_entry;
+ struct dsa_switch *ds = p->dp->ds;
+
+ if (!ds->ops->port_mirror_del)
+ return;
+
+ mall_tc_entry = dsa_slave_mall_tc_entry_find(p, cls->cookie);
+ if (!mall_tc_entry)
+ return;
+
+ list_del(&mall_tc_entry->list);
+
+ switch (mall_tc_entry->type) {
+ case DSA_PORT_MALL_MIRROR:
+ ds->ops->port_mirror_del(ds, p->dp->index,
+ &mall_tc_entry->mirror);
+ break;
+ default:
+ WARN_ON(1);
+ }
+
+ kfree(mall_tc_entry);
+}
+
+static int dsa_slave_setup_tc(struct net_device *dev, u32 handle,
+ __be16 protocol, struct tc_to_netdev *tc)
+{
+ bool ingress = TC_H_MAJ(handle) == TC_H_MAJ(TC_H_INGRESS);
+ int ret = -EOPNOTSUPP;
+
+ switch (tc->type) {
+ case TC_SETUP_MATCHALL:
+ switch (tc->cls_mall->command) {
+ case TC_CLSMATCHALL_REPLACE:
+ return dsa_slave_add_cls_matchall(dev, protocol,
+ tc->cls_mall,
+ ingress);
+ case TC_CLSMATCHALL_DESTROY:
+ dsa_slave_del_cls_matchall(dev, tc->cls_mall);
+ return 0;
+ }
+ default:
+ break;
+ }
+
+ return ret;
+}
+
void dsa_cpu_port_ethtool_init(struct ethtool_ops *ops)
{
ops->get_sset_count = dsa_cpu_port_get_sset_count;
@@ -1043,6 +1175,7 @@ static const struct net_device_ops dsa_slave_netdev_ops = {
.ndo_bridge_setlink = switchdev_port_bridge_setlink,
.ndo_bridge_dellink = switchdev_port_bridge_dellink,
.ndo_get_phys_port_name = dsa_slave_get_phys_port_name,
+ .ndo_setup_tc = dsa_slave_setup_tc,
};
static const struct switchdev_ops dsa_slave_switchdev_ops = {
@@ -1259,7 +1392,8 @@ int dsa_slave_create(struct dsa_switch *ds, struct device *parent,
if (slave_dev == NULL)
return -ENOMEM;
- slave_dev->features = master->vlan_features;
+ slave_dev->features = master->vlan_features | NETIF_F_HW_TC;
+ slave_dev->hw_features |= NETIF_F_HW_TC;
slave_dev->ethtool_ops = &dsa_slave_ethtool_ops;
eth_hw_addr_inherit(slave_dev, master);
slave_dev->priv_flags |= IFF_NO_QUEUE;
@@ -1278,6 +1412,7 @@ int dsa_slave_create(struct dsa_switch *ds, struct device *parent,
p = netdev_priv(slave_dev);
p->dp = &ds->ports[port];
+ INIT_LIST_HEAD(&p->mall_tc_list);
p->xmit = dst->tag_ops->xmit;
p->old_pause = -1;
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v4 2/4] net: dsa: b53: Add mirror capture register definitions
From: Florian Fainelli @ 2017-01-30 4:30 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, jiri, Florian Fainelli
In-Reply-To: <20170130043026.28867-1-f.fainelli@gmail.com>
Add definitions for the different Roboswitch registers relevant for
ingress and egress mirroring.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_regs.h | 32 ++++++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/drivers/net/dsa/b53/b53_regs.h b/drivers/net/dsa/b53/b53_regs.h
index dac0af4e2cd0..9fd24c418fa4 100644
--- a/drivers/net/dsa/b53/b53_regs.h
+++ b/drivers/net/dsa/b53/b53_regs.h
@@ -206,6 +206,38 @@
#define BRCM_HDR_P8_EN BIT(0) /* Enable tagging on port 8 */
#define BRCM_HDR_P5_EN BIT(1) /* Enable tagging on port 5 */
+/* Mirror capture control register (16 bit) */
+#define B53_MIR_CAP_CTL 0x10
+#define CAP_PORT_MASK 0xf
+#define BLK_NOT_MIR BIT(14)
+#define MIRROR_EN BIT(15)
+
+/* Ingress mirror control register (16 bit) */
+#define B53_IG_MIR_CTL 0x12
+#define MIRROR_MASK 0x1ff
+#define DIV_EN BIT(13)
+#define MIRROR_FILTER_MASK 0x3
+#define MIRROR_FILTER_SHIFT 14
+#define MIRROR_ALL 0
+#define MIRROR_DA 1
+#define MIRROR_SA 2
+
+/* Ingress mirror divider register (16 bit) */
+#define B53_IG_MIR_DIV 0x14
+#define IN_MIRROR_DIV_MASK 0x3ff
+
+/* Ingress mirror MAC address register (48 bit) */
+#define B53_IG_MIR_MAC 0x16
+
+/* Egress mirror control register (16 bit) */
+#define B53_EG_MIR_CTL 0x1C
+
+/* Egress mirror divider register (16 bit) */
+#define B53_EG_MIR_DIV 0x1E
+
+/* Egress mirror MAC address register (48 bit) */
+#define B53_EG_MIR_MAC 0x20
+
/* Device ID register (8 or 32 bit) */
#define B53_DEVICE_ID 0x30
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v4 4/4] net: dsa: bcm_sf2: Add support for port mirroring
From: Florian Fainelli @ 2017-01-30 4:30 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, jiri, Florian Fainelli
In-Reply-To: <20170130043026.28867-1-f.fainelli@gmail.com>
We can use b53_mirror_add and b53_mirror_del because the Starfighter 2
is register compatible in that specific case.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/bcm_sf2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
index 8eecfd227e06..3e514d7af218 100644
--- a/drivers/net/dsa/bcm_sf2.c
+++ b/drivers/net/dsa/bcm_sf2.c
@@ -1036,6 +1036,8 @@ static const struct dsa_switch_ops bcm_sf2_ops = {
.port_fdb_dump = b53_fdb_dump,
.port_fdb_add = b53_fdb_add,
.port_fdb_del = b53_fdb_del,
+ .port_mirror_add = b53_mirror_add,
+ .port_mirror_del = b53_mirror_del,
};
struct bcm_sf2_of_data {
--
2.9.3
^ permalink raw reply related
* [PATCH net-next v4 3/4] net: dsa: b53: Add support for port mirroring
From: Florian Fainelli @ 2017-01-30 4:30 UTC (permalink / raw)
To: netdev; +Cc: davem, andrew, vivien.didelot, cphealy, jiri, Florian Fainelli
In-Reply-To: <20170130043026.28867-1-f.fainelli@gmail.com>
Add support for configuring port mirroring through the cls_matchall
classifier. We do a full ingress or egress capture towards the capture
port. Future improvements could include leveraging the divider to allow
less frames to be captured, as well as matching specific MAC DA/SA.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/net/dsa/b53/b53_common.c | 67 ++++++++++++++++++++++++++++++++++++++++
drivers/net/dsa/b53/b53_priv.h | 4 +++
2 files changed, 71 insertions(+)
diff --git a/drivers/net/dsa/b53/b53_common.c b/drivers/net/dsa/b53/b53_common.c
index 3a7d16b6c3eb..8cf4801994e8 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1450,6 +1450,71 @@ static enum dsa_tag_protocol b53_get_tag_protocol(struct dsa_switch *ds)
return DSA_TAG_PROTO_NONE;
}
+int b53_mirror_add(struct dsa_switch *ds, int port,
+ struct dsa_mall_mirror_tc_entry *mirror, bool ingress)
+{
+ struct b53_device *dev = ds->priv;
+ u16 reg, loc;
+
+ if (ingress)
+ loc = B53_IG_MIR_CTL;
+ else
+ loc = B53_EG_MIR_CTL;
+
+ b53_read16(dev, B53_MGMT_PAGE, loc, ®);
+ reg &= ~MIRROR_MASK;
+ reg |= BIT(port);
+ b53_write16(dev, B53_MGMT_PAGE, loc, reg);
+
+ b53_read16(dev, B53_MGMT_PAGE, B53_MIR_CAP_CTL, ®);
+ reg &= ~CAP_PORT_MASK;
+ reg |= mirror->to_local_port;
+ reg |= MIRROR_EN;
+ b53_write16(dev, B53_MGMT_PAGE, B53_MIR_CAP_CTL, reg);
+
+ return 0;
+}
+EXPORT_SYMBOL(b53_mirror_add);
+
+void b53_mirror_del(struct dsa_switch *ds, int port,
+ struct dsa_mall_mirror_tc_entry *mirror)
+{
+ struct b53_device *dev = ds->priv;
+ bool loc_disable = false, other_loc_disable = false;
+ u16 reg, loc;
+
+ if (mirror->ingress)
+ loc = B53_IG_MIR_CTL;
+ else
+ loc = B53_EG_MIR_CTL;
+
+ /* Update the desired ingress/egress register */
+ b53_read16(dev, B53_MGMT_PAGE, loc, ®);
+ reg &= ~BIT(port);
+ if (!(reg & MIRROR_MASK))
+ loc_disable = true;
+ b53_write16(dev, B53_MGMT_PAGE, loc, reg);
+
+ /* Now look at the other one to know if we can disable mirroring
+ * entirely
+ */
+ if (mirror->ingress)
+ b53_read16(dev, B53_MGMT_PAGE, B53_EG_MIR_CTL, ®);
+ else
+ b53_read16(dev, B53_MGMT_PAGE, B53_IG_MIR_CTL, ®);
+ if (!(reg & MIRROR_MASK))
+ other_loc_disable = true;
+
+ b53_read16(dev, B53_MGMT_PAGE, B53_MIR_CAP_CTL, ®);
+ /* Both no longer have ports, let's disable mirroring */
+ if (loc_disable && other_loc_disable) {
+ reg &= ~MIRROR_EN;
+ reg &= ~mirror->to_local_port;
+ }
+ b53_write16(dev, B53_MGMT_PAGE, B53_MIR_CAP_CTL, reg);
+}
+EXPORT_SYMBOL(b53_mirror_del);
+
static const struct dsa_switch_ops b53_switch_ops = {
.get_tag_protocol = b53_get_tag_protocol,
.setup = b53_setup,
@@ -1474,6 +1539,8 @@ static const struct dsa_switch_ops b53_switch_ops = {
.port_fdb_dump = b53_fdb_dump,
.port_fdb_add = b53_fdb_add,
.port_fdb_del = b53_fdb_del,
+ .port_mirror_add = b53_mirror_add,
+ .port_mirror_del = b53_mirror_del,
};
struct b53_chip_data {
diff --git a/drivers/net/dsa/b53/b53_priv.h b/drivers/net/dsa/b53/b53_priv.h
index 9d87889728ac..a9dc90a01438 100644
--- a/drivers/net/dsa/b53/b53_priv.h
+++ b/drivers/net/dsa/b53/b53_priv.h
@@ -407,5 +407,9 @@ int b53_fdb_del(struct dsa_switch *ds, int port,
int b53_fdb_dump(struct dsa_switch *ds, int port,
struct switchdev_obj_port_fdb *fdb,
int (*cb)(struct switchdev_obj *obj));
+int b53_mirror_add(struct dsa_switch *ds, int port,
+ struct dsa_mall_mirror_tc_entry *mirror, bool ingress);
+void b53_mirror_del(struct dsa_switch *ds, int port,
+ struct dsa_mall_mirror_tc_entry *mirror);
#endif
--
2.9.3
^ permalink raw reply related
* Re: [PATCH iproute2 v5 2/4] ifstat: Add extended statistics to ifstat
From: Stephen Hemminger @ 2017-01-30 4:34 UTC (permalink / raw)
To: Nogah Frankel
Cc: netdev, roopa, roszenrami, jbenc, sergei.shtylyov, jiri, eladr,
idosch, yotamg, ogerlitz
In-Reply-To: <1485434681-33947-3-git-send-email-nogahf@mellanox.com>
On Thu, 26 Jan 2017 14:44:39 +0200
Nogah Frankel <nogahf@mellanox.com> wrote:
> Extended stats are part of the RTM_GETSTATS method. This patch adds them
> to ifstat.
> While extended stats can come in many forms, we support only the
> rtnl_link_stats64 struct for them (which is the 64 bits version of struct
> rtnl_link_stats).
> We support stats in the main nesting level, or one lower.
> The extension can be called by its name or any shorten of it. If there is
> more than one matched, the first one will be picked.
>
> To get the extended stats the flag -x <stats type> is used.
It would be better if this command used 64 bit statistics transparently
like other tools in iproute2. Transparency is always better user experience.
^ permalink raw reply
* Re: [PATCH iproute2 1/1] tc: distinguish Add/Replace action operations.
From: Stephen Hemminger @ 2017-01-30 4:27 UTC (permalink / raw)
To: Roman Mashak; +Cc: netdev, Jamal Hadi Salim
In-Reply-To: <1485093333-18317-1-git-send-email-mrv@mojatatu.com>
On Sun, 22 Jan 2017 08:55:33 -0500
Roman Mashak <mrv@mojatatu.com> wrote:
> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
> ---
> tc/m_action.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Applied, thanks
^ permalink raw reply
* Копия: Инновaциoнная сиcтema отбеливания зубoв в доmашних уcловиях
From: Ice-kids.ru интернет-магазин детской одежды из Финляндии Icepeak и Luhta @ 2017-01-30 5:16 UTC (permalink / raw)
To: netdev
Это копия сообщения, которое вы отправили Ice-kids.ru через Ice-kids.ru интернет-магазин детской одежды из Финляндии Icepeak и Luhta
Это письмо отправлено с сайта http://www.ice-kids.ru/ от:
MeriSoavyTot <netdev@vger.kernel.org>
Oгpomный выбор вариантoв отбеливания зубов зaвeдёт в тупик любoго. Каждый mетод уникалeн по-cвоeму, но нe каждый полезен для зубов. Глaвное – нe oшибиться при выборe, вeдь стоимоcть таких процeдур нe всем по кaрману!
Mы представляeм абcолютнo новый метoд, разработанный ведущими стoматолoгаmи. Его эффективнocть подтвеpждена mногoчисленными тестированиями и исследовaнияmи
<a href=https://goo.gl/XXapNU?drurrybrire>Зaказать</a>
^ permalink raw reply
* Re: [PATCH net-next v4 1/4] net: dsa: Add plumbing for port mirroring
From: Jiri Pirko @ 2017-01-30 6:36 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, davem, andrew, vivien.didelot, cphealy, jiri
In-Reply-To: <20170130043026.28867-2-f.fainelli@gmail.com>
Mon, Jan 30, 2017 at 05:30:23AM CET, f.fainelli@gmail.com wrote:
>Add necessary plumbing at the slave network device level to have switch
>drivers implement ndo_setup_tc() and most particularly the cls_matchall
>classifier. We add support for two switch operations:
>
>port_add_mirror and port_del_mirror() which configure, on a per-port
>basis the mirror parameters requested from the cls_matchall classifier.
>
>Code is largely borrowed from the Mellanox Spectrum switch driver.
>
>Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: dsa: bcm_sf2: CFP support
From: Florian Fainelli @ 2017-01-30 6:46 UTC (permalink / raw)
To: netdev; +Cc: davem, cphealy, vivien.didelot, andrew
In-Reply-To: <20170129031325.21911-1-f.fainelli@gmail.com>
On January 28, 2017 7:13:21 PM PST, Florian Fainelli <f.fainelli@gmail.com> wrote:
>Hi all,
>
>This patch series adds support for the Broadcom Compact Field Processor
>(CFP)
>which is a classification and matching engine built into most Broadcom
>switches.
>
>We support that using ethtool::rxnfc because it allows all known uses
>cases from
>the users I support to work, and more importantly, it allows the
>selection of a
>target rule index, which is later used by e.g: offloading hardware,
>this is an
>essential feature that I could not find being supported with cls_* for
>instance.
David, this needs to be rebase against net-next/master after Vivien's changes. Will post an update tomorrow. Thanks!
--
Florian
^ permalink raw reply
* Re: [PATCH V2 3/3] net: bgmac: use PHY subsystem for initializing PHY
From: Rafał Miłecki @ 2017-01-30 7:02 UTC (permalink / raw)
To: Florian Fainelli
Cc: David S . Miller, Jon Mason, Felix Fietkau, Network Development,
Rafał Miłecki
In-Reply-To: <e76bfeec-8bcd-4c9e-c5e7-5a5b50f4b36e@gmail.com>
On 29 January 2017 at 23:36, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Le 01/29/17 à 13:31, Rafał Miłecki a écrit :
>> On 29 January 2017 at 21:22, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>> On 01/29/2017 12:14 PM, Rafał Miłecki wrote:
>>>> On 01/29/2017 04:08 AM, Florian Fainelli wrote:
>>>>> On 01/28/2017 01:08 PM, Rafał Miłecki wrote:
>>>>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>>>>
>>>>>> This adds support for using bgmac with PHYs supported by standalone PHY
>>>>>> drivers. Having any PHY initialization in bgmac is hacky and shouldn't
>>>>>> be extended but rather removed if anyone has hardware to test it.
>>>>>>
>>>>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>>>>> ---
>>>>>> drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c | 10 ++++++++++
>>>>>> 1 file changed, 10 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
>>>>>> b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
>>>>>> index 9d9984999dce..6ce80cbcb48e 100644
>>>>>> --- a/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
>>>>>> +++ b/drivers/net/ethernet/broadcom/bgmac-bcma-mdio.c
>>>>>> @@ -132,6 +132,10 @@ static void bcma_mdio_phy_init(struct bgmac *bgmac)
>>>>>> struct bcma_chipinfo *ci = &bgmac->bcma.core->bus->chipinfo;
>>>>>> u8 i;
>>>>>>
>>>>>> + /* For some legacy hardware we do chipset-based PHY
>>>>>> initialization here
>>>>>> + * without even detecting PHY ID. It's hacky and should be
>>>>>> cleaned as
>>>>>> + * soon as someone can test it.
>>>>>> + */
>>>>>> if (ci->id == BCMA_CHIP_ID_BCM5356) {
>>>>>> for (i = 0; i < 5; i++) {
>>>>>> bcma_mdio_phy_write(bgmac, i, 0x1f, 0x008b);
>>>>>> @@ -140,6 +144,7 @@ static void bcma_mdio_phy_init(struct bgmac *bgmac)
>>>>>> bcma_mdio_phy_write(bgmac, i, 0x12, 0x2aaa);
>>>>>> bcma_mdio_phy_write(bgmac, i, 0x1f, 0x000b);
>>>>>> }
>>>>>> + return;
>>>>>
>>>>> That part is clearly initializing the built-in Ethernet switch's PHYs,
>>>>> and so the natural place for that would be to stick these init values
>>>>> into the Broadcom PHY driver. When b53-srab/b53_common attaches the
>>>>> switch, it will scan all of these port's builtin PHYs and bind to an
>>>>> appropriate PHY driver which could have this initialization as part of
>>>>> the config_init routine for instance. Right now, we are most likely
>>>>> using the Generic PHY.
>>>>
>>>> I don't think this code is for switch's PHYs. I believe this code is for
>>>> wireless access points that have no switch and have Ethernet interface
>>>> connected
>>>> directly to some single-port PHY. I saw 2 or 3 devices like this. They
>>>> often
>>>> also use PoE.
>>>
>>> Humm, built-in PHYs would typically appear as 0-5 on the MDIO bus,
>>> whereas external PHYs would have a different (and non conflicting)
>>> address, also, there are restrictions on the Roboswitch devices as to
>>> where you could wire these external PHYs (to port 5, or 7, 8).
>>
>> From BCM47186B0:
>> [ 0.942419] bgmac_bcma bcma0:2: Found PHY addr: 25
>>
>> From BCM47189:
>> [ 1.758079] bgmac_bcma bcma0:5: Found PHY addr: 0
>
> Address 0 is usually a broadcast address, although with most Broadcom
> switches, it just maps to the first port's built-in PHY.
>
>>
>> I got one more AP device but I bricked it by corrupting NVRAM
>> (bootloader doesn't start due to that).
>>
>>
>> My BCM47186B0 seems to not have any switch. It isn't that clear in
>> BCM47189 case. You may be right, some sources say BCM47189 has
>> built-in switch so maybe it's indeed BCM54210E connected to switch's
>> port. On the other hand I'm not using any switch driver on my BCM47189
>> AP board, so how does it work? Just an accidentally working setup left
>> by the bootloader?
>
> That's what I suspect is happening yes. Do you have the different FCC
> IDs of these routers so maybe looking at pictures of the inside would
> tell us what kind of internal vs. external PHYs are populated?
I don't. I read all chipset IDs I could see:
1) 2 Winbond RAM chips
2) MXIC MX25L25635F flash
3) BCM47189 SoC
4) B50212E PHY
5) BCM43217 WiFi
There clearly isn't external switch (like BCM43125 or so) but we can't
say (even from the photos) where that B50212E is connected to. It's
most likely built-in switch's port as you said.
--
Rafał
^ 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