* [PATCHv2 perf/core 1/7] tools lib bpf: Fix map offsets in relocation
From: Joe Stringer @ 2017-01-23 1:11 UTC (permalink / raw)
To: acme; +Cc: wangnan0, ast, daniel, linux-kernel, netdev,
Arnaldo Carvalho de Melo
In-Reply-To: <20170123011128.26534-1-joe@ovn.org>
Commit 4708bbda5cb2 ("tools lib bpf: Fix maps resolution") attempted to
fix map resolution by identifying the number of symbols that point to
maps, and using this number to resolve each of the maps.
However, during relocation the original definition of the map size was
still in use. For up to two maps, the calculation was correct if there
was a small difference in size between the map definition in libbpf and
the one that the client library uses. However if the difference was
large, particularly if more than two maps were used in the BPF program,
the relocation would fail.
For example, when using a map definition with size 28, with three maps,
map relocation would count
(sym_offset / sizeof(struct bpf_map_def) => map_idx)
(0 / 16 => 0), ie map_idx = 0
(28 / 16 => 1), ie map_idx = 1
(56 / 16 => 3), ie map_idx = 3
So, libbpf reports:
libbpf: bpf relocation: map_idx 3 large than 2
Fix map relocation by checking the exact offset of maps when doing
relocation.
Fixes: 4708bbda5cb2 ("tools lib bpf: Fix maps resolution")
Signed-off-by: Joe Stringer <joe@ovn.org>
Signed-off-by: Wang Nan <wangnan0@huawei.com>
[Allow different map size in an object]
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
---
v2: Use cached offsets of maps for relocation (Wang Nan)
This is a repost of the version Wang Nan posted on Jan 19.
---
tools/lib/bpf/libbpf.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 84e6b35da4bd..671d5ad07cf1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -779,7 +779,7 @@ static int
bpf_program__collect_reloc(struct bpf_program *prog,
size_t nr_maps, GElf_Shdr *shdr,
Elf_Data *data, Elf_Data *symbols,
- int maps_shndx)
+ int maps_shndx, struct bpf_map *maps)
{
int i, nrels;
@@ -829,7 +829,15 @@ bpf_program__collect_reloc(struct bpf_program *prog,
return -LIBBPF_ERRNO__RELOC;
}
- map_idx = sym.st_value / sizeof(struct bpf_map_def);
+ /* TODO: 'maps' is sorted. We can use bsearch to make it faster. */
+ for (map_idx = 0; map_idx < nr_maps; map_idx++) {
+ if (maps[map_idx].offset == sym.st_value) {
+ pr_debug("relocation: find map %zd (%s) for insn %u\n",
+ map_idx, maps[map_idx].name, insn_idx);
+ break;
+ }
+ }
+
if (map_idx >= nr_maps) {
pr_warning("bpf relocation: map_idx %d large than %d\n",
(int)map_idx, (int)nr_maps - 1);
@@ -953,7 +961,8 @@ static int bpf_object__collect_reloc(struct bpf_object *obj)
err = bpf_program__collect_reloc(prog, nr_maps,
shdr, data,
obj->efile.symbols,
- obj->efile.maps_shndx);
+ obj->efile.maps_shndx,
+ obj->maps);
if (err)
return err;
}
--
2.11.0
^ permalink raw reply related
* [PATCHv2 perf/core 0/7] Libbpf improvements
From: Joe Stringer @ 2017-01-23 1:11 UTC (permalink / raw)
To: acme; +Cc: wangnan0, ast, daniel, linux-kernel, netdev
Patch 1 fixes an issue when using drastically different BPF map definitions
inside ELFs from a client using libbpf, vs the map definition libbpf uses.
Patches 2-4 add some simple, useful helper functions for setting prog type
and retrieving libbpf errors without depending on kernel headers from
userspace programs.
Patches 5-7 add a new pinning functionality for maps, programs, and objects.
Library users may call bpf_map__pin(map, path) or bpf_program__pin(prog, path)
to pin maps and programs separately, or use bpf_object__pin(obj, path) to
pin all maps and programs from the BPF object to the path. The map and program
variations require a full path where it will be pinned in the filesystem,
and the object variation will create directories "maps/" and "progs/" under
the specified path, then mount each map and program under those subdirectories.
---
v1: Initial post.
v2: Wang Nan provided improvements to patch 1.
Dropped patch 2 from v1.
Added acks for acked patches.
Split the bpf_obj__pin() to also provide map / program pinning APIs.
Allow users to provide full filesystem path (don't autodetect/mount BPFFS).
Joe Stringer (7):
tools lib bpf: Fix map offsets in relocation
tools lib bpf: Define prog_type fns with macro
tools lib bpf: Add set/is helpers for all prog types
tools lib bpf: Add libbpf_get_error()
tools lib bpf: Add bpf_program__pin()
tools lib bpf: Add bpf_map__pin()
tools lib bpf: Add bpf_object__pin()
tools/lib/bpf/libbpf.c | 240 ++++++++++++++++++++++++++++++++++++++++++------
tools/lib/bpf/libbpf.h | 17 +++-
tools/perf/tests/llvm.c | 2 +-
3 files changed, 229 insertions(+), 30 deletions(-)
--
2.11.0
^ permalink raw reply
* RE: [RFC PATCH net-next 4/5] bridge: vlan lwt and dst_metadata netlink support
From: Rosen, Rami @ 2017-01-23 0:22 UTC (permalink / raw)
To: Roopa Prabhu, netdev@vger.kernel.org
Cc: davem@davemloft.net, stephen@networkplumber.org,
nikolay@cumulusnetworks.com, tgraf@suug.ch,
hannes@stressinduktion.org, jbenc@redhat.com, pshelar@ovn.org,
dsa@cumulusnetworks.com, hadi@mojatatu.com
In-Reply-To: <1484977616-1541-5-git-send-email-roopa@cumulusnetworks.com>
Hi, Roopa,
Two minor comments:
The parameter br is not used in the br_add_vlan_tunnel_info() method, it should be removed:
+static int br_add_vlan_tunnel_info(struct net_bridge *br,
+ struct net_bridge_port *p, int cmd,
+ u16 vid, u32 tun_id)
+{
+ int err;
+
+ switch (cmd) {
+ case RTM_SETLINK:
+ if (p) {
+ /* if the MASTER flag is set this will act on the global
+ * per-VLAN entry as well
+ */
+ err = nbp_vlan_tunnel_info_add(p, vid, tun_id);
+ if (err)
+ break;
+ } else {
+ return -EINVAL;
+ }
+
+ break;
+
+ case RTM_DELLINK:
+ if (p)
+ nbp_vlan_tunnel_info_delete(p, vid);
+ else
+ return -EINVAL;
+ break;
+ }
+
+ return 0;
+}
+
The parameter br is used inside br_process_vlan_tunnel_info() only in the two
Cases, when br_add_vlan_tunnel_info() is invoked. Since we saw earlier that it should be removed from br_add_vlan_tunnel_info(), it should also be removed from br_process_vlan_tunnel_info() as it is not needed anymore:
+static int br_process_vlan_tunnel_info(struct net_bridge *br,
+ struct net_bridge_port *p, int cmd,
+ struct vtunnel_info *tinfo_curr,
+ struct vtunnel_info *tinfo_last) {
+ int t, v;
+ int err;
+
+ if (tinfo_curr->flags & BRIDGE_VLAN_INFO_RANGE_BEGIN) {
+ if (tinfo_last->flags & BRIDGE_VLAN_INFO_RANGE_BEGIN)
+ return -EINVAL;
+ memcpy(tinfo_last, tinfo_curr, sizeof(struct vtunnel_info));
+ } else if (tinfo_curr->flags & BRIDGE_VLAN_INFO_RANGE_END) {
+ if (!(tinfo_last->flags & BRIDGE_VLAN_INFO_RANGE_BEGIN))
+ return -EINVAL;
+ if ((tinfo_curr->vid - tinfo_last->vid) !=
+ (tinfo_curr->tunid - tinfo_last->tunid))
+ return -EINVAL;
+ /* XXX: tun id and vlan id attrs must be same
+ */
+ t = tinfo_last->tunid;
+ for (v = tinfo_last->vid; v <= tinfo_curr->vid; v++) {
+ err = br_add_vlan_tunnel_info(br, p, cmd,
+ v, t);
+ if (err)
+ return err;
+ t++;
+ }
+ memset(tinfo_last, 0, sizeof(struct vtunnel_info));
+ memset(tinfo_curr, 0, sizeof(struct vtunnel_info));
+ } else {
+ err = br_add_vlan_tunnel_info(br, p, cmd,
+ tinfo_curr->vid,
+ tinfo_curr->tunid);
+ if (err)
+ return err;
+ }
+
+ return 0;
+}
+
Regards,
Rami Rosen
^ permalink raw reply
* Re: [PATCH v4 3/3] samples/bpf: add lpm-trie benchmark
From: Alexei Starovoitov @ 2017-01-22 23:02 UTC (permalink / raw)
To: Daniel Mack; +Cc: ast, dh.herrmann, daniel, netdev, davem
In-Reply-To: <20170121162613.4159-4-daniel@zonque.org>
On Sat, Jan 21, 2017 at 05:26:13PM +0100, Daniel Mack wrote:
> From: David Herrmann <dh.herrmann@gmail.com>
>
> Extend the map_perf_test_{user,kern}.c infrastructure to stress test
> lpm-trie lookups. We hook into the kprobe on sys_gettid() and measure
> the latency depending on trie size and lookup count.
>
> On my Intel Haswell i7-6400U, a single gettid() syscall with an empty
> bpf program takes roughly 6.5us on my system. Lookups in empty tries
> take ~1.8us on first try, ~0.9us on retries. Lookups in tries with 8192
> entries take ~7.1us (on the first _and_ any subsequent try).
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Reviewed-by: Daniel Mack <daniel@zonque.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Thank you for all the hard work you've put into these patches.
All looks great to me.
^ permalink raw reply
* Re: [PATCH v4 2/3] bpf: Add tests for the lpm trie map
From: Alexei Starovoitov @ 2017-01-22 22:58 UTC (permalink / raw)
To: Daniel Mack; +Cc: ast, dh.herrmann, daniel, netdev, davem
In-Reply-To: <20170121162613.4159-3-daniel@zonque.org>
On Sat, Jan 21, 2017 at 05:26:12PM +0100, Daniel Mack wrote:
> From: David Herrmann <dh.herrmann@gmail.com>
>
> The first part of this program runs randomized tests against the
> lpm-bpf-map. It implements a "Trivial Longest Prefix Match" (tlpm)
> based on simple, linear, single linked lists. The implementation
> should be pretty straightforward.
>
> Based on tlpm, this inserts randomized data into bpf-lpm-maps and
> verifies the trie-based bpf-map implementation behaves the same way
> as tlpm.
>
> The second part uses 'real world' IPv4 and IPv6 addresses and tests
> the trie with those.
>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 1/3] bpf: add a longest prefix match trie map implementation
From: Alexei Starovoitov @ 2017-01-22 22:57 UTC (permalink / raw)
To: Daniel Mack; +Cc: ast, dh.herrmann, daniel, netdev, davem
In-Reply-To: <20170121162613.4159-2-daniel@zonque.org>
On Sat, Jan 21, 2017 at 05:26:11PM +0100, Daniel Mack wrote:
> This trie implements a longest prefix match algorithm that can be used
> to match IP addresses to a stored set of ranges.
>
> Internally, data is stored in an unbalanced trie of nodes that has a
> maximum height of n, where n is the prefixlen the trie was created
> with.
>
> Tries may be created with prefix lengths that are multiples of 8, in
> the range from 8 to 2048. The key used for lookup and update operations
> is a struct bpf_lpm_trie_key, and the value is a uint64_t.
>
> The code carries more information about the internal implementation.
>
> Signed-off-by: Daniel Mack <daniel@zonque.org>
> Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Looks great to me.
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [patch] samples/bpf: silence shift wrapping warning
From: Alexei Starovoitov @ 2017-01-22 22:51 UTC (permalink / raw)
To: Dan Carpenter
Cc: Arnaldo Carvalho de Melo, Thomas Graf, Alexei Starovoitov,
Joe Stringer, David S. Miller, linux-kernel, kernel-janitors,
netdev
In-Reply-To: <20170121045143.GC15269@mwanda>
On Sat, Jan 21, 2017 at 07:51:43AM +0300, Dan Carpenter wrote:
> max_key is a value in the 0-63 range, so on 32 bit systems the shift
> could wrap.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Looks fine. I think 'net-next' is ok.
Acked-by: Alexei Starovoitov <ast@kernel.org>
> diff --git a/samples/bpf/lwt_len_hist_user.c b/samples/bpf/lwt_len_hist_user.c
> index ec8f3bb..bd06eef 100644
> --- a/samples/bpf/lwt_len_hist_user.c
> +++ b/samples/bpf/lwt_len_hist_user.c
> @@ -68,7 +68,7 @@ int main(int argc, char **argv)
> for (i = 1; i <= max_key + 1; i++) {
> stars(starstr, data[i - 1], max_value, MAX_STARS);
> printf("%8ld -> %-8ld : %-8ld |%-*s|\n",
> - (1l << i) >> 1, (1l << i) - 1, data[i - 1],
> + (1ULL << i) >> 1, (1ULL << i) - 1, data[i - 1],
> MAX_STARS, starstr);
> }
>
^ permalink raw reply
* [PATCH net-next v5 2/2] net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
From: Martin Blumenstingl @ 2017-01-22 22:02 UTC (permalink / raw)
To: davem, netdev, devicetree, linux-amlogic
Cc: robh+dt, mark.rutland, carlo, khilman, narmstrong,
Martin Blumenstingl
In-Reply-To: <20170122220246.13602-1-martin.blumenstingl@googlemail.com>
Prior to this patch we were using a hardcoded RGMII TX clock delay of
2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for
many boards, but unfortunately not for all (due to the way the actual
circuit is designed, sometimes because the TX delay is enabled in the
PHY, etc.). Making the TX delay on the MAC side configurable allows us
to support all possible hardware combinations.
This allows fixing a compatibility issue on some boards, where the
RTL8211F PHY is configured to generate the TX delay. We can now turn
off the TX delay in the MAC, because otherwise we would be applying the
delay twice (which results in non-working TX traffic).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
index ffaed1f35efe..8840a360a0b7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c
@@ -35,10 +35,6 @@
#define PRG_ETH0_TXDLY_SHIFT 5
#define PRG_ETH0_TXDLY_MASK GENMASK(6, 5)
-#define PRG_ETH0_TXDLY_OFF (0x0 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_QUARTER (0x1 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_HALF (0x2 << PRG_ETH0_TXDLY_SHIFT)
-#define PRG_ETH0_TXDLY_THREE_QUARTERS (0x3 << PRG_ETH0_TXDLY_SHIFT)
/* divider for the result of m250_sel */
#define PRG_ETH0_CLK_M250_DIV_SHIFT 7
@@ -69,6 +65,8 @@ struct meson8b_dwmac {
struct clk_divider m25_div;
struct clk *m25_div_clk;
+
+ u32 tx_delay_ns;
};
static void meson8b_dwmac_mask_bits(struct meson8b_dwmac *dwmac, u32 reg,
@@ -179,6 +177,7 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
{
int ret;
unsigned long clk_rate;
+ u8 tx_dly_val;
switch (dwmac->phy_mode) {
case PHY_INTERFACE_MODE_RGMII:
@@ -196,9 +195,13 @@ static int meson8b_init_prg_eth(struct meson8b_dwmac *dwmac)
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0,
PRG_ETH0_INVERTED_RMII_CLK, 0);
- /* TX clock delay - all known boards use a 1/4 cycle delay */
+ /* TX clock delay in ns = "8ns / 4 * tx_dly_val" (where
+ * 8ns are exactly one cycle of the 125MHz RGMII TX clock):
+ * 0ns = 0x0, 2ns = 0x1, 4ns = 0x2, 6ns = 0x3
+ */
+ tx_dly_val = dwmac->tx_delay_ns >> 1;
meson8b_dwmac_mask_bits(dwmac, PRG_ETH0, PRG_ETH0_TXDLY_MASK,
- PRG_ETH0_TXDLY_QUARTER);
+ tx_dly_val << PRG_ETH0_TXDLY_SHIFT);
break;
case PHY_INTERFACE_MODE_RMII:
@@ -284,6 +287,11 @@ static int meson8b_dwmac_probe(struct platform_device *pdev)
goto err_remove_config_dt;
}
+ /* use 2ns as fallback since this value was previously hardcoded */
+ if (of_property_read_u32(pdev->dev.of_node, "amlogic,tx-delay-ns",
+ &dwmac->tx_delay_ns))
+ dwmac->tx_delay_ns = 2;
+
ret = meson8b_init_clk(dwmac);
if (ret)
goto err_remove_config_dt;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v5 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Martin Blumenstingl @ 2017-01-22 22:02 UTC (permalink / raw)
To: davem, netdev, devicetree, linux-amlogic
Cc: robh+dt, mark.rutland, carlo, khilman, narmstrong,
Martin Blumenstingl
In-Reply-To: <20161217182119.4037-1-martin.blumenstingl@googlemail.com>
Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
cycle (= 2ns) TX clock delay. This seems to work fine for many boards
(for example Odroid-C2 or Amlogic's reference boards) but there are
some others where TX traffic is simply broken.
There are probably multiple reasons why it's working on some boards
while it's broken on others:
- some of Amlogic's reference boards are using a Micrel PHY
- hardware circuit design
- maybe more...
iperf3 results on my Mecool BB2 board (Meson GXM, RTL8211F PHY) with
TX clock delay disabled on the MAC (as it's enabled in the PHY driver).
TX throughput was virtually zero before:
$ iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ 4] local 192.168.1.206 port 52828 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 108 MBytes 901 Mbits/sec
[ 4] 1.00-2.00 sec 94.2 MBytes 791 Mbits/sec
[ 4] 2.00-3.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 3.00-4.00 sec 96.2 MBytes 808 Mbits/sec
[ 4] 4.00-5.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 5.00-6.00 sec 96.5 MBytes 810 Mbits/sec
[ 4] 6.00-7.00 sec 96.6 MBytes 810 Mbits/sec
[ 4] 7.00-8.00 sec 96.5 MBytes 809 Mbits/sec
[ 4] 8.00-9.00 sec 105 MBytes 884 Mbits/sec
[ 4] 9.00-10.00 sec 111 MBytes 934 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1000 MBytes 839 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 998 MBytes 837 Mbits/sec receiver
iperf Done.
$ iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ 4] local 192.168.1.206 port 52832 connected to 192.168.1.100 port 5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.01 sec 99.5 MBytes 829 Mbits/sec 117 139 KBytes
[ 4] 1.01-2.00 sec 105 MBytes 884 Mbits/sec 129 70.7 KBytes
[ 4] 2.00-3.01 sec 107 MBytes 889 Mbits/sec 106 187 KBytes
[ 4] 3.01-4.01 sec 105 MBytes 878 Mbits/sec 92 143 KBytes
[ 4] 4.01-5.00 sec 105 MBytes 882 Mbits/sec 140 129 KBytes
[ 4] 5.00-6.01 sec 106 MBytes 883 Mbits/sec 115 195 KBytes
[ 4] 6.01-7.00 sec 102 MBytes 863 Mbits/sec 133 70.7 KBytes
[ 4] 7.00-8.01 sec 106 MBytes 884 Mbits/sec 143 97.6 KBytes
[ 4] 8.01-9.01 sec 104 MBytes 875 Mbits/sec 124 107 KBytes
[ 4] 9.01-10.01 sec 105 MBytes 876 Mbits/sec 90 139 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.01 sec 1.02 GBytes 874 Mbits/sec 1189 sender
[ 4] 0.00-10.01 sec 1.02 GBytes 873 Mbits/sec receiver
iperf Done.
I get similar TX throughput on my Meson GXBB "MXQ Pro+" board when I
disable the PHY's TX-delay and configure a 4ms TX-delay on the MAC.
So changes to at least the RTL8211F PHY driver are needed to get it
working properly in all situations.
Changes since v4:
- add a fallback of 2ns (the value which was previously hardcoded) for
the TX delay so we are backwards-compatible with older .dts'
- update the documentation with the new fallback value and add a small
note that the "amlogic,tx-delay" property is ignored when the phy-mode
is "rmii".
Changes since v3:
- rebased to apply against current net-next branch (fixes a conflict
with d2ed0a7755fe14c7 "net: ethernet: stmmac: fix of-node and
fixed-link-phydev leaks")
Changes since v2:
- moved all .dts patches (3-7) to a separate series
- removed the default 2ns TX delay when phy-mode RGMII is specified
- (rebased against current net-next)
Changes since v1:
- renamed the devicetree property "amlogic,tx-delay" to
"amlogic,tx-delay-ns", which makes the .dts easier to read as we can
simply specify human-readable values instead of having "preprocessor
defines and calculation in human brain". Thanks to Andrew Lunn for
the suggestion!
- improved documentation to indicate when the MAC TX-delay should be
configured and how to use the PHY's TX-delay
- changed the default TX-delay in the dwmac-meson8b driver from 2ns
to 0ms when any of the rgmii-*id modes are used (the 2ns default
value still applies for phy-mode "rgmii")
- added patches to properly reset the PHY on Meson GXBB devices and to
use a similar configuration than the one we use on Meson GXL devices
(by passing a phy-handle to stmmac and defining the PHY in the mdio0
bus - patch 3-6)
- add the "amlogic,tx-delay-ns" property to all boards which are using
the RGMII PHY (patch 7)
Martin Blumenstingl (2):
net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
.../devicetree/bindings/net/meson-dwmac.txt | 16 ++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 20 ++++++++++++++------
2 files changed, 30 insertions(+), 6 deletions(-)
--
2.11.0
^ permalink raw reply
* [PATCH net-next v5 1/2] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Martin Blumenstingl @ 2017-01-22 22:02 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
carlo-KA+7E9HrN00dnm+yROfE0A, khilman-rdvid1DuHRBWk0Htik3J/w,
narmstrong-rdvid1DuHRBWk0Htik3J/w, Martin Blumenstingl
In-Reply-To: <20170122220246.13602-1-martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
This allows configuring the RGMII TX clock delay. The RGMII clock is
generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
The configuration depends on the actual hardware (no delay may be
needed due to the design of the actual circuit, the PHY might add this
delay, etc.).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
Tested-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
Documentation/devicetree/bindings/net/meson-dwmac.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/meson-dwmac.txt b/Documentation/devicetree/bindings/net/meson-dwmac.txt
index 89e62ddc69ca..0703ad3f3c1e 100644
--- a/Documentation/devicetree/bindings/net/meson-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/meson-dwmac.txt
@@ -25,6 +25,22 @@ Required properties on Meson8b and newer:
- "clkin0" - first parent clock of the internal mux
- "clkin1" - second parent clock of the internal mux
+Optional properties on Meson8b and newer:
+- amlogic,tx-delay-ns: The internal RGMII TX clock delay (provided
+ by this driver) in nanoseconds. Allowed values
+ are: 0ns, 2ns, 4ns, 6ns.
+ When phy-mode is set to "rgmii" then the TX
+ delay should be explicitly configured. When
+ not configured a fallback of 2ns is used.
+ When the phy-mode is set to either "rgmii-id"
+ or "rgmii-txid" the TX clock delay is already
+ provided by the PHY. In that case this
+ property should be set to 0ns (which disables
+ the TX clock delay in the MAC to prevent the
+ clock from going off because both PHY and MAC
+ are adding a delay).
+ Any configuration is ignored when the phy-mode
+ is set to "rmii".
Example for Meson6:
--
2.11.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 net-next 0/7] net: dsa: bcm_sf2: Add support for BCM7278
From: David Miller @ 2017-01-22 21:59 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev, vivien.didelot, andrew
In-Reply-To: <20170120203634.2773-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 20 Jan 2017 12:36:27 -0800
> This patch series adds support for the Broadcom BCM7278 integrated switch
> which is a successor of the BCM7445 switch. We have a little bit of
> register shuffling going on, which is why most of the functional changes
> are to deal with that.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: systemport: Add support for SYSTEMPORT lite
From: David Miller @ 2017-01-22 21:56 UTC (permalink / raw)
To: f.fainelli; +Cc: netdev
In-Reply-To: <20170120190827.26444-1-f.fainelli@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Fri, 20 Jan 2017 11:08:25 -0800
> This patch series adds support for SYSTEMPORT Lite which is an evolution
> of the existing SYSTEMPORT adapter.
>
> The two generations are largely identical as far as the transmit/receive
> path are concerned, and there were just a few control path changes here
> and there.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net v1 0/2] amd-xgbe: AMD XGBE driver fixes 2017-01-20
From: David Miller @ 2017-01-22 21:54 UTC (permalink / raw)
To: thomas.lendacky; +Cc: netdev
In-Reply-To: <20170120181352.2321.63733.stgit@tlendack-t1.amdoffice.net>
From: Tom Lendacky <thomas.lendacky@amd.com>
Date: Fri, 20 Jan 2017 12:13:52 -0600
> This patch series addresses some issues in the AMD XGBE driver.
>
> The following fixes are included in this driver update series:
>
> - Add a fix for a version of the hardware that uses different register
> offset values for a device with the same PCI device ID
> - Add support to check the return code from the xgbe_init() function
>
> This patch series is based on net.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: add NUMA awareness to seg6_hmac_init_algo()
From: David Miller @ 2017-01-22 21:50 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, david.lebrun
In-Reply-To: <1484928536.16328.127.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 20 Jan 2017 08:08:56 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Since we allocate per cpu storage, let's also use NUMA hints.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmicro: fix LS field mask in EEE configuration
From: David Miller @ 2017-01-22 21:49 UTC (permalink / raw)
To: Joao.Pinto; +Cc: rayagond, netdev
In-Reply-To: <ed690f703a3c82193737f1a9813dff8b1ff403dd.1484927665.git.jpinto@synopsys.com>
From: Joao Pinto <Joao.Pinto@synopsys.com>
Date: Fri, 20 Jan 2017 16:00:26 +0000
> This patch fixes the LS mask when setting EEE timer.
> LS field is 10 bits long and not 11 as currently.
>
> Signed-off-by: Joao Pinto <jpinto@synopsys.com>
> Reported-By: Rayagond Kokatanur <rayagond@vayavyalabs.com>
Please indicate the appropriate target tree of your patch in the
subject line just like all other developers on this list do, don't
make me guess.
This time I figured out that this is meant for the net-next tree,
but I will not guess next time, I will just reject your patch
instead.
Thanks.
^ permalink raw reply
* Re: [PATCH] net/mlx4: use rb_entry()
From: David Miller @ 2017-01-22 21:48 UTC (permalink / raw)
To: leon; +Cc: geliangtang, yishaih, netdev, linux-rdma, linux-kernel
In-Reply-To: <20170122074839.GD28570@mtr-leonro.local>
From: Leon Romanovsky <leon@kernel.org>
Date: Sun, 22 Jan 2017 09:48:39 +0200
> I don't understand completely the rationale behind this conversion.
> rb_entry == container_of, why do we need another name for it?
Because it's an annotation.
Either you agree that the macro exists and it should be used in
every spot where those types are being used, or you don't and
therefore argue for the macro and it's usage completely.
^ permalink raw reply
* Re: [PATCH] net/mlx4: use rb_entry()
From: David Miller @ 2017-01-22 21:48 UTC (permalink / raw)
To: geliangtang; +Cc: yishaih, netdev, linux-rdma, linux-kernel
In-Reply-To: <6c1c772de8f70113580dade04f89a377174d8c88.1484817025.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Fri, 20 Jan 2017 22:36:57 +0800
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] 6lowpan: use rb_entry()
From: David Miller @ 2017-01-22 21:47 UTC (permalink / raw)
To: geliangtang
Cc: aar, jukka.rissanen, linux-bluetooth, linux-wpan, netdev,
linux-kernel
In-Reply-To: <c6a809ea5820242a4ae126b03cdcd910a36e5cae.1484817152.git.geliangtang@gmail.com>
From: Geliang Tang <geliangtang@gmail.com>
Date: Fri, 20 Jan 2017 22:36:53 +0800
> To make the code clearer, use rb_entry() instead of container_of() to
> deal with rbtree.
>
> Signed-off-by: Geliang Tang <geliangtang@gmail.com>
Applied.
^ permalink raw reply
* Re: [RESEND PATCH net] macsec: fix validation failed in asynchronous operation.
From: David Miller @ 2017-01-22 21:44 UTC (permalink / raw)
To: ryder.lee-NuS5LvNUpcJWk0Htik3J/w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
sd-y1jBWg8GRStKuXlAQpz2QA
In-Reply-To: <1484988127-25860-1-git-send-email-ryder.lee-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
Why are you resending this?
The original posting on Jan 20th made it to the mailing list and is queued
up in patchwork just fine.
Also, regardless of the reason, a "RESEND" patch should always contain an
explanation of why it needs to be resent. So that the maintainer doesn't
need to ask questions like I am right now.
^ permalink raw reply
* [PATCH net-next] net: dsa: Fix inverted test for multiple CPU interface
From: Andrew Lunn @ 2017-01-22 21:16 UTC (permalink / raw)
To: David Miller; +Cc: Vivien Didelot, Florian Fainelli, netdev, Andrew Lunn
Remove the wrong !, otherwise we get false positives about having
multiple CPU interfaces.
Fixes: b22de490869d ("net: dsa: store CPU switch structure in the tree")
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
net/dsa/dsa.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/dsa.c b/net/dsa/dsa.c
index 77cb78767f1d..1f3afeb673d6 100644
--- a/net/dsa/dsa.c
+++ b/net/dsa/dsa.c
@@ -225,7 +225,7 @@ static int dsa_switch_setup_one(struct dsa_switch *ds, struct device *parent)
continue;
if (!strcmp(name, "cpu")) {
- if (!dst->cpu_switch) {
+ if (dst->cpu_switch) {
netdev_err(dst->master_netdev,
"multiple cpu ports?!\n");
return -EINVAL;
--
2.11.0
^ permalink raw reply related
* [PATCH net-next v6 1/1] net sched actions: Add support for user cookies
From: Jamal Hadi Salim @ 2017-01-22 20:25 UTC (permalink / raw)
To: davem
Cc: netdev, jiri, paulb, john.fastabend, simon.horman, mrv, hadarh,
ogerlitz, roid, xiyou.wangcong, daniel, Jamal Hadi Salim
From: Jamal Hadi Salim <jhs@mojatatu.com>
Introduce optional 128-bit action cookie.
Like all other cookie schemes in the networking world (eg in protocols
like http or existing kernel fib protocol field, etc) the idea is to save
user state that when retrieved serves as a correlator. The kernel
_should not_ intepret it. The user can store whatever they wish in the
128 bits.
Sample exercise(showing variable length use of cookie)
.. create an accept action with cookie a1b2c3d4
sudo $TC actions add action ok index 1 cookie a1b2c3d4
.. dump all gact actions..
sudo $TC -s actions ls action gact
action order 0: gact action pass
random type none pass val 0
index 1 ref 1 bind 0 installed 5 sec used 5 sec
Action statistics:
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
cookie a1b2c3d4
.. bind the accept action to a filter..
sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 1
... send some traffic..
$ ping 127.0.0.1 -c 3
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.020 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.027 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.038 ms
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2109ms
rtt min/avg/max/mdev = 0.020/0.028/0.038/0.008 ms 1
... show some stats
$ sudo $TC -s actions get action gact index 1
action order 1: gact action pass
random type none pass val 0
index 1 ref 2 bind 1 installed 204 sec used 5 sec
Action statistics:
Sent 12168 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
cookie a1b2c3d4
.. try longer cookie...
$ sudo $TC actions replace action ok index 1 cookie 1234567890abcdef
.. dump..
$ sudo $TC -s actions ls action gact
action order 1: gact action pass
random type none pass val 0
index 1 ref 2 bind 1 installed 204 sec used 5 sec
Action statistics:
Sent 12168 bytes 164 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
cookie 1234567890abcdef
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
---
Changes in v6:
- fix mem leak caught by Florian
Changes in V5:
- kill the stylistic changes
- Adopt a new structure with length-valuepointer representation
- rename some things
Changes in v4:
- move stylistic changes out into a separate patch
(and add more stylistic changes)
Changes in v3:
- use TC_ prefix for the max size
- move the cookie struct so visible only to kernel
- remove unneeded void * cast
Changes in V2:
-move from a union to a length-value representation
include/net/act_api.h | 1 +
include/net/pkt_cls.h | 8 ++++++++
include/uapi/linux/pkt_cls.h | 3 +++
net/sched/act_api.c | 36 ++++++++++++++++++++++++++++++++++++
4 files changed, 48 insertions(+)
diff --git a/include/net/act_api.h b/include/net/act_api.h
index 1d71644..cfa2ae3 100644
--- a/include/net/act_api.h
+++ b/include/net/act_api.h
@@ -41,6 +41,7 @@ struct tc_action {
struct rcu_head tcfa_rcu;
struct gnet_stats_basic_cpu __percpu *cpu_bstats;
struct gnet_stats_queue __percpu *cpu_qstats;
+ struct tc_cookie *act_cookie;
};
#define tcf_head common.tcfa_head
#define tcf_index common.tcfa_index
diff --git a/include/net/pkt_cls.h b/include/net/pkt_cls.h
index f0a0514..b43077e 100644
--- a/include/net/pkt_cls.h
+++ b/include/net/pkt_cls.h
@@ -515,4 +515,12 @@ struct tc_cls_bpf_offload {
u32 gen_flags;
};
+
+/* This structure holds cookie structure that is passed from user
+ * to the kernel for actions and classifiers
+ */
+struct tc_cookie {
+ u8 *data;
+ u32 len;
+};
#endif
diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
index fd373eb..345551e 100644
--- a/include/uapi/linux/pkt_cls.h
+++ b/include/uapi/linux/pkt_cls.h
@@ -4,6 +4,8 @@
#include <linux/types.h>
#include <linux/pkt_sched.h>
+#define TC_COOKIE_MAX_SIZE 16
+
/* Action attributes */
enum {
TCA_ACT_UNSPEC,
@@ -12,6 +14,7 @@ enum {
TCA_ACT_INDEX,
TCA_ACT_STATS,
TCA_ACT_PAD,
+ TCA_ACT_COOKIE,
__TCA_ACT_MAX
};
diff --git a/net/sched/act_api.c b/net/sched/act_api.c
index cd08df9..58cf1c5 100644
--- a/net/sched/act_api.c
+++ b/net/sched/act_api.c
@@ -24,6 +24,7 @@
#include <net/net_namespace.h>
#include <net/sock.h>
#include <net/sch_generic.h>
+#include <net/pkt_cls.h>
#include <net/act_api.h>
#include <net/netlink.h>
@@ -33,6 +34,8 @@ static void free_tcf(struct rcu_head *head)
free_percpu(p->cpu_bstats);
free_percpu(p->cpu_qstats);
+ kfree(p->act_cookie->data);
+ kfree(p->act_cookie);
kfree(p);
}
@@ -475,6 +478,12 @@ int tcf_action_destroy(struct list_head *actions, int bind)
goto nla_put_failure;
if (tcf_action_copy_stats(skb, a, 0))
goto nla_put_failure;
+ if (a->act_cookie) {
+ if (nla_put(skb, TCA_ACT_COOKIE, a->act_cookie->len,
+ a->act_cookie->data))
+ goto nla_put_failure;
+ }
+
nest = nla_nest_start(skb, TCA_OPTIONS);
if (nest == NULL)
goto nla_put_failure;
@@ -575,6 +584,33 @@ struct tc_action *tcf_action_init_1(struct net *net, struct nlattr *nla,
if (err < 0)
goto err_mod;
+ if (tb[TCA_ACT_COOKIE]) {
+ int cklen = nla_len(tb[TCA_ACT_COOKIE]);
+
+ if (cklen > TC_COOKIE_MAX_SIZE) {
+ err = -EINVAL;
+ tcf_hash_release(a, bind);
+ goto err_mod;
+ }
+
+ a->act_cookie = kzalloc(sizeof(*a->act_cookie), GFP_KERNEL);
+ if (!a->act_cookie) {
+ err = -ENOMEM;
+ tcf_hash_release(a, bind);
+ goto err_mod;
+ }
+
+ a->act_cookie->data = nla_memdup(tb[TCA_ACT_COOKIE],
+ GFP_KERNEL);
+ if (!a->act_cookie->data) {
+ err = -ENOMEM;
+ kfree(a->act_cookie);
+ tcf_hash_release(a, bind);
+ goto err_mod;
+ }
+ a->act_cookie->len = cklen;
+ }
+
/* module count goes up only when brand new policy is created
* if it exists and is only bound to in a_o->init() then
* ACT_P_CREATED is not returned (a zero is).
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next v5 1/1] net sched actions: Add support for user cookies
From: Jamal Hadi Salim @ 2017-01-22 19:44 UTC (permalink / raw)
To: Jiri Pirko
Cc: Florian Fainelli, davem, netdev, jiri, paulb, john.fastabend,
simon.horman, mrv, hadarh, ogerlitz, roid, xiyou.wangcong, daniel
In-Reply-To: <20170122193208.GC1797@nanopsycho.orion>
On 17-01-22 02:32 PM, Jiri Pirko wrote:
> Sun, Jan 22, 2017 at 07:57:17PM CET, jhs@mojatatu.com wrote:
>> On 17-01-22 01:13 PM, Florian Fainelli wrote:
>>>
>>>
>>
>>>
>>>> + a->act_cookie->data = nla_memdup(tb[TCA_ACT_COOKIE],
>>>> + GFP_KERNEL);
>>>> + if (!a->act_cookie->data) {
>>>> + err = -ENOMEM;
>>>> + tcf_hash_release(a, bind);
>>>> + goto err_mod;
>>>> + }
>>>
>>> Are not you leaking a->act_cookie here in case nla_memdup() fails here?
>>>
>>
>> yes, I am. Thanks for catching this. V6 coming up.
>
> Btw, you don't have to send cover letter for a single patch. In fact, you
> should not.
>
You can see i write small novels in my commit logs. Do you suggest i
put the git history there as well?
cheers,
jamal
^ permalink raw reply
* Re: [PATCH net-next v5 1/1] net sched actions: Add support for user cookies
From: Jiri Pirko @ 2017-01-22 19:32 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: Florian Fainelli, davem, netdev, jiri, paulb, john.fastabend,
simon.horman, mrv, hadarh, ogerlitz, roid, xiyou.wangcong, daniel
In-Reply-To: <57017269-891c-6347-33e5-600fe8b1726e@mojatatu.com>
Sun, Jan 22, 2017 at 07:57:17PM CET, jhs@mojatatu.com wrote:
>On 17-01-22 01:13 PM, Florian Fainelli wrote:
>>
>>
>
>>
>> > + a->act_cookie->data = nla_memdup(tb[TCA_ACT_COOKIE],
>> > + GFP_KERNEL);
>> > + if (!a->act_cookie->data) {
>> > + err = -ENOMEM;
>> > + tcf_hash_release(a, bind);
>> > + goto err_mod;
>> > + }
>>
>> Are not you leaking a->act_cookie here in case nla_memdup() fails here?
>>
>
>yes, I am. Thanks for catching this. V6 coming up.
Btw, you don't have to send cover letter for a single patch. In fact, you
should not.
^ permalink raw reply
* [PATCH 3/3] sh_eth: stop using bare numbers for EESIPR values
From: Sergei Shtylyov @ 2017-01-22 19:19 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc
In-Reply-To: <1636105.gp4aQxGd5K@wasted.cogentembedded.com>
Now that we have almost all EESIPR bits declared (and those that are
still not are most probably reserved anyway) we can at last replace the
bare numbers used for 'sh_eth_cpu_data::eesipr_value' initializers with
the bit names ORed together...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.c | 89 +++++++++++++++++++++++++++++-----
1 file changed, 78 insertions(+), 11 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.c
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.c
+++ net-next/drivers/net/ethernet/renesas/sh_eth.c
@@ -518,7 +518,14 @@ static struct sh_eth_cpu_data r7s72100_d
.ecsr_value = ECSR_ICD,
.ecsipr_value = ECSIPR_ICDIP,
- .eesipr_value = 0xe77f009f,
+ .eesipr_value = EESIPR_TWB1IP | EESIPR_TWBIP | EESIPR_TC1IP |
+ EESIPR_TABTIP | EESIPR_RABTIP | EESIPR_RFCOFIP |
+ EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP |
+ EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
@@ -556,7 +563,14 @@ static struct sh_eth_cpu_data r8a7740_da
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003fffff,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ 0x0000f000 | EESIPR_CNDIP | EESIPR_DLCIP |
+ EESIPR_CDIP | EESIPR_TROIP | EESIPR_RMAFIP |
+ EESIPR_CEEFIP | EESIPR_CELFIP |
+ EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
@@ -603,7 +617,12 @@ static struct sh_eth_cpu_data r8a777x_da
.ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
.ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
- .eesipr_value = 0x01ff009f,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ADEIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP |
+ EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
@@ -626,7 +645,12 @@ static struct sh_eth_cpu_data r8a779x_da
.ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP |
ECSIPR_MPDIP,
- .eesipr_value = 0x01ff009f,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ADEIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP |
+ EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
@@ -667,7 +691,12 @@ static struct sh_eth_cpu_data sh7724_dat
.ecsr_value = ECSR_PSRTO | ECSR_LCHNG | ECSR_ICD,
.ecsipr_value = ECSIPR_PSRTOIP | ECSIPR_LCHNGIP | ECSIPR_ICDIP,
- .eesipr_value = 0x01ff009f,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ADEIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_RRFIP |
+ EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
@@ -702,7 +731,14 @@ static struct sh_eth_cpu_data sh7757_dat
.register_type = SH_ETH_REG_FAST_SH4,
- .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003fffff,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ 0x0000f000 | EESIPR_CNDIP | EESIPR_DLCIP |
+ EESIPR_CDIP | EESIPR_TROIP | EESIPR_RMAFIP |
+ EESIPR_CEEFIP | EESIPR_CELFIP |
+ EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_FTC | EESR_CND | EESR_DLC | EESR_CD | EESR_RTO,
.eesr_err_check = EESR_TWB | EESR_TABT | EESR_RABT | EESR_RFE |
@@ -769,7 +805,14 @@ static struct sh_eth_cpu_data sh7757_dat
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003fffff,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ 0x0000f000 | EESIPR_CNDIP | EESIPR_DLCIP |
+ EESIPR_CDIP | EESIPR_TROIP | EESIPR_RMAFIP |
+ EESIPR_CEEFIP | EESIPR_CELFIP |
+ EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
@@ -800,7 +843,12 @@ static struct sh_eth_cpu_data sh7734_dat
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003f07ff,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_CEEFIP | EESIPR_CELFIP |
+ EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
@@ -830,7 +878,12 @@ static struct sh_eth_cpu_data sh7763_dat
.ecsr_value = ECSR_ICD | ECSR_MPD,
.ecsipr_value = ECSIPR_LCHNGIP | ECSIPR_ICDIP | ECSIPR_MPDIP,
- .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003f07ff,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ EESIPR_RMAFIP | EESIPR_CEEFIP | EESIPR_CELFIP |
+ EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tx_check = EESR_TC1 | EESR_FTC,
.eesr_err_check = EESR_TWB1 | EESR_TWB | EESR_TABT | EESR_RABT |
@@ -851,7 +904,14 @@ static struct sh_eth_cpu_data sh7763_dat
static struct sh_eth_cpu_data sh7619_data = {
.register_type = SH_ETH_REG_FAST_SH3_SH2,
- .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003fffff,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ 0x0000f000 | EESIPR_CNDIP | EESIPR_DLCIP |
+ EESIPR_CDIP | EESIPR_TROIP | EESIPR_RMAFIP |
+ EESIPR_CEEFIP | EESIPR_CELFIP |
+ EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.apr = 1,
.mpr = 1,
@@ -862,7 +922,14 @@ static struct sh_eth_cpu_data sh7619_dat
static struct sh_eth_cpu_data sh771x_data = {
.register_type = SH_ETH_REG_FAST_SH3_SH2,
- .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP | 0x003fffff,
+ .eesipr_value = EESIPR_RFCOFIP | EESIPR_ECIIP |
+ EESIPR_FTCIP | EESIPR_TDEIP | EESIPR_TFUFIP |
+ EESIPR_FRIP | EESIPR_RDEIP | EESIPR_RFOFIP |
+ 0x0000f000 | EESIPR_CNDIP | EESIPR_DLCIP |
+ EESIPR_CDIP | EESIPR_TROIP | EESIPR_RMAFIP |
+ EESIPR_CEEFIP | EESIPR_CELFIP |
+ EESIPR_RRFIP | EESIPR_RTLFIP | EESIPR_RTSFIP |
+ EESIPR_PREIP | EESIPR_CERFIP,
.tsu = 1,
};
^ permalink raw reply
* [PATCH 2/3] sh_eth: add missing EESIPR bits
From: Sergei Shtylyov @ 2017-01-22 19:18 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc
In-Reply-To: <1636105.gp4aQxGd5K@wasted.cogentembedded.com>
Renesas SH77{34|63} manuals describe more EESIPR bits than the current
driver. Declare the new bits with the end goal of using the bit names
instead of the bare numbers for the 'sh_eth_cpu_data::eesipr_value'
initializers...
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
drivers/net/ethernet/renesas/sh_eth.h | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
Index: net-next/drivers/net/ethernet/renesas/sh_eth.h
===================================================================
--- net-next.orig/drivers/net/ethernet/renesas/sh_eth.h
+++ net-next/drivers/net/ethernet/renesas/sh_eth.h
@@ -269,13 +269,17 @@ enum EESR_BIT {
/* EESIPR */
enum EESIPR_BIT {
- EESIPR_TWBIP = 0x40000000,
+ EESIPR_TWB1IP = 0x80000000,
+ EESIPR_TWBIP = 0x40000000, /* same as TWB0IP */
+ EESIPR_TC1IP = 0x20000000,
+ EESIPR_TUCIP = 0x10000000,
+ EESIPR_ROCIP = 0x08000000,
EESIPR_TABTIP = 0x04000000,
EESIPR_RABTIP = 0x02000000,
EESIPR_RFCOFIP = 0x01000000,
EESIPR_ADEIP = 0x00800000,
EESIPR_ECIIP = 0x00400000,
- EESIPR_FTCIP = 0x00200000,
+ EESIPR_FTCIP = 0x00200000, /* same as TC0IP */
EESIPR_TDEIP = 0x00100000,
EESIPR_TFUFIP = 0x00080000,
EESIPR_FRIP = 0x00040000,
@@ -286,6 +290,8 @@ enum EESIPR_BIT {
EESIPR_CDIP = 0x00000200,
EESIPR_TROIP = 0x00000100,
EESIPR_RMAFIP = 0x00000080,
+ EESIPR_CEEFIP = 0x00000040,
+ EESIPR_CELFIP = 0x00000020,
EESIPR_RRFIP = 0x00000010,
EESIPR_RTLFIP = 0x00000008,
EESIPR_RTSFIP = 0x00000004,
^ 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