* [patch net-next 1/9] mlxsw: pci: Add lag related resources to resources query
From: Jiri Pirko @ 2016-09-20 9:16 UTC (permalink / raw)
To: netdev; +Cc: davem, nogahf, idosch, eladr, yotamg, ogerlitz
In-Reply-To: <1474363017-2901-1-git-send-email-jiri@resnulli.us>
From: Nogah Frankel <nogahf@mellanox.com>
Add max lag and max ports in lag resources to resources query.
Signed-off-by: Nogah Frankel <nogahf@mellanox.com>
Reviewed-by: Ido Schimmel <idosch@mellanox.com>
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
drivers/net/ethernet/mellanox/mlxsw/core.h | 6 +++++-
drivers/net/ethernet/mellanox/mlxsw/pci.c | 10 ++++++++++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core.h b/drivers/net/ethernet/mellanox/mlxsw/core.h
index d2e3297..51f27a3 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/core.h
@@ -269,8 +269,12 @@ struct mlxsw_driver {
};
struct mlxsw_resources {
- u8 max_span_valid:1;
+ u8 max_span_valid:1,
+ max_lag_valid:1,
+ max_ports_in_lag_valid:1;
u8 max_span;
+ u8 max_lag;
+ u8 max_ports_in_lag;
};
struct mlxsw_resources *mlxsw_core_resources_get(struct mlxsw_core *mlxsw_core);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/pci.c b/drivers/net/ethernet/mellanox/mlxsw/pci.c
index 1d1360c..cb284ea 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/pci.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/pci.c
@@ -1156,6 +1156,8 @@ mlxsw_pci_config_profile_swid_config(struct mlxsw_pci *mlxsw_pci,
#define MLXSW_RESOURCES_TABLE_END_ID 0xffff
#define MLXSW_MAX_SPAN_ID 0x2420
+#define MLXSW_MAX_LAG_ID 0x2520
+#define MLXSW_MAX_PORTS_IN_LAG_ID 0x2521
#define MLXSW_RESOURCES_QUERY_MAX_QUERIES 100
#define MLXSW_RESOURCES_PER_QUERY 32
@@ -1167,6 +1169,14 @@ static void mlxsw_pci_resources_query_parse(int id, u64 val,
resources->max_span = val;
resources->max_span_valid = 1;
break;
+ case MLXSW_MAX_LAG_ID:
+ resources->max_lag = val;
+ resources->max_lag_valid = 1;
+ break;
+ case MLXSW_MAX_PORTS_IN_LAG_ID:
+ resources->max_ports_in_lag = val;
+ resources->max_ports_in_lag_valid = 1;
+ break;
default:
break;
}
--
2.5.5
^ permalink raw reply related
* [patch net-next 0/9] mlxsw: Replace Hw related const with resource query results
From: Jiri Pirko @ 2016-09-20 9:16 UTC (permalink / raw)
To: netdev; +Cc: davem, nogahf, idosch, eladr, yotamg, ogerlitz
From: Jiri Pirko <jiri@mellanox.com>
Nogah says:
Many of the ASIC's properties can be read from the HW with resources query.
This patchset adds new resources to the resource query and implement
using them, instead of the constants that we currently use.
Those resources are lag, kvd and router related.
Nogah Frankel (9):
mlxsw: pci: Add lag related resources to resources query
mlxsw: spectrum: lag resources- use resources data instead of consts
mlxsw: pci: Add KVD size relate resources
mlxsw: profile: Add KVD resources to profile config
mlxsw: pci: Add max virtual routers resource
mlxsw: spectrum: Implement max virtual routers resource
mlxsw: pci: Add some miscellaneous resources
mlxsw: pci: Add max router interface resource
mlxsw: spectrum: Implement max rif resource
drivers/net/ethernet/mellanox/mlxsw/core.c | 26 ++--
drivers/net/ethernet/mellanox/mlxsw/core.h | 41 +++++--
drivers/net/ethernet/mellanox/mlxsw/pci.c | 135 +++++++++++++++++----
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 67 ++++++----
drivers/net/ethernet/mellanox/mlxsw/spectrum.h | 21 ++--
.../net/ethernet/mellanox/mlxsw/spectrum_router.c | 74 +++++++++--
.../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 4 +-
drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 4 -
8 files changed, 276 insertions(+), 96 deletions(-)
--
2.5.5
^ permalink raw reply
* [PATCH iproute2] ipmonitor: fix ip monitor can't work when NET_NS is not enabled
From: Liping Zhang @ 2016-09-20 9:09 UTC (permalink / raw)
To: stephen; +Cc: netdev, nicolas.dichtel, Liping Zhang
From: Liping Zhang <liping.zhang@spreadtrum.com>
In ip monitor, netns_map_init will check getnsid is supported or not.
But when /proc/self/ns/net does not exist, we just print out error
messages and exit. So user cannot use ip monitor anymore when
CONFIG_NET_NS is disabled:
# ip monitor
open("/proc/self/ns/net"): No such file or directory
If open "/proc/self/ns/net" failed, set have_rtnl_getnsid to false.
Fixes: d652ccbf8195 ("netns: allow to dump and monitor nsid")
Signed-off-by: Liping Zhang <liping.zhang@spreadtrum.com>
---
ip/ipnetns.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/ipnetns.c b/ip/ipnetns.c
index af87065..ccc652c 100644
--- a/ip/ipnetns.c
+++ b/ip/ipnetns.c
@@ -72,8 +72,8 @@ static int ipnetns_have_nsid(void)
if (have_rtnl_getnsid < 0) {
fd = open("/proc/self/ns/net", O_RDONLY);
if (fd < 0) {
- perror("open(\"/proc/self/ns/net\")");
- exit(1);
+ have_rtnl_getnsid = 0;
+ return 0;
}
addattr32(&req.n, 1024, NETNSA_FD, fd);
--
1.9.1
^ permalink raw reply related
* XDP (eXpress Data Path) documentation
From: Jesper Dangaard Brouer via iovisor-dev @ 2016-09-20 9:08 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iovisor-dev-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org
Cc: Jonathan Corbet, Nathan Willis, Alexei Starovoitov, Tom Herbert,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Saeed Mahameed
Hi all,
As promised, I've started documenting the XDP eXpress Data Path):
[1] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/index.html
IMHO the documentation have reached a stage where it is useful for the
XDP project, BUT I request collaboration on improving the documentation
from all. (Native English speakers are encouraged to send grammar fixes ;-))
You wouldn't believe it: But this pretty looking documentation actually
follows the new Kernel documentation format. It is actually just
".rst" text files stored in my github repository under kernel/Documentation [2]
[2] https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/Documentation
Thus, just git clone my repository and started editing and send me
patches (or github pull requests). Like:
$ git clone https://github.com/netoptimizer/prototype-kernel
$ cd prototype-kernel/kernel/Documentation/
$ make html
$ firefox _build/html/index.html &
This new documentation format combines the best of two worlds, pretty
online browser documentation with almost plain text files, and changes
being tracked via git commits [3] (and auto git hooks to generate the
readthedocs.org page). You got to love it! :-)
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
[3] https://github.com/netoptimizer/prototype-kernel/commits/master
^ permalink raw reply
* [PATCH net] ipmr, ip6mr: return lastuse relative to now
From: Nikolay Aleksandrov @ 2016-09-20 9:06 UTC (permalink / raw)
To: netdev; +Cc: roopa, sashok, davem, Nikolay Aleksandrov
When I introduced the lastuse member I made a subtle error because it was
returned as an absolute value but that is meaningless to user-space as it
doesn't allow to see how old exactly an entry is. Let's make it similar to
how the bridge returns such values and make it relative to "now" (jiffies).
This allows us to show the actual age of the entries and is much more
useful (e.g. user-space daemons can age out entries, iproute2 can display
the lastuse properly).
Fixes: 43b9e1274060 ("net: ipmr/ip6mr: add support for keeping an entry age")
Reported-by: Satish Ashok <sashok@cumulusnetworks.com>
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
I realize that this changes the way it is exported, but since it hasn't
been in a release yet and we're most probably the only users, I think it is
worth fixing. This change allows user-space daemons to age out entries and
also for the lastuse value to be shown properly via iproute2.
net/ipv4/ipmr.c | 3 ++-
net/ipv6/ip6mr.c | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 26253328d227..1505a0e37f44 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -2110,7 +2110,8 @@ static int __ipmr_fill_mroute(struct mr_table *mrt, struct sk_buff *skb,
mfcs.mfcs_wrong_if = c->mfc_un.res.wrong_if;
if (nla_put_64bit(skb, RTA_MFC_STATS, sizeof(mfcs), &mfcs, RTA_PAD) ||
nla_put_u64_64bit(skb, RTA_EXPIRES,
- jiffies_to_clock_t(c->mfc_un.res.lastuse),
+ jiffies_to_clock_t(jiffies -
+ c->mfc_un.res.lastuse),
RTA_PAD))
return -EMSGSIZE;
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 6122f9c5cc49..c35d56c5ecc9 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -2274,7 +2274,8 @@ static int __ip6mr_fill_mroute(struct mr6_table *mrt, struct sk_buff *skb,
mfcs.mfcs_wrong_if = c->mfc_un.res.wrong_if;
if (nla_put_64bit(skb, RTA_MFC_STATS, sizeof(mfcs), &mfcs, RTA_PAD) ||
nla_put_u64_64bit(skb, RTA_EXPIRES,
- jiffies_to_clock_t(c->mfc_un.res.lastuse),
+ jiffies_to_clock_t(jiffies -
+ c->mfc_un.res.lastuse),
RTA_PAD))
return -EMSGSIZE;
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next 0/5] mlx4 misc fixes and improvements
From: David Miller @ 2016-09-20 9:02 UTC (permalink / raw)
To: tariqt; +Cc: gerlitz.or, netdev, eranbe
In-Reply-To: <6bcc5e49-2204-242a-c939-2352d0646f87@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Tue, 20 Sep 2016 11:50:17 +0300
>> So when we're pretty late in the 4.8-rc cycle, a fix for a problem
>> which was not introduced in 4.8-rc1 was targeted to net-next (4.9) and
>> not net.
>>
>> This indeed creates a small mess when the fix needs to go to -stable
>> as well.
...
> I see that the series status is 'Changes requested'.
> I agree with Or. If possible, please take the series, and we will
> issue a request to push into -stable in the future.
> Anyway, I can also do a re-submission if you prefer. Just let me know.
Either the bug exists in pre-net trees and needs to go to -stable, or
it does not.
If it does, you submit the change targetting 'net'.
This whole mess occurred because you tried to combine changes
inappropriate for 'net' with the bug fix.
Instead of fixing the issue properly, by removing the cleanups
and inappropriate changes, you tried to target 'net-next' instead.
That's why this mess exists.
Please send the change properly, targetting 'net', and not
alongside changes which are inappropriate to 'net'.
There is no other acceptable way to resolve this problem.
Thank you.
^ permalink raw reply
* Re: [net-next PATCH V2] mlx4: add missed recycle opportunity for XDP_TX on TX failure
From: David Miller @ 2016-09-20 8:58 UTC (permalink / raw)
To: brouer; +Cc: netdev, tariqt, eric.dumazet, tom, bblanco, rana.shahot
In-Reply-To: <20160919154556.10965.75722.stgit@firesoul>
From: Jesper Dangaard Brouer <brouer@redhat.com>
Date: Mon, 19 Sep 2016 17:46:38 +0200
> Correct drop handling for XDP_TX on TX failure, were recently added in
> commit 95357907ae73 ("mlx4: fix XDP_TX is acting like XDP_PASS on TX
> ring full").
>
> The change missed an opportunity for recycling the RX page, instead of
> going through the page allocator, like the regular XDP_DROP action does.
> This patch cease the opportunity, by going through the XDP_DROP case.
>
> Fixes: 95357907ae73 ("mlx4: fix XDP_TX is acting like XDP_PASS on TX ring full")
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> Reviewed-by: Tariq Toukan <tariqt@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2] qed: Fix stack corruption on probe
From: David Miller @ 2016-09-20 8:57 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev, David.Laight, Yuval.Mintz
In-Reply-To: <1474296461-22558-1-git-send-email-Yuval.Mintz@qlogic.com>
From: Yuval Mintz <Yuval.Mintz@qlogic.com>
Date: Mon, 19 Sep 2016 17:47:41 +0300
> Commit fe56b9e6a8d95 ("qed: Add module with basic common support")
> has introduced a stack corruption during probe, where filling a
> local struct with data to be sent to management firmware is incorrectly
> filled; The data is written outside of the struct and corrupts
> the stack.
>
> Changes from v1:
> ----------------
> - Correct the value written [Caught by David Laight]
>
> Fixes: fe56b9e6a8d95 ("qed: Add module with basic common support")
> Signed-off-by: Yuval Mintz <Yuval.Mintz@caviumnetworks.com>
Applied, thanks.
^ permalink raw reply
* [net-next:master 249/416] emac.c:undefined reference to `bad_dma_ops'
From: kbuild test robot @ 2016-09-20 8:48 UTC (permalink / raw)
To: Timur Tabi; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 2327 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: 878786d95e07ce2f5fb6e3cd8a6c2ed320339196
commit: b9b17debc69d27cd55e21ee51a5ba7fc50a426cf [249/416] net: emac: emac gigabit ethernet controller driver
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout b9b17debc69d27cd55e21ee51a5ba7fc50a426cf
# save the attached .config to linux build tree
make.cross ARCH=m32r
All errors (new ones prefixed by >>):
drivers/built-in.o: In function `emac_probe':
>> emac.c:(.text+0x3de178): undefined reference to `bad_dma_ops'
emac.c:(.text+0x3de180): undefined reference to `bad_dma_ops'
drivers/built-in.o: In function `emac_tx_q_descs_free':
>> emac-mac.c:(.text+0x3de924): undefined reference to `bad_dma_ops'
emac-mac.c:(.text+0x3de928): undefined reference to `bad_dma_ops'
drivers/built-in.o: In function `emac_rx_q_free_descs':
emac-mac.c:(.text+0x3de9f8): undefined reference to `bad_dma_ops'
drivers/built-in.o:emac-mac.c:(.text+0x3de9fc): more undefined references to `bad_dma_ops' follow
sound/built-in.o: In function `snd_pcm_lib_default_mmap':
(.text+0xfc64): undefined reference to `dma_common_mmap'
sound/built-in.o: In function `snd_pcm_lib_default_mmap':
(.text+0xfc64): relocation truncated to fit: R_M32R_26_PCREL_RELA against undefined symbol `dma_common_mmap'
sound/built-in.o: In function `cygnus_pcm_preallocate_dma_buffer':
cygnus-pcm.c:(.text+0x10fff0): undefined reference to `bad_dma_ops'
cygnus-pcm.c:(.text+0x10fff4): undefined reference to `bad_dma_ops'
cygnus-pcm.c:(.text+0x110028): undefined reference to `bad_dma_ops'
sound/built-in.o: In function `cygnus_dma_free_dma_buffers':
cygnus-pcm.c:(.text+0x110128): undefined reference to `bad_dma_ops'
cygnus-pcm.c:(.text+0x110130): undefined reference to `bad_dma_ops'
sound/built-in.o:cygnus-pcm.c:(.text+0x1101c8): more undefined references to `bad_dma_ops' follow
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 36412 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] net-next: dsa: set_addr should be optional
From: David Miller @ 2016-09-20 8:48 UTC (permalink / raw)
To: john; +Cc: andrew, f.fainelli, netdev, linux-kernel
In-Reply-To: <1474291683-44167-1-git-send-email-john@phrozen.org>
From: John Crispin <john@phrozen.org>
Date: Mon, 19 Sep 2016 15:27:59 +0200
> The Marvell driver is the only one that actually sets the switches HW
> address. All other drivers have an empty stub. fix this by making the
> callback optional.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net-next] net: phy: Add MAC-IF driver for Microsemi PHYs.
From: David Miller @ 2016-09-20 8:41 UTC (permalink / raw)
To: Raju.Lakkaraju; +Cc: netdev, f.fainelli, Allan.Nielsen, andrew
In-Reply-To: <1474279434-14583-1-git-send-email-Raju.Lakkaraju@microsemi.com>
From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Date: Mon, 19 Sep 2016 15:33:54 +0530
> From: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
>
> All the review comments updated and resending for review.
>
> This is MAC interface feature.
> Microsemi PHY can support RGMII, RMII or GMII/MII interface between MAC and PHY.
> MAC-IF function program the right value based on Device tree configuration.
>
> Tested on Beaglebone Black with VSC 8531 PHY.
>
> Signed-off-by: Raju Lakkaraju <Raju.Lakkaraju@microsemi.com>
Applied.
^ permalink raw reply
* Re: [v3 PATCH 0/2] rhashtable: rhashtable with duplicate objects
From: David Miller @ 2016-09-20 8:44 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, tgraf-G/eBtMaohhA,
tom-BjP2VixgY4xUbtYUoyoikg, greearb-my8/4N5VtI7c+919tysfdA
In-Reply-To: <1474284732.6544.2.camel-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Mon, 19 Sep 2016 13:32:12 +0200
> On Mon, 2016-09-19 at 13:03 +0200, Johannes Berg wrote:
>> On Mon, 2016-09-19 at 18:58 +0800, Herbert Xu wrote:
>> >
>> > v3 fixes a bug in the remove path that causes the element count
>> > to decrease when it shouldn't, leading to a gigantic hash table
>> > when it underflows.
>> >
>> Ok, with the BUG_ON() thrown in, this works in the test that was
>> failing before. I'll run the entire suite again over lunch.
>>
>
> Ok, the entire test suite passed (with the BUG_ON, but hey).
>
> Dave, let me know what you want to do (or have done, as it may be).
I'll apply this directly to net-next and push it out after some
build testing.
Thanks guys.
^ permalink raw reply
* Re: [PATCH net-next v3] xen-netfront: avoid packet loss when ethernet header crosses page boundary
From: David Miller @ 2016-09-20 8:41 UTC (permalink / raw)
To: vkuznets
Cc: jgross, ptalbert, netdev, linux-kernel, david.vrabel, xen-devel,
boris.ostrovsky
In-Reply-To: <1474282420-9723-1-git-send-email-vkuznets@redhat.com>
From: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: Mon, 19 Sep 2016 12:53:40 +0200
> Small packet loss is reported on complex multi host network configurations
> including tunnels, NAT, ... My investigation led me to the following check
> in netback which drops packets:
>
> if (unlikely(txreq.size < ETH_HLEN)) {
> netdev_err(queue->vif->dev,
> "Bad packet size: %d\n", txreq.size);
> xenvif_tx_err(queue, &txreq, extra_count, idx);
> break;
> }
>
> But this check itself is legitimate. SKBs consist of a linear part (which
> has to have the ethernet header) and (optionally) a number of frags.
> Netfront transmits the head of the linear part up to the page boundary
> as the first request and all the rest becomes frags so when we're
> reconstructing the SKB in netback we can't distinguish between original
> frags and the 'tail' of the linear part. The first SKB needs to be at
> least ETH_HLEN size. So in case we have an SKB with its linear part
> starting too close to the page boundary the packet is lost.
>
> I see two ways to fix the issue:
> - Change the 'wire' protocol between netfront and netback to start keeping
> the original SKB structure. We'll have to add a flag indicating the fact
> that the particular request is a part of the original linear part and not
> a frag. We'll need to know the length of the linear part to pre-allocate
> memory.
> - Avoid transmitting SKBs with linear parts starting too close to the page
> boundary. That seems preferable short-term and shouldn't bring
> significant performance degradation as such packets are rare. That's what
> this patch is trying to achieve with skb_copy().
>
> Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
> Acked-by: David Vrabel <david.vrabel@citrix.com>
Applied.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [patch net-next] mlxsw: spectrum: Fix sparse warnings
From: David Miller @ 2016-09-20 8:33 UTC (permalink / raw)
To: jiri; +Cc: netdev, idosch, eladr, yotamg, nogahf, ogerlitz
In-Reply-To: <1474266566-5780-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 19 Sep 2016 08:29:26 +0200
> From: Ido Schimmel <idosch@mellanox.com>
>
...
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [patch net-next] mlxsw: Change the RX LAG hash function from XOR to CRC
From: David Miller @ 2016-09-20 8:33 UTC (permalink / raw)
To: jiri; +Cc: netdev, eladr, idosch, yotamg, nogahf, ogerlitz
In-Reply-To: <1474266504-5723-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 19 Sep 2016 08:28:24 +0200
> From: Elad Raz <eladr@mellanox.com>
>
> Change the RX hash function from XOR to CRC in order to have better
> distribution of the traffic.
>
> Signed-off-by: Elad Raz <eladr@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 7/8] net/mlx5e: XDP TX forwarding support
From: Jesper Dangaard Brouer @ 2016-09-20 8:29 UTC (permalink / raw)
To: Tariq Toukan
Cc: David S. Miller, netdev, Eran Ben Elisha, Saeed Mahameed,
Rana Shahout
In-Reply-To: <1474293539-2595-8-git-send-email-tariqt@mellanox.com>
On Mon, 19 Sep 2016 16:58:58 +0300 Tariq Toukan <tariqt@mellanox.com> wrote:
> + act = bpf_prog_run_xdp(prog, &xdp);
> + switch (act) {
> + case XDP_PASS:
> + return false;
> + case XDP_TX:
> + consumed = mlx5e_xmit_xdp_frame(&rq->channel->xdp_sq, di,
> + MLX5_RX_HEADROOM,
> + len);
> + rq->stats.xdp_tx += consumed;
> + return consumed;
> + default:
> + bpf_warn_invalid_xdp_action(act);
> + return false;
This looks wrong. According to the specification[1] and comment in the
code /include/uapi/linux/bpf.h: "Unknown return codes will result in
packet drop"
> + case XDP_ABORTED:
It is not clearly defined, but I believe XDP_ABORTED should also result
in a warning (calling bpf_warn_invalid_xdp_action(act)).
> + case XDP_DROP:
> + rq->stats.xdp_drop++;
> + mlx5e_page_release(rq, di, true);
> + return true;
> + }
I've started documenting XDP[2], as this patch clearly shows there is a
need to have a specification, given already the second driver
supporting XDP gets these details wrong.
[1] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/implementation/xdp_actions.html#xdp-aborted
[2] https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/index.html
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* [PATCH net 4/5] r8152: remove r8153_enable_eee
From: Hayes Wang @ 2016-09-20 8:22 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-219-Taiwan-albertk@realtek.com>
Remove r8153_enable_eee().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 9ce5bd5..e7a05dd 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2803,12 +2803,6 @@ static void r8153_eee_en(struct r8152 *tp, bool enable)
ocp_reg_write(tp, OCP_EEE_CFG, config);
}
-static void r8153_enable_eee(struct r8152 *tp)
-{
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
-}
-
static void r8153_hw_phy_cfg(struct r8152 *tp)
{
u32 ocp_data;
@@ -2843,7 +2837,9 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
- r8153_enable_eee(tp);
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+
r8153_aldps_en(tp, true);
r8152b_enable_fc(tp);
--
2.7.4
^ permalink raw reply related
* [PATCH net 5/5] r8152: disable ALDPS and EEE before setting PHY
From: Hayes Wang @ 2016-09-20 8:22 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-219-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Disable ALDPS and EEE to avoid the possible failure when setting the PHY.
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index e7a05dd..3c3cdb4 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -32,7 +32,7 @@
#define NETNEXT_VERSION "08"
/* Information for net */
-#define NET_VERSION "5"
+#define NET_VERSION "6"
#define DRIVER_VERSION "v1." NETNEXT_VERSION "." NET_VERSION
#define DRIVER_AUTHOR "Realtek linux nic maintainers <nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>"
@@ -2808,6 +2808,13 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
u32 ocp_data;
u16 data;
+ /* disable ALDPS before updating the PHY parameters */
+ r8153_aldps_en(tp, false);
+
+ /* disable EEE before updating the PHY parameters */
+ r8153_eee_en(tp, false);
+ ocp_reg_write(tp, OCP_EEE_ADV, 0);
+
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
data &= ~CTAP_SHORT_EN;
@@ -3390,7 +3397,6 @@ static void r8153_init(struct r8152 *tp)
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return;
- r8153_aldps_en(tp, false);
r8153_u1u2en(tp, false);
for (i = 0; i < 500; i++) {
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH net 3/5] r8152: move PHY settings to hw_phy_cfg
From: Hayes Wang @ 2016-09-20 8:22 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-219-Taiwan-albertk@realtek.com>
Move the PHY relative settings together to hw_phy_cfg().
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index dbf11ba..9ce5bd5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2632,6 +2632,10 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
+ r8152b_enable_eee(tp);
+ r8152_aldps_en(tp, true);
+ r8152b_enable_fc(tp);
+
set_bit(PHY_RESET, &tp->flags);
}
@@ -2839,6 +2843,10 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
sram_write(tp, SRAM_10M_AMP1, 0x00af);
sram_write(tp, SRAM_10M_AMP2, 0x0208);
+ r8153_enable_eee(tp);
+ r8153_aldps_en(tp, true);
+ r8152b_enable_fc(tp);
+
set_bit(PHY_RESET, &tp->flags);
}
@@ -3369,9 +3377,6 @@ static void r8152b_init(struct r8152 *tp)
SPDWN_RXDV_MSK | SPDWN_LINKCHG_MSK;
ocp_write_word(tp, MCU_TYPE_PLA, PLA_GPHY_INTR_IMR, ocp_data);
- r8152b_enable_eee(tp);
- r8152_aldps_en(tp, true);
- r8152b_enable_fc(tp);
rtl_tally_reset(tp);
/* enable rx aggregation */
@@ -3490,9 +3495,6 @@ static void r8153_init(struct r8152 *tp)
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL3, 0);
ocp_write_word(tp, MCU_TYPE_PLA, PLA_MAC_PWR_CTRL4, 0);
- r8153_enable_eee(tp);
- r8153_aldps_en(tp, true);
- r8152b_enable_fc(tp);
rtl_tally_reset(tp);
r8153_u2p3en(tp, true);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net 2/5] r8152: move enabling PHY
From: Hayes Wang @ 2016-09-20 8:22 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-219-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Move enabling PHY to init(), otherwise some other settings may fail.
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 43 +++++++++++++++++++++++++------------------
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index ae7db46..dbf11ba 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2632,14 +2632,6 @@ static void rtl8152_disable(struct r8152 *tp)
static void r8152b_hw_phy_cfg(struct r8152 *tp)
{
- u16 data;
-
- data = r8152_mdio_read(tp, MII_BMCR);
- if (data & BMCR_PDOWN) {
- data &= ~BMCR_PDOWN;
- r8152_mdio_write(tp, MII_BMCR, data);
- }
-
set_bit(PHY_RESET, &tp->flags);
}
@@ -2818,16 +2810,6 @@ static void r8153_hw_phy_cfg(struct r8152 *tp)
u32 ocp_data;
u16 data;
- if (tp->version == RTL_VER_03 || tp->version == RTL_VER_04 ||
- tp->version == RTL_VER_05)
- ocp_reg_write(tp, OCP_ADC_CFG, CKADSEL_L | ADC_EN | EN_EMI_L);
-
- data = r8152_mdio_read(tp, MII_BMCR);
- if (data & BMCR_PDOWN) {
- data &= ~BMCR_PDOWN;
- r8152_mdio_write(tp, MII_BMCR, data);
- }
-
if (tp->version == RTL_VER_03) {
data = ocp_reg_read(tp, OCP_EEE_CFG);
data &= ~CTAP_SHORT_EN;
@@ -3355,10 +3337,17 @@ static void rtl_tally_reset(struct r8152 *tp)
static void r8152b_init(struct r8152 *tp)
{
u32 ocp_data;
+ u16 data;
if (test_bit(RTL8152_UNPLUG, &tp->flags))
return;
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data & BMCR_PDOWN) {
+ data &= ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
+
r8152_aldps_en(tp, false);
if (tp->version == RTL_VER_01) {
@@ -3394,6 +3383,7 @@ static void r8152b_init(struct r8152 *tp)
static void r8153_init(struct r8152 *tp)
{
u32 ocp_data;
+ u16 data;
int i;
if (test_bit(RTL8152_UNPLUG, &tp->flags))
@@ -3416,6 +3406,23 @@ static void r8153_init(struct r8152 *tp)
msleep(20);
}
+ if (tp->version == RTL_VER_03 || tp->version == RTL_VER_04 ||
+ tp->version == RTL_VER_05)
+ ocp_reg_write(tp, OCP_ADC_CFG, CKADSEL_L | ADC_EN | EN_EMI_L);
+
+ data = r8152_mdio_read(tp, MII_BMCR);
+ if (data & BMCR_PDOWN) {
+ data &= ~BMCR_PDOWN;
+ r8152_mdio_write(tp, MII_BMCR, data);
+ }
+
+ for (i = 0; i < 500; i++) {
+ ocp_data = ocp_reg_read(tp, OCP_PHY_STATUS) & PHY_STAT_MASK;
+ if (ocp_data == PHY_STAT_LAN_ON)
+ break;
+ msleep(20);
+ }
+
usb_disable_lpm(tp->udev);
r8153_u2p3en(tp, false);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH net 1/5] r8152: move some functions
From: Hayes Wang @ 2016-09-20 8:22 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-219-Taiwan-albertk@realtek.com>
Move the following functions forward.
r8152_mmd_indirect()
r8152_mmd_read()
r8152_mmd_write()
r8152_eee_en()
r8152b_enable_eee()
r8153_eee_en()
r8153_enable_eee()
r8152b_enable_fc()
r8153_aldps_en()
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 224 ++++++++++++++++++++++++------------------------
1 file changed, 112 insertions(+), 112 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f41a8ad..ae7db46 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2552,6 +2552,77 @@ static void r8152_aldps_en(struct r8152 *tp, bool enable)
}
}
+static inline void r8152_mmd_indirect(struct r8152 *tp, u16 dev, u16 reg)
+{
+ ocp_reg_write(tp, OCP_EEE_AR, FUN_ADDR | dev);
+ ocp_reg_write(tp, OCP_EEE_DATA, reg);
+ ocp_reg_write(tp, OCP_EEE_AR, FUN_DATA | dev);
+}
+
+static u16 r8152_mmd_read(struct r8152 *tp, u16 dev, u16 reg)
+{
+ u16 data;
+
+ r8152_mmd_indirect(tp, dev, reg);
+ data = ocp_reg_read(tp, OCP_EEE_DATA);
+ ocp_reg_write(tp, OCP_EEE_AR, 0x0000);
+
+ return data;
+}
+
+static void r8152_mmd_write(struct r8152 *tp, u16 dev, u16 reg, u16 data)
+{
+ r8152_mmd_indirect(tp, dev, reg);
+ ocp_reg_write(tp, OCP_EEE_DATA, data);
+ ocp_reg_write(tp, OCP_EEE_AR, 0x0000);
+}
+
+static void r8152_eee_en(struct r8152 *tp, bool enable)
+{
+ u16 config1, config2, config3;
+ u32 ocp_data;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config1 = ocp_reg_read(tp, OCP_EEE_CONFIG1) & ~sd_rise_time_mask;
+ config2 = ocp_reg_read(tp, OCP_EEE_CONFIG2);
+ config3 = ocp_reg_read(tp, OCP_EEE_CONFIG3) & ~fast_snr_mask;
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config1 |= EEE_10_CAP | EEE_NWAY_EN | TX_QUIET_EN | RX_QUIET_EN;
+ config1 |= sd_rise_time(1);
+ config2 |= RG_DACQUIET_EN | RG_LDVQUIET_EN;
+ config3 |= fast_snr(42);
+ } else {
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config1 &= ~(EEE_10_CAP | EEE_NWAY_EN | TX_QUIET_EN |
+ RX_QUIET_EN);
+ config1 |= sd_rise_time(7);
+ config2 &= ~(RG_DACQUIET_EN | RG_LDVQUIET_EN);
+ config3 |= fast_snr(511);
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CONFIG1, config1);
+ ocp_reg_write(tp, OCP_EEE_CONFIG2, config2);
+ ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
+}
+
+static void r8152b_enable_eee(struct r8152 *tp)
+{
+ r8152_eee_en(tp, true);
+ r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
+}
+
+static void r8152b_enable_fc(struct r8152 *tp)
+{
+ u16 anar;
+
+ anar = r8152_mdio_read(tp, MII_ADVERTISE);
+ anar |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
+ r8152_mdio_write(tp, MII_ADVERTISE, anar);
+}
+
static void rtl8152_disable(struct r8152 *tp)
{
r8152_aldps_en(tp, false);
@@ -2701,6 +2772,47 @@ static void r8152b_enter_oob(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
}
+static void r8153_aldps_en(struct r8152 *tp, bool enable)
+{
+ u16 data;
+
+ data = ocp_reg_read(tp, OCP_POWER_CFG);
+ if (enable) {
+ data |= EN_ALDPS;
+ ocp_reg_write(tp, OCP_POWER_CFG, data);
+ } else {
+ data &= ~EN_ALDPS;
+ ocp_reg_write(tp, OCP_POWER_CFG, data);
+ msleep(20);
+ }
+}
+
+static void r8153_eee_en(struct r8152 *tp, bool enable)
+{
+ u32 ocp_data;
+ u16 config;
+
+ ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
+ config = ocp_reg_read(tp, OCP_EEE_CFG);
+
+ if (enable) {
+ ocp_data |= EEE_RX_EN | EEE_TX_EN;
+ config |= EEE10_EN;
+ } else {
+ ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
+ config &= ~EEE10_EN;
+ }
+
+ ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
+ ocp_reg_write(tp, OCP_EEE_CFG, config);
+}
+
+static void r8153_enable_eee(struct r8152 *tp)
+{
+ r8153_eee_en(tp, true);
+ ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
+}
+
static void r8153_hw_phy_cfg(struct r8152 *tp)
{
u32 ocp_data;
@@ -2866,21 +2978,6 @@ static void r8153_enter_oob(struct r8152 *tp)
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
}
-static void r8153_aldps_en(struct r8152 *tp, bool enable)
-{
- u16 data;
-
- data = ocp_reg_read(tp, OCP_POWER_CFG);
- if (enable) {
- data |= EN_ALDPS;
- ocp_reg_write(tp, OCP_POWER_CFG, data);
- } else {
- data &= ~EN_ALDPS;
- ocp_reg_write(tp, OCP_POWER_CFG, data);
- msleep(20);
- }
-}
-
static void rtl8153_disable(struct r8152 *tp)
{
r8153_aldps_en(tp, false);
@@ -3246,103 +3343,6 @@ static int rtl8152_close(struct net_device *netdev)
return res;
}
-static inline void r8152_mmd_indirect(struct r8152 *tp, u16 dev, u16 reg)
-{
- ocp_reg_write(tp, OCP_EEE_AR, FUN_ADDR | dev);
- ocp_reg_write(tp, OCP_EEE_DATA, reg);
- ocp_reg_write(tp, OCP_EEE_AR, FUN_DATA | dev);
-}
-
-static u16 r8152_mmd_read(struct r8152 *tp, u16 dev, u16 reg)
-{
- u16 data;
-
- r8152_mmd_indirect(tp, dev, reg);
- data = ocp_reg_read(tp, OCP_EEE_DATA);
- ocp_reg_write(tp, OCP_EEE_AR, 0x0000);
-
- return data;
-}
-
-static void r8152_mmd_write(struct r8152 *tp, u16 dev, u16 reg, u16 data)
-{
- r8152_mmd_indirect(tp, dev, reg);
- ocp_reg_write(tp, OCP_EEE_DATA, data);
- ocp_reg_write(tp, OCP_EEE_AR, 0x0000);
-}
-
-static void r8152_eee_en(struct r8152 *tp, bool enable)
-{
- u16 config1, config2, config3;
- u32 ocp_data;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config1 = ocp_reg_read(tp, OCP_EEE_CONFIG1) & ~sd_rise_time_mask;
- config2 = ocp_reg_read(tp, OCP_EEE_CONFIG2);
- config3 = ocp_reg_read(tp, OCP_EEE_CONFIG3) & ~fast_snr_mask;
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config1 |= EEE_10_CAP | EEE_NWAY_EN | TX_QUIET_EN | RX_QUIET_EN;
- config1 |= sd_rise_time(1);
- config2 |= RG_DACQUIET_EN | RG_LDVQUIET_EN;
- config3 |= fast_snr(42);
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config1 &= ~(EEE_10_CAP | EEE_NWAY_EN | TX_QUIET_EN |
- RX_QUIET_EN);
- config1 |= sd_rise_time(7);
- config2 &= ~(RG_DACQUIET_EN | RG_LDVQUIET_EN);
- config3 |= fast_snr(511);
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CONFIG1, config1);
- ocp_reg_write(tp, OCP_EEE_CONFIG2, config2);
- ocp_reg_write(tp, OCP_EEE_CONFIG3, config3);
-}
-
-static void r8152b_enable_eee(struct r8152 *tp)
-{
- r8152_eee_en(tp, true);
- r8152_mmd_write(tp, MDIO_MMD_AN, MDIO_AN_EEE_ADV, MDIO_EEE_100TX);
-}
-
-static void r8153_eee_en(struct r8152 *tp, bool enable)
-{
- u32 ocp_data;
- u16 config;
-
- ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
- config = ocp_reg_read(tp, OCP_EEE_CFG);
-
- if (enable) {
- ocp_data |= EEE_RX_EN | EEE_TX_EN;
- config |= EEE10_EN;
- } else {
- ocp_data &= ~(EEE_RX_EN | EEE_TX_EN);
- config &= ~EEE10_EN;
- }
-
- ocp_write_word(tp, MCU_TYPE_PLA, PLA_EEE_CR, ocp_data);
- ocp_reg_write(tp, OCP_EEE_CFG, config);
-}
-
-static void r8153_enable_eee(struct r8152 *tp)
-{
- r8153_eee_en(tp, true);
- ocp_reg_write(tp, OCP_EEE_ADV, MDIO_EEE_1000T | MDIO_EEE_100TX);
-}
-
-static void r8152b_enable_fc(struct r8152 *tp)
-{
- u16 anar;
-
- anar = r8152_mdio_read(tp, MII_ADVERTISE);
- anar |= ADVERTISE_PAUSE_CAP | ADVERTISE_PAUSE_ASYM;
- r8152_mdio_write(tp, MII_ADVERTISE, anar);
-}
-
static void rtl_tally_reset(struct r8152 *tp)
{
u32 ocp_data;
--
2.7.4
^ permalink raw reply related
* [PATCH net 0/5] r8152: correct the flow of PHY
From: Hayes Wang @ 2016-09-20 8:22 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
First, to enable the PHY as early as possible. Some settings may fail if the
PHY is power down.
Move the other PHY settings to hw_phy_cfg() to make sure the order is correct.
Finally, disable ALDPS and EEE before updating the PHY for RTL8153.
Hayes Wang (5):
r8152: move some functions
r8152: move enabling PHY
r8152: move PHY settings to hw_phy_cfg
r8152: remove r8153_enable_eee
r8152: disable ALDPS and EEE before setting PHY
drivers/net/usb/r8152.c | 281 +++++++++++++++++++++++++-----------------------
1 file changed, 146 insertions(+), 135 deletions(-)
--
2.7.4
^ permalink raw reply
* Re: [PATCH net-next 8/8] net/mlx5e: XDP TX xmit more
From: Tariq Toukan @ 2016-09-20 8:19 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Tariq Toukan
Cc: David S. Miller, netdev, Eran Ben Elisha, Saeed Mahameed,
Rana Shahout
In-Reply-To: <20160920094629.12e78a85@redhat.com>
Hi Jesper,
On 20/09/2016 10:46 AM, Jesper Dangaard Brouer wrote:
> On Mon, 19 Sep 2016 16:58:59 +0300
> Tariq Toukan <tariqt@mellanox.com> wrote:
>
>> From: Saeed Mahameed <saeedm@mellanox.com>
>>
>> Previously we rang XDP SQ doorbell on every forwarded XDP packet.
>>
>> Here we introduce a xmit more like mechanism that will queue up more
>> than one packet into SQ (up to RX napi budget) w/o notifying the hardware.
>>
>> Once RX napi budget is consumed and we exit napi RX loop, we will
>> flush (doorbell) all XDP looped packets in case there are such.
> I've already raised strong concerns with this approach on the RFC
> patchset. Of not really taking advantage of RX bulking.
> Please do not ignore this!
Sure. Your approach can fit with our plans to split the RX completion
poll loop into several stages.
I will try it when we get there.
>
> If you can promise, that we/you will also try to other approach I'm
> suggesting, then I'm fine with this patch.
>
Thanks.
^ permalink raw reply
* [PATCH net-next 2/3] net: ethernet: mediatek: add support for GMAC0 connecting with external PHY through TRGMII
From: sean.wang @ 2016-09-20 7:59 UTC (permalink / raw)
To: john, davem; +Cc: nbd, netdev, linux-mediatek, keyhaede, objelf, Sean Wang
In-Reply-To: <1474358360-29901-1-git-send-email-sean.wang@mediatek.com>
From: Sean Wang <sean.wang@mediatek.com>
Changing dynamically source clock, TX/RX delay and interface mode
used by TRGMII hardware module inside PHY capability polling routine
for adapting to the various speed of RGMII used by external PHY for
GMAC0.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 33 ++++++++++++++++++++++++++++-
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 29 +++++++++++++++++++++++++
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index a0e338b..609fd2b 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -52,7 +52,7 @@ static const struct mtk_ethtool_stats {
};
static const char * const mtk_clks_source_name[] = {
- "ethif", "esw", "gp1", "gp2"
+ "ethif", "esw", "gp1", "gp2", "trgpll"
};
void mtk_w32(struct mtk_eth *eth, u32 val, unsigned reg)
@@ -135,6 +135,33 @@ static int mtk_mdio_read(struct mii_bus *bus, int phy_addr, int phy_reg)
return _mtk_mdio_read(eth, phy_addr, phy_reg);
}
+static void mtk_gmac0_rgmii_adjust(struct mtk_eth *eth, int speed)
+{
+ u32 val;
+ int ret;
+
+ val = (speed == SPEED_1000) ?
+ INTF_MODE_RGMII_1000 : INTF_MODE_RGMII_10_100;
+ mtk_w32(eth, val, INTF_MODE);
+
+ regmap_update_bits(eth->ethsys, ETHSYS_CLKCFG0,
+ ETHSYS_TRGMII_CLK_SEL362_5,
+ ETHSYS_TRGMII_CLK_SEL362_5);
+
+ val = (speed == SPEED_1000) ? 250000000 : 500000000;
+ ret = clk_set_rate(eth->clks[MTK_CLK_TRGPLL], val);
+ if (ret)
+ dev_err(eth->dev, "Failed to set trgmii pll: %d\n", ret);
+
+ val = (speed == SPEED_1000) ?
+ RCK_CTRL_RGMII_1000 : RCK_CTRL_RGMII_10_100;
+ mtk_w32(eth, val, TRGMII_RCK_CTRL);
+
+ val = (speed == SPEED_1000) ?
+ TCK_CTRL_RGMII_1000 : TCK_CTRL_RGMII_10_100;
+ mtk_w32(eth, val, TRGMII_TCK_CTRL);
+}
+
static int mtk_of_get_phy_mode(struct mtk_mac *mac, struct device_node *np)
{
int phy_mode, err;
@@ -149,6 +176,7 @@ static int mtk_of_get_phy_mode(struct mtk_mac *mac, struct device_node *np)
return err;
if (!strcasecmp(pm, "trgmii")) {
mac->trgmii = true;
+
/* TRGMII could be compatible with RGMII */
return PHY_INTERFACE_MODE_RGMII;
} else
@@ -177,6 +205,9 @@ static void mtk_phy_link_adjust(struct net_device *dev)
break;
};
+ if (mac->id == 0 && !mac->trgmii)
+ mtk_gmac0_rgmii_adjust(mac->hw, mac->phy_dev->speed);
+
if (mac->phy_dev->link)
mcr |= MAC_MCR_FORCE_LINK;
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index e3b9525..f1f44de 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -313,6 +313,30 @@
MAC_MCR_FORCE_TX_FC | MAC_MCR_SPEED_1000 | \
MAC_MCR_FORCE_DPX | MAC_MCR_FORCE_LINK)
+/*TRGMII RXC control register*/
+#define TRGMII_RCK_CTRL 0x10300
+#define DQSI0(x) ((x << 0) & GENMASK(6, 0))
+#define DQSI1(x) ((x << 8) & GENMASK(14, 8))
+#define RXCTL_DMWTLAT(x) ((x << 16) & GENMASK(18, 16))
+#define RXC_DQSISEL BIT(30)
+#define RCK_CTRL_RGMII_1000 (RXC_DQSISEL | RXCTL_DMWTLAT(2) | DQSI1(16))
+#define RCK_CTRL_RGMII_10_100 RXCTL_DMWTLAT(2)
+
+/*TRGMII RXC control register*/
+#define TRGMII_TCK_CTRL 0x10340
+#define TXCTL_DMWTLAT(x) ((x << 16) & GENMASK(18, 16))
+#define TXC_INV BIT(30)
+#define TCK_CTRL_RGMII_1000 TXCTL_DMWTLAT(2)
+#define TCK_CTRL_RGMII_10_100 (TXC_INV | TXCTL_DMWTLAT(2))
+
+/*TRGMII Interface mode register*/
+#define INTF_MODE 0x10390
+#define TRGMII_INTF_DIS BIT(0)
+#define TRGMII_MODE BIT(1)
+#define TRGMII_CENTRAL_ALIGNED BIT(2)
+#define INTF_MODE_RGMII_1000 (TRGMII_MODE | TRGMII_CENTRAL_ALIGNED)
+#define INTF_MODE_RGMII_10_100 0
+
/* GPIO port control registers for GMAC 2*/
#define GPIO_OD33_CTRL8 0x4c0
#define GPIO_BIAS_CTRL 0xed0
@@ -323,6 +347,10 @@
#define SYSCFG0_GE_MASK 0x3
#define SYSCFG0_GE_MODE(x, y) (x << (12 + (y * 2)))
+/* ethernet subsystem clock register */
+#define ETHSYS_CLKCFG0 0x2c
+#define ETHSYS_TRGMII_CLK_SEL362_5 BIT(11)
+
/*ethernet reset control register*/
#define ETHSYS_RSTCTRL 0x34
#define RSTCTRL_FE BIT(6)
@@ -389,6 +417,7 @@ enum mtk_clks_map {
MTK_CLK_ESW,
MTK_CLK_GP1,
MTK_CLK_GP2,
+ MTK_CLK_TRGPLL,
MTK_CLK_MAX
};
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 0/3] add support for RGMII on GMAC0 through TRGMII hardware module
From: sean.wang @ 2016-09-20 7:59 UTC (permalink / raw)
To: john, davem; +Cc: nbd, netdev, linux-mediatek, keyhaede, objelf, Sean Wang
From: Sean Wang <sean.wang@mediatek.com>
By default, GMAC0 is connected to built-in switch called
MT7530 through the proprietary interface called Turbo RGMII
(TRGMII). TRGMII also supports well for RGMII as generic external
PHY uses but requires some slight changes to the setup of TRGMII
and doesn't have well support on current driver.
So this patchset
1) provides the slight changes of the setup for RGMII can work
through TRGMII
2) adds additional setting "trgmii" about phy-mode on device tree
to make GMAC0 distinguish which mode it runs
3) changes dynamically source clock, TX/RX delay and interface
mode on TRGMII for adapting various link
Sean Wang (3):
net: ethernet: mediatek: add extension of phy-mode for TRGMII
net: ethernet: mediatek: add support for GMAC0 connecting with
external PHY through TRGMII
net: ethernet: mediatek: add the dts property to set if TRGMII
supported on GMAC0
.../devicetree/bindings/net/mediatek-net.txt | 5 +-
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 57 ++++++++++++++++++++--
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 32 ++++++++++++
3 files changed, 90 insertions(+), 4 deletions(-)
--
1.9.1
^ 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