* Re: [PATCH v5 0/5] M_CAN Framework re-write
From: Wolfgang Grandegger @ 2019-02-22 9:38 UTC (permalink / raw)
To: Dan Murphy, mkl, davem; +Cc: linux-can, netdev, linux-kernel
In-Reply-To: <43e01edf-9b9a-c68d-ec1a-218a8117f59e@grandegger.com>
Hello Dan,
what kernel version is that patch series for. I have problems to apply it!
Wolfgang.
Am 21.02.19 um 17:41 schrieb Wolfgang Grandegger:
> Hello Dan,
>
> I will have a closer look end of this week!
>
> Wolfgang.
>
> Am 21.02.19 um 17:24 schrieb Dan Murphy:
>> Bump
>>
>> On 2/14/19 12:27 PM, Dan Murphy wrote:
>>> Hello
>>>
>>> OK I did not give up on this patch series just got a little preoccupied with
>>> some other kernel work. But here is the update per the comments.
>>>
>>> It should be understood I broke these out for reviewability.
>>> For instance the first patch does not compile on its own as including this
>>> patch should not change the current functionality and it pulls all the io-mapped
>>> code from the m_can base file to a platfrom file.
>>>
>>> The next patch "Migrate the m_can code to use the framework"
>>> is the change to the kernel for the io-mapped conversion from a flat file to use
>>> the framework. Finally the rename patch just renames the m_can_priv to
>>> m_can_classdev. I broke this change out specifically for readability of the
>>> migration patch per comments on the code.
>>>
>>> AFAIC the first 3 patches can all be squashed into a single patch. Or the
>>> first 2 patches in the series can be re-arranged but then m_can functionality is
>>> affected in the migration patch.
>>>
>>> Again the first 3 patches here are all just for readability and review purposes.
>>>
>>> Dan
>>>
>>> Dan Murphy (5):
>>> can: m_can: Create a m_can platform framework
>>> can: m_can: Migrate the m_can code to use the framework
>>> can: m_can: Rename m_can_priv to m_can_classdev
>>> dt-bindings: can: tcan4x5x: Add DT bindings for TCAN4x5X driver
>>> can: tcan4x5x: Add tcan4x5x driver to the kernel
>>>
>>> .../devicetree/bindings/net/can/tcan4x5x.txt | 37 +
>>> drivers/net/can/m_can/Kconfig | 14 +-
>>> drivers/net/can/m_can/Makefile | 2 +
>>> drivers/net/can/m_can/m_can.c | 788 +++++++++---------
>>> drivers/net/can/m_can/m_can.h | 159 ++++
>>> drivers/net/can/m_can/m_can_platform.c | 198 +++++
>>> drivers/net/can/m_can/tcan4x5x.c | 531 ++++++++++++
>>> 7 files changed, 1320 insertions(+), 409 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/net/can/tcan4x5x.txt
>>> create mode 100644 drivers/net/can/m_can/m_can.h
>>> create mode 100644 drivers/net/can/m_can/m_can_platform.c
>>> create mode 100644 drivers/net/can/m_can/tcan4x5x.c
>>>
>>
>>
^ permalink raw reply
* [PATCH net-next v2] route: Add a new fib_multipath_hash_policy base on cpu id for tunnel packet
From: wenxu @ 2019-02-22 9:20 UTC (permalink / raw)
To: davem; +Cc: netdev
From: wenxu <wenxu@ucloud.cn>
Current fib_multipath_hash_policy can make hash based on the L3 or
L4. But it only work on the outer IP. So a specific tunnel always
has the same hash value. But a specific tunnel may contain so many
inner connections. However there is no good way for tunnel packet.
A specific tunnel route based on the percpu dst_cache. It will not
lookup route table for each packet.
This patch provide a based cpu id hash policy. The different
connection run on different cpu and there will be different hash
value for percpu dst_cache.
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
net/ipv4/route.c | 6 ++++++
net/ipv4/sysctl_net_ipv4.c | 2 +-
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index ecc12a7..6cf2fd4 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1821,6 +1821,7 @@ int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
const struct sk_buff *skb, struct flow_keys *flkeys)
{
struct flow_keys hash_keys;
+ u32 cpu = 0;
u32 mhash;
switch (net->ipv4.sysctl_fib_multipath_hash_policy) {
@@ -1834,6 +1835,8 @@ int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
hash_keys.addrs.v4addrs.dst = fl4->daddr;
}
break;
+ case 2:
+ cpu = smp_processor_id() + 1;
case 1:
/* skb is currently provided only when forwarding */
if (skb) {
@@ -1870,6 +1873,9 @@ int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
}
mhash = flow_hash_from_keys(&hash_keys);
+ if (cpu)
+ mhash = jhash_2words(mhash, cpu, 0);
+
return mhash >> 1;
}
#endif /* CONFIG_IP_ROUTE_MULTIPATH */
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index ba0fc4b..708bbbb 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -951,7 +951,7 @@ static int proc_fib_multipath_hash_policy(struct ctl_table *table, int write,
.mode = 0644,
.proc_handler = proc_fib_multipath_hash_policy,
.extra1 = &zero,
- .extra2 = &one,
+ .extra2 = &two,
},
#endif
{
--
1.8.3.1
^ permalink raw reply related
* Re: mlx5 stable backport help
From: Or Gerlitz @ 2019-02-22 9:13 UTC (permalink / raw)
To: Saeed Mahameed
Cc: davem@davemloft.net, netdev@vger.kernel.org, Or Gerlitz,
Roi Dayan
In-Reply-To: <7b4945782c33f4dbb3b4538fc2c40af86e7c5ae1.camel@mellanox.com>
On Fri, Feb 22, 2019 at 12:35 AM Saeed Mahameed <saeedm@mellanox.com> wrote:
> On Thu, 2019-02-21 at 12:21 +0200, Or Gerlitz wrote:
> So we all agree that the offending patch is "net/mlx5e: Support tunnel
> encap over tagged Ethernet" even if the issue existed before,
as you said the issue existed before we added support for offloading
tunnels in the presence of vlan on the underlay, it's like this since 4.12
when we introduced support for neigh update in 232c001398ae "net/mlx5e:
Add support to neighbour update flow" which is basically the one to blame/fix
since some code was moved and some code was added (e->route_dev)
backporting the patch without pulling more patches can be done as I sketched
below.
Anyway, we can maybe let it go without backporting, production environments
are typically not changing their source mac in prime time. So this can be seen
more as future proofing.
> in order to fix the issue you will have to port not only this patch but
> the whole series which claimed to fix the issue, so the fixes tag was
> wrong.. this patch on its own is no good.
>> [1] using e->out_dev instead of e->route_dev
>> [2] use the hunks from mlx5e_tc_tun_create_header_ipv4/6() in
>> mlx5e_create_encap_header_ipv4/6()
^ permalink raw reply
* [PATCH][net-next] net: Use RCU_INIT_POINTER() to set sk_wq
From: Li RongQing @ 2019-02-22 9:08 UTC (permalink / raw)
To: netdev
This pointer is RCU protected, so proper primitives should be used.
Signed-off-by: Zhang Yu <zhangyu31@baidu.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
net/core/sock.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index f4b8b78535f8..f5d82f3fa474 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1865,7 +1865,7 @@ struct sock *sk_clone_lock(const struct sock *sk, const gfp_t priority)
*/
sk_refcnt_debug_inc(newsk);
sk_set_socket(newsk, NULL);
- newsk->sk_wq = NULL;
+ RCU_INIT_POINTER(newsk->sk_wq, NULL);
if (newsk->sk_prot->sockets_allocated)
sk_sockets_allocated_inc(newsk);
@@ -2828,11 +2828,11 @@ void sock_init_data(struct socket *sock, struct sock *sk)
if (sock) {
sk->sk_type = sock->type;
- sk->sk_wq = sock->wq;
+ RCU_INIT_POINTER(sk->sk_wq, sock->wq);
sock->sk = sk;
sk->sk_uid = SOCK_INODE(sock)->i_uid;
} else {
- sk->sk_wq = NULL;
+ RCU_INIT_POINTER(sk->sk_wq, NULL);
sk->sk_uid = make_kuid(sock_net(sk)->user_ns, 0);
}
--
2.16.2
^ permalink raw reply related
* Re: [PATCH v2 iproute2-next 04/11] devlink: Add helper functions for name and value separately
From: Jiri Pirko @ 2019-02-22 8:58 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Aya Levin, David Ahern, netdev, Jiri Pirko, Moshe Shemesh,
Eran Ben Elisha
In-Reply-To: <20190221100211.28cef41a@shemminger-XPS-13-9360>
Thu, Feb 21, 2019 at 07:02:11PM CET, stephen@networkplumber.org wrote:
>On Thu, 21 Feb 2019 15:42:40 +0200
>Aya Levin <ayal@mellanox.com> wrote:
>
>> Add a new helper functions which outputs only values (without name
>> label) for different types: boolean, uint, uint64, string and binary.
>> In addition add a helper function which prints only the name label.
>>
>> Signed-off-by: Aya Levin <ayal@mellanox.com>
>> Reviewed-by: Moshe Shemesh <moshe@mellanox.com>
>> ---
>> devlink/devlink.c | 66 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 65 insertions(+), 1 deletion(-)
>>
>> diff --git a/devlink/devlink.c b/devlink/devlink.c
>> index b073ae020d52..5d69c4f24f29 100644
>> --- a/devlink/devlink.c
>> +++ b/devlink/devlink.c
>> @@ -1588,7 +1588,6 @@ static void pr_out_port_handle_end(struct dl *dl)
>> pr_out("\n");
>> }
>>
>> -
>> static void pr_out_str(struct dl *dl, const char *name, const char *val)
>> {
>> if (dl->json_output) {
>> @@ -1636,6 +1635,71 @@ static void pr_out_u64(struct dl *dl, const char *name, uint64_t val)
>> }
>> }
>>
>> +static void pr_out_bool_value(struct dl *dl, bool value)
>> +{
>> + if (dl->json_output)
>> + jsonw_bool(dl->jw, value);
>> + else
>> + pr_out(" %s", value ? "true" : "false");
>> +}
>> +
>> +static void pr_out_uint_value(struct dl *dl, unsigned int value)
>> +{
>> + if (dl->json_output)
>> + jsonw_uint(dl->jw, value);
>> + else
>> + pr_out(" %u", value);
>> +}
>> +
>> +static void pr_out_uint64_value(struct dl *dl, uint64_t value)
>> +{
>> + if (dl->json_output)
>> + jsonw_u64(dl->jw, value);
>> + else
>> + pr_out(" %lu", value);
>> +}
>> +
>> +static void pr_out_binary_value(struct dl *dl, uint8_t *data, uint32_t len)
>> +{
>> + int i = 1;
>> +
>> + if (dl->json_output)
>> + jsonw_start_array(dl->jw);
>> + else
>> + pr_out("\n");
>> +
>> + while (i < len) {
>> + if (dl->json_output) {
>> + jsonw_printf(dl->jw, "%d", data[i]);
>> + } else {
>> + pr_out(" %02x", data[i]);
>> + if (!(i % 16))
>> + pr_out("\n");
>> + }
>> + i++;
>> + }
>> + if (dl->json_output)
>> + jsonw_end_array(dl->jw);
>> + else if ((i - 1) % 16)
>> + pr_out("\n");
>> +}
>> +
>> +static void pr_out_str_value(struct dl *dl, const char *value)
>> +{
>> + if (dl->json_output)
>> + jsonw_string(dl->jw, value);
>> + else
>> + pr_out(" %s", value);
>> +}
>> +
>> +static void pr_out_name(struct dl *dl, const char *name)
>> +{
>> + if (dl->json_output)
>> + jsonw_name(dl->jw, name);
>> + else
>> + pr_out(" %s:", name);
>> +}
>> +
>> static void pr_out_region_chunk_start(struct dl *dl, uint64_t addr)
>> {
>> if (dl->json_output) {
>
>NAK
>
>Please convert devlink to use existing iproute2 json_print infrasructure
>rather than reinventing it.
That requires whole devlink/devlink.c code change. Could this be done as
a follow-up?
^ permalink raw reply
* Re: [PATCH net-next] route: Add a new fib_multipath_hash_policy base on cpu id for tunnel packet
From: Sergei Shtylyov @ 2019-02-22 9:06 UTC (permalink / raw)
To: wenxu, davem; +Cc: netdev
In-Reply-To: <1550807549-22720-1-git-send-email-wenxu@ucloud.cn>
Hello!
On 22.02.2019 6:52, wenxu@ucloud.cn wrote:
> From: wenxu <wenxu@ucloud.cn>
>
> Current fib_multipath_hash_policy can make hash based on the L3 or
> L4. But it only work on the outer IP. So a specific tunnel always
> has the same hash value. But a specific tunnel may contain so many
> inner connection. However there is no good ways for tunnel packet.
Connections? Way?
> A specific tunnel route based on the percpu dst_cache, It will not
> lookup route table each packet.
For each packet?
> This patch provide a based cpu id hash policy. The different
> connection run on differnt cpu and There will differnet hash
Different. Will be?
> value for percpu dst_cache.
>
> Signed-off-by: wenxu <wenxu@ucloud.cn>
> ---
> net/ipv4/route.c | 6 ++++++
> net/ipv4/sysctl_net_ipv4.c | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index ecc12a7..6cf2fd4 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
[...]
> @@ -1834,6 +1835,8 @@ int fib_multipath_hash(const struct net *net, const struct flowi4 *fl4,
> hash_keys.addrs.v4addrs.dst = fl4->daddr;
> }
> break;
> + case 2:
> + cpu = smp_processor_id() + 1;
Should be a comment /* fall through */ if this fall thru isn't in error.
> case 1:
> /* skb is currently provided only when forwarding */
> if (skb) {
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH net-next 2/5] net/mlx5e: Make the log friendly when decapsulation offload not supported
From: Or Gerlitz @ 2019-02-22 9:06 UTC (permalink / raw)
To: Tonghao Zhang; +Cc: Saeed Mahameed, Linux Netdev List
In-Reply-To: <CAMDZJNWrg_q9p8Av-xWwiCRte4XBn3Nd66EXh8EXpQG2gB0-=A@mail.gmail.com>
On Fri, Feb 22, 2019 at 9:49 AM Tonghao Zhang <xiangxia.m.yue@gmail.com> wrote:
>
> On Fri, Feb 22, 2019 at 12:32 AM Or Gerlitz <gerlitz.or@gmail.com> wrote:
> >
> > On Thu, Feb 21, 2019 at 3:42 PM <xiangxia.m.yue@gmail.com> wrote:
> > >
> > > From: Tonghao Zhang <xiangxia.m.yue@gmail.com>
> > >
> > > If we try to offload decapsulation actions to VFs hw, we get the log [1].
> >
> > but the switching was on the tunnel type (if (tunnel_type == [...]) -
> Yes, but we try to offload tc flow to VF device. For example
> the p2p1_0 is VF, but not rep
so this should go to the nic and not esw tc offload code path in en_tc.c
and the nic path (look for parse_tc_nic_actions or a like) doesn't have
a case for the tunnel key action - you should not have got to this code
at all, please look deeper to realize what is going on there, maybe p2p1_0
is a rep? what does ip -d link show gives on it?
^ permalink raw reply
* Re: [PATCH v2] iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_debug_range_resp
From: Arnd Bergmann @ 2019-02-22 8:52 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Nathan Chancellor, Johannes Berg, Emmanuel Grumbach, Luca Coelho,
Intel Linux Wireless, Kalle Valo, linux-wireless, Networking,
LKML
In-Reply-To: <CAKwvOdmCeHxiGPkXXzjwnTtgzEDDjYRE1QBdu7BHeuzCE4YtRA@mail.gmail.com>
On Fri, Feb 22, 2019 at 1:14 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
> On Thu, Feb 21, 2019 at 12:08 AM Nathan Chancellor <natechancellor@gmail.com> wrote:
> One thing I'm curious about, is "why does do_div exist?" When should I
> use do_div vs div_u64 (not div_s64 as is used in this patch)?
I think do_div() is mostly historic, we've had it since the early days
when C compilers were not as good with inline functions. The various
other versions are regular functions, and I tend to prefer them for new
code, but do_div() is widely known and documented, so I have little
hope of it going away any time soon.
Arnd
^ permalink raw reply
* [PATCH v2] bpf: test_bpf: turn of preemption in function __run_once
From: Anders Roxell @ 2019-02-22 8:46 UTC (permalink / raw)
To: ast, daniel; +Cc: netdev, linux-kernel, Anders Roxell, Arnd Bergmann
When running BPF test suite the following splat occurs:
[ 415.930950] test_bpf: #0 TAX jited:0
[ 415.931067] BUG: assuming atomic context at lib/test_bpf.c:6674
[ 415.946169] in_atomic(): 0, irqs_disabled(): 0, pid: 11556, name: modprobe
[ 415.953176] INFO: lockdep is turned off.
[ 415.957207] CPU: 1 PID: 11556 Comm: modprobe Tainted: G W 5.0.0-rc7-next-20190220 #1
[ 415.966328] Hardware name: HiKey Development Board (DT)
[ 415.971592] Call trace:
[ 415.974069] dump_backtrace+0x0/0x160
[ 415.977761] show_stack+0x24/0x30
[ 415.981104] dump_stack+0xc8/0x114
[ 415.984534] __cant_sleep+0xf0/0x108
[ 415.988145] test_bpf_init+0x5e0/0x1000 [test_bpf]
[ 415.992971] do_one_initcall+0x90/0x428
[ 415.996837] do_init_module+0x60/0x1e4
[ 416.000614] load_module+0x1de0/0x1f50
[ 416.004391] __se_sys_finit_module+0xc8/0xe0
[ 416.008691] __arm64_sys_finit_module+0x24/0x30
[ 416.013255] el0_svc_common+0x78/0x130
[ 416.017031] el0_svc_handler+0x38/0x78
[ 416.020806] el0_svc+0x8/0xc
Rework so that preemption is disabled when we loop over function
'BPF_PROG_RUN(...)'.
Commit 568f196756ad ("bpf: check that BPF programs run with preemption disabled")
highlighted the issue.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
---
lib/test_bpf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/test_bpf.c b/lib/test_bpf.c
index f3e570722a7e..0845f635f404 100644
--- a/lib/test_bpf.c
+++ b/lib/test_bpf.c
@@ -6668,12 +6668,14 @@ static int __run_one(const struct bpf_prog *fp, const void *data,
u64 start, finish;
int ret = 0, i;
+ preempt_disable();
start = ktime_get_ns();
for (i = 0; i < runs; i++)
ret = BPF_PROG_RUN(fp, data);
finish = ktime_get_ns();
+ preempt_enable();
*duration = finish - start;
do_div(*duration, runs);
--
2.20.1
^ permalink raw reply related
* [PATCH] sctp: don't compare hb_timer expire date before starting it
From: kwiecienmaciek @ 2019-02-22 8:45 UTC (permalink / raw)
To: linux-sctp; +Cc: netdev, alexander.sverdlin, Maciej Kwiecien
From: Maciej Kwiecien <maciej.kwiecien@nokia.com>
hb_timer might not start at all for a particular transport because its
start is conditional. In a result a node is not sending heartbeats.
Function sctp_transport_reset_hb_timer has two roles:
- initial start of hb_timer for a given transport,
- update expire date of hb_timer for a given transport.
The function is optimized to update timer's expire only if it is before
a new calculated one but this comparison is invalid for a timer which
has not yet started. Such a timer has expire == 0 and if a new expire
value is bigger than (MAX_JIFFIES / 2 + 2) then "time_before" macro will
fail and timer will not start resulting in no heartbeat packets send by
the node.
This was found when association was initialized within first 5 mins
after system boot due to jiffies init value which is near to MAX_JIFFIES.
Test kernel version: 4.9.154 (ARCH=arm)
hb_timer.expire = 0; //initialized, not started timer
new_expire = MAX_JIFFIES / 2 + 2; //or more
time_before(hb_timer.expire, new_expire) == false
Fixes: ba6f5e33bdbb ("sctp: avoid refreshing heartbeat timer too often")
Reported-by: Marcin Stojek <marcin.stojek@nokia.com>
Tested-by: Marcin Stojek <marcin.stojek@nokia.com>
Signed-off-by: Maciej Kwiecien <maciej.kwiecien@nokia.com>
---
net/sctp/transport.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/sctp/transport.c b/net/sctp/transport.c
index 033696e6f74f..ad158d311ffa 100644
--- a/net/sctp/transport.c
+++ b/net/sctp/transport.c
@@ -207,7 +207,8 @@ void sctp_transport_reset_hb_timer(struct sctp_transport *transport)
/* When a data chunk is sent, reset the heartbeat interval. */
expires = jiffies + sctp_transport_timeout(transport);
- if (time_before(transport->hb_timer.expires, expires) &&
+ if ((time_before(transport->hb_timer.expires, expires) ||
+ !timer_pending(&transport->hb_timer)) &&
!mod_timer(&transport->hb_timer,
expires + prandom_u32_max(transport->rto)))
sctp_transport_hold(transport);
--
2.14.1
^ permalink raw reply related
* [PATCH V2 4/8] net: ethernet: stmmac: add management of clk_csr property
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
In Documentation stmmac.txt there is possibility to
fixed CSR Clock range selection with property clk_csr.
This patch add the management of this property
For example to use it, add in your ethernet node DT:
clk_csr = <3>;
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 2b800ce..3031f2b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -408,6 +408,9 @@ stmmac_probe_config_dt(struct platform_device *pdev, const char **mac)
/* Default to phy auto-detection */
plat->phy_addr = -1;
+ /* Get clk_csr from device tree */
+ of_property_read_u32(np, "clk_csr", &plat->clk_csr);
+
/* "snps,phy-addr" is not a standard property. Mark it as deprecated
* and warn of its use. Remove this when phy node support is added.
*/
--
2.7.4
^ permalink raw reply related
* [PATCH V2 0/8] stmmac: add some fixes for stm32
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
For common stmmac:
- Add support to set CSR Clock range selection in DT
For stm32mpu:
- Glue codes to support magic packet
- Glue codes to support all PHY config :
PHY_MODE (MII,GMII, RMII, RGMII) and in normal,
PHY wo crystal (25Mhz),
PHY wo crystal (50Mhz), No 125Mhz from PHY config
For stm32mcu:
- Add Ethernet support for stm32h7
- Add syscfg clk support for stm32f4
Changes in V2:
Apply remarks from andrew lunn
- add all interfaces RGMII*
- reg value should be the same as ethernet-phy@X
Christophe Roullier (8):
net: ethernet: stmmac: manage Ethernet WoL for stm32mp157c.
net: ethernet: stmmac: update to support all PHY config for
stm32mp157c.
dt-bindings: net: stmmac: add phys config properties
net: ethernet: stmmac: add management of clk_csr property
net: ethernet: stmmac: update to be compatible with MCU family
(stm32f4, stm32h7)
dt-bindings: net: stmmac: add syscfg clock property
ARM: dts: stm32: Add Ethernet support on stm32h7 SOC and activate it
for eval and disco boards
ARM: dts: stm32: add syscfg clock support for Ethernet on STM32F429
SoC
.../devicetree/bindings/net/stm32-dwmac.txt | 10 +-
arch/arm/boot/dts/stm32f429.dtsi | 6 +-
arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 15 ++
arch/arm/boot/dts/stm32h743.dtsi | 19 +++
arch/arm/boot/dts/stm32h743i-disco.dts | 17 ++
arch/arm/boot/dts/stm32h743i-eval.dts | 17 ++
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 182 +++++++++++++++++----
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 3 +
8 files changed, 233 insertions(+), 36 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH V2 1/8] net: ethernet: stmmac: manage Ethernet WoL for stm32mp157c.
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
Add glue codes to support magic packet on stm32mp157c
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 30 ++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 7e2e79d..d1cf145 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -42,6 +42,7 @@ struct stm32_dwmac {
struct clk *clk_ethstp;
struct clk *syscfg_clk;
bool int_phyclk; /* Clock from RCC to drive PHY */
+ int irq_pwr_wakeup;
u32 mode_reg; /* MAC glue-logic mode register */
struct regmap *regmap;
u32 speed;
@@ -232,7 +233,9 @@ static int stm32_dwmac_parse_data(struct stm32_dwmac *dwmac,
static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct device_node *np = dev->of_node;
+ int err = 0;
dwmac->int_phyclk = of_property_read_bool(np, "st,int-phyclk");
@@ -260,7 +263,26 @@ static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
return PTR_ERR(dwmac->syscfg_clk);
}
- return 0;
+ /* Get IRQ information early to have an ability to ask for deferred
+ * probe if needed before we went too far with resource allocation.
+ */
+ dwmac->irq_pwr_wakeup = platform_get_irq_byname(pdev,
+ "stm32_pwr_wakeup");
+ if (!dwmac->int_phyclk && dwmac->irq_pwr_wakeup >= 0) {
+ err = device_init_wakeup(&pdev->dev, true);
+ if (err) {
+ dev_err(&pdev->dev, "Failed to init wake up irq\n");
+ return err;
+ }
+ err = dev_pm_set_dedicated_wake_irq(&pdev->dev,
+ dwmac->irq_pwr_wakeup);
+ if (err) {
+ dev_err(&pdev->dev, "Failed to set wake up irq\n");
+ device_init_wakeup(&pdev->dev, false);
+ }
+ device_set_wakeup_enable(&pdev->dev, false);
+ }
+ return err;
}
static int stm32_dwmac_probe(struct platform_device *pdev)
@@ -326,9 +348,15 @@ static int stm32_dwmac_remove(struct platform_device *pdev)
struct net_device *ndev = platform_get_drvdata(pdev);
struct stmmac_priv *priv = netdev_priv(ndev);
int ret = stmmac_dvr_remove(&pdev->dev);
+ struct stm32_dwmac *dwmac = priv->plat->bsp_priv;
stm32_dwmac_clk_disable(priv->plat->bsp_priv);
+ if (dwmac->irq_pwr_wakeup >= 0) {
+ dev_pm_clear_wake_irq(&pdev->dev);
+ device_init_wakeup(&pdev->dev, false);
+ }
+
return ret;
}
--
2.7.4
^ permalink raw reply related
* [PATCH V2 3/8] dt-bindings: net: stmmac: add phys config properties
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
Add properties to support all Phy config
PHY_MODE (MII,GMII, RMII, RGMII) and in normal, PHY wo crystal (25Mhz),
PHY wo crystal (50Mhz), No 125Mhz from PHY config.
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
Documentation/devicetree/bindings/net/stm32-dwmac.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
index 1341012..f42dc68 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
@@ -24,9 +24,9 @@ Required properties:
encompases the glue register, and the offset of the control register.
Optional properties:
-- clock-names: For MPU family "mac-clk-ck" for PHY without quartz
-- st,int-phyclk (boolean) : valid only where PHY do not have quartz and need to be clock
- by RCC
+- clock-names: For MPU family "eth-ck" for PHY without quartz
+- st,eth_clk_sel (boolean) : set this property in RGMII PHY when you do not want use 125Mhz
+- st,eth_ref_clk_sel (boolean) : set this property in RMII mode when you have PHY without crystal 50MHz
Example:
--
2.7.4
^ permalink raw reply related
* [PATCH V2 2/8] net: ethernet: stmmac: update to support all PHY config for stm32mp157c.
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
Update glue codes to support all PHY config on stm32mp157c
PHY_MODE (MII,GMII, RMII, RGMII) and in normal, PHY wo crystal (25Mhz),
PHY wo crystal (50Mhz), No 125Mhz from PHY config.
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 105 +++++++++++++++++-----
1 file changed, 85 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index d1cf145..8d5150a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -25,9 +25,24 @@
#define SYSCFG_MCU_ETH_MASK BIT(23)
#define SYSCFG_MP1_ETH_MASK GENMASK(23, 16)
+#define SYSCFG_PMCCLRR_OFFSET 0x40
#define SYSCFG_PMCR_ETH_CLK_SEL BIT(16)
#define SYSCFG_PMCR_ETH_REF_CLK_SEL BIT(17)
+
+/* Ethernet PHY interface selection in register SYSCFG Configuration
+ *------------------------------------------
+ * src |BIT(23)| BIT(22)| BIT(21)|BIT(20)|
+ *------------------------------------------
+ * MII | 0 | 0 | 0 | 1 |
+ *------------------------------------------
+ * GMII | 0 | 0 | 0 | 0 |
+ *------------------------------------------
+ * RGMII | 0 | 0 | 1 | n/a |
+ *------------------------------------------
+ * RMII | 1 | 0 | 0 | n/a |
+ *------------------------------------------
+ */
#define SYSCFG_PMCR_ETH_SEL_MII BIT(20)
#define SYSCFG_PMCR_ETH_SEL_RGMII BIT(21)
#define SYSCFG_PMCR_ETH_SEL_RMII BIT(23)
@@ -35,15 +50,54 @@
#define SYSCFG_MCU_ETH_SEL_MII 0
#define SYSCFG_MCU_ETH_SEL_RMII 1
+/* STM32MP1 register definitions
+ *
+ * Below table summarizes the clock requirement and clock sources for
+ * supported phy interface modes.
+ * __________________________________________________________________________
+ *|PHY_MODE | Normal | PHY wo crystal| PHY wo crystal |No 125Mhz from PHY|
+ *| | | 25MHz | 50MHz | |
+ * ---------------------------------------------------------------------------
+ *| MII | - | eth-ck | n/a | n/a |
+ *| | | | | |
+ * ---------------------------------------------------------------------------
+ *| GMII | - | eth-ck | n/a | n/a |
+ *| | | | | |
+ * ---------------------------------------------------------------------------
+ *| RGMII | - | eth-ck | n/a | eth-ck (no pin) |
+ *| | | | | st,eth_clk_sel |
+ * ---------------------------------------------------------------------------
+ *| RMII | - | eth-ck | eth-ck | n/a |
+ *| | | | st,eth_ref_clk_sel | |
+ * ---------------------------------------------------------------------------
+ *
+ * BIT(17) : set this bit in RMII mode when you have PHY without crystal 50MHz
+ * BIT(16) : set this bit in GMII/RGMII PHY when you do not want use 125Mhz
+ * from PHY
+ *-----------------------------------------------------
+ * src | BIT(17) | BIT(16) |
+ *-----------------------------------------------------
+ * MII | n/a | n/a |
+ *-----------------------------------------------------
+ * GMII | n/a | st,eth_clk_sel |
+ *-----------------------------------------------------
+ * RGMII | n/a | st,eth_clk_sel |
+ *-----------------------------------------------------
+ * RMII | st,eth_ref_clk_sel | n/a |
+ *-----------------------------------------------------
+ *
+ */
+
struct stm32_dwmac {
struct clk *clk_tx;
struct clk *clk_rx;
struct clk *clk_eth_ck;
struct clk *clk_ethstp;
struct clk *syscfg_clk;
- bool int_phyclk; /* Clock from RCC to drive PHY */
+ int eth_clk_sel_reg;
+ int eth_ref_clk_sel_reg;
int irq_pwr_wakeup;
- u32 mode_reg; /* MAC glue-logic mode register */
+ u32 mode_reg; /* MAC glue-logic mode register */
struct regmap *regmap;
u32 speed;
const struct stm32_ops *ops;
@@ -103,7 +157,7 @@ static int stm32mp1_clk_prepare(struct stm32_dwmac *dwmac, bool prepare)
if (ret)
return ret;
- if (dwmac->int_phyclk) {
+ if (dwmac->clk_eth_ck) {
ret = clk_prepare_enable(dwmac->clk_eth_ck);
if (ret) {
clk_disable_unprepare(dwmac->syscfg_clk);
@@ -112,7 +166,7 @@ static int stm32mp1_clk_prepare(struct stm32_dwmac *dwmac, bool prepare)
}
} else {
clk_disable_unprepare(dwmac->syscfg_clk);
- if (dwmac->int_phyclk)
+ if (dwmac->clk_eth_ck)
clk_disable_unprepare(dwmac->clk_eth_ck);
}
return ret;
@@ -122,7 +176,7 @@ static int stm32mp1_set_mode(struct plat_stmmacenet_data *plat_dat)
{
struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
u32 reg = dwmac->mode_reg;
- int val;
+ int val, ret;
switch (plat_dat->interface) {
case PHY_INTERFACE_MODE_MII:
@@ -131,19 +185,22 @@ static int stm32mp1_set_mode(struct plat_stmmacenet_data *plat_dat)
break;
case PHY_INTERFACE_MODE_GMII:
val = SYSCFG_PMCR_ETH_SEL_GMII;
- if (dwmac->int_phyclk)
+ if (dwmac->eth_clk_sel_reg)
val |= SYSCFG_PMCR_ETH_CLK_SEL;
pr_debug("SYSCFG init : PHY_INTERFACE_MODE_GMII\n");
break;
case PHY_INTERFACE_MODE_RMII:
val = SYSCFG_PMCR_ETH_SEL_RMII;
- if (dwmac->int_phyclk)
+ if (dwmac->eth_ref_clk_sel_reg)
val |= SYSCFG_PMCR_ETH_REF_CLK_SEL;
pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RMII\n");
break;
case PHY_INTERFACE_MODE_RGMII:
+ case PHY_INTERFACE_MODE_RGMII_ID:
+ case PHY_INTERFACE_MODE_RGMII_RXID:
+ case PHY_INTERFACE_MODE_RGMII_TXID:
val = SYSCFG_PMCR_ETH_SEL_RGMII;
- if (dwmac->int_phyclk)
+ if (dwmac->eth_clk_sel_reg)
val |= SYSCFG_PMCR_ETH_CLK_SEL;
pr_debug("SYSCFG init : PHY_INTERFACE_MODE_RGMII\n");
break;
@@ -154,6 +211,11 @@ static int stm32mp1_set_mode(struct plat_stmmacenet_data *plat_dat)
return -EINVAL;
}
+ /* Need to update PMCCLRR (clear register) */
+ ret = regmap_write(dwmac->regmap, reg + SYSCFG_PMCCLRR_OFFSET,
+ dwmac->ops->syscfg_eth_mask);
+
+ /* Update PMCSETR (set register) */
return regmap_update_bits(dwmac->regmap, reg,
dwmac->ops->syscfg_eth_mask, val);
}
@@ -237,22 +299,25 @@ static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
struct device_node *np = dev->of_node;
int err = 0;
- dwmac->int_phyclk = of_property_read_bool(np, "st,int-phyclk");
+ /* Gigabit Ethernet 125MHz clock selection. */
+ dwmac->eth_clk_sel_reg = of_property_read_bool(np, "st,eth_clk_sel");
- /* Check if internal clk from RCC selected */
- if (dwmac->int_phyclk) {
- /* Get ETH_CLK clocks */
- dwmac->clk_eth_ck = devm_clk_get(dev, "eth-ck");
- if (IS_ERR(dwmac->clk_eth_ck)) {
- dev_err(dev, "No ETH CK clock provided...\n");
- return PTR_ERR(dwmac->clk_eth_ck);
- }
+ /* Ethernet 50Mhz RMII clock selection */
+ dwmac->eth_ref_clk_sel_reg =
+ of_property_read_bool(np, "st,eth_ref_clk_sel");
+
+ /* Get ETH_CLK clocks */
+ dwmac->clk_eth_ck = devm_clk_get(dev, "eth-ck");
+ if (IS_ERR(dwmac->clk_eth_ck)) {
+ dev_warn(dev, "No phy clock provided...\n");
+ dwmac->clk_eth_ck = NULL;
}
/* Clock used for low power mode */
dwmac->clk_ethstp = devm_clk_get(dev, "ethstp");
if (IS_ERR(dwmac->clk_ethstp)) {
- dev_err(dev, "No ETH peripheral clock provided for CStop mode ...\n");
+ dev_err(dev,
+ "No ETH peripheral clock provided for CStop mode ...\n");
return PTR_ERR(dwmac->clk_ethstp);
}
@@ -268,7 +333,7 @@ static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
*/
dwmac->irq_pwr_wakeup = platform_get_irq_byname(pdev,
"stm32_pwr_wakeup");
- if (!dwmac->int_phyclk && dwmac->irq_pwr_wakeup >= 0) {
+ if (!dwmac->clk_eth_ck && dwmac->irq_pwr_wakeup >= 0) {
err = device_init_wakeup(&pdev->dev, true);
if (err) {
dev_err(&pdev->dev, "Failed to init wake up irq\n");
@@ -370,7 +435,7 @@ static int stm32mp1_suspend(struct stm32_dwmac *dwmac)
clk_disable_unprepare(dwmac->clk_tx);
clk_disable_unprepare(dwmac->syscfg_clk);
- if (dwmac->int_phyclk)
+ if (dwmac->clk_eth_ck)
clk_disable_unprepare(dwmac->clk_eth_ck);
return ret;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 7/8] ARM: dts: stm32: Add Ethernet support on stm32h7 SOC and activate it for eval and disco boards
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
Synopsys GMAC 4.10 is used. And Phy mode for eval and disco is RMII
with PHY SMSC LAN8742
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
arch/arm/boot/dts/stm32h743-pinctrl.dtsi | 15 +++++++++++++++
arch/arm/boot/dts/stm32h743.dtsi | 19 +++++++++++++++++++
arch/arm/boot/dts/stm32h743i-disco.dts | 17 +++++++++++++++++
arch/arm/boot/dts/stm32h743i-eval.dts | 17 +++++++++++++++++
4 files changed, 68 insertions(+)
diff --git a/arch/arm/boot/dts/stm32h743-pinctrl.dtsi b/arch/arm/boot/dts/stm32h743-pinctrl.dtsi
index 24be8e6..980b276 100644
--- a/arch/arm/boot/dts/stm32h743-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32h743-pinctrl.dtsi
@@ -173,6 +173,21 @@
};
};
+ ethernet_rmii: rmii@0 {
+ pins {
+ pinmux = <STM32_PINMUX('G', 11, AF11)>,
+ <STM32_PINMUX('G', 13, AF11)>,
+ <STM32_PINMUX('G', 12, AF11)>,
+ <STM32_PINMUX('C', 4, AF11)>,
+ <STM32_PINMUX('C', 5, AF11)>,
+ <STM32_PINMUX('A', 7, AF11)>,
+ <STM32_PINMUX('C', 1, AF11)>,
+ <STM32_PINMUX('A', 2, AF11)>,
+ <STM32_PINMUX('A', 1, AF11)>;
+ slew-rate = <2>;
+ };
+ };
+
usart1_pins: usart1@0 {
pins1 {
pinmux = <STM32_PINMUX('B', 14, AF4)>; /* USART1_TX */
diff --git a/arch/arm/boot/dts/stm32h743.dtsi b/arch/arm/boot/dts/stm32h743.dtsi
index cbdd69c..f6384af 100644
--- a/arch/arm/boot/dts/stm32h743.dtsi
+++ b/arch/arm/boot/dts/stm32h743.dtsi
@@ -511,6 +511,25 @@
status = "disabled";
};
};
+
+ syscfg: system-config@58000400 {
+ compatible = "syscon";
+ reg = <0x58000400 0x400>;
+ };
+
+ mac: ethernet@40028000 {
+ compatible = "st,stm32-dwmac", "snps,dwmac-4.10a";
+ reg = <0x40028000 0x8000>;
+ reg-names = "stmmaceth";
+ interrupts = <61>;
+ interrupt-names = "macirq";
+ clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx",
+ "syscfg-clk";
+ clocks = <&rcc ETH1MAC_CK>, <&rcc ETH1TX_CK>, <&rcc ETH1RX_CK>, <&rcc SYSCFG_CK>;
+ st,syscon = <&syscfg 0x4>;
+ snps,pbl = <8>;
+ status = "disabled";
+ };
};
};
diff --git a/arch/arm/boot/dts/stm32h743i-disco.dts b/arch/arm/boot/dts/stm32h743i-disco.dts
index 45e088c..26ddd52 100644
--- a/arch/arm/boot/dts/stm32h743i-disco.dts
+++ b/arch/arm/boot/dts/stm32h743i-disco.dts
@@ -66,6 +66,23 @@
clock-frequency = <25000000>;
};
+&mac {
+ status = "okay";
+ pinctrl-0 = <ðernet_rmii>;
+ pinctrl-names = "default";
+ phy-mode = "rmii";
+ phy-handle = <&phy1>;
+
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+};
+
&usart2 {
pinctrl-0 = <&usart2_pins>;
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/stm32h743i-eval.dts b/arch/arm/boot/dts/stm32h743i-eval.dts
index 3f8e0c4..c1c1cc1 100644
--- a/arch/arm/boot/dts/stm32h743i-eval.dts
+++ b/arch/arm/boot/dts/stm32h743i-eval.dts
@@ -104,6 +104,23 @@
status = "okay";
};
+&mac {
+ status = "okay";
+ pinctrl-0 = <ðernet_rmii>;
+ pinctrl-names = "default";
+ phy-mode = "rmii";
+ phy-handle = <&phy1>;
+
+ mdio0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+ };
+};
+
&usart1 {
pinctrl-0 = <&usart1_pins>;
pinctrl-names = "default";
--
2.7.4
^ permalink raw reply related
* [PATCH V2 8/8] ARM: dts: stm32: add syscfg clock support for Ethernet on STM32F429 SoC
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
This patch add syscfg clock support for Ethernet of the STM32F429 SoC.
Needed if bootloader do not manage it.
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
arch/arm/boot/dts/stm32f429.dtsi | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 8d6f028..6f78346 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -657,10 +657,12 @@
reg-names = "stmmaceth";
interrupts = <61>;
interrupt-names = "macirq";
- clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx";
+ clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx",
+ "syscfg-clk";
clocks = <&rcc 0 STM32F4_AHB1_CLOCK(ETHMAC)>,
<&rcc 0 STM32F4_AHB1_CLOCK(ETHMACTX)>,
- <&rcc 0 STM32F4_AHB1_CLOCK(ETHMACRX)>;
+ <&rcc 0 STM32F4_AHB1_CLOCK(ETHMACRX)>,
+ <&rcc 0 STM32F4_APB2_CLOCK(SYSCFG)>;
st,syscon = <&syscfg 0x4>;
snps,pbl = <8>;
snps,mixed-burst;
--
2.7.4
^ permalink raw reply related
* [PATCH V2 6/8] dt-bindings: net: stmmac: add syscfg clock property
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
Need syscfg clock for MCU family in case bootloader does not
activate it.
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
Documentation/devicetree/bindings/net/stm32-dwmac.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.txt b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
index f42dc68..524f8a0 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.txt
@@ -14,8 +14,8 @@ Required properties:
- clock-names: Should be "stmmaceth" for the host clock.
Should be "mac-clk-tx" for the MAC TX clock.
Should be "mac-clk-rx" for the MAC RX clock.
- For MPU family need to add also "ethstp" for power mode clock and,
- "syscfg-clk" for SYSCFG clock.
+ Should be "syscfg-clk" for the SYSCFG clock.
+ For MPU family need to add also "ethstp" for power mode clock
- interrupt-names: Should contain a list of interrupt names corresponding to
the interrupts in the interrupts property, if available.
Should be "macirq" for the main MAC IRQ
--
2.7.4
^ permalink raw reply related
* [PATCH V2 5/8] net: ethernet: stmmac: update to be compatible with MCU family (stm32f4, stm32h7)
From: Christophe Roullier @ 2019-02-22 8:28 UTC (permalink / raw)
To: robh, davem, joabreu, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: linux-stm32, linux-kernel, devicetree, linux-arm-kernel, netdev,
christophe.roullier, andrew
In-Reply-To: <1550824089-19961-1-git-send-email-christophe.roullier@st.com>
Update glue codes to be compatible with MCU family.
Signed-off-by: Christophe Roullier <christophe.roullier@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 51 ++++++++++++++++++-----
1 file changed, 41 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 8d5150a..66d95c2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -6,7 +6,6 @@
* License terms: GNU General Public License (GPL), version 2
*
*/
-
#include <linux/clk.h>
#include <linux/kernel.h>
#include <linux/mfd/syscon.h>
@@ -119,12 +118,6 @@ static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
int ret;
- if (dwmac->ops->set_mode) {
- ret = dwmac->ops->set_mode(plat_dat);
- if (ret)
- return ret;
- }
-
ret = clk_prepare_enable(dwmac->clk_tx);
if (ret)
return ret;
@@ -139,13 +132,26 @@ static int stm32_dwmac_init(struct plat_stmmacenet_data *plat_dat)
if (dwmac->ops->clk_prepare) {
ret = dwmac->ops->clk_prepare(dwmac, true);
+ if (ret)
+ goto err_clk_disable;
+ }
+
+ if (dwmac->ops->set_mode) {
+ ret = dwmac->ops->set_mode(plat_dat);
if (ret) {
- clk_disable_unprepare(dwmac->clk_rx);
- clk_disable_unprepare(dwmac->clk_tx);
+ if (dwmac->ops->clk_prepare)
+ dwmac->ops->clk_prepare(dwmac, false);
+ goto err_clk_disable;
}
}
return ret;
+
+err_clk_disable:
+ clk_disable_unprepare(dwmac->clk_rx);
+ clk_disable_unprepare(dwmac->clk_tx);
+
+ return ret;
}
static int stm32mp1_clk_prepare(struct stm32_dwmac *dwmac, bool prepare)
@@ -243,7 +249,19 @@ static int stm32mcu_set_mode(struct plat_stmmacenet_data *plat_dat)
}
return regmap_update_bits(dwmac->regmap, reg,
- dwmac->ops->syscfg_eth_mask, val);
+ dwmac->ops->syscfg_eth_mask, val << 23);
+}
+
+static int stm32mcu_clk_prepare(struct stm32_dwmac *dwmac, bool prepare)
+{
+ int ret = 0;
+
+ if (prepare)
+ ret = clk_prepare_enable(dwmac->syscfg_clk);
+ else
+ clk_disable_unprepare(dwmac->syscfg_clk);
+
+ return ret;
}
static void stm32_dwmac_clk_disable(struct stm32_dwmac *dwmac)
@@ -350,6 +368,17 @@ static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
return err;
}
+static int stm32mcu_parse_data(struct stm32_dwmac *dwmac,
+ struct device *dev)
+{
+ /* Clock for sysconfig */
+ dwmac->syscfg_clk = devm_clk_get(dev, "syscfg-clk");
+ if (IS_ERR(dwmac->syscfg_clk))
+ dev_warn(dev, "No syscfg clock provided...\n");
+
+ return 0;
+}
+
static int stm32_dwmac_probe(struct platform_device *pdev)
{
struct plat_stmmacenet_data *plat_dat;
@@ -496,7 +525,9 @@ static SIMPLE_DEV_PM_OPS(stm32_dwmac_pm_ops,
static struct stm32_ops stm32mcu_dwmac_data = {
.set_mode = stm32mcu_set_mode,
+ .clk_prepare = stm32mcu_clk_prepare,
.suspend = stm32mcu_suspend,
+ .parse_data = stm32mcu_parse_data,
.syscfg_eth_mask = SYSCFG_MCU_ETH_MASK
};
--
2.7.4
^ permalink raw reply related
* [PATCH net-next] netfilter: nft_tunnel: Add dst_cache support
From: wenxu @ 2019-02-22 8:26 UTC (permalink / raw)
To: pablo; +Cc: netdev
From: wenxu <wenxu@ucloud.cn>
The metadata_dst is not init the dst_cache which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
net/netfilter/nft_tunnel.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/netfilter/nft_tunnel.c b/net/netfilter/nft_tunnel.c
index ea28588..b113fca 100644
--- a/net/netfilter/nft_tunnel.c
+++ b/net/netfilter/nft_tunnel.c
@@ -406,6 +406,13 @@ static int nft_tunnel_obj_init(const struct nft_ctx *ctx,
return -ENOMEM;
memcpy(&md->u.tun_info, &info, sizeof(info));
+#ifdef CONFIG_DST_CACHE
+ err = dst_cache_init(&md->u.tun_info.dst_cache, GFP_KERNEL);
+ if (err < 0) {
+ metadata_dst_free(md);
+ return err;
+ }
+#endif
ip_tunnel_info_opts_set(&md->u.tun_info, &priv->opts.u, priv->opts.len,
priv->opts.flags);
priv->md = md;
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] bpf: test_bpf: turn of preemption in function __run_once
From: Anders Roxell @ 2019-02-22 8:25 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: Alexei Starovoitov, Networking, Linux Kernel Mailing List
In-Reply-To: <c93b8a98-f76f-7c45-817a-0cd334273306@iogearbox.net>
On Thu, 21 Feb 2019 at 16:38, Daniel Borkmann <daniel@iogearbox.net> wrote:
>
> On 02/21/2019 09:44 AM, Anders Roxell wrote:
> > When running test seccomp_bpf the following splat occurs:
> >
> > [ RUN ] global.secseccomp_bpf.c:2136:global.detect_seccomp_filter_flags:Expected 22 (22) == (*__errno_location ()) (14)
> > seccomp_bpf.c:2138:global.detect_seccomp_filter_flags:Failed to detect that an unknown
> > filter flag (0x8) is unsupported! Does a new flag need to be added to this test?
> > [ 2155.677841] BUG: assuming atomic context at kernel/seccomp.c:271
> > [ 2155.689351] in_atomic(): 0, irqs_disabled(): 0, pid: 28540, name: seccomp_bpf
> > [ 2155.696597] INFO: lockdep is turned off.
> > [ 2155.700605] CPU: 5 PID: 28540 Comm: seccomp_bpf Tainted: G W 5.0.0-rc7-next-20190220 #1
> > [ 2155.709972] Hardware name: HiKey Development Board (DT)
> > [ 2155.715232] Call trace:
> > [ 2155.717710] dump_backtrace+0x0/0x160
> > [ 2155.721399] show_stack+0x24/0x30
> > [ 2155.724742] dump_stack+0xc8/0x114
> > [ 2155.728172] __cant_sleep+0xf0/0x108
> > [ 2155.731777] __seccomp_filter+0x8c/0x5c8
> > [ 2155.735727] __secure_computing+0x4c/0xe8
> > [ 2155.739767] syscall_trace_enter+0xf8/0x2b8
> > [ 2155.743982] el0_svc_common+0xf0/0x130
> > [ 2155.747758] el0_svc_handler+0x38/0x78
> > [ 2155.751534] el0_svc+0x8/0xc
> >
> > Rework so that preemption is disabled when we loop over function
> > 'BPF_PROG_RUN(...)'.
> > Commit 568f196756ad ("bpf: check that BPF programs run with preemption disabled")
> > highlighted the issue.
> >
> > Suggested-by: Arnd Bergmann <arnd@arndb.de>
> > Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
>
> Hmm, wrong commit description?
urgh, you are correct. I'm sorry.
Sending a v2 shortly.
> Below code is not related to seccomp
> but rather BPF test suite. Could you fix it up and resubmit? Rest
> looks okay to me.
>
> > ---
> > lib/test_bpf.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/lib/test_bpf.c b/lib/test_bpf.c
> > index f3e570722a7e..0845f635f404 100644
> > --- a/lib/test_bpf.c
> > +++ b/lib/test_bpf.c
> > @@ -6668,12 +6668,14 @@ static int __run_one(const struct bpf_prog *fp, const void *data,
> > u64 start, finish;
> > int ret = 0, i;
> >
> > + preempt_disable();
> > start = ktime_get_ns();
> >
> > for (i = 0; i < runs; i++)
> > ret = BPF_PROG_RUN(fp, data);
> >
> > finish = ktime_get_ns();
> > + preempt_enable();
> >
> > *duration = finish - start;
> > do_div(*duration, runs);
> >
>
^ permalink raw reply
* Re: [PATCH] bpfilter: re-add header search paths to tools include to fix build error
From: Masahiro Yamada @ 2019-02-22 8:23 UTC (permalink / raw)
To: Guenter Roeck
Cc: David S . Miller, Networking, Song Liu, Alexei Starovoitov,
Yonghong Song, Linux Kernel Mailing List, Martin KaFai Lau,
Daniel Borkmann
In-Reply-To: <80b08bfa-8052-aebb-db43-c7cbf3f5dd9d@roeck-us.net>
On Fri, Feb 22, 2019 at 2:55 PM Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 2/21/19 7:23 PM, Masahiro Yamada wrote:
> > I thought header search paths to tools/include(/uapi) were unneeded,
> > but it looks like a build error occurs depending on the compiler.
> >
> > Commit 303a339f30a9 ("bpfilter: remove extra header search paths for
> > bpfilter_umh") reintroduced the build error fixed by commit ae40832e53c3
> > ("bpfilter: fix a build err").
> >
> > Apology for the breakage, and thanks to Guenter for reporting this.
> >
> > Fixes: 303a339f30a9 ("bpfilter: remove extra header search paths for bpfilter_umh")
> > Reported-by: Guenter Roeck <linux@roeck-us.net>
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> Tested-by: Guenter Roeck <linux@roeck-us.net>
Thank you!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net-next 1/2] devlink: Rename devlink health attributes
From: Sergei Shtylyov @ 2019-02-22 7:59 UTC (permalink / raw)
To: Eran Ben Elisha, netdev, David S. Miller; +Cc: Jiri Pirko, Aya Levin
In-Reply-To: <1550751122-2788-2-git-send-email-eranbe@mellanox.com>
Hello!
On 21.02.2019 15:12, Eran Ben Elisha wrote:
> From: Aya Levin <ayal@mellanox.com>
>
> Rename devlink health attributes for better reflect the attributes use.
s/for/to/.
> Add COUNT prefix on error counter attribute and recovery counter
> attribute.
>
> Fixes: 7afe335a8bed ("devlink: Add health get command")
> Signed-off-by: Aya Levin <ayal@mellanox.com>
> Signed-off-by: Eran Ben Elisha <eranbe@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
[...]
MBR, Sergei
^ permalink raw reply
* [PATCH net-next] net/sched: act_tunnel_key: Add dst_cache support
From: wenxu @ 2019-02-22 7:58 UTC (permalink / raw)
To: jhs, davem; +Cc: netdev
From: wenxu <wenxu@ucloud.cn>
The metadata_dst is not init the dst_cache which make the
ip_md_tunnel_xmit can't use the dst_cache. It will lookup
route table every packets.
Signed-off-by: wenxu <wenxu@ucloud.cn>
---
net/sched/act_tunnel_key.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/net/sched/act_tunnel_key.c b/net/sched/act_tunnel_key.c
index 9104b8e..3404af7 100644
--- a/net/sched/act_tunnel_key.c
+++ b/net/sched/act_tunnel_key.c
@@ -321,12 +321,18 @@ static int tunnel_key_init(struct net *net, struct nlattr *nla,
goto err_out;
}
+#ifdef CONFIG_DST_CACHE
+ ret = dst_cache_init(&metadata->u.tun_info.dst_cache, GFP_KERNEL);
+ if (ret)
+ goto release_tun_meta;
+#endif
+
if (opts_len) {
ret = tunnel_key_opts_set(tb[TCA_TUNNEL_KEY_ENC_OPTS],
&metadata->u.tun_info,
opts_len, extack);
if (ret < 0)
- goto release_tun_meta;
+ goto release_dst_cache;
}
metadata->u.tun_info.mode |= IP_TUNNEL_INFO_TX;
@@ -342,14 +348,14 @@ static int tunnel_key_init(struct net *net, struct nlattr *nla,
&act_tunnel_key_ops, bind, true);
if (ret) {
NL_SET_ERR_MSG(extack, "Cannot create TC IDR");
- goto release_tun_meta;
+ goto release_dst_cache;
}
ret = ACT_P_CREATED;
} else if (!ovr) {
NL_SET_ERR_MSG(extack, "TC IDR already exists");
ret = -EEXIST;
- goto release_tun_meta;
+ goto release_dst_cache;
}
t = to_tunnel_key(*a);
@@ -359,7 +365,7 @@ static int tunnel_key_init(struct net *net, struct nlattr *nla,
NL_SET_ERR_MSG(extack, "Cannot allocate tunnel key parameters");
ret = -ENOMEM;
exists = true;
- goto release_tun_meta;
+ goto release_dst_cache;
}
params_new->tcft_action = parm->t_action;
params_new->tcft_enc_metadata = metadata;
@@ -376,6 +382,10 @@ static int tunnel_key_init(struct net *net, struct nlattr *nla,
return ret;
+release_dst_cache:
+#ifdef CONFIG_DST_CACHE
+ dst_cache_destroy(&metadata->u.tun_info.dst_cache);
+#endif
release_tun_meta:
dst_release(&metadata->dst);
@@ -391,8 +401,15 @@ static void tunnel_key_release(struct tc_action *a)
{
struct tcf_tunnel_key *t = to_tunnel_key(a);
struct tcf_tunnel_key_params *params;
+#ifdef CONFIG_DST_CACHE
+ struct ip_tunnel_info *info;
+#endif
params = rcu_dereference_protected(t->params, 1);
+#ifdef CONFIG_DST_CACHE
+ info = ¶ms->tcft_enc_metadata->u.tun_info;
+ dst_cache_destroy(&info->dst_cache);
+#endif
tunnel_key_release_params(params);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [Bridge] [PATCH net] net: bridge: remove ipv6 zero address check in mcast queries
From: Hangbin Liu @ 2019-02-22 7:57 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: Linus Lüssing, netdev, roopa, bridge, davem, yinxu,
Sebastian Gottschall
In-Reply-To: <9db055dd-6486-1d6e-7dce-edc511650af9@cumulusnetworks.com>
Hi Nikolay,
On Thu, Feb 21, 2019 at 03:20:14PM +0200, Nikolay Aleksandrov wrote:
> >
> > Yes, I agree. But this "regression" could be fixed by setting up correct
> > switch configuration. See more explains below.
> >
>
> That is irrelevant, if the setup once worked we should not break it unless
> it's in RFC requirement violation and RFC 4541 is only suggestive, not required.
Thanks for your reply. I just noticed the RFC4541 category is informational.
> > "because this would cause the Queries to be seen as coming from a newly
> > elected Querier" means other address could be elected as a Querier but
> > "0.0.0.0" should not.
> >
>
> But this change hasn't been incorporated, has it ? A 0.0.0.0 address currently
> will always win the election and silence all of the rest. Current bridge state
> is simply broken for some cases because of that.
Yes. I agree. I realized linus also said
"""
However, one of the two options seems to be necessary. Either
reverting the patch for the IGMP part, too. Or Ignoring 0.0.0.0
sources for querier eletcion and presence detection.
"""
>
> Removing 0.0.0.0 from the election will effectively disable snooping even if there's
> a configured bridge unless it has an address. You can see that this will end up in
> people having suddenly their multicast flooded with current setups, right ?
Yes
> Any big behaviour change like that should be optional, but I don't think we need
> another option as this is not so big of a deal because we're not breaking any
> required behaviour.
Just a little curious, RFC 3376 said the General Queries are sent from multicast
routers. I think a router *should* has a IP address, isn't it?
RFC 4541 also suggested:
If the switch is not the Querier, it should use the 'all-zeros' IP
Source Address in these proxy queries (even though some hosts may
elect to not process queries with a 0.0.0.0 IP Source Address).
When such proxy queries are received, they must not be included in
the Querier election process.
And what I got is most vendors apply this suggestion.
> In case you decide to follow the option path, please use the new boolopt api to avoid
> adding new fields to the bridge, this should be an on/off thing. I still vote for a
> revert though.
For consistency with other vendors and rfc, I would prefer to remove zero address election.
For compatibility with previous users, I'm also OK to revert it.
Regards
Hangbin
^ 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