[-- Attachment #1: Type: text/plain, Size: 578 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc44x_defconfig) produced these warnings: net/ipv4/tcp_ipv4.c: In function 'tcp_v4_init_sock': net/ipv4/tcp_ipv4.c:1891:19: warning: unused variable 'tp' [-Wunused-variable] net/ipv6/tcp_ipv6.c: In function 'tcp_v6_init_sock': net/ipv6/tcp_ipv6.c:1836:19: warning: unused variable 'tp' [-Wunused-variable] Introduced by commit 900f65d361d3 ("tcp: move duplicate code from tcp_v4_init_sock()/tcp_v6_init_sock()"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 23 Apr 2012 16:54:09 +1000 > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc44x_defconfig) produced these warnings: > > net/ipv4/tcp_ipv4.c: In function 'tcp_v4_init_sock': > net/ipv4/tcp_ipv4.c:1891:19: warning: unused variable 'tp' [-Wunused-variable] > net/ipv6/tcp_ipv6.c: In function 'tcp_v6_init_sock': > net/ipv6/tcp_ipv6.c:1836:19: warning: unused variable 'tp' [-Wunused-variable] > > Introduced by commit 900f65d361d3 ("tcp: move duplicate code from > tcp_v4_init_sock()/tcp_v6_init_sock()"). Thanks, I just pushed the following: -------------------- tcp: Fix build warning after tcp_{v4,v6}_init_sock consolidation. net/ipv4/tcp_ipv4.c: In function 'tcp_v4_init_sock': net/ipv4/tcp_ipv4.c:1891:19: warning: unused variable 'tp' [-Wunused-variable] net/ipv6/tcp_ipv6.c: In function 'tcp_v6_init_sock': net/ipv6/tcp_ipv6.c:1836:19: warning: unused variable 'tp' [-Wunused-variable] Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- net/ipv4/tcp_ipv4.c | 3 +-- net/ipv6/tcp_ipv6.c | 3 +-- 2 files changed, 2 insertions(+), 4 deletions(-) diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index 5b07ea1..0883921 100644 --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -1888,14 +1888,13 @@ static const struct tcp_sock_af_ops tcp_sock_ipv4_specific = { static int tcp_v4_init_sock(struct sock *sk) { struct inet_connection_sock *icsk = inet_csk(sk); - struct tcp_sock *tp = tcp_sk(sk); tcp_init_sock(sk); icsk->icsk_af_ops = &ipv4_specific; #ifdef CONFIG_TCP_MD5SIG - tp->af_specific = &tcp_sock_ipv4_specific; + tcp_sk(sk)->af_specific = &tcp_sock_ipv4_specific; #endif return 0; diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index 24dac6b..8044f6a 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -1829,14 +1829,13 @@ static const struct tcp_sock_af_ops tcp_sock_ipv6_mapped_specific = { static int tcp_v6_init_sock(struct sock *sk) { struct inet_connection_sock *icsk = inet_csk(sk); - struct tcp_sock *tp = tcp_sk(sk); tcp_init_sock(sk); icsk->icsk_af_ops = &ipv6_specific; #ifdef CONFIG_TCP_MD5SIG - tp->af_specific = &tcp_sock_ipv6_specific; + tcp_sk(sk)->af_specific = &tcp_sock_ipv6_specific; #endif return 0; -- 1.7.10
[-- Attachment #1: Type: text/plain, Size: 468 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc44x_defconfig) produced this warning: net/ipv6/xfrm6_mode_tunnel.c: In function 'xfrm6_mode_tunnel_input': net/ipv6/xfrm6_mode_tunnel.c:72:2: warning: suggest parentheses around assignment used as truth value [-Wparentheses] Introduced by commit 14bbd6a565e1 ("net: Add skb_unclone() helper function"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 575 bytes --] Hi all, After merging the net-next tree, today's linux-next build (i386 defconfig and probably others) produced this warning: net/ipv6/addrconf.c: In function 'addrconf_notify': net/ipv6/addrconf.c:2793:22: warning: 'link_dev' may be used uninitialized in this function [-Wuninitialized] net/ipv6/addrconf.c:2802:21: note: 'link_dev' was declared here Introduced by commit df8372ca747f ("ipv6: fix checkpatch errors in net/ipv6/addrconf.c"). It looks like here are some missing braces. -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Wed, 21 Aug 2013 19:10:41 +1000
> Hi all,
>
> After merging the net-next tree, today's linux-next build (i386 defconfig
> and probably others) produced this warning:
>
> net/ipv6/addrconf.c: In function 'addrconf_notify':
> net/ipv6/addrconf.c:2793:22: warning: 'link_dev' may be used uninitialized in this function [-Wuninitialized]
> net/ipv6/addrconf.c:2802:21: note: 'link_dev' was declared here
>
> Introduced by commit df8372ca747f ("ipv6: fix checkpatch errors in
> net/ipv6/addrconf.c"). It looks like here are some missing braces.
Yes, which has since been reverted.
[-- Attachment #1: Type: text/plain, Size: 903 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c: In function 'qlcnic_send_filter': drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:349:3: warning: passing argument 2 of 'ether_addr_equal' from incompatible pointer type [enabled by default] if (ether_addr_equal(tmp_fil->faddr, &src_addr) && ^ In file included from include/linux/if_vlan.h:16:0, from drivers/net/ethernet/qlogic/qlcnic/qlcnic_io.c:9: include/linux/etherdevice.h:244:20: note: expected 'const u8 *' but argument is of type 'u64 *' static inline bool ether_addr_equal(const u8 *addr1, const u8 *addr2) ^ Introduced by commit 6878f79a8b71 ("net: qlcnic: slight optimization of addr compare"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #1: Type: text/plain, Size: 383 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allnoconfig) produced this warning: include/net/ip.h:211:5: warning: "CONFIG_SYSCTL" is not defined [-Wundef] #if CONFIG_SYSCTL ^ Introduced by commit 122ff243f5f1 ("ipv4: make ip_local_reserved_ports per netns"). -- Cheers, Stephen Rothwell sfr@canb.auug.org.au [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 836 bytes --]
On Wed, May 14, 2014 at 11:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> allnoconfig) produced this warning:
>
>
> include/net/ip.h:211:5: warning: "CONFIG_SYSCTL" is not defined [-Wundef]
> #if CONFIG_SYSCTL
> ^
>
> Introduced by commit 122ff243f5f1 ("ipv4: make ip_local_reserved_ports
> per netns").
Oops, blame my fat fingers... Just s/#if/#ifdef/. ;)
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu, 15 May 2014 10:39:20 -0700
> On Wed, May 14, 2014 at 11:47 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (powerpc
>> allnoconfig) produced this warning:
>>
>>
>> include/net/ip.h:211:5: warning: "CONFIG_SYSCTL" is not defined [-Wundef]
>> #if CONFIG_SYSCTL
>> ^
>>
>> Introduced by commit 122ff243f5f1 ("ipv4: make ip_local_reserved_ports
>> per netns").
>
>
> Oops, blame my fat fingers... Just s/#if/#ifdef/. ;)
I've just pushed out a fix for this, thanks everyone.
On Thu, May 15, 2014 at 10:43 AM, David Miller <davem@davemloft.net> wrote:
>
> I've just pushed out a fix for this, thanks everyone.
Thanks, David!
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: net/ipv4/igmp.c: In function 'igmp_group_added': net/ipv4/igmp.c:1227:14: warning: unused variable 'net' [-Wunused-variable] struct net *net = dev_net(in_dev->dev); ^ net/ipv4/igmp.c: In function 'ip_mc_inc_group': net/ipv4/igmp.c:1319:14: warning: unused variable 'net' [-Wunused-variable] struct net *net = dev_net(in_dev->dev); ^ net/ipv4/igmp.c: In function 'ip_mc_init_dev': net/ipv4/igmp.c:1646:14: warning: unused variable 'net' [-Wunused-variable] struct net *net = dev_net(in_dev->dev); ^ net/ipv4/igmp.c: In function 'ip_mc_up': net/ipv4/igmp.c:1665:14: warning: unused variable 'net' [-Wunused-variable] struct net *net = dev_net(in_dev->dev); ^ Introduced by commits 87a8a2ae65b7 ("igmp: Namespaceify igmp_llm_reports sysctl knob") 165094afcee7 ("igmp: Namespacify igmp_qrv sysctl knob") CONFIG_IP_MULTICAST is not set for this build. -- Cheers, Stephen Rothwell
On 02/15/2016 04:09 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> net/ipv4/igmp.c: In function 'igmp_group_added':
> net/ipv4/igmp.c:1227:14: warning: unused variable 'net' [-Wunused-variable]
> struct net *net = dev_net(in_dev->dev);
> ^
> net/ipv4/igmp.c: In function 'ip_mc_inc_group':
> net/ipv4/igmp.c:1319:14: warning: unused variable 'net' [-Wunused-variable]
> struct net *net = dev_net(in_dev->dev);
> ^
> net/ipv4/igmp.c: In function 'ip_mc_init_dev':
> net/ipv4/igmp.c:1646:14: warning: unused variable 'net' [-Wunused-variable]
> struct net *net = dev_net(in_dev->dev);
> ^
> net/ipv4/igmp.c: In function 'ip_mc_up':
> net/ipv4/igmp.c:1665:14: warning: unused variable 'net' [-Wunused-variable]
> struct net *net = dev_net(in_dev->dev);
> ^
>
> Introduced by commits
>
> 87a8a2ae65b7 ("igmp: Namespaceify igmp_llm_reports sysctl knob")
> 165094afcee7 ("igmp: Namespacify igmp_qrv sysctl knob")
>
> CONFIG_IP_MULTICAST is not set for this build.
Right, I have forgotten to add the ifdef guards for the respective
variables, will squeeze a patch in the next series on namespaceifying
various sysctls.
Thanks for testing!
Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/net/tun.c: In function 'tun_do_read.part.5': /home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] int err; ^ Introduced by commit 1576d9860599 ("tun: switch to use skb array for tx") I can't easily see if this is a false positive. -- Cheers, Stephen Rothwell
On 2016年07月04日 11:15, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> drivers/net/tun.c: In function 'tun_do_read.part.5':
> /home/sfr/next/next/drivers/net/tun.c:1491:6: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized]
> int err;
> ^
>
> Introduced by commit
>
> 1576d9860599 ("tun: switch to use skb array for tx")
>
> I can't easily see if this is a false positive.
>
Thanks for the reporting, will post a fix.
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) produced this warning (CONFIG_MPLS is disabled): net/ipv4/tunnel4.c: In function 'tunnel4_init': net/ipv4/tunnel4.c:223:1: warning: label 'err_mpls' defined but not used [-Wunused-label] err_mpls: ^ and the powerpc ppc64_defconfig build produced this (CONFIG_IPV6 is disabled): net/ipv4/tunnel4.c: In function 'tunnel4_init': net/ipv4/tunnel4.c:226:1: warning: label 'err_ipv6' defined but not used [-Wunused-label] err_ipv6: ^ Introduced by commit 8afe97e5d416 ("tunnels: support MPLS over IPv4 tunnels") -- Cheers, Stephen Rothwell
On Mon, Jul 11, 2016 at 04:13:11PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning (CONFIG_MPLS is disabled):
>
> net/ipv4/tunnel4.c: In function 'tunnel4_init':
> net/ipv4/tunnel4.c:223:1: warning: label 'err_mpls' defined but not used [-Wunused-label]
> err_mpls:
> ^
>
> and the powerpc ppc64_defconfig build produced this (CONFIG_IPV6 is disabled):
>
> net/ipv4/tunnel4.c: In function 'tunnel4_init':
> net/ipv4/tunnel4.c:226:1: warning: label 'err_ipv6' defined but not used [-Wunused-label]
> err_ipv6:
> ^
>
> Introduced by commit
>
> 8afe97e5d416 ("tunnels: support MPLS over IPv4 tunnels")
Thanks Stephen,
I have posted a fix for this.
"[PATCH net-next v2] tunnels: correct conditional build of MPLS and IPv6"
Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) produced this warning: drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 'xgene_enet_phy_connect': drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused variable 'adev' [-Wunused-variable] struct acpi_device *adev; ^ Introduced by commit 8089a96f601b ("drivers: net: xgene: Add backward compatibility") (CONFIG_ACPI si not set for tis build) -- Cheers, Stephen Rothwell
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 27 Jul 2016 16:15:33 +1000 > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > allyesconfig) produced this warning: > > drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 'xgene_enet_phy_connect': > drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused variable 'adev' [-Wunused-variable] > struct acpi_device *adev; > ^ > > Introduced by commit > > 8089a96f601b ("drivers: net: xgene: Add backward compatibility") > (CONFIG_ACPI si not set for tis build) Fixed thusly: ==================== >From 36232012344b8db67052432742deaf17f82e70e6 Mon Sep 17 00:00:00 2001 From: "David S. Miller" <davem@davemloft.net> Date: Tue, 26 Jul 2016 23:19:29 -0700 Subject: [PATCH] xgene: Fix build warning with ACPI disabled. drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 'xgene_enet_phy_connect': drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused variable 'adev' [-Wunused-variable] Fixes: 8089a96f601b ("drivers: net: xgene: Add backward compatibility") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c index 8a2a221..7714b7d 100644 --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c @@ -756,7 +756,6 @@ int xgene_enet_phy_connect(struct net_device *ndev) struct device_node *np; struct phy_device *phy_dev; struct device *dev = &pdata->pdev->dev; - struct acpi_device *adev; int i; if (dev->of_node) { @@ -781,7 +780,7 @@ int xgene_enet_phy_connect(struct net_device *ndev) pdata->phy_dev = phy_dev; } else { #ifdef CONFIG_ACPI - adev = acpi_phy_find_device(dev); + struct acpi_device *adev = acpi_phy_find_device(dev); if (adev) pdata->phy_dev = adev->driver_data; -- 2.1.0
Hi David,
On Tue, 26 Jul 2016 23:19:59 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
>
> Fixed thusly:
>
> ====================
> From 36232012344b8db67052432742deaf17f82e70e6 Mon Sep 17 00:00:00 2001
> From: "David S. Miller" <davem@davemloft.net>
> Date: Tue, 26 Jul 2016 23:19:29 -0700
> Subject: [PATCH] xgene: Fix build warning with ACPI disabled.
>
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 'xgene_enet_phy_connect':
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused variable 'adev' [-Wunused-variable]
>
> Fixes: 8089a96f601b ("drivers: net: xgene: Add backward compatibility")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> index 8a2a221..7714b7d 100644
> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
> @@ -756,7 +756,6 @@ int xgene_enet_phy_connect(struct net_device *ndev)
> struct device_node *np;
> struct phy_device *phy_dev;
> struct device *dev = &pdata->pdev->dev;
> - struct acpi_device *adev;
> int i;
>
> if (dev->of_node) {
> @@ -781,7 +780,7 @@ int xgene_enet_phy_connect(struct net_device *ndev)
> pdata->phy_dev = phy_dev;
> } else {
> #ifdef CONFIG_ACPI
> - adev = acpi_phy_find_device(dev);
> + struct acpi_device *adev = acpi_phy_find_device(dev);
> if (adev)
> pdata->phy_dev = adev->driver_data;
Looks good to me, thanks.
--
Cheers,
Stephen Rothwell
On Tue, Jul 26, 2016 at 11:35 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > Hi David, > > On Tue, 26 Jul 2016 23:19:59 -0700 (PDT) David Miller <davem@davemloft.net> wrote: >> >> Fixed thusly: >> >> ==================== >> From 36232012344b8db67052432742deaf17f82e70e6 Mon Sep 17 00:00:00 2001 >> From: "David S. Miller" <davem@davemloft.net> >> Date: Tue, 26 Jul 2016 23:19:29 -0700 >> Subject: [PATCH] xgene: Fix build warning with ACPI disabled. >> >> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c: In function 'xgene_enet_phy_connect': >> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c:759:22: warning: unused variable 'adev' [-Wunused-variable] >> >> Fixes: 8089a96f601b ("drivers: net: xgene: Add backward compatibility") >> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> >> Signed-off-by: David S. Miller <davem@davemloft.net> >> --- >> drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c >> index 8a2a221..7714b7d 100644 >> --- a/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c >> +++ b/drivers/net/ethernet/apm/xgene/xgene_enet_hw.c >> @@ -756,7 +756,6 @@ int xgene_enet_phy_connect(struct net_device *ndev) >> struct device_node *np; >> struct phy_device *phy_dev; >> struct device *dev = &pdata->pdev->dev; >> - struct acpi_device *adev; >> int i; >> >> if (dev->of_node) { >> @@ -781,7 +780,7 @@ int xgene_enet_phy_connect(struct net_device *ndev) >> pdata->phy_dev = phy_dev; >> } else { >> #ifdef CONFIG_ACPI >> - adev = acpi_phy_find_device(dev); >> + struct acpi_device *adev = acpi_phy_find_device(dev); >> if (adev) >> pdata->phy_dev = adev->driver_data; > > Looks good to me, thanks. Thanks David, for the quick fix. > > -- > Cheers, > Stephen Rothwell
Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: kernel/bpf/bpf_lru_list.c: In function '__bpf_lru_list_rotate_inactive.isra.3': kernel/bpf/bpf_lru_list.c:201:28: warning: 'next' may be used uninitialized in this function [-Wmaybe-uninitialized] l->next_inactive_rotation = next; ^ Introduced by commit 3a08c2fd7634 ("bpf: LRU List") I can't tell if this is a false positive or not. -- Cheers, Stephen Rothwell
On Wed, Nov 16, 2016 at 11:36:47AM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > kernel/bpf/bpf_lru_list.c: In function '__bpf_lru_list_rotate_inactive.isra.3': > kernel/bpf/bpf_lru_list.c:201:28: warning: 'next' may be used uninitialized in this function [-Wmaybe-uninitialized] > l->next_inactive_rotation = next; > ^ > > Introduced by commit > > 3a08c2fd7634 ("bpf: LRU List") > > I can't tell if this is a false positive or not. A false positive. A patch has been posted: https://patchwork.ozlabs.org/patch/695202/ Thanks for the report. --Martin
Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: In file included from include/linux/byteorder/big_endian.h:4:0, from arch/powerpc/include/uapi/asm/byteorder.h:13, from include/asm-generic/bitops/le.h:5, from arch/powerpc/include/asm/bitops.h:279, from include/linux/bitops.h:36, from include/linux/kernel.h:10, from include/linux/skbuff.h:17, from include/linux/if_ether.h:23, from include/linux/etherdevice.h:25, from drivers/net/ethernet/intel/i40e/i40e_main.c:27: drivers/net/ethernet/intel/i40e/i40e_main.c: In function 'i40e_sync_vsi_filters': include/uapi/linux/byteorder/big_endian.h:34:26: warning: large integer implicitly truncated to unsigned type [-Woverflow] #define __cpu_to_le16(x) ((__force __le16)__swab16((x))) ^ include/linux/byteorder/generic.h:89:21: note: in expansion of macro '__cpu_to_le16' #define cpu_to_le16 __cpu_to_le16 ^ drivers/net/ethernet/intel/i40e/i40e_main.c:2200:5: note: in expansion of macro 'cpu_to_le16' cpu_to_le16((u16)I40E_AQC_MM_ERR_NO_RES); ^ Introduced by commit ac9e23901441 ("i40e: refactor i40e_update_filter_state to avoid passing aq_err") -- Cheers, Stephen Rothwell
Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) produced this warning: In file included from drivers/net/ethernet/ibm/ibmvnic.c:52:0: drivers/net/ethernet/ibm/ibmvnic.c: In function 'ibmvnic_open': include/linux/dma-mapping.h:571:2: warning: 'dma_addr' may be used uninitialized in this function [-Wmaybe-uninitialized] debug_dma_mapping_error(dev, dma_addr); ^ drivers/net/ethernet/ibm/ibmvnic.c:852:13: note: 'dma_addr' was declared here dma_addr_t dma_addr; ^ Introduced by commit 4e6759be28e4 ("ibmvnic: Feature implementation of Vital Product Data (VPD) for the ibmvnic driver") -- Cheers, Stephen Rothwell
Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: drivers/net/phy/broadcom.c:391:12: warning: 'bcm5482_read_status' defined but not used [-Wunused-function] static int bcm5482_read_status(struct phy_device *phydev) ^ drivers/net/phy/broadcom.c:411:12: warning: 'bcm5481_config_aneg' defined but not used [-Wunused-function] static int bcm5481_config_aneg(struct phy_device *phydev) ^ Introduced by commit 80274abafc60 ("net: phy: remove generic settings for callbacks config_aneg and read_status from drivers") -- Cheers, Stephen Rothwell
Am 04.12.2017 um 01:02 schrieb Stephen Rothwell: > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > drivers/net/phy/broadcom.c:391:12: warning: 'bcm5482_read_status' defined but not used [-Wunused-function] > static int bcm5482_read_status(struct phy_device *phydev) > ^ > drivers/net/phy/broadcom.c:411:12: warning: 'bcm5481_config_aneg' defined but not used [-Wunused-function] > static int bcm5481_config_aneg(struct phy_device *phydev) > ^ > > Introduced by commit > > 80274abafc60 ("net: phy: remove generic settings for callbacks config_aneg and read_status from drivers") > This issue has been addressed addressed already, see this patch: https://marc.info/?l=linux-netdev&m=151220825402398&w=2 Rgds, Heiner
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 4 Dec 2017 11:02:49 +1100
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/net/phy/broadcom.c:391:12: warning: 'bcm5482_read_status' defined but not used [-Wunused-function]
> static int bcm5482_read_status(struct phy_device *phydev)
> ^
> drivers/net/phy/broadcom.c:411:12: warning: 'bcm5481_config_aneg' defined but not used [-Wunused-function]
> static int bcm5481_config_aneg(struct phy_device *phydev)
> ^
>
> Introduced by commit
>
> 80274abafc60 ("net: phy: remove generic settings for callbacks config_aneg and read_status from drivers")
This shoudl be resolved now, thanks for the report.
Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: net/sched/cls_api.c: In function 'tc_dump_tfilter': net/sched/cls_api.c:1362:8: warning: 'parent' may be used uninitialized in this function [-Wmaybe-uninitialized] if (!tcf_chain_dump(chain, q, parent, skb, cb, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ index_start, &index)) ~~~~~~~~~~~~~~~~~~~~ Probably introduced by commit 7960d1daf278 ("net: sched: use block index as a handle instead of qdisc when block is shared") -- Cheers, Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 392 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc defconfig) produced this warning: net/core/pktgen.c: In function 'pktgen_if_write': net/core/pktgen.c:1710:1: warning: the frame size of 1048 bytes is larger than 1024 bytes [-Wframe-larger-than=] } ^ Introduced by commit 35951393bbff ("pktgen: Remove VLA usage") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, On 03/13/2018 01:11 AM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (sparc > defconfig) produced this warning: > > net/core/pktgen.c: In function 'pktgen_if_write': > net/core/pktgen.c:1710:1: warning: the frame size of 1048 bytes is larger than 1024 bytes [-Wframe-larger-than=] > } > ^ > > Introduced by commit > > 35951393bbff ("pktgen: Remove VLA usage") > Thanks for the report. David: If this code is not going to be executed very often [1], then I think it is safe to use dynamic memory allocation instead, as this is not going to impact the performance. What do you think? [1] https://lkml.org/lkml/2018/3/9/630 Thanks -- Gustavo
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Tue, 13 Mar 2018 06:46:24 -0500
> Hi Stephen,
>
> On 03/13/2018 01:11 AM, Stephen Rothwell wrote:
>> Hi all,
>> After merging the net-next tree, today's linux-next build (sparc
>> defconfig) produced this warning:
>> net/core/pktgen.c: In function 'pktgen_if_write':
>> net/core/pktgen.c:1710:1: warning: the frame size of 1048 bytes is
>> larger than 1024 bytes [-Wframe-larger-than=]
>> }
>> ^
>> Introduced by commit
>> 35951393bbff ("pktgen: Remove VLA usage")
>>
>
> Thanks for the report.
>
> David:
>
> If this code is not going to be executed very often [1], then I think
> it is safe to use dynamic memory allocation instead, as this is not
> going to impact the performance.
>
> What do you think?
>
> [1] https://lkml.org/lkml/2018/3/9/630
Sure, that works.
It is only invoked when pktgen configuration changes are made.
On 03/13/2018 10:33 AM, David Miller wrote:
> From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
> Date: Tue, 13 Mar 2018 06:46:24 -0500
>
>> Hi Stephen,
>>
>> On 03/13/2018 01:11 AM, Stephen Rothwell wrote:
>>> Hi all,
>>> After merging the net-next tree, today's linux-next build (sparc
>>> defconfig) produced this warning:
>>> net/core/pktgen.c: In function 'pktgen_if_write':
>>> net/core/pktgen.c:1710:1: warning: the frame size of 1048 bytes is
>>> larger than 1024 bytes [-Wframe-larger-than=]
>>> }
>>> ^
>>> Introduced by commit
>>> 35951393bbff ("pktgen: Remove VLA usage")
>>>
>>
>> Thanks for the report.
>>
>> David:
>>
>> If this code is not going to be executed very often [1], then I think
>> it is safe to use dynamic memory allocation instead, as this is not
>> going to impact the performance.
>>
>> What do you think?
>>
>> [1] https://lkml.org/lkml/2018/3/9/630
>
> Sure, that works.
>
> It is only invoked when pktgen configuration changes are made.
>
OK. I'll send a new patch for this.
Thanks
--
Gustavo
[-- Attachment #1: Type: text/plain, Size: 411 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: net/core/filter.c: In function 'sk_msg_convert_ctx_access': net/core/filter.c:6450:6: warning: unused variable 'off' [-Wunused-variable] int off; ^~~ Introduced by commit 303def35f64e ("bpf: allow sk_msg programs to read sock fields") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 781 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: In file included from include/net/dsa.h:24:0, from include/linux/platform_data/b53.h:23, from drivers/net/dsa/b53/b53_spi.c:25: include/net/devlink.h: In function 'devlink_param_value_changed': include/net/devlink.h:771:9: warning: 'return' with a value, in function returning void return -EOPNOTSUPP; ^ include/net/devlink.h:769:1: note: declared here devlink_param_value_changed(struct devlink *devlink, u32 param_id) ^~~~~~~~~~~~~~~~~~~~~~~~~~~ Lots of these ... Introduced by commit ea601e170988 ("devlink: Add devlink notifications support for params") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Fri, 6 Jul 2018 09:56:33 +1000 > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > In file included from include/net/dsa.h:24:0, > from include/linux/platform_data/b53.h:23, > from drivers/net/dsa/b53/b53_spi.c:25: > include/net/devlink.h: In function 'devlink_param_value_changed': > include/net/devlink.h:771:9: warning: 'return' with a value, in function returning void > return -EOPNOTSUPP; > ^ > include/net/devlink.h:769:1: note: declared here > devlink_param_value_changed(struct devlink *devlink, u32 param_id) ... > Introduced by commit > > ea601e170988 ("devlink: Add devlink notifications support for params") Thanks Stephen, this should be fixes now.
[-- Attachment #1: Type: text/plain, Size: 1048 bytes --] Hi Dave, On Sat, 07 Jul 2018 20:30:16 +0900 (KST) David Miller <davem@davemloft.net> wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Fri, 6 Jul 2018 09:56:33 +1000 > > > After merging the net-next tree, today's linux-next build (arm > > multi_v7_defconfig) produced this warning: > > > > In file included from include/net/dsa.h:24:0, > > from include/linux/platform_data/b53.h:23, > > from drivers/net/dsa/b53/b53_spi.c:25: > > include/net/devlink.h: In function 'devlink_param_value_changed': > > include/net/devlink.h:771:9: warning: 'return' with a value, in function returning void > > return -EOPNOTSUPP; > > ^ > > include/net/devlink.h:769:1: note: declared here > > devlink_param_value_changed(struct devlink *devlink, u32 param_id) > ... > > Introduced by commit > > > > ea601e170988 ("devlink: Add devlink notifications support for params") > > Thanks Stephen, this should be fixes now. Great, thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 366 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: WARNING: modpost: missing MODULE_LICENSE() in drivers/net/dsa/realtek.o see include/linux/module.h for more information Introduced by commit d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 459 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: * * Restart config... * .... This is output by my "make allmodconfig" and only started after merging the net-next tree today. It has continued for further merges/builds. I suspect commit 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") which added an "imply" clause. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> *
> * Restart config...
> *
> ....
>
> This is output by my "make allmodconfig" and only started after merging
> the net-next tree today. It has continued for further merges/builds.
>
> I suspect commit
>
> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>
> which added an "imply" clause.
>
I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
not. Is that a caveat when using "imply", and does it mean that "imply"
should better not be used ?
Guenter
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --] Hi Guenter, On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > > On 07/18/2018 07:04 PM, Stephen Rothwell wrote: > > > > After merging the net-next tree, today's linux-next build (x86_64 > > allmodconfig) produced this warning: > > > > * > > * Restart config... > > * > > .... > > > > This is output by my "make allmodconfig" and only started after merging > > the net-next tree today. It has continued for further merges/builds. > > > > I suspect commit > > > > 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") > > > > which added an "imply" clause. > > > I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe > not. Is that a caveat when using "imply", and does it mean that "imply" > should better not be used ? I don't know, sorry. It was just my best guess from what I could see had changed. I wonder if it makes a difference that I am doing my "make allmodconfig" on top of a previous "make allmodconfig" and some symbols are marked as "NEW" (though they are not symbols related to the changes that happened during the net-next tree merge)? -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
> Hi Guenter,
>
> On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>
>> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
>>>
>>> After merging the net-next tree, today's linux-next build (x86_64
>>> allmodconfig) produced this warning:
>>>
>>> *
>>> * Restart config...
>>> *
>>> ....
>>>
>>> This is output by my "make allmodconfig" and only started after merging
>>> the net-next tree today. It has continued for further merges/builds.
>>>
>>> I suspect commit
>>>
>>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>>>
>>> which added an "imply" clause.
>>>
>> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
>> not. Is that a caveat when using "imply", and does it mean that "imply"
>> should better not be used ?
>
> I don't know, sorry. It was just my best guess from what I could see
> had changed.
>
> I wonder if it makes a difference that I am doing my "make
> allmodconfig" on top of a previous "make allmodconfig" and some symbols
> are marked as "NEW" (though they are not symbols related to the changes
> that happened during the net-next tree merge)?
>
I tried to reproduce the problem, but I don't see the message.
What I do see, though, is that "make allmodconfig" on a clean tree,
followed by "make menuconfig", results in configuration changes.
Specifically,
> CONFIG_ARC_EMAC_CORE=m
> CONFIG_ARC_EMAC=m
> CONFIG_EMAC_ROCKCHIP=m
is removed by menuconfig, and a large number of "# ... is not set"
configuration lines are added. Weird and bad, since several of the
disabled configurations _should_ be enabled by "make allmodconfig",
and a large number of hwmon drivers are affected. Bisect does point
to "net: phy: sfp: Add HWMON support for module sensors", meaning
"imply hwmon" does have severe side effects and can not be used.
I'll try to find a fix.
Guenter
[-- Attachment #1: Type: text/plain, Size: 2571 bytes --] Hi Guenter, On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > > On 07/18/2018 10:29 PM, Stephen Rothwell wrote: > > > > On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > >> > >> On 07/18/2018 07:04 PM, Stephen Rothwell wrote: > >>> > >>> After merging the net-next tree, today's linux-next build (x86_64 > >>> allmodconfig) produced this warning: > >>> > >>> * > >>> * Restart config... > >>> * > >>> .... > >>> > >>> This is output by my "make allmodconfig" and only started after merging > >>> the net-next tree today. It has continued for further merges/builds. > >>> > >>> I suspect commit > >>> > >>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") > >>> > >>> which added an "imply" clause. > >>> > >> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe > >> not. Is that a caveat when using "imply", and does it mean that "imply" > >> should better not be used ? > > > > I don't know, sorry. It was just my best guess from what I could see > > had changed. > > > > I wonder if it makes a difference that I am doing my "make > > allmodconfig" on top of a previous "make allmodconfig" and some symbols > > are marked as "NEW" (though they are not symbols related to the changes > > that happened during the net-next tree merge)? > > > > I tried to reproduce the problem, but I don't see the message. > > What I do see, though, is that "make allmodconfig" on a clean tree, > followed by "make menuconfig", results in configuration changes. > Specifically, > > > CONFIG_ARC_EMAC_CORE=m > > CONFIG_ARC_EMAC=m > > CONFIG_EMAC_ROCKCHIP=m > > is removed by menuconfig, and a large number of "# ... is not set" > configuration lines are added. Weird and bad, since several of the > disabled configurations _should_ be enabled by "make allmodconfig", > and a large number of hwmon drivers are affected. Bisect does point > to "net: phy: sfp: Add HWMON support for module sensors", meaning > "imply hwmon" does have severe side effects and can not be used. > > I'll try to find a fix. OK, my mistake, the "make allmodconfig" works, the following "make" causes the config restart. (I am actually doing cross builds and using an external object directory, in case that matters.) I removed the "imply HWMON" line added by the above commit and the problem went away. Also, using "depends on HWMON || HWMON=n" instead of the imply fixes it. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote: > Hi Guenter, > > On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > > > > On 07/18/2018 10:29 PM, Stephen Rothwell wrote: > > > > > > On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > > >> > > >> On 07/18/2018 07:04 PM, Stephen Rothwell wrote: > > >>> > > >>> After merging the net-next tree, today's linux-next build (x86_64 > > >>> allmodconfig) produced this warning: > > >>> > > >>> * > > >>> * Restart config... > > >>> * > > >>> .... > > >>> > > >>> This is output by my "make allmodconfig" and only started after merging > > >>> the net-next tree today. It has continued for further merges/builds. > > >>> > > >>> I suspect commit > > >>> > > >>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") > > >>> > > >>> which added an "imply" clause. > > >>> > > >> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe > > >> not. Is that a caveat when using "imply", and does it mean that "imply" > > >> should better not be used ? > > > > > > I don't know, sorry. It was just my best guess from what I could see > > > had changed. > > > > > > I wonder if it makes a difference that I am doing my "make > > > allmodconfig" on top of a previous "make allmodconfig" and some symbols > > > are marked as "NEW" (though they are not symbols related to the changes > > > that happened during the net-next tree merge)? > > > > > > > I tried to reproduce the problem, but I don't see the message. > > > > What I do see, though, is that "make allmodconfig" on a clean tree, > > followed by "make menuconfig", results in configuration changes. > > Specifically, > > > > > CONFIG_ARC_EMAC_CORE=m > > > CONFIG_ARC_EMAC=m > > > CONFIG_EMAC_ROCKCHIP=m > > > > is removed by menuconfig, and a large number of "# ... is not set" > > configuration lines are added. Weird and bad, since several of the > > disabled configurations _should_ be enabled by "make allmodconfig", > > and a large number of hwmon drivers are affected. Bisect does point > > to "net: phy: sfp: Add HWMON support for module sensors", meaning > > "imply hwmon" does have severe side effects and can not be used. > > > > I'll try to find a fix. > > OK, my mistake, the "make allmodconfig" works, the following "make" > causes the config restart. (I am actually doing cross builds and using > an external object directory, in case that matters.) > > I removed the "imply HWMON" line added by the above commit and the > problem went away. Also, using "depends on HWMON || HWMON=n" instead > of the imply fixes it. Yes, replacing imply with the dependency is what I did in the fixup patch. Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/ It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y, and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why imply doesn't work, but I think I'll stay away from it in the future. Guenter
2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>:
> On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote:
>> Hi Guenter,
>>
>> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>> >
>> > On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
>> > >
>> > > On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>> > >>
>> > >> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
>> > >>>
>> > >>> After merging the net-next tree, today's linux-next build (x86_64
>> > >>> allmodconfig) produced this warning:
>> > >>>
>> > >>> *
>> > >>> * Restart config...
>> > >>> *
>> > >>> ....
>> > >>>
>> > >>> This is output by my "make allmodconfig" and only started after merging
>> > >>> the net-next tree today. It has continued for further merges/builds.
>> > >>>
>> > >>> I suspect commit
>> > >>>
>> > >>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>> > >>>
>> > >>> which added an "imply" clause.
>> > >>>
>> > >> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
>> > >> not. Is that a caveat when using "imply", and does it mean that "imply"
>> > >> should better not be used ?
>> > >
>> > > I don't know, sorry. It was just my best guess from what I could see
>> > > had changed.
>> > >
>> > > I wonder if it makes a difference that I am doing my "make
>> > > allmodconfig" on top of a previous "make allmodconfig" and some symbols
>> > > are marked as "NEW" (though they are not symbols related to the changes
>> > > that happened during the net-next tree merge)?
>> > >
>> >
>> > I tried to reproduce the problem, but I don't see the message.
>> >
>> > What I do see, though, is that "make allmodconfig" on a clean tree,
>> > followed by "make menuconfig", results in configuration changes.
>> > Specifically,
>> >
>> > > CONFIG_ARC_EMAC_CORE=m
>> > > CONFIG_ARC_EMAC=m
>> > > CONFIG_EMAC_ROCKCHIP=m
>> >
>> > is removed by menuconfig, and a large number of "# ... is not set"
>> > configuration lines are added. Weird and bad, since several of the
>> > disabled configurations _should_ be enabled by "make allmodconfig",
>> > and a large number of hwmon drivers are affected. Bisect does point
>> > to "net: phy: sfp: Add HWMON support for module sensors", meaning
>> > "imply hwmon" does have severe side effects and can not be used.
>> >
>> > I'll try to find a fix.
>>
>> OK, my mistake, the "make allmodconfig" works, the following "make"
>> causes the config restart. (I am actually doing cross builds and using
>> an external object directory, in case that matters.)
>>
>> I removed the "imply HWMON" line added by the above commit and the
>> problem went away. Also, using "depends on HWMON || HWMON=n" instead
>> of the imply fixes it.
>
> Yes, replacing imply with the dependency is what I did in the fixup patch.
> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
>
> It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y,
> and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why
> imply doesn't work, but I think I'll stay away from it in the future.
>
> Guenter
Hmm, this could be a Kconfig bug.
I will take a look.
BTW,
'depends on HWMON || HWMON=n' is pointless
because it is always true.
--
Best Regards
Masahiro Yamada
On Fri, Jul 20, 2018 at 08:19:34AM +0900, Masahiro Yamada wrote:
> 2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>:
> > On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote:
> >> Hi Guenter,
> >>
> >> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> >> >
> >> > On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
> >> > >
> >> > > On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
> >> > >>
> >> > >> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
> >> > >>>
> >> > >>> After merging the net-next tree, today's linux-next build (x86_64
> >> > >>> allmodconfig) produced this warning:
> >> > >>>
> >> > >>> *
> >> > >>> * Restart config...
> >> > >>> *
> >> > >>> ....
> >> > >>>
> >> > >>> This is output by my "make allmodconfig" and only started after merging
> >> > >>> the net-next tree today. It has continued for further merges/builds.
> >> > >>>
> >> > >>> I suspect commit
> >> > >>>
> >> > >>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
> >> > >>>
> >> > >>> which added an "imply" clause.
> >> > >>>
> >> > >> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
> >> > >> not. Is that a caveat when using "imply", and does it mean that "imply"
> >> > >> should better not be used ?
> >> > >
> >> > > I don't know, sorry. It was just my best guess from what I could see
> >> > > had changed.
> >> > >
> >> > > I wonder if it makes a difference that I am doing my "make
> >> > > allmodconfig" on top of a previous "make allmodconfig" and some symbols
> >> > > are marked as "NEW" (though they are not symbols related to the changes
> >> > > that happened during the net-next tree merge)?
> >> > >
> >> >
> >> > I tried to reproduce the problem, but I don't see the message.
> >> >
> >> > What I do see, though, is that "make allmodconfig" on a clean tree,
> >> > followed by "make menuconfig", results in configuration changes.
> >> > Specifically,
> >> >
> >> > > CONFIG_ARC_EMAC_CORE=m
> >> > > CONFIG_ARC_EMAC=m
> >> > > CONFIG_EMAC_ROCKCHIP=m
> >> >
> >> > is removed by menuconfig, and a large number of "# ... is not set"
> >> > configuration lines are added. Weird and bad, since several of the
> >> > disabled configurations _should_ be enabled by "make allmodconfig",
> >> > and a large number of hwmon drivers are affected. Bisect does point
> >> > to "net: phy: sfp: Add HWMON support for module sensors", meaning
> >> > "imply hwmon" does have severe side effects and can not be used.
> >> >
> >> > I'll try to find a fix.
> >>
> >> OK, my mistake, the "make allmodconfig" works, the following "make"
> >> causes the config restart. (I am actually doing cross builds and using
> >> an external object directory, in case that matters.)
> >>
> >> I removed the "imply HWMON" line added by the above commit and the
> >> problem went away. Also, using "depends on HWMON || HWMON=n" instead
> >> of the imply fixes it.
> >
> > Yes, replacing imply with the dependency is what I did in the fixup patch.
> > Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
> >
> > It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y,
> > and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why
> > imply doesn't work, but I think I'll stay away from it in the future.
> >
> > Guenter
>
>
> Hmm, this could be a Kconfig bug.
>
> I will take a look.
>
>
> BTW,
> 'depends on HWMON || HWMON=n' is pointless
> because it is always true.
>
I disagree. Its purpose is to enforce SFP=m if HWMON=m while still
permitting HWMON=n.
Guenter
[-- Attachment #1: Type: text/plain, Size: 408 bytes --] Hi Guenter, On Thu, 19 Jul 2018 15:35:21 -0700 Guenter Roeck <linux@roeck-us.net> wrote: > > Yes, replacing imply with the dependency is what I did in the fixup patch. > Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/ I will use that as a merge fix patch when I merge the net-next tree today (unless Dave adds it to his tree first). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Jul 19, 2018 at 3:40 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> WARNING: modpost: missing MODULE_LICENSE() in drivers/net/dsa/realtek.o
> see include/linux/module.h for more information
>
> Introduced by commit
>
> d8652956cf37 ("net: dsa: realtek-smi: Add Realtek SMI driver")
Thanks, there is already a patch for it.
I'm pretty grateful that this was the worst the integration testing
could find :) new drivers always make me nervous.
Yours,
Linus Walleij
2018-07-20 8:19 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>: > 2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>: >> On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote: >>> Hi Guenter, >>> >>> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote: >>> > >>> > On 07/18/2018 10:29 PM, Stephen Rothwell wrote: >>> > > >>> > > On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote: >>> > >> >>> > >> On 07/18/2018 07:04 PM, Stephen Rothwell wrote: >>> > >>> >>> > >>> After merging the net-next tree, today's linux-next build (x86_64 >>> > >>> allmodconfig) produced this warning: >>> > >>> >>> > >>> * >>> > >>> * Restart config... >>> > >>> * >>> > >>> .... >>> > >>> >>> > >>> This is output by my "make allmodconfig" and only started after merging >>> > >>> the net-next tree today. It has continued for further merges/builds. >>> > >>> >>> > >>> I suspect commit >>> > >>> >>> > >>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") >>> > >>> >>> > >>> which added an "imply" clause. >>> > >>> >>> > >> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe >>> > >> not. Is that a caveat when using "imply", and does it mean that "imply" >>> > >> should better not be used ? >>> > > >>> > > I don't know, sorry. It was just my best guess from what I could see >>> > > had changed. >>> > > >>> > > I wonder if it makes a difference that I am doing my "make >>> > > allmodconfig" on top of a previous "make allmodconfig" and some symbols >>> > > are marked as "NEW" (though they are not symbols related to the changes >>> > > that happened during the net-next tree merge)? >>> > > >>> > >>> > I tried to reproduce the problem, but I don't see the message. >>> > >>> > What I do see, though, is that "make allmodconfig" on a clean tree, >>> > followed by "make menuconfig", results in configuration changes. >>> > Specifically, >>> > >>> > > CONFIG_ARC_EMAC_CORE=m >>> > > CONFIG_ARC_EMAC=m >>> > > CONFIG_EMAC_ROCKCHIP=m >>> > >>> > is removed by menuconfig, and a large number of "# ... is not set" >>> > configuration lines are added. Weird and bad, since several of the >>> > disabled configurations _should_ be enabled by "make allmodconfig", >>> > and a large number of hwmon drivers are affected. Bisect does point >>> > to "net: phy: sfp: Add HWMON support for module sensors", meaning >>> > "imply hwmon" does have severe side effects and can not be used. >>> > >>> > I'll try to find a fix. >>> >>> OK, my mistake, the "make allmodconfig" works, the following "make" >>> causes the config restart. (I am actually doing cross builds and using >>> an external object directory, in case that matters.) >>> >>> I removed the "imply HWMON" line added by the above commit and the >>> problem went away. Also, using "depends on HWMON || HWMON=n" instead >>> of the imply fixes it. >> >> Yes, replacing imply with the dependency is what I did in the fixup patch. >> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/ >> >> It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y, >> and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why >> imply doesn't work, but I think I'll stay away from it in the future. >> >> Guenter > > > Hmm, this could be a Kconfig bug. > > I will take a look. Today, I took a look at it. The cause of the problem was the circular dependency. Somehow, 'imply' is not checked in the circular dependency. So, I wrote patches to report this. https://patchwork.kernel.org/patch/10565061/ https://patchwork.kernel.org/patch/10565063/ If you apply those two patches on top of commit 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors") It is reported in allmodconfig stage, like this: masahiro@grover:~/ref/linux-next$ make allmodconfig HOSTCC scripts/kconfig/conf.o YACC scripts/kconfig/zconf.tab.c HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf scripts/kconfig/conf --allmodconfig Kconfig drivers/of/Kconfig:68:error: recursive dependency detected! drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP drivers/base/regmap/Kconfig:6: symbol REGMAP is selected by SENSORS_ASPEED drivers/hwmon/Kconfig:352: symbol SENSORS_ASPEED depends on HWMON drivers/hwmon/Kconfig:5: symbol HWMON is implied by SFP drivers/net/phy/Kconfig:214: symbol SFP depends on PHYLIB drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected by ARC_EMAC drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ For a resolution refer to Documentation/kbuild/kconfig-language.txt subsection "Kconfig recursive dependency limitations" # # configuration written to .config # > > > BTW, > 'depends on HWMON || HWMON=n' is pointless > because it is always true. -- Best Regards Masahiro Yamada
On 08/14/2018 12:05 AM, Masahiro Yamada wrote:
> 2018-07-20 8:19 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
>> 2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>:
>>> On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote:
>>>> Hi Guenter,
>>>>
>>>> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>
>>>>> On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
>>>>>>
>>>>>> On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>>>>>>
>>>>>>> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>> After merging the net-next tree, today's linux-next build (x86_64
>>>>>>>> allmodconfig) produced this warning:
>>>>>>>>
>>>>>>>> *
>>>>>>>> * Restart config...
>>>>>>>> *
>>>>>>>> ....
>>>>>>>>
>>>>>>>> This is output by my "make allmodconfig" and only started after merging
>>>>>>>> the net-next tree today. It has continued for further merges/builds.
>>>>>>>>
>>>>>>>> I suspect commit
>>>>>>>>
>>>>>>>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>>>>>>>>
>>>>>>>> which added an "imply" clause.
>>>>>>>>
>>>>>>> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
>>>>>>> not. Is that a caveat when using "imply", and does it mean that "imply"
>>>>>>> should better not be used ?
>>>>>>
>>>>>> I don't know, sorry. It was just my best guess from what I could see
>>>>>> had changed.
>>>>>>
>>>>>> I wonder if it makes a difference that I am doing my "make
>>>>>> allmodconfig" on top of a previous "make allmodconfig" and some symbols
>>>>>> are marked as "NEW" (though they are not symbols related to the changes
>>>>>> that happened during the net-next tree merge)?
>>>>>>
>>>>>
>>>>> I tried to reproduce the problem, but I don't see the message.
>>>>>
>>>>> What I do see, though, is that "make allmodconfig" on a clean tree,
>>>>> followed by "make menuconfig", results in configuration changes.
>>>>> Specifically,
>>>>>
>>>>> > CONFIG_ARC_EMAC_CORE=m
>>>>> > CONFIG_ARC_EMAC=m
>>>>> > CONFIG_EMAC_ROCKCHIP=m
>>>>>
>>>>> is removed by menuconfig, and a large number of "# ... is not set"
>>>>> configuration lines are added. Weird and bad, since several of the
>>>>> disabled configurations _should_ be enabled by "make allmodconfig",
>>>>> and a large number of hwmon drivers are affected. Bisect does point
>>>>> to "net: phy: sfp: Add HWMON support for module sensors", meaning
>>>>> "imply hwmon" does have severe side effects and can not be used.
>>>>>
>>>>> I'll try to find a fix.
>>>>
>>>> OK, my mistake, the "make allmodconfig" works, the following "make"
>>>> causes the config restart. (I am actually doing cross builds and using
>>>> an external object directory, in case that matters.)
>>>>
>>>> I removed the "imply HWMON" line added by the above commit and the
>>>> problem went away. Also, using "depends on HWMON || HWMON=n" instead
>>>> of the imply fixes it.
>>>
>>> Yes, replacing imply with the dependency is what I did in the fixup patch.
>>> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
>>>
>>> It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y,
>>> and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why
>>> imply doesn't work, but I think I'll stay away from it in the future.
>>>
>>> Guenter
>>
>>
>> Hmm, this could be a Kconfig bug.
>>
>> I will take a look.
>
>
> Today, I took a look at it.
>
> The cause of the problem was the circular dependency.
>
> Somehow, 'imply' is not checked in the circular dependency.
>
> So, I wrote patches to report this.
> https://patchwork.kernel.org/patch/10565061/
> https://patchwork.kernel.org/patch/10565063/
>
>
> If you apply those two patches on top of commit
> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
> It is reported in allmodconfig stage, like this:
>
>
> masahiro@grover:~/ref/linux-next$ make allmodconfig
> HOSTCC scripts/kconfig/conf.o
> YACC scripts/kconfig/zconf.tab.c
> HOSTCC scripts/kconfig/zconf.tab.o
> HOSTLD scripts/kconfig/conf
> scripts/kconfig/conf --allmodconfig Kconfig
> drivers/of/Kconfig:68:error: recursive dependency detected!
> drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN
> kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP
> drivers/base/regmap/Kconfig:6: symbol REGMAP is selected by SENSORS_ASPEED
> drivers/hwmon/Kconfig:352: symbol SENSORS_ASPEED depends on HWMON
> drivers/hwmon/Kconfig:5: symbol HWMON is implied by SFP
> drivers/net/phy/Kconfig:214: symbol SFP depends on PHYLIB
> drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE
> drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected
> by ARC_EMAC
> drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
>
Interesting; I thought that "implied" does not really select the symbol.
That means 'imply' just doesn't work for HWMON, and we'll have to stick
with the old "depends on HWMON || HWMON=n".
Thanks,
Guenter
[-- Attachment #1: Type: text/plain, Size: 1161 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64_allmodconfig) produced this warning: drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c: In function 'run_xdp': drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:324:3: warning: this statement may fall through [-Wimplicit-fallthrough=] bpf_warn_invalid_xdp_action(xdp_act); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:325:2: note: here case XDP_ABORTED: ^~~~ drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:326:3: warning: this statement may fall through [-Wimplicit-fallthrough=] trace_xdp_exception(priv->net_dev, xdp_prog, xdp_act); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:327:2: note: here case XDP_DROP: ^~~~ Introduced by commit 7e273a8ebdd3 ("dpaa2-eth: Add basic XDP support") This due to my use of -Wimplicit-fallthrough. This is new code. The warning can be suppressed by adding a comment like /* fall through */ at the appropriate places to indicate that the fallthrough is intended. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1332 bytes --] Hi all, On Thu, 29 Nov 2018 11:24:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build > (x86_64_allmodconfig) produced this warning: > > drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c: In function 'run_xdp': > drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:324:3: warning: this statement may fall through [-Wimplicit-fallthrough=] > bpf_warn_invalid_xdp_action(xdp_act); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:325:2: note: here > case XDP_ABORTED: > ^~~~ > drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:326:3: warning: this statement may fall through [-Wimplicit-fallthrough=] > trace_xdp_exception(priv->net_dev, xdp_prog, xdp_act); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:327:2: note: here > case XDP_DROP: > ^~~~ > > Introduced by commit > > 7e273a8ebdd3 ("dpaa2-eth: Add basic XDP support") > > This due to my use of -Wimplicit-fallthrough. This is new code. The > warning can be suppressed by adding a comment like /* fall through */ > at the appropriate places to indicate that the fallthrough is intended. I am still seeing these warnings. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen,
On 12/18/18 8:42 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 29 Nov 2018 11:24:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the net-next tree, today's linux-next build
>> (x86_64_allmodconfig) produced this warning:
>>
>> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c: In function 'run_xdp':
>> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:324:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
>> bpf_warn_invalid_xdp_action(xdp_act);
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:325:2: note: here
>> case XDP_ABORTED:
>> ^~~~
>> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:326:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
>> trace_xdp_exception(priv->net_dev, xdp_prog, xdp_act);
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:327:2: note: here
>> case XDP_DROP:
>> ^~~~
>>
>> Introduced by commit
>>
>> 7e273a8ebdd3 ("dpaa2-eth: Add basic XDP support")
>>
>> This due to my use of -Wimplicit-fallthrough. This is new code. The
>> warning can be suppressed by adding a comment like /* fall through */
>> at the appropriate places to indicate that the fallthrough is intended.
>
> I am still seeing these warnings.
>
That's weird. I don't see them anymore in next-20181218.
They were fixed by this commit: c1cb11bcbd09f5f027cbc7fadddab169714948df
Thanks
[-- Attachment #1: Type: text/plain, Size: 2485 bytes --] Hi Gustavo, On Tue, 18 Dec 2018 21:07:06 -0600 "Gustavo A. R. Silva" <gustavo@embeddedor.com> wrote: > > On 12/18/18 8:42 PM, Stephen Rothwell wrote: > > Hi all, > > > > On Thu, 29 Nov 2018 11:24:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > >> > >> After merging the net-next tree, today's linux-next build > >> (x86_64_allmodconfig) produced this warning: > >> > >> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c: In function 'run_xdp': > >> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:324:3: warning: this statement may fall through [-Wimplicit-fallthrough=] > >> bpf_warn_invalid_xdp_action(xdp_act); > >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:325:2: note: here > >> case XDP_ABORTED: > >> ^~~~ > >> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:326:3: warning: this statement may fall through [-Wimplicit-fallthrough=] > >> trace_xdp_exception(priv->net_dev, xdp_prog, xdp_act); > >> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> drivers/net/ethernet/freescale/dpaa2/dpaa2-eth.c:327:2: note: here > >> case XDP_DROP: > >> ^~~~ > >> > >> Introduced by commit > >> > >> 7e273a8ebdd3 ("dpaa2-eth: Add basic XDP support") > >> > >> This due to my use of -Wimplicit-fallthrough. This is new code. The > >> warning can be suppressed by adding a comment like /* fall through */ > >> at the appropriate places to indicate that the fallthrough is intended. > > > > I am still seeing these warnings. > > > > That's weird. I don't see them anymore in next-20181218. > > They were fixed by this commit: c1cb11bcbd09f5f027cbc7fadddab169714948df My mistake (patter mismatch :-)), there are very similar warnings in drivers/net/veth.c which are older. Someone could fix those if they wanted to :-) drivers/net/veth.c: In function 'veth_xdp_rcv_one': drivers/net/veth.c:542:4: warning: this statement may fall through [-Wimplicit-fallthrough=] bpf_warn_invalid_xdp_action(act); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/veth.c:543:3: note: here case XDP_ABORTED: ^~~~ drivers/net/veth.c: In function 'veth_xdp_rcv_skb': drivers/net/veth.c:663:3: warning: this statement may fall through [-Wimplicit-fallthrough=] bpf_warn_invalid_xdp_action(act); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/veth.c:664:2: note: here case XDP_ABORTED: ^~~~ -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 801 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: net/core/sock.c: In function 'sock_setsockopt': net/core/sock.c:914:3: warning: this statement may fall through [-Wimplicit-fallthrough=] sock_set_flag(sk, SOCK_TSTAMP_NEW); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/core/sock.c:915:2: note: here case SO_TIMESTAMPING_OLD: ^~~~ Introduced by commit 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") I get this warning because I am building with -Wimplicit-fallthrough in attempt to catch new additions early. The gcc warning can be turned off by adding a /* fall through */ comment at the point the fall through happens (assuming that the fall through is intentional). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 4 Feb 2019 10:44:27 +1100 > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig) produced this warning: > > net/core/sock.c: In function 'sock_setsockopt': > net/core/sock.c:914:3: warning: this statement may fall through [-Wimplicit-fallthrough=] > sock_set_flag(sk, SOCK_TSTAMP_NEW); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > net/core/sock.c:915:2: note: here > case SO_TIMESTAMPING_OLD: > ^~~~ > > Introduced by commit > > 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") Thanks, I just pushed the following: ==================== [PATCH] net: Fix fall through warning in y2038 tstamp changes. net/core/sock.c: In function 'sock_setsockopt': net/core/sock.c:914:3: warning: this statement may fall through [-Wimplicit-fallthrough=] sock_set_flag(sk, SOCK_TSTAMP_NEW); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ net/core/sock.c:915:2: note: here case SO_TIMESTAMPING_OLD: ^~~~ Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- net/core/sock.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/core/sock.c b/net/core/sock.c index a8904ae40713..71ded4d8025c 100644 --- a/net/core/sock.c +++ b/net/core/sock.c @@ -912,6 +912,7 @@ int sock_setsockopt(struct socket *sock, int level, int optname, case SO_TIMESTAMPING_NEW: sock_set_flag(sk, SOCK_TSTAMP_NEW); + /* fall through */ case SO_TIMESTAMPING_OLD: if (val & ~SOF_TIMESTAMPING_MASK) { ret = -EINVAL; -- 2.20.1
[-- Attachment #1: Type: text/plain, Size: 1275 bytes --] Hi Dave, On Sun, 03 Feb 2019 20:26:06 -0800 (PST) David Miller <davem@davemloft.net> wrote: > > Thanks, I just pushed the following: > > ==================== > [PATCH] net: Fix fall through warning in y2038 tstamp changes. > > net/core/sock.c: In function 'sock_setsockopt': > net/core/sock.c:914:3: warning: this statement may fall through [-Wimplicit-fallthrough=] > sock_set_flag(sk, SOCK_TSTAMP_NEW); > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > net/core/sock.c:915:2: note: here > case SO_TIMESTAMPING_OLD: > ^~~~ > > Fixes: 9718475e6908 ("socket: Add SO_TIMESTAMPING_NEW") > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> > Signed-off-by: David S. Miller <davem@davemloft.net> > --- > net/core/sock.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/net/core/sock.c b/net/core/sock.c > index a8904ae40713..71ded4d8025c 100644 > --- a/net/core/sock.c > +++ b/net/core/sock.c > @@ -912,6 +912,7 @@ int sock_setsockopt(struct socket *sock, int level, int optname, > > case SO_TIMESTAMPING_NEW: > sock_set_flag(sk, SOCK_TSTAMP_NEW); > + /* fall through */ > case SO_TIMESTAMPING_OLD: > if (val & ~SOF_TIMESTAMPING_MASK) { > ret = -EINVAL; Looks good, thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 562 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c: In function 'mlxsw_sp_port_attr_get': drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:438:19: warning: unused variable 'mlxsw_sp' [-Wunused-variable] struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp; ^~~~~~~~ Introduced by commit 1ecb195753a1 ("mlxsw: spectrum_switchdev: Remove getting PORT_BRIDGE_FLAGS") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 538 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/staging/fsl-dpaa2/ethsw/ethsw.c: In function 'swdev_port_attr_get': drivers/staging/fsl-dpaa2/ethsw/ethsw.c:646:26: warning: unused variable 'port_priv' [-Wunused-variable] struct ethsw_port_priv *port_priv = netdev_priv(netdev); ^~~~~~~~~ Introduced by commit 1b8b589d9103 ("staging: fsl-dpaa2: ethsw: Remove getting PORT_BRIDGE_FLAGS") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Le 2/12/19 à 4:49 PM, Stephen Rothwell a écrit : > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c: In function 'mlxsw_sp_port_attr_get': > drivers/net/ethernet/mellanox/mlxsw/spectrum_switchdev.c:438:19: warning: unused variable 'mlxsw_sp' [-Wunused-variable] > struct mlxsw_sp *mlxsw_sp = mlxsw_sp_port->mlxsw_sp; > ^~~~~~~~ > > Introduced by commit > > 1ecb195753a1 ("mlxsw: spectrum_switchdev: Remove getting PORT_BRIDGE_FLAGS") Fixed with: http://patchwork.ozlabs.org/project/netdev/list/?series=91603 -- Florian
Le 2/12/19 à 4:51 PM, Stephen Rothwell a écrit : > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/staging/fsl-dpaa2/ethsw/ethsw.c: In function 'swdev_port_attr_get': > drivers/staging/fsl-dpaa2/ethsw/ethsw.c:646:26: warning: unused variable 'port_priv' [-Wunused-variable] > struct ethsw_port_priv *port_priv = netdev_priv(netdev); > ^~~~~~~~~ > > Introduced by commit > > 1b8b589d9103 ("staging: fsl-dpaa2: ethsw: Remove getting PORT_BRIDGE_FLAGS") > Also fixed with: http://patchwork.ozlabs.org/project/netdev/list/?series=91603 -- Florian
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/ethernet/rocker/rocker_main.c: In function 'rocker_port_attr_set': drivers/net/ethernet/rocker/rocker_main.c:2083:9: warning: this statement may fall through [-Wimplicit-fallthrough=] err = rocker_world_port_attr_pre_bridge_flags_set(rocker_port, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ attr->u.brport_flags, ~~~~~~~~~~~~~~~~~~~~~ trans); ~~~~~~ drivers/net/ethernet/rocker/rocker_main.c:2086:2: note: here case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS: ^~~~ Introduced by commit 93700458ff63 ("rocker: Check Handle PORT_PRE_BRIDGE_FLAGS") I get this warning because I am building with -Wimplicit-fallthrough in attempt to catch new additions early. The gcc warning can be turned off by adding a /* fall through */ comment at the point the fall through happens (assuming that the fall through is intentional). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 2/21/19 5:06 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (x86_64
> allmodconfig) produced this warning:
>
> drivers/net/ethernet/rocker/rocker_main.c: In function 'rocker_port_attr_set':
> drivers/net/ethernet/rocker/rocker_main.c:2083:9: warning: this statement may fall through [-Wimplicit-fallthrough=]
> err = rocker_world_port_attr_pre_bridge_flags_set(rocker_port,
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> attr->u.brport_flags,
> ~~~~~~~~~~~~~~~~~~~~~
> trans);
> ~~~~~~
> drivers/net/ethernet/rocker/rocker_main.c:2086:2: note: here
> case SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS:
> ^~~~
>
> Introduced by commit
>
> 93700458ff63 ("rocker: Check Handle PORT_PRE_BRIDGE_FLAGS")
>
> I get this warning because I am building with -Wimplicit-fallthrough
> in attempt to catch new additions early. The gcc warning can be turned
> off by adding a /* fall through */ comment at the point the fall through
> happens (assuming that the fall through is intentional).
There is a missing break, my rebase went wrong with that, I will send a
fix shortly for that.
--
Florian
[-- Attachment #1: Type: text/plain, Size: 308 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig) produced this warning: drivers/net/phy/Kconfig:276:warning: prompt redefined Introduced by commit 17cc9821766c ("net: phy: Move Omega PHY entry to Cygnus PHY driver") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 3/21/19 4:05 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
>
> drivers/net/phy/Kconfig:276:warning: prompt redefined
>
> Introduced by commit
>
> 17cc9821766c ("net: phy: Move Omega PHY entry to Cygnus PHY driver")
>
Whoops yes, that should not be there, thanks Stephen.
--
Florian
[-- Attachment #1: Type: text/plain, Size: 887 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/ethernet/netronome/nfp/flower/offload.c: In function 'nfp_flower_copy_pre_actions': drivers/net/ethernet/netronome/nfp/flower/offload.c:630:7: warning: this statement may fall through [-Wimplicit-fallthrough=] if (tunnel_act) ^ drivers/net/ethernet/netronome/nfp/flower/offload.c:632:3: note: here case NFP_FL_ACTION_OPCODE_PRE_LAG: ^~~~ Introduced by commit 1c6952ca587d ("nfp: flower: generate merge flow rule") I get this warning because I am building with -Wimplicit-fallthrough in attempt to catch new additions early. The gcc warning can be turned off by adding a /* fall through */ comment at the point the fall through happens (assuming that the fall through is intentional). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Apr 16, 2019 at 2:21 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/net/ethernet/netronome/nfp/flower/offload.c: In function 'nfp_flower_copy_pre_actions': > drivers/net/ethernet/netronome/nfp/flower/offload.c:630:7: warning: this statement may fall through [-Wimplicit-fallthrough=] > if (tunnel_act) > ^ > drivers/net/ethernet/netronome/nfp/flower/offload.c:632:3: note: here > case NFP_FL_ACTION_OPCODE_PRE_LAG: > ^~~~ > > Introduced by commit > > 1c6952ca587d ("nfp: flower: generate merge flow rule") > > I get this warning because I am building with -Wimplicit-fallthrough > in attempt to catch new additions early. The gcc warning can be turned > off by adding a /* fall through */ comment at the point the fall through > happens (assuming that the fall through is intentional). > Hi Stephen, Thanks for flagging this. The fall through is intentional. I'll submit a fix for the warning. John > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 947 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: net/socket.c: In function 'sock_ioctl': net/socket.c:1173:10: warning: this statement may fall through [-Wimplicit-fallthrough=] err = sock->ops->gettstamp(sock, argp, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ cmd == SIOCGSTAMP_OLD, ~~~~~~~~~~~~~~~~~~~~~~ !IS_ENABLED(CONFIG_64BIT)); ~~~~~~~~~~~~~~~~~~~~~~~~~~ net/socket.c:1176:3: note: here case SIOCGSTAMP_NEW: ^~~~ Introduced by commit 0768e17073dc ("net: socket: implement 64-bit timestamps") I get this warning because I am building with -Wimplicit-fallthrough in attempt to catch new additions early. The gcc warning can be turned off by adding a /* fall through */ comment at the point the fall through happens (assuming that the fall through is intentional). -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 518 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_set_multicast_list': drivers/net/ethernet/xilinx/ll_temac_main.c:490:8: warning: 'i' may be used uninitialized in this function [-Wmaybe-uninitialized] while (i < MULTICAST_CAM_TABLE_NUM) { ^ Introduced by commit 1b3fa5cf859b ("net: ll_temac: Cleanup multicast filter on change") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1737 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: In file included from include/linux/bitmap.h:9, from include/linux/cpumask.h:12, from arch/x86/include/asm/cpumask.h:5, from arch/x86/include/asm/msr.h:11, from arch/x86/include/asm/processor.h:21, from arch/x86/include/asm/cpufeature.h:5, from arch/x86/include/asm/thread_info.h:53, from include/linux/thread_info.h:38, from arch/x86/include/asm/preempt.h:7, from include/linux/preempt.h:78, from include/linux/spinlock.h:51, from include/linux/seqlock.h:36, from include/linux/time.h:6, from include/linux/ktime.h:24, from include/linux/timer.h:6, from include/linux/netdevice.h:24, from include/linux/if_vlan.h:10, from drivers/net/ethernet/mellanox/mlx5/core/en.h:35, from drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c:5: drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c: In function 'mlx5e_ktls_tx_handle_ooo': include/linux/string.h:400:9: warning: 'rec_seq' may be used uninitialized in this function [-Wmaybe-uninitialized] return __builtin_memcmp(p, q, size); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c:240:8: note: 'rec_seq' was declared here char *rec_seq; ^~~~~~~ Introduced by commit d2ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1318 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: Introduced by commit 033b2c7f0f26 ("rxrpc: Add missing "new peer" trace") interacting with commit 55f6c98e3674 ("rxrpc: Fix trace-after-put looking at the put peer record") from the net tree. I have applied the following merge fix patch. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 8 Oct 2019 09:37:50 +1100 Subject: [PATCH] rxrpc: fix up for "rxrpc: Fix trace-after-put looking at the put peer record" interacting with commit 033b2c7f0f26 ("rxrpc: Add missing "new peer" trace") Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/rxrpc/peer_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/rxrpc/peer_object.c b/net/rxrpc/peer_object.c index a7f1a2cdd198..452163eadb98 100644 --- a/net/rxrpc/peer_object.c +++ b/net/rxrpc/peer_object.c @@ -231,7 +231,7 @@ struct rxrpc_peer *rxrpc_alloc_peer(struct rxrpc_local *local, gfp_t gfp) peer->cong_cwnd = 3; else peer->cong_cwnd = 4; - trace_rxrpc_peer(peer, rxrpc_peer_new, 1, here); + trace_rxrpc_peer(peer->debug_id, rxrpc_peer_new, 1, here); } _leave(" = %p", peer); -- 2.23.0.rc1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> diff --git a/net/rxrpc/peer_object.c b/net/rxrpc/peer_object.c
> index a7f1a2cdd198..452163eadb98 100644
> --- a/net/rxrpc/peer_object.c
> +++ b/net/rxrpc/peer_object.c
> @@ -231,7 +231,7 @@ struct rxrpc_peer *rxrpc_alloc_peer(struct rxrpc_local *local, gfp_t gfp)
> peer->cong_cwnd = 3;
> else
> peer->cong_cwnd = 4;
> - trace_rxrpc_peer(peer, rxrpc_peer_new, 1, here);
> + trace_rxrpc_peer(peer->debug_id, rxrpc_peer_new, 1, here);
> }
>
> _leave(" = %p", peer);
Acked-by: David Howells <dhowells@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --] Hi all, After merging the net-next tree, today's linux-next build (arm multi_v7_defconfig.) produced this warning: In file included from net/core/ethtool.c:21: include/linux/sfp.h:566:12: warning: 'sfp_bus_add_upstream' defined but not used [-Wunused-function] 566 | static int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream, | ^~~~~~~~~~~~~~~~~~~~ Introduced by commit 727b3668b730 ("net: sfp: rework upstream interface") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 2843 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: In file included from ./arch/powerpc/include/generated/asm/local64.h:1, from include/linux/u64_stats_sync.h:72, from include/linux/cgroup-defs.h:20, from include/linux/cgroup.h:28, from include/linux/memcontrol.h:13, from include/linux/swap.h:9, from include/linux/suspend.h:5, from arch/powerpc/kernel/asm-offsets.c:23: include/linux/u64_stats_sync.h: In function 'u64_stats_read': include/asm-generic/local64.h:30:37: warning: passing argument 1 of 'local_read' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] 30 | #define local64_read(l) local_read(&(l)->a) | ^~~~~~~ include/linux/u64_stats_sync.h:80:9: note: in expansion of macro 'local64_read' 80 | return local64_read(&p->v); | ^~~~~~~~~~~~ In file included from include/asm-generic/local64.h:22, from ./arch/powerpc/include/generated/asm/local64.h:1, from include/linux/u64_stats_sync.h:72, from include/linux/cgroup-defs.h:20, from include/linux/cgroup.h:28, from include/linux/memcontrol.h:13, from include/linux/swap.h:9, from include/linux/suspend.h:5, from arch/powerpc/kernel/asm-offsets.c:23: arch/powerpc/include/asm/local.h:20:44: note: expected 'local_t *' {aka 'struct <anonymous> *'} but argument is of type 'const local_t *' {aka 'const struct <anonymous> *'} 20 | static __inline__ long local_read(local_t *l) | ~~~~~~~~~^ Introduced by commit 316580b69d0a ("u64_stats: provide u64_stats_t type") Powerpc folks: is there some reason that local_read() cannot take a const argument? I have added this patch (which builds fine) for today: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Mon, 11 Nov 2019 12:32:24 +1100 Subject: [PATCH] powerpc: local_read() should take a const local_t argument Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- arch/powerpc/include/asm/local.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/local.h b/arch/powerpc/include/asm/local.h index fdd00939270b..bc4bd19b7fc2 100644 --- a/arch/powerpc/include/asm/local.h +++ b/arch/powerpc/include/asm/local.h @@ -17,7 +17,7 @@ typedef struct #define LOCAL_INIT(i) { (i) } -static __inline__ long local_read(local_t *l) +static __inline__ long local_read(const local_t *l) { return READ_ONCE(l->v); } -- 2.23.0 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On 11/10/19 5:39 PM, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > In file included from ./arch/powerpc/include/generated/asm/local64.h:1, > from include/linux/u64_stats_sync.h:72, > from include/linux/cgroup-defs.h:20, > from include/linux/cgroup.h:28, > from include/linux/memcontrol.h:13, > from include/linux/swap.h:9, > from include/linux/suspend.h:5, > from arch/powerpc/kernel/asm-offsets.c:23: > include/linux/u64_stats_sync.h: In function 'u64_stats_read': > include/asm-generic/local64.h:30:37: warning: passing argument 1 of 'local_read' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] > 30 | #define local64_read(l) local_read(&(l)->a) > | ^~~~~~~ > include/linux/u64_stats_sync.h:80:9: note: in expansion of macro 'local64_read' > 80 | return local64_read(&p->v); > | ^~~~~~~~~~~~ > In file included from include/asm-generic/local64.h:22, > from ./arch/powerpc/include/generated/asm/local64.h:1, > from include/linux/u64_stats_sync.h:72, > from include/linux/cgroup-defs.h:20, > from include/linux/cgroup.h:28, > from include/linux/memcontrol.h:13, > from include/linux/swap.h:9, > from include/linux/suspend.h:5, > from arch/powerpc/kernel/asm-offsets.c:23: > arch/powerpc/include/asm/local.h:20:44: note: expected 'local_t *' {aka 'struct <anonymous> *'} but argument is of type 'const local_t *' {aka 'const struct <anonymous> *'} > 20 | static __inline__ long local_read(local_t *l) > | ~~~~~~~~~^ > > Introduced by commit > > 316580b69d0a ("u64_stats: provide u64_stats_t type") > > Powerpc folks: is there some reason that local_read() cannot take a > const argument? > > I have added this patch (which builds fine) for today: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > Date: Mon, 11 Nov 2019 12:32:24 +1100 > Subject: [PATCH] powerpc: local_read() should take a const local_t argument > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > --- > arch/powerpc/include/asm/local.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/powerpc/include/asm/local.h b/arch/powerpc/include/asm/local.h > index fdd00939270b..bc4bd19b7fc2 100644 > --- a/arch/powerpc/include/asm/local.h > +++ b/arch/powerpc/include/asm/local.h > @@ -17,7 +17,7 @@ typedef struct > > #define LOCAL_INIT(i) { (i) } > > -static __inline__ long local_read(local_t *l) > +static __inline__ long local_read(const local_t *l) > { > return READ_ONCE(l->v); > } > I have sent this patch two days ago, I do not believe I had any answer from ppc maintainers. From 47c47befdcf31fb8498c9e630bb8e0dc3ef88079 Mon Sep 17 00:00:00 2001 From: Eric Dumazet <edumazet@google.com> Date: Fri, 8 Nov 2019 06:04:35 -0800 Subject: [PATCH] powerpc: add const qual to local_read() parameter A patch in net-next triggered a compile error on powerpc. This seems reasonable to relax powerpc local_read() requirements. Fixes: 316580b69d0a ("u64_stats: provide u64_stats_t type") Signed-off-by: Eric Dumazet <edumazet@google.com> Reported-by: kbuild test robot <lkp@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/include/asm/local.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/local.h b/arch/powerpc/include/asm/local.h index fdd00939270bf08113b537a090d6a6e34a048361..bc4bd19b7fc235b80ec1132f44409b6fe1057975 100644 --- a/arch/powerpc/include/asm/local.h +++ b/arch/powerpc/include/asm/local.h @@ -17,7 +17,7 @@ typedef struct #define LOCAL_INIT(i) { (i) } -static __inline__ long local_read(local_t *l) +static __inline__ long local_read(const local_t *l) { return READ_ONCE(l->v); } -- 2.24.0.432.g9d3f5f5b63-goog
Thanks Stephen, patch coming today. On Mon, Nov 11, 2019 at 12:19:53PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (arm > multi_v7_defconfig.) produced this warning: > > In file included from net/core/ethtool.c:21: > include/linux/sfp.h:566:12: warning: 'sfp_bus_add_upstream' defined but not used [-Wunused-function] > 566 | static int sfp_bus_add_upstream(struct sfp_bus *bus, void *upstream, > | ^~~~~~~~~~~~~~~~~~~~ > > Introduced by commit > > 727b3668b730 ("net: sfp: rework upstream interface") > > -- > Cheers, > Stephen Rothwell -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
[-- Attachment #1: Type: text/plain, Size: 645 bytes --] Hi all, [Sorry, I should have reported this earlier] After merging the net-next tree, today's linux-next build (powerpc allyesconfig) produced this warning: net/netfilter/nf_flow_table_offload.c: In function 'nf_flow_rule_match': net/netfilter/nf_flow_table_offload.c:80:21: warning: unsigned conversion from 'int' to '__be16' {aka 'short unsigned int'} changes value from '327680' to '0' [-Woverflow] 80 | mask->tcp.flags = TCP_FLAG_RST | TCP_FLAG_FIN; | ^~~~~~~~~~~~ Introduced by commit c29f74e0df7a ("netfilter: nf_flow_table: hardware offload support") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 751 bytes --] Hi all, After merging the net-next tree, today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/net/bareudp.c: In function 'bareudp_xmit_skb': drivers/net/bareudp.c:346:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] 346 | return err; | ^~~ drivers/net/bareudp.c: In function 'bareudp6_xmit_skb': drivers/net/bareudp.c:407:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] 407 | return err; | ^~~ Introduced by commit 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") These are not false positives. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 25 Feb 2020 09:27:36 +1100 > After merging the net-next tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > drivers/net/bareudp.c: In function 'bareudp_xmit_skb': > drivers/net/bareudp.c:346:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] > 346 | return err; > | ^~~ > drivers/net/bareudp.c: In function 'bareudp6_xmit_skb': > drivers/net/bareudp.c:407:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] > 407 | return err; > | ^~~ > > Introduced by commit > > 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Sorry, my compiler didn't show this. I've committed the following into net-next, hopefully it does the trick: ==================== [PATCH] bareudp: Fix uninitialized variable warnings. drivers/net/bareudp.c: In function 'bareudp_xmit_skb': drivers/net/bareudp.c:346:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] 346 | return err; | ^~~ drivers/net/bareudp.c: In function 'bareudp6_xmit_skb': drivers/net/bareudp.c:407:9: warning: 'err' may be used uninitialized in this function [-Wmaybe-uninitialized] 407 | return err; Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> --- drivers/net/bareudp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/bareudp.c b/drivers/net/bareudp.c index 77e72477499d..15337e9d4fad 100644 --- a/drivers/net/bareudp.c +++ b/drivers/net/bareudp.c @@ -320,6 +320,7 @@ static int bareudp_xmit_skb(struct sk_buff *skb, struct net_device *dev, df = key->tun_flags & TUNNEL_DONT_FRAGMENT ? htons(IP_DF) : 0; skb_scrub_packet(skb, xnet); + err = -ENOSPC; if (!skb_pull(skb, skb_network_offset(skb))) goto free_dst; @@ -381,6 +382,7 @@ static int bareudp6_xmit_skb(struct sk_buff *skb, struct net_device *dev, skb_scrub_packet(skb, xnet); + err = -ENOSPC; if (!skb_pull(skb, skb_network_offset(skb))) goto free_dst; -- 2.21.1
[-- Attachment #1: Type: text/plain, Size: 374 bytes --] Hi Dave, On Mon, 24 Feb 2020 14:42:43 -0800 (PST) David Miller <davem@davemloft.net> wrote: > > Sorry, my compiler didn't show this. Yeah, these ones especially change with compiler version. I am currently running gcc v9.2.1 if it matters. > I've committed the following into net-next, hopefully it does the trick: Thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
HI David & Stephen, In v8 version of patch while fixing reverse xmas tree I wrongly judged the variable usage and removed the initialization. But wondering why compiler didn't show me that. Apologies. David, Thanks for fixing it. Regards, Martin -----Original Message----- From: Stephen Rothwell <sfr@canb.auug.org.au> Sent: Tuesday, February 25, 2020 4:17 AM To: David Miller <davem@davemloft.net> Cc: netdev@vger.kernel.org; linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Varghese, Martin (Nokia - IN/Bangalore) <martin.varghese@nokia.com>; willemb@google.com Subject: Re: linux-next: build warning after merge of the net-next tree Hi Dave, On Mon, 24 Feb 2020 14:42:43 -0800 (PST) David Miller <davem@davemloft.net> wrote: > > Sorry, my compiler didn't show this. Yeah, these ones especially change with compiler version. I am currently running gcc v9.2.1 if it matters. > I've committed the following into net-next, hopefully it does the trick: Thanks. -- Cheers, Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 252 bytes --] Hi Dave, On Mon, 24 Feb 2020 14:42:43 -0800 (PST) David Miller <davem@davemloft.net> wrote: > > I've committed the following into net-next, hopefully it does the trick: That fixed the warnings for me, thanks. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 379 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/net/cfg80211.h:3407: warning: bad line: Many times. Introduced by commit 56be393fa8b4 ("cfg80211: Support key configuration for Beacon protection (BIGTK)") I assume that all it needs is a leading " *" on that line. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1498 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc allyesconfig) produced this warning: In file included from include/linux/byteorder/big_endian.h:5, from arch/powerpc/include/uapi/asm/byteorder.h:14, from include/asm-generic/bitops/le.h:6, from arch/powerpc/include/asm/bitops.h:250, from include/linux/bitops.h:29, from include/linux/kernel.h:12, from include/linux/list.h:9, from include/linux/module.h:12, from drivers/net/usb/cdc_ncm.c:41: drivers/net/usb/cdc_ncm.c: In function 'cdc_ncm_ndp32': include/uapi/linux/byteorder/big_endian.h:33:26: warning: conversion from 'unsigned int' to '__le16' {aka 'short unsigned int'} changes value from '402653184' to '0' [-Woverflow] 33 | #define __cpu_to_le32(x) ((__force __le32)__swab32((x))) | ^ include/linux/byteorder/generic.h:88:21: note: in expansion of macro '__cpu_to_le32' 88 | #define cpu_to_le32 __cpu_to_le32 | ^~~~~~~~~~~~~ drivers/net/usb/cdc_ncm.c:1175:19: note: in expansion of macro 'cpu_to_le32' 1175 | ndp32->wLength = cpu_to_le32(sizeof(struct usb_cdc_ncm_ndp32) + sizeof(struct usb_cdc_ncm_dpe32)); | ^~~~~~~~~~~ Introduced by commit 0fa81b304a79 ("cdc_ncm: Implement the 32-bit version of NCM Transfer Block") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1914 bytes --] Hi, This is my patch, sorry for this warning. The fix is to change cpu_to_le32 to cpu_to_le16 in line 1175: ndp32->wLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_ndp32) + sizeof(struct usb_cdc_ncm_dpe32)); The full patch is attached Best, Alexander Bersenev пт, 13 мар. 2020 г. в 14:54, Stephen Rothwell <sfr@canb.auug.org.au>: > > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > allyesconfig) produced this warning: > > In file included from include/linux/byteorder/big_endian.h:5, > from arch/powerpc/include/uapi/asm/byteorder.h:14, > from include/asm-generic/bitops/le.h:6, > from arch/powerpc/include/asm/bitops.h:250, > from include/linux/bitops.h:29, > from include/linux/kernel.h:12, > from include/linux/list.h:9, > from include/linux/module.h:12, > from drivers/net/usb/cdc_ncm.c:41: > drivers/net/usb/cdc_ncm.c: In function 'cdc_ncm_ndp32': > include/uapi/linux/byteorder/big_endian.h:33:26: warning: conversion from 'unsigned int' to '__le16' {aka 'short unsigned int'} changes value from '402653184' to '0' [-Woverflow] > 33 | #define __cpu_to_le32(x) ((__force __le32)__swab32((x))) > | ^ > include/linux/byteorder/generic.h:88:21: note: in expansion of macro '__cpu_to_le32' > 88 | #define cpu_to_le32 __cpu_to_le32 > | ^~~~~~~~~~~~~ > drivers/net/usb/cdc_ncm.c:1175:19: note: in expansion of macro 'cpu_to_le32' > 1175 | ndp32->wLength = cpu_to_le32(sizeof(struct usb_cdc_ncm_ndp32) + sizeof(struct usb_cdc_ncm_dpe32)); > | ^~~~~~~~~~~ > > Introduced by commit > > 0fa81b304a79 ("cdc_ncm: Implement the 32-bit version of NCM Transfer Block") > > -- > Cheers, > Stephen Rothwell [-- Attachment #2: 0001-cdc_ncm-Implement-the-32-bit-version-of-NCM-Transfer.patch --] [-- Type: text/x-patch, Size: 25320 bytes --] From d63e327991478a6104f123d57538feb9196a70ca Mon Sep 17 00:00:00 2001 From: Alexander Bersenev <bay@hackerdom.ru> Date: Fri, 6 Mar 2020 01:02:33 +0500 Subject: [PATCH] cdc_ncm: Implement the 32-bit version of NCM Transfer Block The NCM specification defines two formats of transfer blocks: with 16-bit fields (NTB-16) and with 32-bit fields (NTB-32). Currently only NTB-16 is implemented. This patch adds the support of NTB-32. The motivation behind this is that some devices such as E5785 or E5885 from the current generation of Huawei LTE routers do not support NTB-16. The previous generations of Huawei devices are also use NTB-32 by default. Also this patch enables NTB-32 by default for Huawei devices. During the 2019 ValdikSS made five attempts to contact Huawei to add the NTB-16 support to their router firmware, but they were unsuccessful. Signed-off-by: Alexander Bersenev <bay@hackerdom.ru> --- drivers/net/usb/cdc_ncm.c | 411 ++++++++++++++++++++++++------- drivers/net/usb/huawei_cdc_ncm.c | 8 +- include/linux/usb/cdc_ncm.h | 15 +- 3 files changed, 340 insertions(+), 94 deletions(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c index c2c82e6391b4..8929669b5e6d 100644 --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -175,7 +175,11 @@ static u32 cdc_ncm_check_tx_max(struct usbnet *dev, u32 new_tx) u32 val, max, min; /* clamp new_tx to sane values */ - min = ctx->max_datagram_size + ctx->max_ndp_size + sizeof(struct usb_cdc_ncm_nth16); + if (ctx->is_ndp16) + min = ctx->max_datagram_size + ctx->max_ndp_size + sizeof(struct usb_cdc_ncm_nth16); + else + min = ctx->max_datagram_size + ctx->max_ndp_size + sizeof(struct usb_cdc_ncm_nth32); + max = min_t(u32, CDC_NCM_NTB_MAX_SIZE_TX, le32_to_cpu(ctx->ncm_parm.dwNtbOutMaxSize)); /* some devices set dwNtbOutMaxSize too low for the above default */ @@ -307,10 +311,17 @@ static ssize_t ndp_to_end_store(struct device *d, struct device_attribute *attr if (enable == (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END)) return len; - if (enable && !ctx->delayed_ndp16) { - ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL); - if (!ctx->delayed_ndp16) - return -ENOMEM; + if (enable) { + if (ctx->is_ndp16 && !ctx->delayed_ndp16) { + ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL); + if (!ctx->delayed_ndp16) + return -ENOMEM; + } + if (!ctx->is_ndp16 && !ctx->delayed_ndp32) { + ctx->delayed_ndp32 = kzalloc(ctx->max_ndp_size, GFP_KERNEL); + if (!ctx->delayed_ndp32) + return -ENOMEM; + } } /* flush pending data before changing flag */ @@ -512,6 +523,9 @@ static int cdc_ncm_init(struct usbnet *dev) dev_err(&dev->intf->dev, "SET_CRC_MODE failed\n"); } + /* use ndp16 by default */ + ctx->is_ndp16 = 1; + /* set NTB format, if both formats are supported. * * "The host shall only send this command while the NCM Data @@ -519,14 +533,27 @@ static int cdc_ncm_init(struct usbnet *dev) */ if (le16_to_cpu(ctx->ncm_parm.bmNtbFormatsSupported) & USB_CDC_NCM_NTB32_SUPPORTED) { - dev_dbg(&dev->intf->dev, "Setting NTB format to 16-bit\n"); - err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, - USB_TYPE_CLASS | USB_DIR_OUT - | USB_RECIP_INTERFACE, - USB_CDC_NCM_NTB16_FORMAT, - iface_no, NULL, 0); - if (err < 0) + if (ctx->drvflags & CDC_NCM_FLAG_PREFER_NTB32) { + ctx->is_ndp16 = 0; + dev_dbg(&dev->intf->dev, "Setting NTB format to 32-bit\n"); + err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, + USB_TYPE_CLASS | USB_DIR_OUT + | USB_RECIP_INTERFACE, + USB_CDC_NCM_NTB32_FORMAT, + iface_no, NULL, 0); + } else { + ctx->is_ndp16 = 1; + dev_dbg(&dev->intf->dev, "Setting NTB format to 16-bit\n"); + err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, + USB_TYPE_CLASS | USB_DIR_OUT + | USB_RECIP_INTERFACE, + USB_CDC_NCM_NTB16_FORMAT, + iface_no, NULL, 0); + } + if (err < 0) { + ctx->is_ndp16 = 1; dev_err(&dev->intf->dev, "SET_NTB_FORMAT failed\n"); + } } /* set initial device values */ @@ -549,7 +576,10 @@ static int cdc_ncm_init(struct usbnet *dev) ctx->tx_max_datagrams = CDC_NCM_DPT_DATAGRAMS_MAX; /* set up maximum NDP size */ - ctx->max_ndp_size = sizeof(struct usb_cdc_ncm_ndp16) + (ctx->tx_max_datagrams + 1) * sizeof(struct usb_cdc_ncm_dpe16); + if (ctx->is_ndp16) + ctx->max_ndp_size = sizeof(struct usb_cdc_ncm_ndp16) + (ctx->tx_max_datagrams + 1) * sizeof(struct usb_cdc_ncm_dpe16); + else + ctx->max_ndp_size = sizeof(struct usb_cdc_ncm_ndp32) + (ctx->tx_max_datagrams + 1) * sizeof(struct usb_cdc_ncm_dpe32); /* initial coalescing timer interval */ ctx->timer_interval = CDC_NCM_TIMER_INTERVAL_USEC * NSEC_PER_USEC; @@ -734,7 +764,10 @@ static void cdc_ncm_free(struct cdc_ncm_ctx *ctx) ctx->tx_curr_skb = NULL; } - kfree(ctx->delayed_ndp16); + if (ctx->is_ndp16) + kfree(ctx->delayed_ndp16); + else + kfree(ctx->delayed_ndp32); kfree(ctx); } @@ -772,10 +805,8 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_ u8 *buf; int len; int temp; - int err; u8 iface_no; struct usb_cdc_parsed_header hdr; - __le16 curr_ntb_format; ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) @@ -879,32 +910,6 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_ goto error2; } - /* - * Some Huawei devices have been observed to come out of reset in NDP32 mode. - * Let's check if this is the case, and set the device to NDP16 mode again if - * needed. - */ - if (ctx->drvflags & CDC_NCM_FLAG_RESET_NTB16) { - err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_FORMAT, - USB_TYPE_CLASS | USB_DIR_IN | USB_RECIP_INTERFACE, - 0, iface_no, &curr_ntb_format, 2); - if (err < 0) { - goto error2; - } - - if (curr_ntb_format == cpu_to_le16(USB_CDC_NCM_NTB32_FORMAT)) { - dev_info(&intf->dev, "resetting NTB format to 16-bit"); - err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, - USB_TYPE_CLASS | USB_DIR_OUT - | USB_RECIP_INTERFACE, - USB_CDC_NCM_NTB16_FORMAT, - iface_no, NULL, 0); - - if (err < 0) - goto error2; - } - } - cdc_ncm_find_endpoints(dev, ctx->data); cdc_ncm_find_endpoints(dev, ctx->control); if (!dev->in || !dev->out || !dev->status) { @@ -929,9 +934,15 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_ /* Allocate the delayed NDP if needed. */ if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END) { - ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL); - if (!ctx->delayed_ndp16) - goto error2; + if (ctx->is_ndp16) { + ctx->delayed_ndp16 = kzalloc(ctx->max_ndp_size, GFP_KERNEL); + if (!ctx->delayed_ndp16) + goto error2; + } else { + ctx->delayed_ndp32 = kzalloc(ctx->max_ndp_size, GFP_KERNEL); + if (!ctx->delayed_ndp32) + goto error2; + } dev_info(&intf->dev, "NDP will be placed at end of frame for this device."); } @@ -1055,7 +1066,7 @@ static void cdc_ncm_align_tail(struct sk_buff *skb, size_t modulus, size_t remai /* return a pointer to a valid struct usb_cdc_ncm_ndp16 of type sign, possibly * allocating a new one within skb */ -static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp(struct cdc_ncm_ctx *ctx, struct sk_buff *skb, __le32 sign, size_t reserve) +static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb, __le32 sign, size_t reserve) { struct usb_cdc_ncm_ndp16 *ndp16 = NULL; struct usb_cdc_ncm_nth16 *nth16 = (void *)skb->data; @@ -1110,12 +1121,73 @@ static struct usb_cdc_ncm_ndp16 *cdc_ncm_ndp(struct cdc_ncm_ctx *ctx, struct sk_ return ndp16; } +static struct usb_cdc_ncm_ndp32 *cdc_ncm_ndp32(struct cdc_ncm_ctx *ctx, struct sk_buff *skb, __le32 sign, size_t reserve) +{ + struct usb_cdc_ncm_ndp32 *ndp32 = NULL; + struct usb_cdc_ncm_nth32 *nth32 = (void *)skb->data; + size_t ndpoffset = le32_to_cpu(nth32->dwNdpIndex); + + /* If NDP should be moved to the end of the NCM package, we can't follow the + * NTH32 header as we would normally do. NDP isn't written to the SKB yet, and + * the wNdpIndex field in the header is actually not consistent with reality. It will be later. + */ + if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END) { + if (ctx->delayed_ndp32->dwSignature == sign) + return ctx->delayed_ndp32; + + /* We can only push a single NDP to the end. Return + * NULL to send what we've already got and queue this + * skb for later. + */ + else if (ctx->delayed_ndp32->dwSignature) + return NULL; + } + + /* follow the chain of NDPs, looking for a match */ + while (ndpoffset) { + ndp32 = (struct usb_cdc_ncm_ndp32 *)(skb->data + ndpoffset); + if (ndp32->dwSignature == sign) + return ndp32; + ndpoffset = le32_to_cpu(ndp32->dwNextNdpIndex); + } + + /* align new NDP */ + if (!(ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END)) + cdc_ncm_align_tail(skb, ctx->tx_ndp_modulus, 0, ctx->tx_curr_size); + + /* verify that there is room for the NDP and the datagram (reserve) */ + if ((ctx->tx_curr_size - skb->len - reserve) < ctx->max_ndp_size) + return NULL; + + /* link to it */ + if (ndp32) + ndp32->dwNextNdpIndex = cpu_to_le32(skb->len); + else + nth32->dwNdpIndex = cpu_to_le32(skb->len); + + /* push a new empty NDP */ + if (!(ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END)) + ndp32 = skb_put_zero(skb, ctx->max_ndp_size); + else + ndp32 = ctx->delayed_ndp32; + + ndp32->dwSignature = sign; + ndp32->wLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_ndp32) + sizeof(struct usb_cdc_ncm_dpe32)); + return ndp32; +} + struct sk_buff * cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) { struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0]; - struct usb_cdc_ncm_nth16 *nth16; - struct usb_cdc_ncm_ndp16 *ndp16; + union { + struct usb_cdc_ncm_nth16 *nth16; + struct usb_cdc_ncm_nth32 *nth32; + } nth; + union { + struct usb_cdc_ncm_ndp16 *ndp16; + struct usb_cdc_ncm_ndp32 *ndp32; + } ndp; struct sk_buff *skb_out; u16 n = 0, index, ndplen; u8 ready2send = 0; @@ -1179,11 +1251,19 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) } ctx->tx_low_mem_val--; } - /* fill out the initial 16-bit NTB header */ - nth16 = skb_put_zero(skb_out, sizeof(struct usb_cdc_ncm_nth16)); - nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN); - nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16)); - nth16->wSequence = cpu_to_le16(ctx->tx_seq++); + if (ctx->is_ndp16) { + /* fill out the initial 16-bit NTB header */ + nth.nth16 = skb_put_zero(skb_out, sizeof(struct usb_cdc_ncm_nth16)); + nth.nth16->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH16_SIGN); + nth.nth16->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth16)); + nth.nth16->wSequence = cpu_to_le16(ctx->tx_seq++); + } else { + /* fill out the initial 32-bit NTB header */ + nth.nth32 = skb_put_zero(skb_out, sizeof(struct usb_cdc_ncm_nth32)); + nth.nth32->dwSignature = cpu_to_le32(USB_CDC_NCM_NTH32_SIGN); + nth.nth32->wHeaderLength = cpu_to_le16(sizeof(struct usb_cdc_ncm_nth32)); + nth.nth32->wSequence = cpu_to_le16(ctx->tx_seq++); + } /* count total number of frames in this NTB */ ctx->tx_curr_frame_num = 0; @@ -1205,13 +1285,17 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) } /* get the appropriate NDP for this skb */ - ndp16 = cdc_ncm_ndp(ctx, skb_out, sign, skb->len + ctx->tx_modulus + ctx->tx_remainder); + if (ctx->is_ndp16) + ndp.ndp16 = cdc_ncm_ndp16(ctx, skb_out, sign, skb->len + ctx->tx_modulus + ctx->tx_remainder); + else + ndp.ndp32 = cdc_ncm_ndp32(ctx, skb_out, sign, skb->len + ctx->tx_modulus + ctx->tx_remainder); /* align beginning of next frame */ cdc_ncm_align_tail(skb_out, ctx->tx_modulus, ctx->tx_remainder, ctx->tx_curr_size); /* check if we had enough room left for both NDP and frame */ - if (!ndp16 || skb_out->len + skb->len + delayed_ndp_size > ctx->tx_curr_size) { + if ((ctx->is_ndp16 && !ndp.ndp16) || (!ctx->is_ndp16 && !ndp.ndp32) || + skb_out->len + skb->len + delayed_ndp_size > ctx->tx_curr_size) { if (n == 0) { /* won't fit, MTU problem? */ dev_kfree_skb_any(skb); @@ -1233,13 +1317,22 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) } /* calculate frame number withing this NDP */ - ndplen = le16_to_cpu(ndp16->wLength); - index = (ndplen - sizeof(struct usb_cdc_ncm_ndp16)) / sizeof(struct usb_cdc_ncm_dpe16) - 1; + if (ctx->is_ndp16) { + ndplen = le16_to_cpu(ndp.ndp16->wLength); + index = (ndplen - sizeof(struct usb_cdc_ncm_ndp16)) / sizeof(struct usb_cdc_ncm_dpe16) - 1; + + /* OK, add this skb */ + ndp.ndp16->dpe16[index].wDatagramLength = cpu_to_le16(skb->len); + ndp.ndp16->dpe16[index].wDatagramIndex = cpu_to_le16(skb_out->len); + ndp.ndp16->wLength = cpu_to_le16(ndplen + sizeof(struct usb_cdc_ncm_dpe16)); + } else { + ndplen = le16_to_cpu(ndp.ndp32->wLength); + index = (ndplen - sizeof(struct usb_cdc_ncm_ndp32)) / sizeof(struct usb_cdc_ncm_dpe32) - 1; - /* OK, add this skb */ - ndp16->dpe16[index].wDatagramLength = cpu_to_le16(skb->len); - ndp16->dpe16[index].wDatagramIndex = cpu_to_le16(skb_out->len); - ndp16->wLength = cpu_to_le16(ndplen + sizeof(struct usb_cdc_ncm_dpe16)); + ndp.ndp32->dpe32[index].dwDatagramLength = cpu_to_le32(skb->len); + ndp.ndp32->dpe32[index].dwDatagramIndex = cpu_to_le32(skb_out->len); + ndp.ndp32->wLength = cpu_to_le16(ndplen + sizeof(struct usb_cdc_ncm_dpe32)); + } skb_put_data(skb_out, skb->data, skb->len); ctx->tx_curr_frame_payload += skb->len; /* count real tx payload data */ dev_kfree_skb_any(skb); @@ -1286,13 +1379,22 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) /* If requested, put NDP at end of frame. */ if (ctx->drvflags & CDC_NCM_FLAG_NDP_TO_END) { - nth16 = (struct usb_cdc_ncm_nth16 *)skb_out->data; - cdc_ncm_align_tail(skb_out, ctx->tx_ndp_modulus, 0, ctx->tx_curr_size - ctx->max_ndp_size); - nth16->wNdpIndex = cpu_to_le16(skb_out->len); - skb_put_data(skb_out, ctx->delayed_ndp16, ctx->max_ndp_size); + if (ctx->is_ndp16) { + nth.nth16 = (struct usb_cdc_ncm_nth16 *)skb_out->data; + cdc_ncm_align_tail(skb_out, ctx->tx_ndp_modulus, 0, ctx->tx_curr_size - ctx->max_ndp_size); + nth.nth16->wNdpIndex = cpu_to_le16(skb_out->len); + skb_put_data(skb_out, ctx->delayed_ndp16, ctx->max_ndp_size); + + /* Zero out delayed NDP - signature checking will naturally fail. */ + ndp.ndp16 = memset(ctx->delayed_ndp16, 0, ctx->max_ndp_size); + } else { + nth.nth32 = (struct usb_cdc_ncm_nth32 *)skb_out->data; + cdc_ncm_align_tail(skb_out, ctx->tx_ndp_modulus, 0, ctx->tx_curr_size - ctx->max_ndp_size); + nth.nth32->dwNdpIndex = cpu_to_le32(skb_out->len); + skb_put_data(skb_out, ctx->delayed_ndp32, ctx->max_ndp_size); - /* Zero out delayed NDP - signature checking will naturally fail. */ - ndp16 = memset(ctx->delayed_ndp16, 0, ctx->max_ndp_size); + ndp.ndp32 = memset(ctx->delayed_ndp32, 0, ctx->max_ndp_size); + } } /* If collected data size is less or equal ctx->min_tx_pkt @@ -1314,8 +1416,13 @@ cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign) } /* set final frame length */ - nth16 = (struct usb_cdc_ncm_nth16 *)skb_out->data; - nth16->wBlockLength = cpu_to_le16(skb_out->len); + if (ctx->is_ndp16) { + nth.nth16 = (struct usb_cdc_ncm_nth16 *)skb_out->data; + nth.nth16->wBlockLength = cpu_to_le16(skb_out->len); + } else { + nth.nth32 = (struct usb_cdc_ncm_nth32 *)skb_out->data; + nth.nth32->dwBlockLength = cpu_to_le32(skb_out->len); + } /* return skb */ ctx->tx_curr_skb = NULL; @@ -1398,7 +1505,12 @@ cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags) goto error; spin_lock_bh(&ctx->mtx); - skb_out = cdc_ncm_fill_tx_frame(dev, skb, cpu_to_le32(USB_CDC_NCM_NDP16_NOCRC_SIGN)); + + if (ctx->is_ndp16) + skb_out = cdc_ncm_fill_tx_frame(dev, skb, cpu_to_le32(USB_CDC_NCM_NDP16_NOCRC_SIGN)); + else + skb_out = cdc_ncm_fill_tx_frame(dev, skb, cpu_to_le32(USB_CDC_NCM_NDP32_NOCRC_SIGN)); + spin_unlock_bh(&ctx->mtx); return skb_out; @@ -1459,6 +1571,54 @@ int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in) } EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_nth16); +int cdc_ncm_rx_verify_nth32(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in) +{ + struct usbnet *dev = netdev_priv(skb_in->dev); + struct usb_cdc_ncm_nth32 *nth32; + int len; + int ret = -EINVAL; + + if (ctx == NULL) + goto error; + + if (skb_in->len < (sizeof(struct usb_cdc_ncm_nth32) + + sizeof(struct usb_cdc_ncm_ndp32))) { + netif_dbg(dev, rx_err, dev->net, "frame too short\n"); + goto error; + } + + nth32 = (struct usb_cdc_ncm_nth32 *)skb_in->data; + + if (nth32->dwSignature != cpu_to_le32(USB_CDC_NCM_NTH32_SIGN)) { + netif_dbg(dev, rx_err, dev->net, + "invalid NTH32 signature <%#010x>\n", + le32_to_cpu(nth32->dwSignature)); + goto error; + } + + len = le32_to_cpu(nth32->dwBlockLength); + if (len > ctx->rx_max) { + netif_dbg(dev, rx_err, dev->net, + "unsupported NTB block length %u/%u\n", len, + ctx->rx_max); + goto error; + } + + if ((ctx->rx_seq + 1) != le16_to_cpu(nth32->wSequence) && + (ctx->rx_seq || le16_to_cpu(nth32->wSequence)) && + !((ctx->rx_seq == 0xffff) && !le16_to_cpu(nth32->wSequence))) { + netif_dbg(dev, rx_err, dev->net, + "sequence number glitch prev=%d curr=%d\n", + ctx->rx_seq, le16_to_cpu(nth32->wSequence)); + } + ctx->rx_seq = le16_to_cpu(nth32->wSequence); + + ret = le32_to_cpu(nth32->dwNdpIndex); +error: + return ret; +} +EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_nth32); + /* verify NDP header and return number of datagrams, or negative error */ int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset) { @@ -1495,6 +1655,42 @@ int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset) } EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_ndp16); +/* verify NDP header and return number of datagrams, or negative error */ +int cdc_ncm_rx_verify_ndp32(struct sk_buff *skb_in, int ndpoffset) +{ + struct usbnet *dev = netdev_priv(skb_in->dev); + struct usb_cdc_ncm_ndp32 *ndp32; + int ret = -EINVAL; + + if ((ndpoffset + sizeof(struct usb_cdc_ncm_ndp32)) > skb_in->len) { + netif_dbg(dev, rx_err, dev->net, "invalid NDP offset <%u>\n", + ndpoffset); + goto error; + } + ndp32 = (struct usb_cdc_ncm_ndp32 *)(skb_in->data + ndpoffset); + + if (le16_to_cpu(ndp32->wLength) < USB_CDC_NCM_NDP32_LENGTH_MIN) { + netif_dbg(dev, rx_err, dev->net, "invalid DPT32 length <%u>\n", + le16_to_cpu(ndp32->wLength)); + goto error; + } + + ret = ((le16_to_cpu(ndp32->wLength) - + sizeof(struct usb_cdc_ncm_ndp32)) / + sizeof(struct usb_cdc_ncm_dpe32)); + ret--; /* we process NDP entries except for the last one */ + + if ((sizeof(struct usb_cdc_ncm_ndp32) + + ret * (sizeof(struct usb_cdc_ncm_dpe32))) > skb_in->len) { + netif_dbg(dev, rx_err, dev->net, "Invalid nframes = %d\n", ret); + ret = -EINVAL; + } + +error: + return ret; +} +EXPORT_SYMBOL_GPL(cdc_ncm_rx_verify_ndp32); + int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in) { struct sk_buff *skb; @@ -1503,34 +1699,66 @@ int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in) int nframes; int x; int offset; - struct usb_cdc_ncm_ndp16 *ndp16; - struct usb_cdc_ncm_dpe16 *dpe16; + union { + struct usb_cdc_ncm_ndp16 *ndp16; + struct usb_cdc_ncm_ndp32 *ndp32; + } ndp; + union { + struct usb_cdc_ncm_dpe16 *dpe16; + struct usb_cdc_ncm_dpe32 *dpe32; + } dpe; + int ndpoffset; int loopcount = 50; /* arbitrary max preventing infinite loop */ u32 payload = 0; - ndpoffset = cdc_ncm_rx_verify_nth16(ctx, skb_in); + if (ctx->is_ndp16) + ndpoffset = cdc_ncm_rx_verify_nth16(ctx, skb_in); + else + ndpoffset = cdc_ncm_rx_verify_nth32(ctx, skb_in); + if (ndpoffset < 0) goto error; next_ndp: - nframes = cdc_ncm_rx_verify_ndp16(skb_in, ndpoffset); - if (nframes < 0) - goto error; + if (ctx->is_ndp16) { + nframes = cdc_ncm_rx_verify_ndp16(skb_in, ndpoffset); + if (nframes < 0) + goto error; - ndp16 = (struct usb_cdc_ncm_ndp16 *)(skb_in->data + ndpoffset); + ndp.ndp16 = (struct usb_cdc_ncm_ndp16 *)(skb_in->data + ndpoffset); - if (ndp16->dwSignature != cpu_to_le32(USB_CDC_NCM_NDP16_NOCRC_SIGN)) { - netif_dbg(dev, rx_err, dev->net, - "invalid DPT16 signature <%#010x>\n", - le32_to_cpu(ndp16->dwSignature)); - goto err_ndp; + if (ndp.ndp16->dwSignature != cpu_to_le32(USB_CDC_NCM_NDP16_NOCRC_SIGN)) { + netif_dbg(dev, rx_err, dev->net, + "invalid DPT16 signature <%#010x>\n", + le32_to_cpu(ndp.ndp16->dwSignature)); + goto err_ndp; + } + dpe.dpe16 = ndp.ndp16->dpe16; + } else { + nframes = cdc_ncm_rx_verify_ndp32(skb_in, ndpoffset); + if (nframes < 0) + goto error; + + ndp.ndp32 = (struct usb_cdc_ncm_ndp32 *)(skb_in->data + ndpoffset); + + if (ndp.ndp32->dwSignature != cpu_to_le32(USB_CDC_NCM_NDP32_NOCRC_SIGN)) { + netif_dbg(dev, rx_err, dev->net, + "invalid DPT32 signature <%#010x>\n", + le32_to_cpu(ndp.ndp32->dwSignature)); + goto err_ndp; + } + dpe.dpe32 = ndp.ndp32->dpe32; } - dpe16 = ndp16->dpe16; - for (x = 0; x < nframes; x++, dpe16++) { - offset = le16_to_cpu(dpe16->wDatagramIndex); - len = le16_to_cpu(dpe16->wDatagramLength); + for (x = 0; x < nframes; x++) { + if (ctx->is_ndp16) { + offset = le16_to_cpu(dpe.dpe16->wDatagramIndex); + len = le16_to_cpu(dpe.dpe16->wDatagramLength); + } else { + offset = le32_to_cpu(dpe.dpe32->dwDatagramIndex); + len = le32_to_cpu(dpe.dpe32->dwDatagramLength); + } /* * CDC NCM ch. 3.7 @@ -1561,10 +1789,19 @@ int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in) usbnet_skb_return(dev, skb); payload += len; /* count payload bytes in this NTB */ } + + if (ctx->is_ndp16) + dpe.dpe16++; + else + dpe.dpe32++; } err_ndp: /* are there more NDPs to process? */ - ndpoffset = le16_to_cpu(ndp16->wNextNdpIndex); + if (ctx->is_ndp16) + ndpoffset = le16_to_cpu(ndp.ndp16->wNextNdpIndex); + else + ndpoffset = le32_to_cpu(ndp.ndp32->dwNextNdpIndex); + if (ndpoffset && loopcount--) goto next_ndp; diff --git a/drivers/net/usb/huawei_cdc_ncm.c b/drivers/net/usb/huawei_cdc_ncm.c index e15a472c6a54..099d84827004 100644 --- a/drivers/net/usb/huawei_cdc_ncm.c +++ b/drivers/net/usb/huawei_cdc_ncm.c @@ -77,11 +77,11 @@ static int huawei_cdc_ncm_bind(struct usbnet *usbnet_dev, */ drvflags |= CDC_NCM_FLAG_NDP_TO_END; - /* Additionally, it has been reported that some Huawei E3372H devices, with - * firmware version 21.318.01.00.541, come out of reset in NTB32 format mode, hence - * needing to be set to the NTB16 one again. + /* For many Huawei devices the NTB32 mode is the default and the best mode + * they work with. Huawei E5785 and E5885 devices refuse to work in NTB16 mode at all. */ - drvflags |= CDC_NCM_FLAG_RESET_NTB16; + drvflags |= CDC_NCM_FLAG_PREFER_NTB32; + ret = cdc_ncm_bind_common(usbnet_dev, intf, 1, drvflags); if (ret) goto err; diff --git a/include/linux/usb/cdc_ncm.h b/include/linux/usb/cdc_ncm.h index 1646c06989df..0ce4377545f8 100644 --- a/include/linux/usb/cdc_ncm.h +++ b/include/linux/usb/cdc_ncm.h @@ -46,9 +46,12 @@ #define CDC_NCM_DATA_ALTSETTING_NCM 1 #define CDC_NCM_DATA_ALTSETTING_MBIM 2 -/* CDC NCM subclass 3.2.1 */ +/* CDC NCM subclass 3.3.1 */ #define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10 +/* CDC NCM subclass 3.3.2 */ +#define USB_CDC_NCM_NDP32_LENGTH_MIN 0x20 + /* Maximum NTB length */ #define CDC_NCM_NTB_MAX_SIZE_TX 32768 /* bytes */ #define CDC_NCM_NTB_MAX_SIZE_RX 32768 /* bytes */ @@ -84,7 +87,7 @@ /* Driver flags */ #define CDC_NCM_FLAG_NDP_TO_END 0x02 /* NDP is placed at end of frame */ #define CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE 0x04 /* Avoid altsetting toggle during init */ -#define CDC_NCM_FLAG_RESET_NTB16 0x08 /* set NDP16 one more time after altsetting switch */ +#define CDC_NCM_FLAG_PREFER_NTB32 0x08 /* prefer NDP32 over NDP16 */ #define cdc_ncm_comm_intf_is_mbim(x) ((x)->desc.bInterfaceSubClass == USB_CDC_SUBCLASS_MBIM && \ (x)->desc.bInterfaceProtocol == USB_CDC_PROTO_NONE) @@ -113,7 +116,11 @@ struct cdc_ncm_ctx { u32 timer_interval; u32 max_ndp_size; - struct usb_cdc_ncm_ndp16 *delayed_ndp16; + u8 is_ndp16; + union { + struct usb_cdc_ncm_ndp16 *delayed_ndp16; + struct usb_cdc_ncm_ndp32 *delayed_ndp32; + }; u32 tx_timer_pending; u32 tx_curr_frame_num; @@ -150,6 +157,8 @@ void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf); struct sk_buff *cdc_ncm_fill_tx_frame(struct usbnet *dev, struct sk_buff *skb, __le32 sign); int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in); int cdc_ncm_rx_verify_ndp16(struct sk_buff *skb_in, int ndpoffset); +int cdc_ncm_rx_verify_nth32(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in); +int cdc_ncm_rx_verify_ndp32(struct sk_buff *skb_in, int ndpoffset); struct sk_buff * cdc_ncm_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags); int cdc_ncm_rx_fixup(struct usbnet *dev, struct sk_buff *skb_in); -- 2.25.1
Please submit this formally, inline and not as an attachment, to netdev. Otherwise patchwork will not pick it up and it will thus not get tracked properly. Thank you.
Ok, done.
Best,
Alexander Bersenev
пт, 13 мар. 2020 г. в 23:21, David Miller <davem@davemloft.net>:
>
>
> Please submit this formally, inline and not as an attachment, to netdev.
> Otherwise patchwork will not pick it up and it will thus not get tracked
> properly.
>
> Thank you.
[-- Attachment #1: Type: text/plain, Size: 494 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) produced this warning: drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning: 'e1000e_check_me' defined but not used [-Wunused-function] static bool e1000e_check_me(u16 device_id) ^~~~~~~~~~~~~~~ Introduced by commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems") CONFIG_PM_SLEEP is not set for this build. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
> -----Original Message-----
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Sent: Monday, May 25, 2020 05:40
> To: David Miller <davem@davemloft.net>; Networking
> <netdev@vger.kernel.org>
> Cc: Linux Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel Mailing
> List <linux-kernel@vger.kernel.org>; Lifshits, Vitaly <vitaly.lifshits@intel.com>;
> Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> Subject: linux-next: build warning after merge of the net-next tree
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (sparc64
> defconfig) produced this warning:
>
> drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning: 'e1000e_check_me'
> defined but not used [-Wunused-function] static bool e1000e_check_me(u16
> device_id)
> ^~~~~~~~~~~~~~~
>
> Introduced by commit
>
> e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
>
> CONFIG_PM_SLEEP is not set for this build.
>
[Kirsher, Jeffrey T]
Vitaly informed me that he has a fix that he will be sending me, I will make sure to expedite it.
[-- Attachment #1: Type: text/plain, Size: 526 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:666:13: warning: 'cxgb4_uld_in_use' defined but not used [-Wunused-function] 666 | static bool cxgb4_uld_in_use(struct adapter *adap) | ^~~~~~~~~~~~~~~~ Introduced by commit a3ac249a1ab5 ("cxgb4/chcr: Enable ktls settings at run time") CONFIG_CHELSIO_TLS_DEVICE is not set for this build. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 684 bytes --] Hi all, On Tue, 2 Jun 2020 12:17:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > drivers/net/ethernet/chelsio/cxgb4/cxgb4_uld.c:666:13: warning: 'cxgb4_uld_in_use' defined but not used [-Wunused-function] > 666 | static bool cxgb4_uld_in_use(struct adapter *adap) > | ^~~~~~~~~~~~~~~~ > > Introduced by commit > > a3ac249a1ab5 ("cxgb4/chcr: Enable ktls settings at run time") > > CONFIG_CHELSIO_TLS_DEVICE is not set for this build. I am still getting this warning. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1349 bytes --] Hi all, On Wed, 27 May 2020 01:15:09 +0000 "Kirsher, Jeffrey T" <jeffrey.t.kirsher@intel.com> wrote: > > > -----Original Message----- > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Sent: Monday, May 25, 2020 05:40 > > To: David Miller <davem@davemloft.net>; Networking > > <netdev@vger.kernel.org> > > Cc: Linux Next Mailing List <linux-next@vger.kernel.org>; Linux Kernel Mailing > > List <linux-kernel@vger.kernel.org>; Lifshits, Vitaly <vitaly.lifshits@intel.com>; > > Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com> > > Subject: linux-next: build warning after merge of the net-next tree > > > > Hi all, > > > > After merging the net-next tree, today's linux-next build (sparc64 > > defconfig) produced this warning: > > > > drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning: 'e1000e_check_me' > > defined but not used [-Wunused-function] static bool e1000e_check_me(u16 > > device_id) > > ^~~~~~~~~~~~~~~ > > > > Introduced by commit > > > > e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems") > > > > CONFIG_PM_SLEEP is not set for this build. > > > [Kirsher, Jeffrey T] > > Vitaly informed me that he has a fix that he will be sending me, I will make sure to expedite it. I am still getting this warning. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
> -----Original Message-----
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Sent: Friday, June 12, 2020 18:16
> To: Kirsher, Jeffrey T <jeffrey.t.kirsher@intel.com>
> Cc: David Miller <davem@davemloft.net>; Networking
> <netdev@vger.kernel.org>; Linux Next Mailing List <linux-
> next@vger.kernel.org>; Linux Kernel Mailing List <linux-
> kernel@vger.kernel.org>; Lifshits, Vitaly <vitaly.lifshits@intel.com>
> Subject: Re: linux-next: build warning after merge of the net-next tree
>
> Hi all,
>
> On Wed, 27 May 2020 01:15:09 +0000 "Kirsher, Jeffrey T"
> <jeffrey.t.kirsher@intel.com> wrote:
> >
> > > -----Original Message-----
> > > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > > Sent: Monday, May 25, 2020 05:40
> > > To: David Miller <davem@davemloft.net>; Networking
> > > <netdev@vger.kernel.org>
> > > Cc: Linux Next Mailing List <linux-next@vger.kernel.org>; Linux
> > > Kernel Mailing List <linux-kernel@vger.kernel.org>; Lifshits, Vitaly
> > > <vitaly.lifshits@intel.com>; Kirsher, Jeffrey T
> > > <jeffrey.t.kirsher@intel.com>
> > > Subject: linux-next: build warning after merge of the net-next tree
> > >
> > > Hi all,
> > >
> > > After merging the net-next tree, today's linux-next build (sparc64
> > > defconfig) produced this warning:
> > >
> > > drivers/net/ethernet/intel/e1000e/netdev.c:137:13: warning:
> 'e1000e_check_me'
> > > defined but not used [-Wunused-function] static bool
> > > e1000e_check_me(u16
> > > device_id)
> > > ^~~~~~~~~~~~~~~
> > >
> > > Introduced by commit
> > >
> > > e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
> > > systems")
> > >
> > > CONFIG_PM_SLEEP is not set for this build.
> > >
> > [Kirsher, Jeffrey T]
> >
> > Vitaly informed me that he has a fix that he will be sending me, I will make
> sure to expedite it.
>
> I am still getting this warning.
I apologize, I have not seen a fix from Vitaly, that I am aware of. I will make sure you have a patch before Monday.
[-- Attachment #1: Type: text/plain, Size: 585 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) produced this warning: drivers/net/ethernet/sun/niu.c:9903:12: warning: 'niu_resume' defined but not used [-Wunused-function] static int niu_resume(struct device *dev_d) ^~~~~~~~~~ drivers/net/ethernet/sun/niu.c:9876:12: warning: 'niu_suspend' defined but not used [-Wunused-function] static int niu_suspend(struct device *dev_d) ^~~~~~~~~~~ Introduced by commit b0db0cc2f695 ("sun/niu: use generic power management") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Jul 7, 2020 at 12:36 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (sparc64 > defconfig) produced this warning: > > drivers/net/ethernet/sun/niu.c:9903:12: warning: 'niu_resume' defined but not used [-Wunused-function] > static int niu_resume(struct device *dev_d) > ^~~~~~~~~~ > drivers/net/ethernet/sun/niu.c:9876:12: warning: 'niu_suspend' defined but not used [-Wunused-function] > static int niu_suspend(struct device *dev_d) > ^~~~~~~~~~~ > > Introduced by commit > > b0db0cc2f695 ("sun/niu: use generic power management") This warning should not have come as the earlier definition of.suspend() and .resume(), they were not inside "#ifdef CONFIG_PM" container. Or any other container. Hence I thought adding the "__maybe_unused" attribute to them would be unnecessary. I am sending a patch to do the same. -- Vaibhav Gupta > > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 575 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: net/bridge/br_multicast.c: In function 'br_multicast_find_port': net/bridge/br_multicast.c:1818:21: warning: unused variable 'br' [-Wunused-variable] 1818 | struct net_bridge *br = mp->br; | ^~ Introduced by commit 0436862e417e ("net: bridge: mcast: support for IGMPv3/MLDv2 ALLOW_NEW_SOURCES report") Maybe turning mlock_dereference into a static inline function would help. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, 8 Sep 2020 13:00:00 +1000 Stephen Rothwell wrote:
> Hi all,
>
> After merging the net-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> net/bridge/br_multicast.c: In function 'br_multicast_find_port':
> net/bridge/br_multicast.c:1818:21: warning: unused variable 'br' [-Wunused-variable]
> 1818 | struct net_bridge *br = mp->br;
> | ^~
>
> Introduced by commit
>
> 0436862e417e ("net: bridge: mcast: support for IGMPv3/MLDv2 ALLOW_NEW_SOURCES report")
>
> Maybe turning mlock_dereference into a static inline function would help.
Or perhaps provide a better definition of whatever is making the
reference disappear? RCU_LOCKDEP_WARN()?
Thanks for the report!
[-- Attachment #1: Type: text/plain, Size: 351 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/index.rst:6: WARNING: toctree contains reference to nonexisting document 'networking/framerelay' Introduced by commit f73659192b0b ("net: wan: Delete the DLCI / SDLA drivers") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Nov 17, 2020 at 9:20 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/networking/index.rst:6: WARNING: toctree contains reference to nonexisting document 'networking/framerelay'
>
> Introduced by commit
>
> f73659192b0b ("net: wan: Delete the DLCI / SDLA drivers")
Thanks for reporting! I submitted another patch to remove the
reference to the deleted document. Thanks!
[-- Attachment #1: Type: text/plain, Size: 363 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/linux/phy.h:869: warning: Function parameter or member 'config_intr' not described in 'phy_driver' Introduced by commit 6527b938426f ("net: phy: remove the .did_interrupt() and .ack_interrupt() callback") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 499 bytes --] Hi all, On Thu, 26 Nov 2020 17:40:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (htmldocs) > produced this warning: > > include/linux/phy.h:869: warning: Function parameter or member 'config_intr' not described in 'phy_driver' > > Introduced by commit > > 6527b938426f ("net: phy: remove the .did_interrupt() and .ack_interrupt() callback") I am still getting this warning. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Dec 15, 2020 at 07:01:25AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 26 Nov 2020 17:40:57 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the net-next tree, today's linux-next build (htmldocs)
> > produced this warning:
> >
> > include/linux/phy.h:869: warning: Function parameter or member 'config_intr' not described in 'phy_driver'
> >
> > Introduced by commit
> >
> > 6527b938426f ("net: phy: remove the .did_interrupt() and .ack_interrupt() callback")
>
> I am still getting this warning.
Hi,
Sorry for not responding in time, I know I verified this the first time
but somehow did not answer the email.
The .config_intr() is documented but it seems that it's not parsed
properly since the comment starts on the same line as the /**. A diff
like below seems to do the trick. I will send it out.
--- a/include/linux/phy.h
+++ b/include/linux/phy.h
@@ -743,7 +743,8 @@ struct phy_driver {
/** @read_status: Determines the negotiated speed and duplex */
int (*read_status)(struct phy_device *phydev);
- /** @config_intr: Enables or disables interrupts.
+ /**
+ * @config_intr: Enables or disables interrupts.
* It should also clear any pending interrupts prior to enabling the
* IRQs and after disabling them.
*/
Ioana
[-- Attachment #1: Type: text/plain, Size: 660 bytes --] Hi all, After merging the net-next tree, yesterday's linux-next build (htmldocs) produced this warning: Documentation/networking/filter.rst:1053: WARNING: Inline emphasis start-string without end-string. Documentation/networking/filter.rst:1053: WARNING: Inline emphasis start-string without end-string. Documentation/networking/filter.rst:1053: WARNING: Inline emphasis start-string without end-string. Documentation/networking/filter.rst:1053: WARNING: Inline emphasis start-string without end-string. Introduced by commit 91c960b00566 ("bpf: Rename BPF_XADD and prepare to encode other atomics in .imm") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 364 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst:16: WARNING: Unknown target name: "mlx5 port function". Introduced by commit 142d93d12dc1 ("net/mlx5: Add devlink subfunction port documentation") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 334 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/switchdev.rst:482: WARNING: Unexpected indentation. Introduced by commit 0f22ad45f47c ("Documentation: networking: switchdev: clarify device driver behavior") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 440 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/dsa/dsa.rst:468: WARNING: Unexpected indentation. Documentation/networking/dsa/dsa.rst:477: WARNING: Block quote ends without a blank line; unexpected unindent. Introduced by commit 8411abbcad8e ("Documentation: networking: dsa: mention integration with devlink") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 498 bytes --] Hi all, After merging the net-next tree, today's linux-next build (sparc64 defconfig) produced this warning: drivers/net/ethernet/intel/e1000e/netdev.c:6926:12: warning: 'e1000e_pm_prepare' defined but not used [-Wunused-function] static int e1000e_pm_prepare(struct device *dev) ^~~~~~~~~~~~~~~~~ Introduced by commit ccf8b940e5fd ("e1000e: Leverage direct_complete to speed up s2ram") CONFIG_PM_SLEEP is not set for this build. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hi Stephen, On Wed, Mar 17, 2021 at 06:56:05PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (sparc64 > defconfig) produced this warning: > > drivers/net/ethernet/intel/e1000e/netdev.c:6926:12: warning: 'e1000e_pm_prepare' defined but not used [-Wunused-function] > static int e1000e_pm_prepare(struct device *dev) > ^~~~~~~~~~~~~~~~~ > > Introduced by commit > > ccf8b940e5fd ("e1000e: Leverage direct_complete to speed up s2ram") > > CONFIG_PM_SLEEP is not set for this build. > Thanks for reporting. I think we need to add the '__maybe_unused' attribute as in case CONFIG_PM_SLEEP is not set. Tony, it seems that the original v1 patch should eliminate this warning, could you please help double check and apply that version? thanks, Chenyu > -- > Cheers, > Stephen Rothwell
[-- Attachment #1: Type: text/plain, Size: 365 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: net/tipc/subscr.h:73: warning: Function parameter or member 's' not described in 'tipc_subscription' Introduced by commit 429189acac53 ("tipc: add host-endian copy of user subscription to struct tipc_subscription") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 333 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/linux/netdevice.h:2191: warning: Function parameter or member 'dev_refcnt' not described in 'net_device' Introduced by commit 919067cc845f ("net: add CONFIG_PCPU_DEV_REFCNT") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 421 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Sphinx parallel build error: docutils.utils.SystemMessage: /home/sfr/next/next/Documentation/networking/nf_flowtable.rst:176: (SEVERE/4) Unexpected section title. } ... Introduced by commit 143490cde566 ("docs: nf_flowtable: update documentation with enhancements") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 631 bytes --] Hi all, On Thu, 25 Mar 2021 17:23:50 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (htmldocs) > produced this warning: > > Sphinx parallel build error: > docutils.utils.SystemMessage: /home/sfr/next/next/Documentation/networking/nf_flowtable.rst:176: (SEVERE/4) Unexpected section title. > > } > ... > > Introduced by commit > > 143490cde566 ("docs: nf_flowtable: update documentation with enhancements") This is actually a build error and fails the htmldocs build - well, actually causes it to hang. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 347 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: net/tipc/bearer.c:248: warning: Function parameter or member 'extack' not described in 'tipc_enable_bearer' Introduced by commit b83e214b2e04 ("tipc: add extack messages for bearer/media failure") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 750 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string': drivers/net/ethernet/ibm/ibmvnic.c:855:2: warning: enumeration value 'VNIC_DOWN' not handled in switch [-Wswitch] 855 | switch (state) { | ^~~~~~ drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string': drivers/net/ethernet/ibm/ibmvnic.c:1958:2: warning: enumeration value 'VNIC_RESET_PASSIVE_INIT' not handled in switch [-Wswitch] 1958 | switch (reason) { | ^~~~~~ Introduced by commit 53f8b1b25419 ("ibmvnic: Allow device probe if the device is not ready at boot") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Jun 10, 2021 at 10:26 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > drivers/net/ethernet/ibm/ibmvnic.c: In function 'adapter_state_to_string': > drivers/net/ethernet/ibm/ibmvnic.c:855:2: warning: enumeration value 'VNIC_DOWN' not handled in switch [-Wswitch] > 855 | switch (state) { > | ^~~~~~ > drivers/net/ethernet/ibm/ibmvnic.c: In function 'reset_reason_to_string': > drivers/net/ethernet/ibm/ibmvnic.c:1958:2: warning: enumeration value 'VNIC_RESET_PASSIVE_INIT' not handled in switch [-Wswitch] > 1958 | switch (reason) { > | ^~~~~~ > > Introduced by commit > > 53f8b1b25419 ("ibmvnic: Allow device probe if the device is not ready at boot") > > -- > Cheers, > Stephen Rothwell https://lore.kernel.org/netdev/20210611153537.83420-1-lijunp213@gmail.com/T/#u Thanks, Lijun
[-- Attachment #1: Type: text/plain, Size: 521 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/devlink/prestera.rst:3: WARNING: Title overline too short. ===================== prestera devlink support ===================== Documentation/networking/devlink/prestera.rst: WARNING: document isn't included in any toctree Introduced by commit 66826c43e63d ("documentation: networking: devlink: add prestera switched driver Documentation") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 347 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: drivers/net/phy/phy-c45.c:624: warning: Function parameter or member 'enable' not described in 'genphy_c45_fast_retrain' Introduced by commit 63c67f526db8 ("net: phy: add genphy_c45_fast_retrain") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 431 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/linux/phylink.h:82: warning: Function parameter or member 'DECLARE_PHY_INTERFACE_MASK(supported_interfaces' not described in 'phylink_config' Introduced by commit 38c310eb46f5 ("net: phylink: add MAC phy_interface_t bitmap") Or maybe this is a problem with the tool ... -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Wed, Oct 27, 2021 at 10:07:21PM +1100, Stephen Rothwell wrote: > Hi all, > > After merging the net-next tree, today's linux-next build (htmldocs) > produced this warning: > > include/linux/phylink.h:82: warning: Function parameter or member 'DECLARE_PHY_INTERFACE_MASK(supported_interfaces' not described in 'phylink_config' > > Introduced by commit > > 38c310eb46f5 ("net: phylink: add MAC phy_interface_t bitmap") > > Or maybe this is a problem with the tool ... Hmm. Looks like it is a tooling problem. * @supported_interfaces: bitmap describing which PHY_INTERFACE_MODE_xxx * are supported by the MAC/PCS. DECLARE_PHY_INTERFACE_MASK(supported_interfaces); I'm guessing the tool doesn't use the preprocessed source. I'm not sure what the solution to this would be. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On 10/27/21 4:34 AM, Russell King (Oracle) wrote:
> On Wed, Oct 27, 2021 at 10:07:21PM +1100, Stephen Rothwell wrote:
>> Hi all,
>>
>> After merging the net-next tree, today's linux-next build (htmldocs)
>> produced this warning:
>>
>> include/linux/phylink.h:82: warning: Function parameter or member 'DECLARE_PHY_INTERFACE_MASK(supported_interfaces' not described in 'phylink_config'
>>
>> Introduced by commit
>>
>> 38c310eb46f5 ("net: phylink: add MAC phy_interface_t bitmap")
>>
>> Or maybe this is a problem with the tool ...
>
> Hmm. Looks like it is a tooling problem.
>
> * @supported_interfaces: bitmap describing which PHY_INTERFACE_MODE_xxx
> * are supported by the MAC/PCS.
>
> DECLARE_PHY_INTERFACE_MASK(supported_interfaces);
>
> I'm guessing the tool doesn't use the preprocessed source. I'm not sure
> what the solution to this would be.
>
I just sent a patch to scripts/kernel-doc to support that macro.
--
~Randy
[-- Attachment #1: Type: text/plain, Size: 344 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/linux/skbuff.h:953: warning: Function parameter or member 'll_node' not described in 'sk_buff' Introduced by commit f35f821935d8 ("tcp: defer skb freeing after socket lock is released") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 340 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/net/sock.h:540: warning: Function parameter or member 'defer_list' not described in 'sock' Introduced by commit f35f821935d8 ("tcp: defer skb freeing after socket lock is released") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, Nov 16, 2021 at 6:55 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/net/sock.h:540: warning: Function parameter or member 'defer_list' not described in 'sock'
>
> Introduced by commit
>
> f35f821935d8 ("tcp: defer skb freeing after socket lock is released")
>
> --
> Cheers,
> Stephen Rothwell
Thanks for the report, I thought we got rid of these htmldocs for sock already.
[-- Attachment #1: Type: text/plain, Size: 890 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/devlink/mlx5.rst:13: WARNING: Error parsing content block for the "list-table" directive: uniform two-level bullet list expected, but row 2 does not contain the same number of items as row 1 (2 vs 3). .. list-table:: Generic parameters implemented * - Name - Mode - Validation * - ``enable_roce`` - driverinit * - ``io_eq_size`` - driverinit - The range is between 64 and 4096. * - ``event_eq_size`` - driverinit - The range is between 64 and 4096. * - ``max_macs`` - driverinit - The range is between 1 and 2^31. Only power of 2 values are supported. Introduced by commit 0844fa5f7b89 ("net/mlx5: Let user configure io_eq_size param") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Fri, Jan 07, 2022 at 02:57:49AM +1100, Stephen Rothwell wrote: >Hi all, > >After merging the net-next tree, today's linux-next build (htmldocs) >produced this warning: > >Documentation/networking/devlink/mlx5.rst:13: WARNING: Error parsing content block for the "list-table" directive: uniform two-level bullet list expected, but row 2 does not contain the same number of items as row 1 (2 vs 3). > ... >Introduced by commit > > 0844fa5f7b89 ("net/mlx5: Let user configure io_eq_size param") > Thanks for the report, I just submitted a fix to net-next.
[-- Attachment #1: Type: text/plain, Size: 341 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/linux/netdevice.h:2290: warning: Function parameter or member 'dm_private' not described in 'net_device' Introduced by commit b26ef81c46ed ("drop_monitor: remove quadratic behavior") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 338 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/smc-sysctl.rst:3: WARNING: Title overline too short. ========= SMC Sysctl ========= Introduced by commit 12bbb0d163a9 ("net/smc: add sysctl for autocorking") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 548 bytes --] Hi all, On Thu, 3 Mar 2022 20:13:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (htmldocs) > produced this warning: > > Documentation/networking/smc-sysctl.rst:3: WARNING: Title overline too short. > > ========= > SMC Sysctl > ========= > > Introduced by commit > > 12bbb0d163a9 ("net/smc: add sysctl for autocorking") Also: Documentation/networking/smc-sysctl.rst: WARNING: document isn't included in any toctree -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, Mar 03, 2022 at 08:15:36PM +1100, Stephen Rothwell wrote:
>Hi all,
>
>On Thu, 3 Mar 2022 20:13:52 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> After merging the net-next tree, today's linux-next build (htmldocs)
>> produced this warning:
>>
>> Documentation/networking/smc-sysctl.rst:3: WARNING: Title overline too short.
>>
>> =========
>> SMC Sysctl
>> =========
>>
>> Introduced by commit
>>
>> 12bbb0d163a9 ("net/smc: add sysctl for autocorking")
>
>Also:
>
>Documentation/networking/smc-sysctl.rst: WARNING: document isn't included in any toctree
Thanks for your reminder ! I'll send a patch to fix this warnings soon.
[-- Attachment #1: Type: text/plain, Size: 367 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst: WARNING: document isn't included in any toctree Introduced by commit c3a0addefbde ("docs: ctucanfd: CTU CAN FD open-source IP core documentation.") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Hello Stephen, thanks for the notice. On Thursday 21 of April 2022 09:07:49 Stephen Rothwell wrote: > After merging the net-next tree, today's linux-next build (htmldocs) > produced this warning: > > Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst: > WARNING: document isn't included in any toctree > > Introduced by commit > > c3a0addefbde ("docs: ctucanfd: CTU CAN FD open-source IP core > documentation.") I would be happy for suggestion for reference location. Is the next file right location Documentation/networking/device_drivers/can/index.rst for reference to Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst It is documentation of the driver for CAN FD open-source IP core developed by the group formed at Czech Technical University. I have probably minor updates for the links to the external resources, AXI, APB and other documentation because it moves from site to site under Intel, ARM, Xilinx web sites hierarchies. Best wishes, Pavel -- Pavel Pisa phone: +420 603531357 e-mail: pisa@cmp.felk.cvut.cz Department of Control Engineering FEE CVUT Karlovo namesti 13, 121 35, Prague 2 university: http://control.fel.cvut.cz/ personal: http://cmp.felk.cvut.cz/~pisa projects: https://www.openhub.net/accounts/ppisa CAN related:http://canbus.pages.fel.cvut.cz/ Open Technologies Research Education and Exchange Services https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home
[-- Attachment #1: Type: text/plain, Size: 1067 bytes --] On 21.04.2022 09:29:46, Pavel Pisa wrote: > On Thursday 21 of April 2022 09:07:49 Stephen Rothwell wrote: > > After merging the net-next tree, today's linux-next build (htmldocs) > > produced this warning: > > > > Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst: > > WARNING: document isn't included in any toctree > > > > Introduced by commit > > > > c3a0addefbde ("docs: ctucanfd: CTU CAN FD open-source IP core > > documentation.") > > I would be happy for suggestion for reference location. > > Is the next file right location > > Documentation/networking/device_drivers/can/index.rst > > for reference to > > Documentation/networking/device_drivers/can/ctu/ctucanfd-driver.rst Feel free to send a patch. I'm happy to take it. Marc -- Pengutronix e.K. | Marc Kleine-Budde | Embedded Linux | https://www.pengutronix.de | Vertretung West/Dortmund | Phone: +49-231-2826-924 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 632 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/kapi:92: net/core/dev.c:4101: WARNING: Missing matching underline for section title overline. ----------------------------------------------------------------------------------- I notice this method can also return errors from the queue disciplines, including NET_XMIT_DROP, which is a positive value. So, errors can also Introduced by commit c526fd8f9f4f ("net: inline dev_queue_xmit()") I am not sure why this has turned up just now. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 483 bytes --] Hi all, After merging the net-next tree, today's linux-next build (powerpc ppc64_defconfig) produced this warning: net/netfilter/nf_conntrack_netlink.c:1717:12: warning: 'ctnetlink_dump_one_entry' defined but not used [-Wunused-function] 1717 | static int ctnetlink_dump_one_entry(struct sk_buff *skb, | ^~~~~~~~~~~~~~~~~~~~~~~~ Introduced by commit 8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --] Hi all, On Tue, 17 May 2022 11:03:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > After merging the net-next tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > net/netfilter/nf_conntrack_netlink.c:1717:12: warning: 'ctnetlink_dump_one_entry' defined but not used [-Wunused-function] > 1717 | static int ctnetlink_dump_one_entry(struct sk_buff *skb, > | ^~~~~~~~~~~~~~~~~~~~~~~~ > > Introduced by commit > > 8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list") So for my i386 defconfig build this became on error, so I have applied the following patch for today. From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Tue, 17 May 2022 18:58:43 +1000 Subject: [PATCH] fix up for "netfilter: conntrack: remove unconfirmed list" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- net/netfilter/nf_conntrack_netlink.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c index e768f59741a6..722af5e309ba 100644 --- a/net/netfilter/nf_conntrack_netlink.c +++ b/net/netfilter/nf_conntrack_netlink.c @@ -1714,6 +1714,7 @@ static int ctnetlink_done_list(struct netlink_callback *cb) return 0; } +#ifdef CONFIG_NF_CONNTRACK_EVENTS static int ctnetlink_dump_one_entry(struct sk_buff *skb, struct netlink_callback *cb, struct nf_conn *ct, @@ -1754,6 +1755,7 @@ static int ctnetlink_dump_one_entry(struct sk_buff *skb, return res; } +#endif static int ctnetlink_dump_unconfirmed(struct sk_buff *skb, struct netlink_callback *cb) -- 2.35.1 -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Tue, 17 May 2022 11:03:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) produced this warning:
> >
> > net/netfilter/nf_conntrack_netlink.c:1717:12: warning: 'ctnetlink_dump_one_entry' defined but not used [-Wunused-function]
> > 1717 | static int ctnetlink_dump_one_entry(struct sk_buff *skb,
> > | ^~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Introduced by commit
> >
> > 8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list")
>
> So for my i386 defconfig build this became on error, so I have applied
> the following patch for today.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 17 May 2022 18:58:43 +1000
> Subject: [PATCH] fix up for "netfilter: conntrack: remove unconfirmed list"
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Thanks Stephen.
Acked-by: Florian Westphal <fw@strlen.de>
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --] Hi all, On Tue, 17 May 2022 13:25:32 +0200 Florian Westphal <fw@strlen.de> wrote: > > Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > On Tue, 17 May 2022 11:03:03 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > > > > > After merging the net-next tree, today's linux-next build (powerpc > > > ppc64_defconfig) produced this warning: > > > > > > net/netfilter/nf_conntrack_netlink.c:1717:12: warning: 'ctnetlink_dump_one_entry' defined but not used [-Wunused-function] > > > 1717 | static int ctnetlink_dump_one_entry(struct sk_buff *skb, > > > | ^~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > Introduced by commit > > > > > > 8a75a2c17410 ("netfilter: conntrack: remove unconfirmed list") > > > > So for my i386 defconfig build this became on error, so I have applied > > the following patch for today. > > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > Date: Tue, 17 May 2022 18:58:43 +1000 > > Subject: [PATCH] fix up for "netfilter: conntrack: remove unconfirmed list" > > > > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> > > Thanks Stephen. > > Acked-by: Florian Westphal <fw@strlen.de> This is still not fixed in the net-next (or the netfilter-next) tree. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 993 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/admin-guide/sysctl/net.rst:37: WARNING: Malformed table. Text in column margin in table line 4. ========= =================== = ========== ================== Directory Content Directory Content ========= =================== = ========== ================== 802 E802 protocol mptcp Multipath TCP appletalk Appletalk protocol netfilter Network Filter ax25 AX25 netrom NET/ROM bridge Bridging rose X.25 PLP layer core General parameter tipc TIPC ethernet Ethernet protocol unix Unix domain sockets ipv4 IP version 4 x25 X.25 protocol ipv6 IP version 6 ========= =================== = ========== ================== Introduced by commit 1202cdd66531 ("Remove DECnet support from kernel") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 526 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/kapi:26: net/core/skbuff.c:780: WARNING: Error in declarator or parameters Invalid C declaration: Expecting "(" in parameters. [error at 19] void __fix_address kfree_skb_reason (struct sk_buff *skb, enum skb_drop_reason reason) -------------------^ Introduced by commit c205cc7534a9 ("net: skb: prevent the split of kfree_skb_reason() by gcc") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 361 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/devlink/etas_es58x.rst: WARNING: document isn't included in any toctree Introduced by commit 9f63f96aac92 ("Documentation: devlink: add devlink documentation for the etas_es58x driver") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 387 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/device_drivers/ethernet/amazon/ena.rst:209: WARNING: Explicit markup ends without a blank line; unexpected unindent. Introduced by commit f7d625adeb7b ("net: ena: Add dynamic recycling mechanism for rx buffers") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
> Hi all,
>
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/networking/device_drivers/ethernet/amazon/ena.rst:209:
> WARNING: Explicit markup ends without a blank line; unexpected unindent.
>
> Introduced by commit
>
> f7d625adeb7b ("net: ena: Add dynamic recycling mechanism for rx buffers")
>
> --
> Cheers,
> Stephen Rothwell
Thank you for highlighting this, we're working on a patch to resolve the warning.
Thanks,
David
[-- Attachment #1: Type: text/plain, Size: 364 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/linux/netdevice.h:2415: warning: Function parameter or member 'xdp_zc_max_segs' not described in 'net_device' Introduced by commit 13ce2daa259a ("xsk: add new netlink attribute dedicated for ZC max frags") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 344 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/userspace-api/netlink/netlink-raw.rst:14: WARNING: undefined label: 'classic_netlink' Introduced by commit 2db8abf0b455 ("doc/netlink: Document the netlink-raw schema extensions") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, 29 Aug 2023 at 05:20, Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > Hi all, > > After merging the net-next tree, today's linux-next build (htmldocs) > produced this warning: > > Documentation/userspace-api/netlink/netlink-raw.rst:14: WARNING: undefined label: 'classic_netlink' > > Introduced by commit > > 2db8abf0b455 ("doc/netlink: Document the netlink-raw schema extensions") Apologies, I seem to have missed the following change between v2 and v3 of the patchset. I'll send a patch to fix it. diff --git a/Documentation/userspace-api/netlink/intro.rst b/Documentation/userspace-api/netlink/intro.rst index 0955e9f203d3..3ea70ad53c58 100644 --- a/Documentation/userspace-api/netlink/intro.rst +++ b/Documentation/userspace-api/netlink/intro.rst @@ -528,6 +528,8 @@ families may, however, require a larger buffer. 32kB buffer is recommended for most efficient handling of dumps (larger buffer fits more dumped objects and therefore fewer recvmsg() calls are needed). +.. _classic_netlink: + Classic Netlink ===============
[-- Attachment #1: Type: text/plain, Size: 374 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: include/net/page_pool/types.h:73: warning: Function parameter or member 'STRUCT_GROUP(' not described in 'page_pool_params' Introduced by commit 5027ec19f104 ("net: page_pool: split the page_pool_params into fast and slow") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Thu, 23 Nov 2023 13:45:45 +1100 Stephen Rothwell wrote:
> include/net/page_pool/types.h:73: warning: Function parameter or member 'STRUCT_GROUP(' not described in 'page_pool_params'
Yes, sorry, the script is confused when group contains only private
fields. I'll add a public field there any day now (tm) so the warning
will go away.
[-- Attachment #1: Type: text/plain, Size: 747 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/core-api/kernel-api:90: include/linux/bitmap.h:524: ERROR: Unexpected indentation. Documentation/core-api/kernel-api:90: include/linux/bitmap.h:524: CRITICAL: Unexpected section title or transition. |||||| WARNING: kernel-doc 'scripts/kernel-doc -rst -enable-lineno -sphinx-version 7.2.6 -internal include/linux/bitmap.h' processing failed with: Documentation/core-api/kernel-api:90: include/linux/bitmap.h:524: (SEVERE/4) Unexpected section title or transition. |||||| Introduced by commit de5f84338970 ("lib/bitmap: Introduce bitmap_scatter() and bitmap_gather() helpers") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #1: Type: text/plain, Size: 413 bytes --] Hi all, After merging the net-next tree, today's linux-next build (htmldocs) produced this warning: Documentation/networking/multi-pf-netdev.rst:94: ERROR: Unexpected indentation. Documentation/networking/multi-pf-netdev.rst:106: ERROR: Unexpected indentation. Introduced by commit 77d9ec3f6c8c ("Documentation: networking: Add description for multi-pf netdev") -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]
On Tue, 12 Mar 2024 15:33:04 +1100 Stephen Rothwell wrote:
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/networking/multi-pf-netdev.rst:94: ERROR: Unexpected indentation.
> Documentation/networking/multi-pf-netdev.rst:106: ERROR: Unexpected indentation.
Sorry to ask basic questions during the merge window, but what version
of sphinx do you use? The warnings generated seem to depend rather
heavily on the version :(
[-- Attachment #1: Type: text/plain, Size: 759 bytes --] Hi Jakub, On Tue, 12 Mar 2024 07:45:37 -0700 Jakub Kicinski <kuba@kernel.org> wrote: > > On Tue, 12 Mar 2024 15:33:04 +1100 Stephen Rothwell wrote: > > After merging the net-next tree, today's linux-next build (htmldocs) > > produced this warning: > > > > Documentation/networking/multi-pf-netdev.rst:94: ERROR: Unexpected indentation. > > Documentation/networking/multi-pf-netdev.rst:106: ERROR: Unexpected indentation. > > Sorry to ask basic questions during the merge window, but what version > of sphinx do you use? The warnings generated seem to depend rather > heavily on the version :( Currently I am using version 7.2.6. I update it occasionally when a new version appears in Debian Testing. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --]