* b53 DSA : vlan tagging broken ?
From: Anand Raj Manickam @ 2019-07-22 16:57 UTC (permalink / raw)
To: f.fainelli, netdev, andrew
Hi ,
I had working DSA with 4.9.184 kernel, with BCM53125, rev 4 hardware .
It had 2 bridges with
br0 8000.00 no lan1
lan2
lan3
eth0.101
br1 8000.01 no eth0.102
wan
# bridge vlan
port vlan ids
wan 102 PVID Egress Untagged
wan 102 PVID Egress Untagged
lan3 101 PVID Egress Untagged
lan3 101 PVID Egress Untagged
lan2 101 PVID Egress Untagged
lan2 101 PVID Egress Untagged
lan1 101 PVID Egress Untagged
lan1 101 PVID Egress Untagged
eth0.102 102 PVID
eth0.102
br1 1 PVID Egress Untagged
eth0.101 101 PVID
eth0.101
br0 1 PVID Egress Untagged
I upgrade the kernel to 5.2 . The behavior is broken. I had to rip the
config and check what was broken from the init scripts.
the bridge vlan commands failed to add , as the newer kernel requires
the vlan interfaces to be up .
https://lkml.org/lkml/2018/5/22/887 - i had the same behaviour as this thread .
I re added them manually , so the we have the same bridge to vlan
mapping as the previous kernel .
but the ingress packets for WAN where going to LAN(bridge) and the
egress packets where on WAN(bridge) but the packets never leaves the
interface .
I test this with a simple config :
ip link add link eth0 name eth0.101 type vlan id 101
ip link add link eth0 name eth0.102 type vlan id 102
ip link set eth0.101 up
ip link set eth0.102 up
ip link add br0 type bridge
ip link add br1 type bridge
ip link set lan1 master br1
ip link set lan2 master br1
ip link set lan3 master br1
ip link set wan master br0
bridge vlan add vid 101 dev lan1 pvid untagged
bridge vlan add vid 101 dev lan2 pvid untagged
bridge vlan add vid 101 dev lan3 pvid untagged
bridge vlan add vid 102 dev wan pvid untagged
bridge vlan del vid 1 dev wan
bridge vlan del vid 1 dev lan1
bridge vlan del vid 1 dev lan2
bridge vlan del vid 1 dev lan3
ip link set eth0.101 master br1
ip link set eth0.102 master br0
bridge vlan del vid 1 dev eth0.102
bridge vlan del vid 1 dev eth0.101
bridge vlan add vid 102 dev eth0.102 pvid
bridge vlan add vid 101 dev eth0.101 pvid
ifconfig br0 up
ifconfig br1 up
ifconfig wan up
ifconfig lan1 up
ifconfig lan2 up
ifconfig lan3 up
I donot see any packets with a tag on eth0
~# bridge vlan
port vlan ids
wan 102 PVID Egress Untagged
lan3 101 PVID Egress Untagged
lan2 101 PVID Egress Untagged
lan1 101 PVID Egress Untagged
eth0.101 101 PVID
eth0.102 102 PVID
br0 1 PVID Egress Untagged
br1 1 PVID Egress Untagged
These are the loaded modules:
# lsmod
Module Size Used by
b53_mdio 16384 0
b53_mmap 16384 0
b53_common 28672 2 b53_mdio,b53_mmap
tag_8021q 16384 0
dsa_core 32768 9 b53_mdio,b53_common,b53_mmap,tag_8021q
phylink 20480 2 b53_common,dsa_core
if i re config
#bridge vlan add vid 102 dev wan pvid untagged
#bridge vlan add vid 102 dev eth0.102 pvid
Then i see the tags for ingress packets . but no packets are
transmitted out on the wire , but the stats in ifconfig show as
transmitted .
# ifconfig br0
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.17.33.137 netmask 255.255.255.0 broadcast 10.17.33.255
inet6 fe80::3ef8:4aff:fe9c:5a04 prefixlen 64 scopeid 0x20<link>
ether 3c:f8:4a:9c:5a:04 txqueuelen 1000 (Ethernet)
RX packets 616 bytes 32351 (31.5 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 679 bytes 30286 (29.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
#ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::d6:5ff:fec2:93af prefixlen 64 scopeid 0x20<link>
ether 02:d6:05:c2:93:af txqueuelen 1000 (Ethernet)
RX packets 58017 bytes 4004093 (3.8 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 4322 bytes 301365 (294.3 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 56
Can some shed some light on this config .
-Anand
^ permalink raw reply
* Re: [GIT] Networking
From: pr-tracker-bot @ 2019-07-22 16:40 UTC (permalink / raw)
To: David Miller; +Cc: torvalds, akpm, netdev, linux-kernel
In-Reply-To: <20190721.211321.455757135945724538.davem@davemloft.net>
The pull request you sent on Sun, 21 Jul 2019 21:13:21 -0700 (PDT):
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git refs/heads/master
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/83768245a3b158b96d33012b22ab01d193afb2da
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: Driver has suspect GRO implementation, TCP performance may be compromised.
From: Paul Menzel @ 2019-07-22 16:04 UTC (permalink / raw)
To: Eric Dumazet
Cc: Eric Dumazet, Jeff Kirsher, intel-wired-lan, netdev,
Linux Kernel Mailing List
In-Reply-To: <CANn89i+VvwMaHy2Br-0CcC3gPQ+PmG3Urpn4KpqL0P7XBykmcw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3655 bytes --]
Dear Eric,
Sorry for the late reply.
On 5/29/19 6:00 PM, Eric Dumazet wrote:
> On Wed, May 29, 2019 at 7:49 AM Paul Menzel <pmenzel@molgen.mpg.de> wrote:
>> On 05/28/19 19:18, Eric Dumazet wrote:
>>> On 5/28/19 8:42 AM, Paul Menzel wrote:
>>
>>>> Occasionally, Linux outputs the message below on the workstation Dell
>>>> OptiPlex 5040 MT.
>>>>
>>>> TCP: net00: Driver has suspect GRO implementation, TCP performance may be compromised.
>>>>
>>>> Linux 4.14.55 and Linux 5.2-rc2 show the message, and the WWW also
>>>> gives some hits [1][2].
>>>>
>>>> ```
>>>> $ sudo ethtool -i net00
>>>> driver: e1000e
>>>> version: 3.2.6-k
>>>> firmware-version: 0.8-4
>>>> expansion-rom-version:
>>>> bus-info: 0000:00:1f.6
>>>> supports-statistics: yes
>>>> supports-test: yes
>>>> supports-eeprom-access: yes
>>>> supports-register-dump: yes
>>>> supports-priv-flags: no
>>>> ```
>>>>
>>>> Can the driver e1000e be improved?
>>>>
>>>> Any idea, what triggers this, as I do not see it every boot? Download
>>>> of big files?
>>>>
>>> Maybe the driver/NIC can receive frames bigger than MTU, although this would be strange.
>>>
>>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>>> index c61edd023b352123e2a77465782e0d32689e96b0..cb0194f66125bcba427e6e7e3cacf0c93040ef61 100644
>>> --- a/net/ipv4/tcp_input.c
>>> +++ b/net/ipv4/tcp_input.c
>>> @@ -150,8 +150,10 @@ static void tcp_gro_dev_warn(struct sock *sk, const struct sk_buff *skb,
>>> rcu_read_lock();
>>> dev = dev_get_by_index_rcu(sock_net(sk), skb->skb_iif);
>>> if (!dev || len >= dev->mtu)
>>> - pr_warn("%s: Driver has suspect GRO implementation, TCP performance may be compromised.\n",
>>> - dev ? dev->name : "Unknown driver");
>>> + pr_warn("%s: Driver has suspect GRO implementation, TCP performance may be compromised."
>>> + " len %u mtu %u\n",
>>> + dev ? dev->name : "Unknown driver",
>>> + len, dev ? dev->mtu : 0);
>>> rcu_read_unlock();
>>> }
>>> }
>>
>> I applied your patch on commit 9fb67d643 (Merge tag 'pinctrl-v5.2-2' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl):
>>
>> [ 5507.291769] TCP: net00: Driver has suspect GRO implementation, TCP performance may be compromised. len 1856 mtu 1500
>
>
> The 'GRO' in the warning can be probably ignored, since this NIC does
> not implement its own GRO.
>
> You can confirm this with this debug patch:
>
> diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c
> b/drivers/net/ethernet/intel/e1000e/netdev.c
> index 0e09bede42a2bd2c912366a68863a52a22def8ee..014a43ce77e09664bda0568dd118064b006acd67
> 100644
> --- a/drivers/net/ethernet/intel/e1000e/netdev.c
> +++ b/drivers/net/ethernet/intel/e1000e/netdev.c
> @@ -561,6 +561,9 @@ static void e1000_receive_skb(struct e1000_adapter *adapter,
> if (staterr & E1000_RXD_STAT_VP)
> __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), tag);
>
> + if (skb->len > netdev->mtu)
> + pr_err_ratelimited("received packet bigger (%u) than
> MTU (%u)\n",
> + skb->len, netdev->mtu);
> napi_gro_receive(&adapter->napi, skb);
> }
With this patch applied, I unfortunately could not trigger the condition
anymore. No idea why. Or is that expected?
(As a side note, plain Linux 5.2.2 still shows the warning.)
Kind regards,
Paul
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5174 bytes --]
^ permalink raw reply
* Re: [PATCH bpf v4 00/14] sockmap/tls fixes
From: John Fastabend @ 2019-07-22 15:48 UTC (permalink / raw)
To: Daniel Borkmann, Jakub Kicinski, john.fastabend,
alexei.starovoitov
Cc: edumazet, netdev, bpf, oss-drivers
In-Reply-To: <3c97d252-37ad-302f-b917-e7ea6e819318@iogearbox.net>
Daniel Borkmann wrote:
> On 7/19/19 7:37 PM, Jakub Kicinski wrote:
> > On Fri, 19 Jul 2019 10:29:13 -0700, Jakub Kicinski wrote:
> >> John says:
> >>
> >> Resolve a series of splats discovered by syzbot and an unhash
> >> TLS issue noted by Eric Dumazet.
> >
> > Sorry for the delay, this code is quite tricky. According to my testing
> > TLS SW and HW should now work, I hope I didn't regress things on the
> > sockmap side.
>
> Applied, thanks everyone!
Thanks Jakub, for the patches without my signed-off already
Acked-by: John Fastabend <john.fastabend@gmail.com>
^ permalink raw reply
* Re: [PATCH bpf v4 00/14] sockmap/tls fixes
From: John Fastabend @ 2019-07-22 15:46 UTC (permalink / raw)
To: Jakub Kicinski, john.fastabend, alexei.starovoitov, daniel
Cc: edumazet, netdev, bpf, oss-drivers
In-Reply-To: <20190719103721.558d9e7d@cakuba.netronome.com>
Jakub Kicinski wrote:
> On Fri, 19 Jul 2019 10:29:13 -0700, Jakub Kicinski wrote:
> > John says:
> >
> > Resolve a series of splats discovered by syzbot and an unhash
> > TLS issue noted by Eric Dumazet.
>
> Sorry for the delay, this code is quite tricky. According to my testing
> TLS SW and HW should now work, I hope I didn't regress things on the
> sockmap side.
I'll run it through our CI as well but looks good to me. Thanks a lot
for getting this finished up.
>
> This is not solving all the issues (ugh), apart from HW needing the
> unhash/shutdown treatment, as discussed we may have a sender stuck in
> wmem wait while we free context underneath. That's a "minor" UAF for
> another day..
Agreed. But this should solve most of the syzbot issues and a few
crashes we saw in testing real workloads.
Thanks,
John
^ permalink raw reply
* [PATCH net-next] [net-next] mlx4: avoid large stack usage in mlx4_init_hca()
From: Arnd Bergmann @ 2019-07-22 15:01 UTC (permalink / raw)
To: Tariq Toukan, David S. Miller
Cc: Arnd Bergmann, Erez Alfasi, Jack Morgenstein, Eli Cohen,
Moshe Shemesh, Jiri Pirko, netdev, linux-rdma, linux-kernel,
clang-built-linux
The mlx4_dev_cap and mlx4_init_hca_param are really too large
to be put on the kernel stack, as shown by this clang warning:
drivers/net/ethernet/mellanox/mlx4/main.c:3304:12: error: stack frame size of 1088 bytes in function 'mlx4_load_one' [-Werror,-Wframe-larger-than=]
With gcc, the problem is the same, but it does not warn because
it does not inline this function, and therefore stays just below
the warning limit, while clang is just above it.
Use kzalloc for dynamic allocation instead of putting them
on stack. This gets the combined stack frame down to 424 bytes.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/mellanox/mlx4/main.c | 66 +++++++++++++----------
1 file changed, 39 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/main.c b/drivers/net/ethernet/mellanox/mlx4/main.c
index 1f6e16d5ea6b..07c204bd3fc4 100644
--- a/drivers/net/ethernet/mellanox/mlx4/main.c
+++ b/drivers/net/ethernet/mellanox/mlx4/main.c
@@ -2292,23 +2292,31 @@ static int mlx4_init_fw(struct mlx4_dev *dev)
static int mlx4_init_hca(struct mlx4_dev *dev)
{
struct mlx4_priv *priv = mlx4_priv(dev);
+ struct mlx4_init_hca_param *init_hca = NULL;
+ struct mlx4_dev_cap *dev_cap = NULL;
struct mlx4_adapter adapter;
- struct mlx4_dev_cap dev_cap;
struct mlx4_profile profile;
- struct mlx4_init_hca_param init_hca;
u64 icm_size;
struct mlx4_config_dev_params params;
int err;
if (!mlx4_is_slave(dev)) {
- err = mlx4_dev_cap(dev, &dev_cap);
+ dev_cap = kzalloc(sizeof(*dev_cap), GFP_KERNEL);
+ init_hca = kzalloc(sizeof(*init_hca), GFP_KERNEL);
+
+ if (!dev_cap || !init_hca) {
+ err = -ENOMEM;
+ goto out_free;
+ }
+
+ err = mlx4_dev_cap(dev, dev_cap);
if (err) {
mlx4_err(dev, "QUERY_DEV_CAP command failed, aborting\n");
- return err;
+ goto out_free;
}
- choose_steering_mode(dev, &dev_cap);
- choose_tunnel_offload_mode(dev, &dev_cap);
+ choose_steering_mode(dev, dev_cap);
+ choose_tunnel_offload_mode(dev, dev_cap);
if (dev->caps.dmfs_high_steer_mode == MLX4_STEERING_DMFS_A0_STATIC &&
mlx4_is_master(dev))
@@ -2331,48 +2339,48 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
MLX4_STEERING_MODE_DEVICE_MANAGED)
profile.num_mcg = MLX4_FS_NUM_MCG;
- icm_size = mlx4_make_profile(dev, &profile, &dev_cap,
- &init_hca);
+ icm_size = mlx4_make_profile(dev, &profile, dev_cap,
+ init_hca);
if ((long long) icm_size < 0) {
err = icm_size;
- return err;
+ goto out_free;
}
dev->caps.max_fmr_maps = (1 << (32 - ilog2(dev->caps.num_mpts))) - 1;
if (enable_4k_uar || !dev->persist->num_vfs) {
- init_hca.log_uar_sz = ilog2(dev->caps.num_uars) +
+ init_hca->log_uar_sz = ilog2(dev->caps.num_uars) +
PAGE_SHIFT - DEFAULT_UAR_PAGE_SHIFT;
- init_hca.uar_page_sz = DEFAULT_UAR_PAGE_SHIFT - 12;
+ init_hca->uar_page_sz = DEFAULT_UAR_PAGE_SHIFT - 12;
} else {
- init_hca.log_uar_sz = ilog2(dev->caps.num_uars);
- init_hca.uar_page_sz = PAGE_SHIFT - 12;
+ init_hca->log_uar_sz = ilog2(dev->caps.num_uars);
+ init_hca->uar_page_sz = PAGE_SHIFT - 12;
}
- init_hca.mw_enabled = 0;
+ init_hca->mw_enabled = 0;
if (dev->caps.flags & MLX4_DEV_CAP_FLAG_MEM_WINDOW ||
dev->caps.bmme_flags & MLX4_BMME_FLAG_TYPE_2_WIN)
- init_hca.mw_enabled = INIT_HCA_TPT_MW_ENABLE;
+ init_hca->mw_enabled = INIT_HCA_TPT_MW_ENABLE;
- err = mlx4_init_icm(dev, &dev_cap, &init_hca, icm_size);
+ err = mlx4_init_icm(dev, dev_cap, init_hca, icm_size);
if (err)
- return err;
+ goto out_free;
- err = mlx4_INIT_HCA(dev, &init_hca);
+ err = mlx4_INIT_HCA(dev, init_hca);
if (err) {
mlx4_err(dev, "INIT_HCA command failed, aborting\n");
goto err_free_icm;
}
- if (dev_cap.flags2 & MLX4_DEV_CAP_FLAG2_SYS_EQS) {
- err = mlx4_query_func(dev, &dev_cap);
+ if (dev_cap->flags2 & MLX4_DEV_CAP_FLAG2_SYS_EQS) {
+ err = mlx4_query_func(dev, dev_cap);
if (err < 0) {
mlx4_err(dev, "QUERY_FUNC command failed, aborting.\n");
goto err_close;
} else if (err & MLX4_QUERY_FUNC_NUM_SYS_EQS) {
- dev->caps.num_eqs = dev_cap.max_eqs;
- dev->caps.reserved_eqs = dev_cap.reserved_eqs;
- dev->caps.reserved_uars = dev_cap.reserved_uars;
+ dev->caps.num_eqs = dev_cap->max_eqs;
+ dev->caps.reserved_eqs = dev_cap->reserved_eqs;
+ dev->caps.reserved_uars = dev_cap->reserved_uars;
}
}
@@ -2381,14 +2389,13 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
* read HCA frequency by QUERY_HCA command
*/
if (dev->caps.flags2 & MLX4_DEV_CAP_FLAG2_TS) {
- memset(&init_hca, 0, sizeof(init_hca));
- err = mlx4_QUERY_HCA(dev, &init_hca);
+ err = mlx4_QUERY_HCA(dev, init_hca);
if (err) {
mlx4_err(dev, "QUERY_HCA command failed, disable timestamp\n");
dev->caps.flags2 &= ~MLX4_DEV_CAP_FLAG2_TS;
} else {
dev->caps.hca_core_clock =
- init_hca.hca_core_clock;
+ init_hca->hca_core_clock;
}
/* In case we got HCA frequency 0 - disable timestamping
@@ -2464,7 +2471,8 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
priv->eq_table.inta_pin = adapter.inta_pin;
memcpy(dev->board_id, adapter.board_id, sizeof(dev->board_id));
- return 0;
+ err = 0;
+ goto out_free;
unmap_bf:
unmap_internal_clock(dev);
@@ -2483,6 +2491,10 @@ static int mlx4_init_hca(struct mlx4_dev *dev)
if (!mlx4_is_slave(dev))
mlx4_free_icms(dev);
+out_free:
+ kfree(dev_cap);
+ kfree(init_hca);
+
return err;
}
--
2.20.0
^ permalink raw reply related
* [PATCH net-next] qed: reduce maximum stack frame size
From: Arnd Bergmann @ 2019-07-22 15:01 UTC (permalink / raw)
To: Ariel Elior, GR-everest-linux-l2, David S. Miller
Cc: Arnd Bergmann, Yuval Mintz, Manish Chopra, Michal Kalderon,
Sudarsana Reddy Kalluru, Denis Bolotin, Rahul Verma, netdev,
linux-kernel, clang-built-linux
clang warns about an overly large stack frame in one function
when it decides to inline all __qed_get_vport_*() functions into
__qed_get_vport_stats():
drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of 1128 bytes in function '_qed_get_vport_stats' [-Werror,-Wframe-larger-than=]
Use a noinline_for_stack annotation to prevent clang from inlining
these, which keeps the maximum stack usage at around half of that
in the worst case, similar to what we get with gcc.
Fixes: 86622ee75312 ("qed: Move statistics to L2 code")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/ethernet/qlogic/qed/qed_l2.c | 34 +++++++++++-------------
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 9f36e7948222..1a5fc2ae351c 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1631,10 +1631,9 @@ static void __qed_get_vport_pstats_addrlen(struct qed_hwfn *p_hwfn,
}
}
-static void __qed_get_vport_pstats(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- struct qed_eth_stats *p_stats,
- u16 statistics_bin)
+static noinline_for_stack void
+__qed_get_vport_pstats(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ struct qed_eth_stats *p_stats, u16 statistics_bin)
{
struct eth_pstorm_per_queue_stat pstats;
u32 pstats_addr = 0, pstats_len = 0;
@@ -1661,10 +1660,9 @@ static void __qed_get_vport_pstats(struct qed_hwfn *p_hwfn,
HILO_64_REGPAIR(pstats.error_drop_pkts);
}
-static void __qed_get_vport_tstats(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- struct qed_eth_stats *p_stats,
- u16 statistics_bin)
+static noinline_for_stack void
+__qed_get_vport_tstats(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ struct qed_eth_stats *p_stats, u16 statistics_bin)
{
struct tstorm_per_port_stat tstats;
u32 tstats_addr, tstats_len;
@@ -1709,10 +1707,9 @@ static void __qed_get_vport_ustats_addrlen(struct qed_hwfn *p_hwfn,
}
}
-static void __qed_get_vport_ustats(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- struct qed_eth_stats *p_stats,
- u16 statistics_bin)
+static noinline_for_stack
+void __qed_get_vport_ustats(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ struct qed_eth_stats *p_stats, u16 statistics_bin)
{
struct eth_ustorm_per_queue_stat ustats;
u32 ustats_addr = 0, ustats_len = 0;
@@ -1751,10 +1748,9 @@ static void __qed_get_vport_mstats_addrlen(struct qed_hwfn *p_hwfn,
}
}
-static void __qed_get_vport_mstats(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- struct qed_eth_stats *p_stats,
- u16 statistics_bin)
+static noinline_for_stack void
+__qed_get_vport_mstats(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ struct qed_eth_stats *p_stats, u16 statistics_bin)
{
struct eth_mstorm_per_queue_stat mstats;
u32 mstats_addr = 0, mstats_len = 0;
@@ -1780,9 +1776,9 @@ static void __qed_get_vport_mstats(struct qed_hwfn *p_hwfn,
HILO_64_REGPAIR(mstats.tpa_coalesced_bytes);
}
-static void __qed_get_vport_port_stats(struct qed_hwfn *p_hwfn,
- struct qed_ptt *p_ptt,
- struct qed_eth_stats *p_stats)
+static noinline_for_stack void
+__qed_get_vport_port_stats(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt,
+ struct qed_eth_stats *p_stats)
{
struct qed_eth_stats_common *p_common = &p_stats->common;
struct port_stats port_stats;
--
2.20.0
^ permalink raw reply related
* [PATCH] wcn36xx: use dynamic allocation for large variables
From: Arnd Bergmann @ 2019-07-22 14:59 UTC (permalink / raw)
To: Kalle Valo
Cc: Arnd Bergmann, Eugene Krasnikov, John W. Linville,
David S. Miller, YueHaibing, wcn36xx, linux-wireless, netdev,
linux-kernel, clang-built-linux
clang triggers a warning about oversized stack frames that gcc does not
notice because of slightly different inlining decisions:
ath/wcn36xx/smd.c:1409:5: error: stack frame size of 1040 bytes in function 'wcn36xx_smd_config_bss' [-Werror,-Wframe-larger-than=]
ath/wcn36xx/smd.c:640:5: error: stack frame size of 1032 bytes in function 'wcn36xx_smd_start_hw_scan' [-Werror,-Wframe-larger-than=]
Basically the wcn36xx_hal_start_scan_offload_req_msg,
wcn36xx_hal_config_bss_req_msg_v1, and wcn36xx_hal_config_bss_req_msg
structures are too large to be put on the kernel stack, but small
enough that gcc does not warn about them.
Use kzalloc() to allocate them all. There are similar structures in other
parts of this driver, but they are all smaller, with the next largest
stack frame at 480 bytes for wcn36xx_smd_send_beacon.
Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/net/wireless/ath/wcn36xx/smd.c | 186 ++++++++++++++-----------
1 file changed, 105 insertions(+), 81 deletions(-)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index 1d2d698fb779..523550f94a3f 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -641,52 +641,58 @@ int wcn36xx_smd_start_hw_scan(struct wcn36xx *wcn, struct ieee80211_vif *vif,
struct cfg80211_scan_request *req)
{
struct wcn36xx_vif *vif_priv = wcn36xx_vif_to_priv(vif);
- struct wcn36xx_hal_start_scan_offload_req_msg msg_body;
+ struct wcn36xx_hal_start_scan_offload_req_msg *msg_body;
int ret, i;
if (req->ie_len > WCN36XX_MAX_SCAN_IE_LEN)
return -EINVAL;
mutex_lock(&wcn->hal_mutex);
- INIT_HAL_MSG(msg_body, WCN36XX_HAL_START_SCAN_OFFLOAD_REQ);
+ msg_body = kzalloc(sizeof(*msg_body), GFP_KERNEL);
+ if (!msg_body) {
+ ret = -ENOMEM;
+ goto out;
+ }
- msg_body.scan_type = WCN36XX_HAL_SCAN_TYPE_ACTIVE;
- msg_body.min_ch_time = 30;
- msg_body.max_ch_time = 100;
- msg_body.scan_hidden = 1;
- memcpy(msg_body.mac, vif->addr, ETH_ALEN);
- msg_body.bss_type = vif_priv->bss_type;
- msg_body.p2p_search = vif->p2p;
+ INIT_HAL_MSG((*msg_body), WCN36XX_HAL_START_SCAN_OFFLOAD_REQ);
- msg_body.num_ssid = min_t(u8, req->n_ssids, ARRAY_SIZE(msg_body.ssids));
- for (i = 0; i < msg_body.num_ssid; i++) {
- msg_body.ssids[i].length = min_t(u8, req->ssids[i].ssid_len,
- sizeof(msg_body.ssids[i].ssid));
- memcpy(msg_body.ssids[i].ssid, req->ssids[i].ssid,
- msg_body.ssids[i].length);
+ msg_body->scan_type = WCN36XX_HAL_SCAN_TYPE_ACTIVE;
+ msg_body->min_ch_time = 30;
+ msg_body->max_ch_time = 100;
+ msg_body->scan_hidden = 1;
+ memcpy(msg_body->mac, vif->addr, ETH_ALEN);
+ msg_body->bss_type = vif_priv->bss_type;
+ msg_body->p2p_search = vif->p2p;
+
+ msg_body->num_ssid = min_t(u8, req->n_ssids, ARRAY_SIZE(msg_body->ssids));
+ for (i = 0; i < msg_body->num_ssid; i++) {
+ msg_body->ssids[i].length = min_t(u8, req->ssids[i].ssid_len,
+ sizeof(msg_body->ssids[i].ssid));
+ memcpy(msg_body->ssids[i].ssid, req->ssids[i].ssid,
+ msg_body->ssids[i].length);
}
- msg_body.num_channel = min_t(u8, req->n_channels,
- sizeof(msg_body.channels));
- for (i = 0; i < msg_body.num_channel; i++)
- msg_body.channels[i] = req->channels[i]->hw_value;
+ msg_body->num_channel = min_t(u8, req->n_channels,
+ sizeof(msg_body->channels));
+ for (i = 0; i < msg_body->num_channel; i++)
+ msg_body->channels[i] = req->channels[i]->hw_value;
- msg_body.header.len -= WCN36XX_MAX_SCAN_IE_LEN;
+ msg_body->header.len -= WCN36XX_MAX_SCAN_IE_LEN;
if (req->ie_len > 0) {
- msg_body.ie_len = req->ie_len;
- msg_body.header.len += req->ie_len;
- memcpy(msg_body.ie, req->ie, req->ie_len);
+ msg_body->ie_len = req->ie_len;
+ msg_body->header.len += req->ie_len;
+ memcpy(msg_body->ie, req->ie, req->ie_len);
}
- PREPARE_HAL_BUF(wcn->hal_buf, msg_body);
+ PREPARE_HAL_BUF(wcn->hal_buf, (*msg_body));
wcn36xx_dbg(WCN36XX_DBG_HAL,
"hal start hw-scan (channels: %u; ssids: %u; p2p: %s)\n",
- msg_body.num_channel, msg_body.num_ssid,
- msg_body.p2p_search ? "yes" : "no");
+ msg_body->num_channel, msg_body->num_ssid,
+ msg_body->p2p_search ? "yes" : "no");
- ret = wcn36xx_smd_send_and_wait(wcn, msg_body.header.len);
+ ret = wcn36xx_smd_send_and_wait(wcn, msg_body->header.len);
if (ret) {
wcn36xx_err("Sending hal_start_scan_offload failed\n");
goto out;
@@ -698,6 +704,7 @@ int wcn36xx_smd_start_hw_scan(struct wcn36xx *wcn, struct ieee80211_vif *vif,
goto out;
}
out:
+ kfree(msg_body);
mutex_unlock(&wcn->hal_mutex);
return ret;
}
@@ -1257,96 +1264,104 @@ int wcn36xx_smd_config_sta(struct wcn36xx *wcn, struct ieee80211_vif *vif,
static int wcn36xx_smd_config_bss_v1(struct wcn36xx *wcn,
const struct wcn36xx_hal_config_bss_req_msg *orig)
{
- struct wcn36xx_hal_config_bss_req_msg_v1 msg_body;
- struct wcn36xx_hal_config_bss_params_v1 *bss = &msg_body.bss_params;
- struct wcn36xx_hal_config_sta_params_v1 *sta = &bss->sta;
+ struct wcn36xx_hal_config_bss_req_msg_v1 *msg_body;
+ struct wcn36xx_hal_config_bss_params_v1 *bss;
+ struct wcn36xx_hal_config_sta_params_v1 *sta;
+ int ret;
+
+ msg_body = kzalloc(sizeof(*msg_body), GFP_KERNEL);
+ if (!msg_body)
+ return -ENOMEM;
+
+ INIT_HAL_MSG((*msg_body), WCN36XX_HAL_CONFIG_BSS_REQ);
- INIT_HAL_MSG(msg_body, WCN36XX_HAL_CONFIG_BSS_REQ);
+ bss = &msg_body->bss_params;
+ sta = &bss->sta;
/* convert orig to v1 */
- memcpy(&msg_body.bss_params.bssid,
+ memcpy(&msg_body->bss_params.bssid,
&orig->bss_params.bssid, ETH_ALEN);
- memcpy(&msg_body.bss_params.self_mac_addr,
+ memcpy(&msg_body->bss_params.self_mac_addr,
&orig->bss_params.self_mac_addr, ETH_ALEN);
- msg_body.bss_params.bss_type = orig->bss_params.bss_type;
- msg_body.bss_params.oper_mode = orig->bss_params.oper_mode;
- msg_body.bss_params.nw_type = orig->bss_params.nw_type;
+ msg_body->bss_params.bss_type = orig->bss_params.bss_type;
+ msg_body->bss_params.oper_mode = orig->bss_params.oper_mode;
+ msg_body->bss_params.nw_type = orig->bss_params.nw_type;
- msg_body.bss_params.short_slot_time_supported =
+ msg_body->bss_params.short_slot_time_supported =
orig->bss_params.short_slot_time_supported;
- msg_body.bss_params.lla_coexist = orig->bss_params.lla_coexist;
- msg_body.bss_params.llb_coexist = orig->bss_params.llb_coexist;
- msg_body.bss_params.llg_coexist = orig->bss_params.llg_coexist;
- msg_body.bss_params.ht20_coexist = orig->bss_params.ht20_coexist;
- msg_body.bss_params.lln_non_gf_coexist =
+ msg_body->bss_params.lla_coexist = orig->bss_params.lla_coexist;
+ msg_body->bss_params.llb_coexist = orig->bss_params.llb_coexist;
+ msg_body->bss_params.llg_coexist = orig->bss_params.llg_coexist;
+ msg_body->bss_params.ht20_coexist = orig->bss_params.ht20_coexist;
+ msg_body->bss_params.lln_non_gf_coexist =
orig->bss_params.lln_non_gf_coexist;
- msg_body.bss_params.lsig_tx_op_protection_full_support =
+ msg_body->bss_params.lsig_tx_op_protection_full_support =
orig->bss_params.lsig_tx_op_protection_full_support;
- msg_body.bss_params.rifs_mode = orig->bss_params.rifs_mode;
- msg_body.bss_params.beacon_interval = orig->bss_params.beacon_interval;
- msg_body.bss_params.dtim_period = orig->bss_params.dtim_period;
- msg_body.bss_params.tx_channel_width_set =
+ msg_body->bss_params.rifs_mode = orig->bss_params.rifs_mode;
+ msg_body->bss_params.beacon_interval = orig->bss_params.beacon_interval;
+ msg_body->bss_params.dtim_period = orig->bss_params.dtim_period;
+ msg_body->bss_params.tx_channel_width_set =
orig->bss_params.tx_channel_width_set;
- msg_body.bss_params.oper_channel = orig->bss_params.oper_channel;
- msg_body.bss_params.ext_channel = orig->bss_params.ext_channel;
+ msg_body->bss_params.oper_channel = orig->bss_params.oper_channel;
+ msg_body->bss_params.ext_channel = orig->bss_params.ext_channel;
- msg_body.bss_params.reserved = orig->bss_params.reserved;
+ msg_body->bss_params.reserved = orig->bss_params.reserved;
- memcpy(&msg_body.bss_params.ssid,
+ memcpy(&msg_body->bss_params.ssid,
&orig->bss_params.ssid,
sizeof(orig->bss_params.ssid));
- msg_body.bss_params.action = orig->bss_params.action;
- msg_body.bss_params.rateset = orig->bss_params.rateset;
- msg_body.bss_params.ht = orig->bss_params.ht;
- msg_body.bss_params.obss_prot_enabled =
+ msg_body->bss_params.action = orig->bss_params.action;
+ msg_body->bss_params.rateset = orig->bss_params.rateset;
+ msg_body->bss_params.ht = orig->bss_params.ht;
+ msg_body->bss_params.obss_prot_enabled =
orig->bss_params.obss_prot_enabled;
- msg_body.bss_params.rmf = orig->bss_params.rmf;
- msg_body.bss_params.ht_oper_mode = orig->bss_params.ht_oper_mode;
- msg_body.bss_params.dual_cts_protection =
+ msg_body->bss_params.rmf = orig->bss_params.rmf;
+ msg_body->bss_params.ht_oper_mode = orig->bss_params.ht_oper_mode;
+ msg_body->bss_params.dual_cts_protection =
orig->bss_params.dual_cts_protection;
- msg_body.bss_params.max_probe_resp_retry_limit =
+ msg_body->bss_params.max_probe_resp_retry_limit =
orig->bss_params.max_probe_resp_retry_limit;
- msg_body.bss_params.hidden_ssid = orig->bss_params.hidden_ssid;
- msg_body.bss_params.proxy_probe_resp =
+ msg_body->bss_params.hidden_ssid = orig->bss_params.hidden_ssid;
+ msg_body->bss_params.proxy_probe_resp =
orig->bss_params.proxy_probe_resp;
- msg_body.bss_params.edca_params_valid =
+ msg_body->bss_params.edca_params_valid =
orig->bss_params.edca_params_valid;
- memcpy(&msg_body.bss_params.acbe,
+ memcpy(&msg_body->bss_params.acbe,
&orig->bss_params.acbe,
sizeof(orig->bss_params.acbe));
- memcpy(&msg_body.bss_params.acbk,
+ memcpy(&msg_body->bss_params.acbk,
&orig->bss_params.acbk,
sizeof(orig->bss_params.acbk));
- memcpy(&msg_body.bss_params.acvi,
+ memcpy(&msg_body->bss_params.acvi,
&orig->bss_params.acvi,
sizeof(orig->bss_params.acvi));
- memcpy(&msg_body.bss_params.acvo,
+ memcpy(&msg_body->bss_params.acvo,
&orig->bss_params.acvo,
sizeof(orig->bss_params.acvo));
- msg_body.bss_params.ext_set_sta_key_param_valid =
+ msg_body->bss_params.ext_set_sta_key_param_valid =
orig->bss_params.ext_set_sta_key_param_valid;
- memcpy(&msg_body.bss_params.ext_set_sta_key_param,
+ memcpy(&msg_body->bss_params.ext_set_sta_key_param,
&orig->bss_params.ext_set_sta_key_param,
sizeof(orig->bss_params.acvo));
- msg_body.bss_params.wcn36xx_hal_persona =
+ msg_body->bss_params.wcn36xx_hal_persona =
orig->bss_params.wcn36xx_hal_persona;
- msg_body.bss_params.spectrum_mgt_enable =
+ msg_body->bss_params.spectrum_mgt_enable =
orig->bss_params.spectrum_mgt_enable;
- msg_body.bss_params.tx_mgmt_power = orig->bss_params.tx_mgmt_power;
- msg_body.bss_params.max_tx_power = orig->bss_params.max_tx_power;
+ msg_body->bss_params.tx_mgmt_power = orig->bss_params.tx_mgmt_power;
+ msg_body->bss_params.max_tx_power = orig->bss_params.max_tx_power;
wcn36xx_smd_convert_sta_to_v1(wcn, &orig->bss_params.sta,
- &msg_body.bss_params.sta);
+ &msg_body->bss_params.sta);
- PREPARE_HAL_BUF(wcn->hal_buf, msg_body);
+ PREPARE_HAL_BUF(wcn->hal_buf, (*msg_body));
wcn36xx_dbg(WCN36XX_DBG_HAL,
"hal config bss v1 bssid %pM self_mac_addr %pM bss_type %d oper_mode %d nw_type %d\n",
@@ -1358,7 +1373,10 @@ static int wcn36xx_smd_config_bss_v1(struct wcn36xx *wcn,
sta->bssid, sta->action, sta->sta_index,
sta->bssid_index, sta->aid, sta->type, sta->mac);
- return wcn36xx_smd_send_and_wait(wcn, msg_body.header.len);
+ ret = wcn36xx_smd_send_and_wait(wcn, msg_body->header.len);
+ kfree(msg_body);
+
+ return ret;
}
@@ -1410,16 +1428,21 @@ int wcn36xx_smd_config_bss(struct wcn36xx *wcn, struct ieee80211_vif *vif,
struct ieee80211_sta *sta, const u8 *bssid,
bool update)
{
- struct wcn36xx_hal_config_bss_req_msg msg;
+ struct wcn36xx_hal_config_bss_req_msg *msg;
struct wcn36xx_hal_config_bss_params *bss;
struct wcn36xx_hal_config_sta_params *sta_params;
struct wcn36xx_vif *vif_priv = wcn36xx_vif_to_priv(vif);
int ret;
mutex_lock(&wcn->hal_mutex);
- INIT_HAL_MSG(msg, WCN36XX_HAL_CONFIG_BSS_REQ);
+ msg = kzalloc(sizeof(*msg), GFP_KERNEL);
+ if (!msg) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ INIT_HAL_MSG((*msg), WCN36XX_HAL_CONFIG_BSS_REQ);
- bss = &msg.bss_params;
+ bss = &msg->bss_params;
sta_params = &bss->sta;
WARN_ON(is_zero_ether_addr(bssid));
@@ -1514,11 +1537,11 @@ int wcn36xx_smd_config_bss(struct wcn36xx *wcn, struct ieee80211_vif *vif,
sta_params->mac);
if (!wcn36xx_is_fw_version(wcn, 1, 2, 2, 24)) {
- ret = wcn36xx_smd_config_bss_v1(wcn, &msg);
+ ret = wcn36xx_smd_config_bss_v1(wcn, msg);
} else {
- PREPARE_HAL_BUF(wcn->hal_buf, msg);
+ PREPARE_HAL_BUF(wcn->hal_buf, (*msg));
- ret = wcn36xx_smd_send_and_wait(wcn, msg.header.len);
+ ret = wcn36xx_smd_send_and_wait(wcn, msg->header.len);
}
if (ret) {
wcn36xx_err("Sending hal_config_bss failed\n");
@@ -1534,6 +1557,7 @@ int wcn36xx_smd_config_bss(struct wcn36xx *wcn, struct ieee80211_vif *vif,
goto out;
}
out:
+ kfree(msg);
mutex_unlock(&wcn->hal_mutex);
return ret;
}
--
2.20.0
^ permalink raw reply related
* [PATCH] ovs: datapath: hide clang frame-overflow warnings
From: Arnd Bergmann @ 2019-07-22 15:00 UTC (permalink / raw)
To: Pravin B Shelar, David S. Miller
Cc: Arnd Bergmann, Tonghao Zhang, Johannes Berg, Kangjie Lu, netdev,
dev, linux-kernel, clang-built-linux
Some functions in the datapath code are factored out so that each
one has a stack frame smaller than 1024 bytes with gcc. However,
when compiling with clang, the functions are inlined more aggressively
and combined again so we get
net/openvswitch/datapath.c:1124:12: error: stack frame size of 1528 bytes in function 'ovs_flow_cmd_set' [-Werror,-Wframe-larger-than=]
Marking both get_flow_actions() and ovs_nla_init_match_and_action()
as 'noinline_for_stack' gives us the same behavior that we see with
gcc, and no warning. Note that this does not mean we actually use
less stack, as the functions call each other, and we still get
three copies of the large 'struct sw_flow_key' type on the stack.
The comment tells us that this was previously considered safe,
presumably since the netlink parsing functions are called with
a known backchain that does not also use a lot of stack space.
Fixes: 9cc9a5cb176c ("datapath: Avoid using stack larger than 1024.")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/openvswitch/datapath.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 892287d06c17..d01410e52097 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1047,7 +1047,7 @@ static int ovs_flow_cmd_new(struct sk_buff *skb, struct genl_info *info)
}
/* Factor out action copy to avoid "Wframe-larger-than=1024" warning. */
-static struct sw_flow_actions *get_flow_actions(struct net *net,
+static noinline_for_stack struct sw_flow_actions *get_flow_actions(struct net *net,
const struct nlattr *a,
const struct sw_flow_key *key,
const struct sw_flow_mask *mask,
@@ -1081,12 +1081,13 @@ static struct sw_flow_actions *get_flow_actions(struct net *net,
* we should not to return match object with dangling reference
* to mask.
* */
-static int ovs_nla_init_match_and_action(struct net *net,
- struct sw_flow_match *match,
- struct sw_flow_key *key,
- struct nlattr **a,
- struct sw_flow_actions **acts,
- bool log)
+static noinline_for_stack int
+ovs_nla_init_match_and_action(struct net *net,
+ struct sw_flow_match *match,
+ struct sw_flow_key *key,
+ struct nlattr **a,
+ struct sw_flow_actions **acts,
+ bool log)
{
struct sw_flow_mask mask;
int error = 0;
--
2.20.0
^ permalink raw reply related
* [PATCH net-next] rxrpc: shut up -Wframe-larger-than= warnings
From: Arnd Bergmann @ 2019-07-22 14:58 UTC (permalink / raw)
To: David Howells, David S. Miller
Cc: Arnd Bergmann, Kees Cook, linux-afs, netdev, linux-kernel,
clang-built-linux
rxkad sometimes triggers a warning about oversized stack frames
when building with clang for a 32-bit architecture:
net/rxrpc/rxkad.c:243:12: error: stack frame size of 1088 bytes in function 'rxkad_secure_packet' [-Werror,-Wframe-larger-than=]
net/rxrpc/rxkad.c:501:12: error: stack frame size of 1088 bytes in function 'rxkad_verify_packet' [-Werror,-Wframe-larger-than=]
The problem is the combination of SYNC_SKCIPHER_REQUEST_ON_STACK()
in rxkad_verify_packet()/rxkad_secure_packet() with the relatively
large scatterlist in rxkad_verify_packet_1()/rxkad_secure_packet_encrypt().
The warning does not show up when using gcc, which does not inline
the functions as aggressively, but the problem is still the same.
Marking the inner functions as 'noinline_for_stack' makes clang
behave the same way as gcc and avoids the warning.
This may not be ideal as it leaves the underlying problem
unchanged. If we want to actually reduce the stack usage here,
the skcipher_request and scatterlist objects need to be moved
off the stack.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/rxrpc/rxkad.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/rxrpc/rxkad.c b/net/rxrpc/rxkad.c
index ae8cd8926456..788e40a1679c 100644
--- a/net/rxrpc/rxkad.c
+++ b/net/rxrpc/rxkad.c
@@ -139,7 +139,7 @@ static int rxkad_prime_packet_security(struct rxrpc_connection *conn)
/*
* partially encrypt a packet (level 1 security)
*/
-static int rxkad_secure_packet_auth(const struct rxrpc_call *call,
+static noinline_for_stack int rxkad_secure_packet_auth(const struct rxrpc_call *call,
struct sk_buff *skb,
u32 data_size,
void *sechdr,
@@ -176,7 +176,7 @@ static int rxkad_secure_packet_auth(const struct rxrpc_call *call,
/*
* wholly encrypt a packet (level 2 security)
*/
-static int rxkad_secure_packet_encrypt(const struct rxrpc_call *call,
+static noinline_for_stack int rxkad_secure_packet_encrypt(const struct rxrpc_call *call,
struct sk_buff *skb,
u32 data_size,
void *sechdr,
@@ -311,7 +311,7 @@ static int rxkad_secure_packet(struct rxrpc_call *call,
/*
* decrypt partial encryption on a packet (level 1 security)
*/
-static int rxkad_verify_packet_1(struct rxrpc_call *call, struct sk_buff *skb,
+static noinline_for_stack int rxkad_verify_packet_1(struct rxrpc_call *call, struct sk_buff *skb,
unsigned int offset, unsigned int len,
rxrpc_seq_t seq,
struct skcipher_request *req)
@@ -397,7 +397,7 @@ static int rxkad_verify_packet_1(struct rxrpc_call *call, struct sk_buff *skb,
/*
* wholly decrypt a packet (level 2 security)
*/
-static int rxkad_verify_packet_2(struct rxrpc_call *call, struct sk_buff *skb,
+static noinline_for_stack int rxkad_verify_packet_2(struct rxrpc_call *call, struct sk_buff *skb,
unsigned int offset, unsigned int len,
rxrpc_seq_t seq,
struct skcipher_request *req)
--
2.20.0
^ permalink raw reply related
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Ondřej Jirman @ 2019-07-22 14:39 UTC (permalink / raw)
To: Jose Abreu
Cc: Andrew Lunn, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Joao Pinto, David S . Miller, Giuseppe Cavallaro,
Alexandre Torgue, Russell King, Florian Fainelli, Heiner Kallweit
In-Reply-To: <BN8PR12MB3266BEC39374BE3E9CD2647DD3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
On Mon, Jul 22, 2019 at 02:26:45PM +0000, Jose Abreu wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Jul/22/2019, 15:19:43 (UTC+00:00)
>
> > On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> > > From: Andrew Lunn <andrew@lunn.ch>
> > > Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> > >
> > > > Does this mean that all stmmac variants support 1G? There are none
> > > > which just support Fast Ethernet?
> > >
> > > This glue logic drivers sometimes reflect a custom IP that's Synopsys
> > > based but modified by customer, so I can't know before-hand what's the
> > > supported max speed. There are some old versions that don't support 1G
> > > but I expect that PHY driver limits this ...
> >
> > If a Fast PHY is used, then yes, it would be limited. But sometimes a
> > 1G PHY is used because they are cheaper than a Fast PHY.
> >
> > > > I'm also not sure the change fits the problem. Why did it not
> > > > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > > > speeds around, so 100 speeds should of been advertised and selected.
> > >
> > > Hmm, now that I'm looking at it closer I agree with you. Maybe link
> > > partner or PHY doesn't support 100M ?
> >
> > In the working case, ethtool shows the link partner supports 10, 100,
> > and 1G. So something odd is going on here.
> >
> > You fix does seems reasonable, and it has been reported to fix the
> > issue, but it would be good to understand what is going on here.
>
> Agreed!
>
> Ondrej, can you please share dmesg log and ethtool output with the fixed
> patch ?
See the attachment, or this link:
https://megous.com/dl/tmp/dmesg-5.3-working
regards,
Ondrej
> ---
> Thanks,
> Jose Miguel Abreu
[-- Attachment #2: dmesg-5.3-working --]
[-- Type: text/plain, Size: 32450 bytes --]
[ 0.000000] Machine model: OrangePi 3
[ 0.000000] cma: Reserved 64 MiB at 0x00000000bc000000
[ 0.000000] On node 0 totalpages: 524288
[ 0.000000] DMA32 zone: 8192 pages used for memmap
[ 0.000000] DMA32 zone: 0 pages reserved
[ 0.000000] DMA32 zone: 524288 pages, LIFO batch:63
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.1
[ 0.000000] percpu: Embedded 22 pages/cpu s53208 r8192 d28712 u90112
[ 0.000000] pcpu-alloc: s53208 r8192 d28712 u90112 alloc=22*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Detected VIPT I-cache on CPU0
[ 0.000000] Speculative Store Bypass Disable mitigation not required
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 516096
[ 0.000000] Kernel command line: console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p3 rootfstype=f2fs rw elevator=noop rootwait panic=3 quiet
[ 0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] Memory: 1962168K/2097152K available (13822K kernel code, 804K rwdata, 4028K rodata, 2048K init, 619K bss, 69448K reserved, 65536K cma-reserved)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[ 0.000000] GIC: Using split EOI/Deactivate mode
[ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[ 0.000004] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[ 0.000205] Console: colour dummy device 80x25
[ 0.000214] printk: console [tty1] enabled
[ 0.000244] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
[ 0.000251] pid_max: default: 32768 minimum: 301
[ 0.000376] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[ 0.000389] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[ 0.000844] *** VALIDATE proc ***
[ 0.001011] *** VALIDATE cgroup1 ***
[ 0.001017] *** VALIDATE cgroup2 ***
[ 0.001597] ASID allocator initialised with 32768 entries
[ 0.001667] rcu: Hierarchical SRCU implementation.
[ 0.002044] smp: Bringing up secondary CPUs ...
[ 0.002673] Detected VIPT I-cache on CPU1
[ 0.002721] CPU1: Booted secondary processor 0x0000000001 [0x410fd034]
[ 0.003242] Detected VIPT I-cache on CPU2
[ 0.003270] CPU2: Booted secondary processor 0x0000000002 [0x410fd034]
[ 0.003764] Detected VIPT I-cache on CPU3
[ 0.003789] CPU3: Booted secondary processor 0x0000000003 [0x410fd034]
[ 0.003853] smp: Brought up 1 node, 4 CPUs
[ 0.003856] SMP: Total of 4 processors activated.
[ 0.003861] CPU features: detected: 32-bit EL0 Support
[ 0.003865] CPU features: detected: CRC32 instructions
[ 0.004200] CPU: All CPU(s) started at EL2
[ 0.004229] alternatives: patching kernel code
[ 0.004264] random: get_random_u64 called from compute_layout+0x94/0xe8 with crng_init=0
[ 0.005805] devtmpfs: initialized
[ 0.009740] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.009753] futex hash table entries: 1024 (order: 4, 65536 bytes, linear)
[ 0.011917] pinctrl core: initialized pinctrl subsystem
[ 0.012603] NET: Registered protocol family 16
[ 0.013482] cpuidle: using governor ladder
[ 0.013562] cpuidle: using governor menu
[ 0.013817] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
[ 0.014827] DMA: preallocated 256 KiB pool for atomic allocations
[ 0.030511] cryptd: max_cpu_qlen set to 1000
[ 0.036889] vcc33-wifi: supplied by vcc-5v
[ 0.037068] vcc-wifi-io: supplied by vcc33-wifi
[ 0.037624] SCSI subsystem initialized
[ 0.037791] usbcore: registered new interface driver usbfs
[ 0.037823] usbcore: registered new interface driver hub
[ 0.037889] usbcore: registered new device driver usb
[ 0.037991] mc: Linux media interface: v0.10
[ 0.038015] videodev: Linux video capture interface: v2.00
[ 0.038083] pps_core: LinuxPPS API ver. 1 registered
[ 0.038086] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.038097] PTP clock support registered
[ 0.038335] Advanced Linux Sound Architecture Driver Initialized.
[ 0.038736] Bluetooth: Core ver 2.22
[ 0.038759] NET: Registered protocol family 31
[ 0.038762] Bluetooth: HCI device and connection manager initialized
[ 0.038770] Bluetooth: HCI socket layer initialized
[ 0.038775] Bluetooth: L2CAP socket layer initialized
[ 0.038786] Bluetooth: SCO socket layer initialized
[ 0.039250] clocksource: Switched to clocksource arch_sys_counter
[ 0.039464] FS-Cache: Loaded
[ 0.043990] thermal_sys: Registered thermal governor 'fair_share'
[ 0.043994] thermal_sys: Registered thermal governor 'bang_bang'
[ 0.043998] thermal_sys: Registered thermal governor 'step_wise'
[ 0.044451] NET: Registered protocol family 2
[ 0.044904] tcp_listen_portaddr_hash hash table entries: 1024 (order: 2, 16384 bytes, linear)
[ 0.044938] TCP established hash table entries: 16384 (order: 5, 131072 bytes, linear)
[ 0.045075] TCP bind hash table entries: 16384 (order: 6, 262144 bytes, linear)
[ 0.045371] TCP: Hash tables configured (established 16384 bind 16384)
[ 0.045462] UDP hash table entries: 1024 (order: 3, 32768 bytes, linear)
[ 0.045512] UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes, linear)
[ 0.045678] NET: Registered protocol family 1
[ 0.046075] RPC: Registered named UNIX socket transport module.
[ 0.046077] RPC: Registered udp transport module.
[ 0.046080] RPC: Registered tcp transport module.
[ 0.046082] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 0.046531] Unpacking initramfs...
[ 0.422703] Freeing initrd memory: 7524K
[ 0.423446] kvm [1]: IPA Size Limit: 40bits
[ 0.424027] kvm [1]: vgic interrupt IRQ1
[ 0.424145] kvm [1]: Hyp mode initialized successfully
[ 0.676316] Initialise system trusted keyrings
[ 0.676486] workingset: timestamp_bits=46 max_order=19 bucket_order=0
[ 0.681208] zbud: loaded
[ 0.682566] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 0.683718] NFS: Registering the id_resolver key type
[ 0.683743] Key type id_resolver registered
[ 0.683746] Key type id_legacy registered
[ 0.683756] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 0.683764] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 0.684932] Key type cifs.idmap registered
[ 0.685039] fuse: init (API version 7.31)
[ 0.685317] SGI XFS with ACLs, security attributes, no debug enabled
[ 0.708181] NET: Registered protocol family 38
[ 0.708196] Key type asymmetric registered
[ 0.708200] Asymmetric key parser 'x509' registered
[ 0.708261] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 246)
[ 0.708429] io scheduler mq-deadline registered
[ 0.708588] io scheduler bfq registered
[ 0.708847] sun50i-de2-bus 1000000.bus: Error couldn't map SRAM to device
[ 0.708874] fbcon: Taking over console
[ 0.709288] sun4i-usb-phy 5100400.phy: Couldn't request ID GPIO
[ 0.709493] sun50i-usb3-phy 5210000.phy: failed to get phy clock
[ 0.712901] sun50i-h6-r-pinctrl 7022000.pinctrl: initialized sunXi PIO driver
[ 0.719403] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled
[ 0.722997] panfrost 1800000.gpu: clock rate = 432000000
[ 0.723015] panfrost 1800000.gpu: bus_clock rate = 100000000
[ 0.723032] panfrost 1800000.gpu: failed to get regulator: -517
[ 0.723048] panfrost 1800000.gpu: regulator init failed -517
[ 0.723408] cacheinfo: Unable to detect cache hierarchy for CPU 0
[ 0.729561] loop: module loaded
[ 0.742760] zram: Added device: zram0
[ 0.743419] Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
[ 0.745108] libphy: Fixed MDIO Bus: probed
[ 0.745263] tun: Universal TUN/TAP device driver, 1.6
[ 0.745888] Broadcom 43xx driver loaded [ Features: NLS ]
[ 0.746016] usbcore: registered new interface driver rt2800usb
[ 0.746047] usbcore: registered new interface driver r8152
[ 0.746097] usbcore: registered new interface driver cdc_ether
[ 0.746123] usbcore: registered new interface driver cdc_eem
[ 0.746163] usbcore: registered new interface driver cdc_ncm
[ 0.746559] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 0.746563] ehci-platform: EHCI generic platform driver
[ 0.746691] ehci-platform 5101000.usb: EHCI Host Controller
[ 0.746713] ehci-platform 5101000.usb: new USB bus registered, assigned bus number 1
[ 0.746791] ehci-platform 5101000.usb: irq 22, io mem 0x05101000
[ 0.759269] ehci-platform 5101000.usb: USB 2.0 started, EHCI 1.00
[ 0.759400] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.03
[ 0.759407] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.759412] usb usb1: Product: EHCI Host Controller
[ 0.759417] usb usb1: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a ehci_hcd
[ 0.759422] usb usb1: SerialNumber: 5101000.usb
[ 0.759729] hub 1-0:1.0: USB hub found
[ 0.759761] hub 1-0:1.0: 1 port detected
[ 0.760114] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 0.760127] ohci-platform: OHCI generic platform driver
[ 0.760232] ohci-platform 5101400.usb: Generic Platform OHCI controller
[ 0.760247] ohci-platform 5101400.usb: new USB bus registered, assigned bus number 2
[ 0.760314] ohci-platform 5101400.usb: irq 23, io mem 0x05101400
[ 0.823385] usb usb2: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.03
[ 0.823392] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.823397] usb usb2: Product: Generic Platform OHCI controller
[ 0.823402] usb usb2: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a ohci_hcd
[ 0.823407] usb usb2: SerialNumber: 5101400.usb
[ 0.823677] hub 2-0:1.0: USB hub found
[ 0.823700] hub 2-0:1.0: 1 port detected
[ 0.824295] usbcore: registered new interface driver cdc_acm
[ 0.824298] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 0.824338] usbcore: registered new interface driver usblp
[ 0.824368] usbcore: registered new interface driver cdc_wdm
[ 0.824398] usbcore: registered new interface driver uas
[ 0.824462] usbcore: registered new interface driver usb-storage
[ 0.824531] usbcore: registered new interface driver ch341
[ 0.824553] usbserial: USB Serial support registered for ch341-uart
[ 0.824580] usbcore: registered new interface driver cp210x
[ 0.824599] usbserial: USB Serial support registered for cp210x
[ 0.824642] usbcore: registered new interface driver ftdi_sio
[ 0.824662] usbserial: USB Serial support registered for FTDI USB Serial Device
[ 0.824746] usbcore: registered new interface driver pl2303
[ 0.824768] usbserial: USB Serial support registered for pl2303
[ 0.825365] vhci_hcd vhci_hcd.0: USB/IP Virtual Host Controller
[ 0.825374] vhci_hcd vhci_hcd.0: new USB bus registered, assigned bus number 3
[ 0.825400] vhci_hcd: created sysfs vhci_hcd.0
[ 0.825520] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.03
[ 0.825527] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.825532] usb usb3: Product: USB/IP Virtual Host Controller
[ 0.825537] usb usb3: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a vhci_hcd
[ 0.825542] usb usb3: SerialNumber: vhci_hcd.0
[ 0.825830] hub 3-0:1.0: USB hub found
[ 0.825857] hub 3-0:1.0: 8 ports detected
[ 0.826211] vhci_hcd vhci_hcd.0: USB/IP Virtual Host Controller
[ 0.826218] vhci_hcd vhci_hcd.0: new USB bus registered, assigned bus number 4
[ 0.826267] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM.
[ 0.826352] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.03
[ 0.826358] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 0.826363] usb usb4: Product: USB/IP Virtual Host Controller
[ 0.826368] usb usb4: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a vhci_hcd
[ 0.826373] usb usb4: SerialNumber: vhci_hcd.0
[ 0.826609] hub 4-0:1.0: USB hub found
[ 0.826631] hub 4-0:1.0: 8 ports detected
[ 0.827100] usbcore: registered new device driver usbip-host
[ 0.827541] mousedev: PS/2 mouse device common for all mice
[ 0.827976] sun6i-rtc 7000000.rtc: registered as rtc0
[ 0.827981] sun6i-rtc 7000000.rtc: RTC enabled
[ 0.828056] i2c /dev entries driver
[ 0.828223] sun50i-h6-r-pinctrl 7022000.pinctrl: 7022000.pinctrl supply vcc-pl not found, using dummy regulator
[ 0.828645] axp20x-i2c 0-0036: AXP20x variant AXP806 found
[ 0.833559] input: axp20x-pek as /devices/platform/soc/7081400.i2c/i2c-0/0-0036/axp221-pek/input/input0
[ 0.834617] dcdca: supplied by vcc-5v
[ 0.835642] dcdcc: supplied by vcc-5v
[ 0.836192] dcdcd: supplied by vcc-5v
[ 0.836748] dcdce: supplied by vcc-5v
[ 0.837315] aldo1: supplied by vcc-5v
[ 0.837861] aldo2: supplied by vcc-5v
[ 0.838401] aldo3: supplied by vcc-5v
[ 0.838963] bldo1: supplied by vcc-5v
[ 0.839932] bldo2: supplied by vcc-5v
[ 0.840465] bldo3: supplied by vcc-5v
[ 0.841022] bldo4: supplied by vcc-5v
[ 0.841572] cldo1: supplied by vcc-5v
[ 0.842119] cldo2: supplied by vcc-5v
[ 0.842677] cldo3: supplied by vcc-5v
[ 0.843232] sw: supplied by regulator-dummy
[ 0.843386] axp20x-i2c 0-0036: AXP20X driver loaded
[ 0.843491] IR NEC protocol handler initialized
[ 0.843494] IR RC5(x/sz) protocol handler initialized
[ 0.843496] IR RC6 protocol handler initialized
[ 0.843498] IR JVC protocol handler initialized
[ 0.843500] IR Sony protocol handler initialized
[ 0.843503] IR SANYO protocol handler initialized
[ 0.843505] IR Sharp protocol handler initialized
[ 0.843507] IR MCE Keyboard/mouse protocol handler initialized
[ 0.843509] IR XMP protocol handler initialized
[ 0.843789] usbcore: registered new interface driver uvcvideo
[ 0.843791] USB Video Class driver (1.1.1)
[ 0.844695] sunxi-wdt 7020400.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0)
[ 0.844882] device-mapper: uevent: version 1.0.3
[ 0.845083] device-mapper: ioctl: 4.40.0-ioctl (2019-01-18) initialised: dm-devel@redhat.com
[ 0.845089] Bluetooth: HCI UART driver ver 2.3
[ 0.845094] Bluetooth: HCI UART protocol H4 registered
[ 0.845155] Bluetooth: HCI UART protocol Broadcom registered
[ 0.846235] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 912000 KHz
[ 0.846617] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 1080000 KHz
[ 0.847162] sun50i-h6-r-pinctrl 7022000.pinctrl: 7022000.pinctrl supply vcc-pm not found, using dummy regulator
[ 0.847659] ledtrig-cpu: registered to indicate activity on CPUs
[ 0.847695] hidraw: raw HID events driver (C) Jiri Kosina
[ 0.847793] usbcore: registered new interface driver usbhid
[ 0.847795] usbhid: USB HID core driver
[ 0.848350] cedrus 1c0e000.video-codec: Device registered as /dev/video0
[ 0.848730] gnss: GNSS driver registered with major 242
[ 0.851607] usbcore: registered new interface driver snd-usb-audio
[ 0.852532] GACT probability NOT on
[ 0.861521] wireguard: WireGuard 0.0.20190702 loaded. See www.wireguard.com for information.
[ 0.861525] wireguard: Copyright (C) 2015-2019 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
[ 0.861598] ipip: IPv4 and MPLS over IPv4 tunneling driver
[ 0.861845] Initializing XFRM netlink socket
[ 0.862116] NET: Registered protocol family 10
[ 0.862579] Segment Routing with IPv6
[ 0.862882] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 0.863295] NET: Registered protocol family 17
[ 0.863309] NET: Registered protocol family 15
[ 0.863343] Bridge firewalling registered
[ 0.863419] Bluetooth: RFCOMM TTY layer initialized
[ 0.863428] Bluetooth: RFCOMM socket layer initialized
[ 0.863448] Bluetooth: RFCOMM ver 1.11
[ 0.863452] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 0.863454] Bluetooth: BNEP filters: protocol multicast
[ 0.863458] Bluetooth: BNEP socket layer initialized
[ 0.863460] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 0.863463] Bluetooth: HIDP socket layer initialized
[ 0.863507] l2tp_core: L2TP core driver, V2.0
[ 0.863508] l2tp_netlink: L2TP netlink interface
[ 0.863530] NET4: DECnet for Linux: V.2.5.68s (C) 1995-2003 Linux DECnet Project Team
[ 0.863643] DECnet: Routing cache hash table of 1024 buckets, 16Kbytes
[ 0.863667] NET: Registered protocol family 12
[ 0.863679] 8021q: 802.1Q VLAN Support v1.8
[ 0.863705] Key type dns_resolver registered
[ 0.864088] registered taskstats version 1
[ 0.864090] Loading compiled-in X.509 certificates
[ 0.872926] Key type encrypted registered
[ 0.878595] sun4i-usb-phy 5100400.phy: Couldn't request ID GPIO
[ 0.881048] sun50i-h6-pinctrl 300b000.pinctrl: initialized sunXi PIO driver
[ 0.881200] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-ph not found, using dummy regulator
[ 0.881433] printk: console [ttyS0] disabled
[ 0.902200] 5000000.serial: ttyS0 at MMIO 0x5000000 (irq = 18, base_baud = 1500000) is a 16550A
[ 0.930600] printk: console [ttyS0] enabled
[ 0.951853] 5000400.serial: ttyS1 at MMIO 0x5000400 (irq = 19, base_baud = 1500000) is a 16550A
[ 0.951912] serial serial0: tty port ttyS1 registered
[ 0.952018] hci_uart_bcm serial0-0: serial0-0 supply vbat not found, using dummy regulator
[ 0.952049] hci_uart_bcm serial0-0: serial0-0 supply vddio not found, using dummy regulator
[ 0.961698] sun4i-drm display-engine: bound 1100000.mixer (ops 0xffffff8010e9a2c8)
[ 0.961800] sun4i-drm display-engine: bound 6510000.tcon-top (ops 0xffffff8010e9e3c8)
[ 0.961937] sun4i-drm display-engine: bound 6515000.lcd-controller (ops 0xffffff8010e967d8)
[ 0.961971] sun8i-dw-hdmi 6000000.hdmi: 6000000.hdmi supply hvcc not found, using dummy regulator
[ 0.962154] sun8i-dw-hdmi 6000000.hdmi: Detected HDMI TX controller v2.12a with HDCP (DWC HDMI 2.0 TX PHY)
[ 0.962399] sun8i-dw-hdmi 6000000.hdmi: registered DesignWare HDMI I2C bus driver
[ 0.991255] rc_core: IR keymap rc-cec not found
[ 0.994488] Registered IR keymap rc-empty
[ 0.994545] rc rc0: dw_hdmi as /devices/platform/soc/6000000.hdmi/rc/rc0
[ 0.994609] input: dw_hdmi as /devices/platform/soc/6000000.hdmi/rc/rc0/input1
[ 0.994791] sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffffff8010e99670)
[ 0.994794] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 0.994795] [drm] No driver support for vblank timestamp query.
[ 0.994933] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
[ 1.030061] random: fast init done
[ 1.140721] Console: switching to colour frame buffer device 240x67
[ 1.173718] sun4i-drm display-engine: fb0: sun4i-drmdrmfb frame buffer device
[ 1.173990] panfrost 1800000.gpu: clock rate = 432000000
[ 1.174005] panfrost 1800000.gpu: bus_clock rate = 100000000
[ 1.174101] panfrost 1800000.gpu: mali-t720 id 0x720 major 0x1 minor 0x1 status 0x0
[ 1.174105] panfrost 1800000.gpu: features: 00000000,10309e40, issues: 00000000,21054400
[ 1.174109] panfrost 1800000.gpu: Features: L2:0x07110206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002821 AS:0xf JS:0x7
[ 1.174111] panfrost 1800000.gpu: shader_present=0x3 l2_present=0x1
[ 1.174678] [drm] Initialized panfrost 1.0.0 20180908 for 1800000.gpu on minor 1
[ 1.175156] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[ 1.175693] xhci-hcd xhci-hcd.3.auto: xHCI Host Controller
[ 1.175704] xhci-hcd xhci-hcd.3.auto: new USB bus registered, assigned bus number 5
[ 1.175808] xhci-hcd xhci-hcd.3.auto: hcc params 0x0220f064 hci version 0x100 quirks 0x0000000002010010
[ 1.175833] xhci-hcd xhci-hcd.3.auto: irq 24, io mem 0x05200000
[ 1.176017] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.03
[ 1.176020] usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.176023] usb usb5: Product: xHCI Host Controller
[ 1.176026] usb usb5: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a xhci-hcd
[ 1.176028] usb usb5: SerialNumber: xhci-hcd.3.auto
[ 1.176226] hub 5-0:1.0: USB hub found
[ 1.176240] hub 5-0:1.0: 1 port detected
[ 1.176345] xhci-hcd xhci-hcd.3.auto: xHCI Host Controller
[ 1.176352] xhci-hcd xhci-hcd.3.auto: new USB bus registered, assigned bus number 6
[ 1.176360] xhci-hcd xhci-hcd.3.auto: Host supports USB 3.0 SuperSpeed
[ 1.176386] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1.176426] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 5.03
[ 1.176429] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.176432] usb usb6: Product: xHCI Host Controller
[ 1.176435] usb usb6: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a xhci-hcd
[ 1.176437] usb usb6: SerialNumber: xhci-hcd.3.auto
[ 1.176575] hub 6-0:1.0: USB hub found
[ 1.176587] hub 6-0:1.0: 1 port detected
[ 1.177598] thermal thermal_zone0: failed to read out thermal zone (-16)
[ 1.177631] thermal thermal_zone1: failed to read out thermal zone (-16)
[ 1.177870] sun50i-h6-pinctrl 300b000.pinctrl: 300b000.pinctrl supply vcc-pf not found, using dummy regulator
[ 1.178174] sunxi-mmc 4020000.mmc: Got CD GPIO
[ 1.203389] sunxi-mmc 4020000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[ 1.203965] sunxi-mmc 4021000.mmc: allocated mmc-pwrseq
[ 1.239482] mmc0: host does not support reading read-only switch, assuming write-enable
[ 1.242266] mmc0: new high speed SDHC card at address aaaa
[ 1.243053] mmcblk0: mmc0:aaaa SC32G 29.7 GiB
[ 1.245094] mmcblk0: p1 p2 p3
[ 1.303877] Bluetooth: hci0: BCM: chip id 130
[ 1.304159] Bluetooth: hci0: BCM: features 0x0f
[ 1.306148] Bluetooth: hci0: BCM4345C5
[ 1.306152] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0000
[ 1.431794] sunxi-mmc 4021000.mmc: initialized, max. request size: 16384 KB, uses new timings mode
[ 1.432870] dwmac-sun8i 5020000.ethernet: PTP uses main clock
[ 1.448878] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[ 1.450368] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1.451884] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[ 1.454566] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[ 1.457841] mmc1: queuing unknown CIS tuple 0x81 (9 bytes)
[ 1.508685] mmc1: new high speed SDIO card at address 0001
[ 1.511037] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[ 1.511182] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.xunlong,orangepi-3.txt failed with error -2
[ 1.511404] usb 6-1: new SuperSpeed Gen 1 USB device number 2 using xhci-hcd
[ 1.536122] usb 6-1: New USB device found, idVendor=05e3, idProduct=0626, bcdDevice= 6.54
[ 1.536126] usb 6-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.536129] usb 6-1: Product: USB3.1 Hub
[ 1.536132] usb 6-1: Manufacturer: GenesysLogic
[ 1.539399] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
[ 1.539413] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
[ 1.539415] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
[ 1.539418] dwmac-sun8i 5020000.ethernet: COE Type 2
[ 1.539420] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
[ 1.539423] dwmac-sun8i 5020000.ethernet: Normal descriptors
[ 1.539426] dwmac-sun8i 5020000.ethernet: Chain mode enabled
[ 1.539505] libphy: stmmac: probed
[ 1.560897] hub 6-1:1.0: USB hub found
[ 1.561189] hub 6-1:1.0: 4 ports detected
[ 1.604397] ehci-platform 5311000.usb: EHCI Host Controller
[ 1.604411] ehci-platform 5311000.usb: new USB bus registered, assigned bus number 7
[ 1.604471] ehci-platform 5311000.usb: irq 25, io mem 0x05311000
[ 1.614585] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[ 1.614656] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 1.615076] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84
[ 1.659269] usb 5-1: new high-speed USB device number 2 using xhci-hcd
[ 1.675254] ehci-platform 5311000.usb: USB 2.0 started, EHCI 1.00
[ 1.675354] usb usb7: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.03
[ 1.675357] usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.675361] usb usb7: Product: EHCI Host Controller
[ 1.675363] usb usb7: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a ehci_hcd
[ 1.675366] usb usb7: SerialNumber: 5311000.usb
[ 1.675601] hub 7-0:1.0: USB hub found
[ 1.675617] hub 7-0:1.0: 1 port detected
[ 1.676010] ohci-platform 5311400.usb: Generic Platform OHCI controller
[ 1.676021] ohci-platform 5311400.usb: new USB bus registered, assigned bus number 8
[ 1.676091] ohci-platform 5311400.usb: irq 26, io mem 0x05311400
[ 1.739320] usb usb8: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 5.03
[ 1.739323] usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.739326] usb usb8: Product: Generic Platform OHCI controller
[ 1.739328] usb usb8: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a ohci_hcd
[ 1.739331] usb usb8: SerialNumber: 5311400.usb
[ 1.739515] hub 8-0:1.0: USB hub found
[ 1.739529] hub 8-0:1.0: 1 port detected
[ 1.739919] usb_phy_generic usb_phy_generic.4.auto: usb_phy_generic.4.auto supply vcc not found, using dummy regulator
[ 1.740079] musb-hdrc musb-hdrc.5.auto: MUSB HDRC host driver
[ 1.740084] musb-hdrc musb-hdrc.5.auto: new USB bus registered, assigned bus number 9
[ 1.740146] usb usb9: New USB device found, idVendor=1d6b, idProduct=0002, bcdDevice= 5.03
[ 1.740149] usb usb9: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.740153] usb usb9: Product: MUSB HDRC host driver
[ 1.740155] usb usb9: Manufacturer: Linux 5.3.0-rc1-00094-g7d082263f65a musb-hcd
[ 1.740158] usb usb9: SerialNumber: musb-hdrc.5.auto
[ 1.740310] hub 9-0:1.0: USB hub found
[ 1.740323] hub 9-0:1.0: 1 port detected
[ 1.740635] sun6i-rtc 7000000.rtc: setting system clock to 2019-07-22T13:48:21 UTC (1563803301)
[ 1.740708] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 1.750388] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 1.750549] ALSA device list:
[ 1.750552] #0: Dummy 1
[ 1.750555] #1: Loopback 1
[ 1.751413] Freeing unused kernel memory: 2048K
[ 1.771259] Run /init as init process
[ 1.825623] usb 5-1: New USB device found, idVendor=05e3, idProduct=0610, bcdDevice= 6.54
[ 1.825630] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 1.825633] usb 5-1: Product: USB2.1 Hub
[ 1.825636] usb 5-1: Manufacturer: GenesysLogic
[ 1.880817] hub 5-1:1.0: USB hub found
[ 1.881145] hub 5-1:1.0: 4 ports detected
[ 2.000045] Bluetooth: hci0: BCM4345C5 (003.006.006) build 0038
[ 2.000740] Bluetooth: hci0: BCM: Using default device address (43:45:c5:00:1f:ac)
[ 2.435373] F2FS-fs (mmcblk0p3): Mounted with checkpoint version = 58e966d1
[ 3.090732] systemd[1]: systemd 242.32-3-arch running in system mode. (+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[ 3.090997] systemd[1]: Detected architecture arm64.
[ 3.094359] systemd[1]: Set hostname to <l10>.
[ 3.664342] systemd[1]: Condition check resulted in Arbitrary Executable File Formats File System Automount Point being skipped.
[ 3.664384] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.664409] systemd[1]: Reached target Swap.
[ 3.664616] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.667743] systemd[1]: Listening on Journal Socket (/dev/log).
[ 3.680859] systemd[1]: Condition check resulted in Journal Audit Socket being skipped.
[ 3.680954] random: systemd: uninitialized urandom read (16 bytes read)
[ 3.681982] systemd[1]: Listening on udev Kernel Socket.
[ 3.682204] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[ 3.682445] systemd[1]: Listening on udev Control Socket.
[ 4.253914] systemd-journald[387]: Received request to flush runtime journal from PID 1
[ 4.936393] FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 5.442451] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
[ 5.442462] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062ff advertising 00,00000000,000062ff
[ 5.443791] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
[ 5.443801] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
[ 5.443805] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
[ 5.443812] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
[ 5.443823] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0 an=1
[ 5.448927] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
[ 5.784492] zram0: detected capacity change from 0 to 402653184
[ 5.838129] random: crng init done
[ 5.838138] random: 7 urandom warning(s) missed due to ratelimiting
[ 5.919346] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
[ 10.559750] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/1Gbps/Full
[ 10.559768] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
[ 10.559782] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 10.559808] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Settings for eth0:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: MII
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x0000003f (63)
drv probe link timer ifdown ifup
Link detected: yes
^ permalink raw reply
* RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Jose Abreu @ 2019-07-22 14:26 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu
Cc: Ondřej Jirman, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190722141943.GE8972@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Jul/22/2019, 15:19:43 (UTC+00:00)
> On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> > From: Andrew Lunn <andrew@lunn.ch>
> > Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> >
> > > Does this mean that all stmmac variants support 1G? There are none
> > > which just support Fast Ethernet?
> >
> > This glue logic drivers sometimes reflect a custom IP that's Synopsys
> > based but modified by customer, so I can't know before-hand what's the
> > supported max speed. There are some old versions that don't support 1G
> > but I expect that PHY driver limits this ...
>
> If a Fast PHY is used, then yes, it would be limited. But sometimes a
> 1G PHY is used because they are cheaper than a Fast PHY.
>
> > > I'm also not sure the change fits the problem. Why did it not
> > > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > > speeds around, so 100 speeds should of been advertised and selected.
> >
> > Hmm, now that I'm looking at it closer I agree with you. Maybe link
> > partner or PHY doesn't support 100M ?
>
> In the working case, ethtool shows the link partner supports 10, 100,
> and 1G. So something odd is going on here.
>
> You fix does seems reasonable, and it has been reported to fix the
> issue, but it would be good to understand what is going on here.
Agreed!
Ondrej, can you please share dmesg log and ethtool output with the fixed
patch ?
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: fix sendmsg6_prog on s390
From: Daniel Borkmann @ 2019-07-22 14:23 UTC (permalink / raw)
To: Ilya Leoshkevich, bpf, netdev; +Cc: gor, heiko.carstens, rdna
In-Reply-To: <20190719090611.91743-1-iii@linux.ibm.com>
On 7/19/19 11:06 AM, Ilya Leoshkevich wrote:
> "sendmsg6: rewrite IP & port (C)" fails on s390, because the code in
> sendmsg_v6_prog() assumes that (ctx->user_ip6[0] & 0xFFFF) refers to
> leading IPv6 address digits, which is not the case on big-endian
> machines.
>
> Since checking bitwise operations doesn't seem to be the point of the
> test, replace two short comparisons with a single int comparison.
>
> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Applied, thanks!
^ permalink raw reply
* Re: [GIT PULL 0/2] libbpf build fixes
From: Daniel Borkmann @ 2019-07-22 14:23 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Alexei Starovoitov
Cc: Clark Williams, bpf, netdev, Adrian Hunter, Andrii Nakryiko,
Ingo Molnar, Jiri Olsa, Namhyung Kim
In-Reply-To: <20190719143407.20847-1-acme@kernel.org>
On 7/19/19 4:34 PM, Arnaldo Carvalho de Melo wrote:
> Hi Daniel,
>
> Please consider pulling or applying from the patches, if someone
> has any issues, please holler,
>
> - Arnaldo
>
> Arnaldo Carvalho de Melo (2):
> libbpf: Fix endianness macro usage for some compilers
> libbpf: Avoid designated initializers for unnamed union members
>
> tools/lib/bpf/btf.c | 5 +++--
> tools/lib/bpf/libbpf.c | 19 ++++++++++---------
> 2 files changed, 13 insertions(+), 11 deletions(-)
>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH bpf v4 00/14] sockmap/tls fixes
From: Daniel Borkmann @ 2019-07-22 14:22 UTC (permalink / raw)
To: Jakub Kicinski, john.fastabend, alexei.starovoitov
Cc: edumazet, netdev, bpf, oss-drivers
In-Reply-To: <20190719103721.558d9e7d@cakuba.netronome.com>
On 7/19/19 7:37 PM, Jakub Kicinski wrote:
> On Fri, 19 Jul 2019 10:29:13 -0700, Jakub Kicinski wrote:
>> John says:
>>
>> Resolve a series of splats discovered by syzbot and an unhash
>> TLS issue noted by Eric Dumazet.
>
> Sorry for the delay, this code is quite tricky. According to my testing
> TLS SW and HW should now work, I hope I didn't regress things on the
> sockmap side.
Applied, thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Andrew Lunn @ 2019-07-22 14:19 UTC (permalink / raw)
To: Jose Abreu
Cc: Ondřej Jirman, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <BN8PR12MB3266678A3ABD0EBF429C9766D3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On Mon, Jul 22, 2019 at 01:58:20PM +0000, Jose Abreu wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Jul/22/2019, 14:40:23 (UTC+00:00)
>
> > Does this mean that all stmmac variants support 1G? There are none
> > which just support Fast Ethernet?
>
> This glue logic drivers sometimes reflect a custom IP that's Synopsys
> based but modified by customer, so I can't know before-hand what's the
> supported max speed. There are some old versions that don't support 1G
> but I expect that PHY driver limits this ...
If a Fast PHY is used, then yes, it would be limited. But sometimes a
1G PHY is used because they are cheaper than a Fast PHY.
> > I'm also not sure the change fits the problem. Why did it not
> > negotiate 100FULL rather than 10Half? You are only moving the 1G
> > speeds around, so 100 speeds should of been advertised and selected.
>
> Hmm, now that I'm looking at it closer I agree with you. Maybe link
> partner or PHY doesn't support 100M ?
In the working case, ethtool shows the link partner supports 10, 100,
and 1G. So something odd is going on here.
You fix does seems reasonable, and it has been reported to fix the
issue, but it would be good to understand what is going on here.
Andrew
^ permalink raw reply
* [PATCH net] net: stmmac: Do not cut down 1G modes
From: Jose Abreu @ 2019-07-22 14:07 UTC (permalink / raw)
To: netdev
Cc: Joao Pinto, Jose Abreu, Giuseppe Cavallaro, Alexandre Torgue,
David S. Miller, Maxime Coquelin, linux-stm32, linux-arm-kernel,
linux-kernel, Ondrej Jirman
Some glue logic drivers support 1G without having GMAC/GMAC4/XGMAC.
Let's allow this speed by default.
Reported-by: Ondrej Jirman <megi@xff.cz>
Tested-by: Ondrej Jirman <megi@xff.cz>
Fixes: 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: Ondrej Jirman <megi@xff.cz>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 207c3755bcc5..b0d5e5346597 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -814,20 +814,15 @@ static void stmmac_validate(struct phylink_config *config,
phylink_set(mac_supported, 10baseT_Full);
phylink_set(mac_supported, 100baseT_Half);
phylink_set(mac_supported, 100baseT_Full);
+ phylink_set(mac_supported, 1000baseT_Half);
+ phylink_set(mac_supported, 1000baseT_Full);
+ phylink_set(mac_supported, 1000baseKX_Full);
phylink_set(mac_supported, Autoneg);
phylink_set(mac_supported, Pause);
phylink_set(mac_supported, Asym_Pause);
phylink_set_port_modes(mac_supported);
- if (priv->plat->has_gmac ||
- priv->plat->has_gmac4 ||
- priv->plat->has_xgmac) {
- phylink_set(mac_supported, 1000baseT_Half);
- phylink_set(mac_supported, 1000baseT_Full);
- phylink_set(mac_supported, 1000baseKX_Full);
- }
-
/* Cut down 1G if asked to */
if ((max_speed > 0) && (max_speed < 1000)) {
phylink_set(mask, 1000baseT_Full);
--
2.7.4
^ permalink raw reply related
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-22 14:04 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, Lars Persson, Ilias Apalodimas
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Maxime Coquelin, Maxime Ripard, Chen-Yu Tsai, linux-tegra
In-Reply-To: <11557fe0-0cba-cb49-0fb6-ad24792d4a53@nvidia.com>
From: Jon Hunter <jonathanh@nvidia.com>
Date: Jul/22/2019, 13:05:38 (UTC+00:00)
>
> On 22/07/2019 12:39, Jose Abreu wrote:
> > From: Lars Persson <lists@bofh.nu>
> > Date: Jul/22/2019, 12:11:50 (UTC+00:00)
> >
> >> On Mon, Jul 22, 2019 at 12:18 PM Ilias Apalodimas
> >> <ilias.apalodimas@linaro.org> wrote:
> >>>
> >>> On Thu, Jul 18, 2019 at 07:48:04AM +0000, Jose Abreu wrote:
> >>>> From: Jon Hunter <jonathanh@nvidia.com>
> >>>> Date: Jul/17/2019, 19:58:53 (UTC+00:00)
> >>>>
> >>>>> Let me know if you have any thoughts.
> >>>>
> >>>> Can you try attached patch ?
> >>>>
> >>>
> >>> The log says someone calls panic() right?
> >>> Can we trye and figure were that happens during the stmmac init phase?
> >>>
> >>
> >> The reason for the panic is hidden in this one line of the kernel logs:
> >> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> >>
> >> The init process is killed by SIGSEGV (signal 11 = 0xb).
> >>
> >> I would suggest you look for data corruption bugs in the RX path. If
> >> the code is fetched from the NFS mount then a corrupt RX buffer can
> >> trigger a crash in userspace.
> >>
> >> /Lars
> >
> >
> > Jon, I'm not familiar with ARM. Are the buffer addresses being allocated
> > in a coherent region ? Can you try attached patch which adds full memory
> > barrier before the sync ?
>
> TBH I am not sure about the buffer addresses either. The attached patch
> did not help. Same problem persists.
OK. I'm just guessing now at this stage but can you disable SMP ?
We have to narrow down if this is coherency issue but you said that
booting without NFS and then mounting manually the share works ... So,
can you share logs with same debug prints in this condition in order to
compare ?
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Jose Abreu @ 2019-07-22 13:58 UTC (permalink / raw)
To: Andrew Lunn, Jose Abreu
Cc: Ondřej Jirman, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190722134023.GD8972@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Jul/22/2019, 14:40:23 (UTC+00:00)
> Does this mean that all stmmac variants support 1G? There are none
> which just support Fast Ethernet?
This glue logic drivers sometimes reflect a custom IP that's Synopsys
based but modified by customer, so I can't know before-hand what's the
supported max speed. There are some old versions that don't support 1G
but I expect that PHY driver limits this ...
> I'm also not sure the change fits the problem. Why did it not
> negotiate 100FULL rather than 10Half? You are only moving the 1G
> speeds around, so 100 speeds should of been advertised and selected.
Hmm, now that I'm looking at it closer I agree with you. Maybe link
partner or PHY doesn't support 100M ?
It's working for Ondrej but I got curious now ...
---
Thanks,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Ondřej Jirman @ 2019-07-22 13:49 UTC (permalink / raw)
To: Jose Abreu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Russell King, Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <BN8PR12MB32660B12F8E2617ED42249BBD3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 8335 bytes --]
On Mon, Jul 22, 2019 at 01:28:51PM +0000, Jose Abreu wrote:
> From: Ondřej Jirman <megi@xff.cz>
> Date: Jul/22/2019, 13:42:40 (UTC+00:00)
>
> > Hello Jose,
> >
> > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > > [ Hope this diff looks better (generated with --minimal) ]
> > >
> > > This converts stmmac to use phylink. Besides the code redution this will
> > > allow to gain more flexibility.
> >
> > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
> >
> > After going through stmmac patches since 5.2, I think it may be realted to this
> > series, but I'm not completely sure. You'll probably have a better understanding
> > of the changes. Do you have an idea what might be wrong? Please, see some logs
> > below.
>
> Probably due to:
> 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
>
> Can you try attached patch ?
Tried, and it works!
dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062ff advertising 00,00000000,000062ff
dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062ff pause=10 link=0 an=1
dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/1Gbps/Full
dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/1Gbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Tested-by: Ondrej Jirman <megi@xff.cz>
thank you,
Ondrej
>
> >
> > thank you and regards,
> > Ondrej
> >
> > On 5.3-rc1 I see:
> >
> > [ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
> > [ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
> > [ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> > [ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> > [ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> > [ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
> > [ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
> > [ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
> > [ 6.276325] random: crng init done
> > [ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
> > [ 7.543987] zram0: detected capacity change from 0 to 402653184
> > [ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
> >
> > ... delay due to other causes ...
> >
> > [ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
> > [ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> > [ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > Supported pause frame use: Symmetric Receive-only
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > Advertised pause frame use: Symmetric Receive-only
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > Link partner advertised pause frame use: Symmetric Receive-only
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 10Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Current message level: 0x0000003f (63)
> > drv probe link timer ifdown ifup
> > Link detected: yes
> >
> > On 5.2 it looks like this:
> >
> > [ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > [ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> > [ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> > [ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> > [ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> > [ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
> > [ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> > [ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
> > [ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> > [ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> > [ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> > [ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> > [ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> >
> > Settings for eth0:
> > Supported ports: [ TP MII ]
> > Supported link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Half 1000baseT/Full
> > Supported pause frame use: Symmetric Receive-only
> > Supports auto-negotiation: Yes
> > Supported FEC modes: Not reported
> > Advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Half 1000baseT/Full
> > Advertised pause frame use: No
> > Advertised auto-negotiation: Yes
> > Advertised FEC modes: Not reported
> > Link partner advertised link modes: 10baseT/Half 10baseT/Full
> > 100baseT/Half 100baseT/Full
> > 1000baseT/Full
> > Link partner advertised pause frame use: Symmetric Receive-only
> > Link partner advertised auto-negotiation: Yes
> > Link partner advertised FEC modes: Not reported
> > Speed: 1000Mb/s
> > Duplex: Full
> > Port: MII
> > PHYAD: 1
> > Transceiver: internal
> > Auto-negotiation: on
> > Supports Wake-on: d
> > Wake-on: d
> > Current message level: 0x0000003f (63)
> > drv probe link timer ifdown ifup
> > Link detected: yes
> >
> >
> > > Cc: Joao Pinto <jpinto@synopsys.com>
> > > Cc: David S. Miller <davem@davemloft.net>
> > > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > > Cc: Alexandre Torgue <alexandre.torgue@st.com>
> > > Cc: Russell King <linux@armlinux.org.uk>
> > > Cc: Andrew Lunn <andrew@lunn.ch>
> > > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > > Cc: Heiner Kallweit <hkallweit1@gmail.com>
> > >
> > > Jose Abreu (3):
> > > net: stmmac: Prepare to convert to phylink
> > > net: stmmac: Start adding phylink support
> > > net: stmmac: Convert to phylink and remove phylib logic
> > >
> > > drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> > > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> > > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> > > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> > > .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> > > 5 files changed, 190 insertions(+), 313 deletions(-)
> > >
> > > --
> > > 2.21.0
> > >
>
>
> ---
> Thanks,
> Jose Miguel Abreu
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH glibc] Linux: Include <linux/sockios.h> in <bits/socket.h> under __USE_MISC
From: Szabolcs Nagy @ 2019-07-22 13:47 UTC (permalink / raw)
To: Florian Weimer
Cc: nd, Arnd Bergmann, GNU C Library, Sergei Trofimovich, Networking,
Linux Kernel Mailing List, David S. Miller, Michael Kerrisk,
linux-man
In-Reply-To: <87lfwqqj3s.fsf@oldenburg2.str.redhat.com>
On 22/07/2019 14:44, Florian Weimer wrote:
> * Szabolcs Nagy:
>
>> (note: in musl these ioctl macros are in sys/ioctl.h
>> which is not a posix header so namespace rules are
>> less strict than for sys/socket.h and users tend to
>> include it for ioctl())
>
> <sys/ioctl.h> can be confusing because some of the constants may depend
> on types that aren't declared by including the header. This makes their
> macros unusable. Defining ioctl constants in headers which also provide
> the matching types avoids that problem at least, also it can introduce
> namespace issues.
yeah, the way we deal with that is we hard code the numbers
since the size of struct is abi, they cannot change.
^ permalink raw reply
* Re: [PATCH glibc] Linux: Include <linux/sockios.h> in <bits/socket.h> under __USE_MISC
From: Florian Weimer @ 2019-07-22 13:44 UTC (permalink / raw)
To: Szabolcs Nagy
Cc: Arnd Bergmann, nd, GNU C Library, Sergei Trofimovich, Networking,
Linux Kernel Mailing List, David S. Miller, Michael Kerrisk,
linux-man
In-Reply-To: <2431941f-3aac-d31f-e6f5-8ed2ed7b2e5c@arm.com>
* Szabolcs Nagy:
> (note: in musl these ioctl macros are in sys/ioctl.h
> which is not a posix header so namespace rules are
> less strict than for sys/socket.h and users tend to
> include it for ioctl())
<sys/ioctl.h> can be confusing because some of the constants may depend
on types that aren't declared by including the header. This makes their
macros unusable. Defining ioctl constants in headers which also provide
the matching types avoids that problem at least, also it can introduce
namespace issues.
Thanks,
Florian
^ permalink raw reply
* Re: [PATCH glibc] Linux: Include <linux/sockios.h> in <bits/socket.h> under __USE_MISC
From: Szabolcs Nagy @ 2019-07-22 13:41 UTC (permalink / raw)
To: Arnd Bergmann, Florian Weimer
Cc: nd, GNU C Library, Sergei Trofimovich, Networking,
Linux Kernel Mailing List, David S. Miller, Michael Kerrisk,
linux-man
In-Reply-To: <CAK8P3a0hC4wvjwCi4=DCET3C4qARMY6c58ffjwG3b1ZPM6kr-A@mail.gmail.com>
On 22/07/2019 12:34, Arnd Bergmann wrote:
> On Mon, Jul 22, 2019 at 1:31 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> Historically, <asm/socket.h> (which is included from <bits/socket.h>)
>> provided ioctl operations for sockets. User code accessed them
>> through <sys/socket.h>. The kernel UAPI headers have removed these
>> definitions in favor of <linux/sockios.h>. This commit makes them
>> available via <sys/socket.h> again.
>
> Looks good to me.
>
> I wonder if we should still do these two changes in the kernel:
>
> - include asm/socket.h from linux/socket.h for consistency
> - move the defines that got moved from asm/sockios.h to linux/sockios.h
> back to the previous location to help anyone who is user
> newer kernel headers with older glibc headers.
does user code actually expect these in sys/socket.h
or in asm/socket.h ?
man 7 socket
mentions SIOCGSTAMP but does not say the header.
man 2 ioctl_list
specifies include/asm-i386/socket.h as the location.
if user code tends to directly include asm/socket.h
then i think it's better to undo the kernel header
change than to put things in sys/socket.h.
(note: in musl these ioctl macros are in sys/ioctl.h
which is not a posix header so namespace rules are
less strict than for sys/socket.h and users tend to
include it for ioctl())
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Andrew Lunn @ 2019-07-22 13:40 UTC (permalink / raw)
To: Jose Abreu
Cc: Ondřej Jirman, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, Joao Pinto, David S . Miller,
Giuseppe Cavallaro, Alexandre Torgue, Russell King,
Florian Fainelli, Heiner Kallweit
In-Reply-To: <BN8PR12MB32660B12F8E2617ED42249BBD3C40@BN8PR12MB3266.namprd12.prod.outlook.com>
On Mon, Jul 22, 2019 at 01:28:51PM +0000, Jose Abreu wrote:
> From: Ondřej Jirman <megi@xff.cz>
> Date: Jul/22/2019, 13:42:40 (UTC+00:00)
>
> > Hello Jose,
> >
> > On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > > [ Hope this diff looks better (generated with --minimal) ]
> > >
> > > This converts stmmac to use phylink. Besides the code redution this will
> > > allow to gain more flexibility.
> >
> > I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> > 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
> >
> > After going through stmmac patches since 5.2, I think it may be realted to this
> > series, but I'm not completely sure. You'll probably have a better understanding
> > of the changes. Do you have an idea what might be wrong? Please, see some logs
> > below.
>
> Probably due to:
> 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
>
> Can you try attached patch ?
>
Hi Jose
Does this mean that all stmmac variants support 1G? There are none
which just support Fast Ethernet?
I'm also not sure the change fits the problem. Why did it not
negotiate 100FULL rather than 10Half? You are only moving the 1G
speeds around, so 100 speeds should of been advertised and selected.
Thanks
Andrew
^ permalink raw reply
* RE: [PATCH net-next 0/3] net: stmmac: Convert to phylink
From: Jose Abreu @ 2019-07-22 13:28 UTC (permalink / raw)
To: Ondřej Jirman, Jose Abreu
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org, Joao Pinto,
David S . Miller, Giuseppe Cavallaro, Alexandre Torgue,
Russell King, Andrew Lunn, Florian Fainelli, Heiner Kallweit
In-Reply-To: <20190722124240.464e73losonwb356@core.my.home>
[-- Attachment #1: Type: text/plain, Size: 6856 bytes --]
From: Ondřej Jirman <megi@xff.cz>
Date: Jul/22/2019, 13:42:40 (UTC+00:00)
> Hello Jose,
>
> On Tue, Jun 11, 2019 at 05:18:44PM +0200, Jose Abreu wrote:
> > [ Hope this diff looks better (generated with --minimal) ]
> >
> > This converts stmmac to use phylink. Besides the code redution this will
> > allow to gain more flexibility.
>
> I'm testing 5.3-rc1 and on Orange Pi 3 (uses stmmac-sun8i.c glue) compared to
> 5.2 it fails to detect 1000Mbps link and the driver negotiates just a 10Mbps speed.
>
> After going through stmmac patches since 5.2, I think it may be realted to this
> series, but I'm not completely sure. You'll probably have a better understanding
> of the changes. Do you have an idea what might be wrong? Please, see some logs
> below.
Probably due to:
5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
Can you try attached patch ?
>
> thank you and regards,
> Ondrej
>
> On 5.3-rc1 I see:
>
> [ 6.116512] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet]
> [ 6.116522] dwmac-sun8i 5020000.ethernet eth0: phy: setting supported 00,00000000,000062cf advertising 00,00000000,000062cf
> [ 6.118714] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> [ 6.118725] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> [ 6.118730] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> [ 6.118738] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii link mode
> [ 6.118747] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/Unknown/Unknown adv=00,00000000,000062cf pause=10 link=0 an=1
> [ 6.126099] dwmac-sun8i 5020000.ethernet eth0: phy link down rgmii/Unknown/Unknown
> [ 6.276325] random: crng init done
> [ 6.276338] random: 7 urandom warning(s) missed due to ratelimiting
> [ 7.543987] zram0: detected capacity change from 0 to 402653184
> [ 7.667702] Adding 393212k swap on /dev/zram0. Priority:10 extents:1 across:393212k SS
>
> ... delay due to other causes ...
>
> [ 28.640234] dwmac-sun8i 5020000.ethernet eth0: phy link up rgmii/10Mbps/Full
> [ 28.640295] dwmac-sun8i 5020000.ethernet eth0: phylink_mac_config: mode=phy/rgmii/10Mbps/Full adv=00,00000000,00000000 pause=0f link=1 an=0
> [ 28.640324] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 10Mbps/Full - flow control rx/tx
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> Advertised pause frame use: Symmetric Receive-only
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> Link partner advertised pause frame use: Symmetric Receive-only
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 10Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Current message level: 0x0000003f (63)
> drv probe link timer ifdown ifup
> Link detected: yes
>
> On 5.2 it looks like this:
>
> [ 1.153596] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> [ 1.416221] dwmac-sun8i 5020000.ethernet: PTP uses main clock
> [ 1.522735] dwmac-sun8i 5020000.ethernet: Current syscon value is not the default 58000 (expect 50000)
> [ 1.522750] dwmac-sun8i 5020000.ethernet: No HW DMA feature register supported
> [ 1.522753] dwmac-sun8i 5020000.ethernet: RX Checksum Offload Engine supported
> [ 1.522755] dwmac-sun8i 5020000.ethernet: COE Type 2
> [ 1.522758] dwmac-sun8i 5020000.ethernet: TX Checksum insertion supported
> [ 1.522761] dwmac-sun8i 5020000.ethernet: Normal descriptors
> [ 1.522763] dwmac-sun8i 5020000.ethernet: Chain mode enabled
> [ 5.352833] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found
> [ 5.352842] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available
> [ 5.352846] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW
> [ 10.463072] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>
> Settings for eth0:
> Supported ports: [ TP MII ]
> Supported link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Half 1000baseT/Full
> Advertised pause frame use: No
> Advertised auto-negotiation: Yes
> Advertised FEC modes: Not reported
> Link partner advertised link modes: 10baseT/Half 10baseT/Full
> 100baseT/Half 100baseT/Full
> 1000baseT/Full
> Link partner advertised pause frame use: Symmetric Receive-only
> Link partner advertised auto-negotiation: Yes
> Link partner advertised FEC modes: Not reported
> Speed: 1000Mb/s
> Duplex: Full
> Port: MII
> PHYAD: 1
> Transceiver: internal
> Auto-negotiation: on
> Supports Wake-on: d
> Wake-on: d
> Current message level: 0x0000003f (63)
> drv probe link timer ifdown ifup
> Link detected: yes
>
>
> > Cc: Joao Pinto <jpinto@synopsys.com>
> > Cc: David S. Miller <davem@davemloft.net>
> > Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
> > Cc: Alexandre Torgue <alexandre.torgue@st.com>
> > Cc: Russell King <linux@armlinux.org.uk>
> > Cc: Andrew Lunn <andrew@lunn.ch>
> > Cc: Florian Fainelli <f.fainelli@gmail.com>
> > Cc: Heiner Kallweit <hkallweit1@gmail.com>
> >
> > Jose Abreu (3):
> > net: stmmac: Prepare to convert to phylink
> > net: stmmac: Start adding phylink support
> > net: stmmac: Convert to phylink and remove phylib logic
> >
> > drivers/net/ethernet/stmicro/stmmac/Kconfig | 3 +-
> > drivers/net/ethernet/stmicro/stmmac/stmmac.h | 7 +-
> > .../ethernet/stmicro/stmmac/stmmac_ethtool.c | 81 +---
> > .../net/ethernet/stmicro/stmmac/stmmac_main.c | 391 ++++++++----------
> > .../ethernet/stmicro/stmmac/stmmac_platform.c | 21 +-
> > 5 files changed, 190 insertions(+), 313 deletions(-)
> >
> > --
> > 2.21.0
> >
---
Thanks,
Jose Miguel Abreu
[-- Attachment #2: 0001-net-stmmac-Do-not-cut-down-1G-modes.patch --]
[-- Type: application/octet-stream, Size: 2316 bytes --]
From 6e94caa3b518735c8c637d58ef76cb1aabac6e09 Mon Sep 17 00:00:00 2001
Message-Id: <6e94caa3b518735c8c637d58ef76cb1aabac6e09.1563802080.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Mon, 22 Jul 2019 15:26:15 +0200
Subject: [PATCH net] net: stmmac: Do not cut down 1G modes
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some glue logic drivers support 1G without having GMAC/GMAC4/XGMAC.
Let's allow this speed by default.
Reported-by: Ondřej Jirman <megi@xff.cz>
Fixes: 5b0d7d7da64b ("net: stmmac: Add the missing speeds that XGMAC supports")
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Jose Abreu <joabreu@synopsys.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: netdev@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 11 +++--------
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 207c3755bcc5..b0d5e5346597 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -814,20 +814,15 @@ static void stmmac_validate(struct phylink_config *config,
phylink_set(mac_supported, 10baseT_Full);
phylink_set(mac_supported, 100baseT_Half);
phylink_set(mac_supported, 100baseT_Full);
+ phylink_set(mac_supported, 1000baseT_Half);
+ phylink_set(mac_supported, 1000baseT_Full);
+ phylink_set(mac_supported, 1000baseKX_Full);
phylink_set(mac_supported, Autoneg);
phylink_set(mac_supported, Pause);
phylink_set(mac_supported, Asym_Pause);
phylink_set_port_modes(mac_supported);
- if (priv->plat->has_gmac ||
- priv->plat->has_gmac4 ||
- priv->plat->has_xgmac) {
- phylink_set(mac_supported, 1000baseT_Half);
- phylink_set(mac_supported, 1000baseT_Full);
- phylink_set(mac_supported, 1000baseKX_Full);
- }
-
/* Cut down 1G if asked to */
if ((max_speed > 0) && (max_speed < 1000)) {
phylink_set(mask, 1000baseT_Full);
--
2.7.4
^ permalink raw reply related
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