* linux-next: Fixes tag needs some work in the net tree
From: Stephen Rothwell @ 2019-08-11 21:33 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Roman Mashak
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
Hi all,
In commit
e1fea322fc6d ("net sched: update skbedit action for batched events operations")
Fixes tag
Fixes: ca9b0e27e ("pkt_action: add new action skbedit")
has these problem(s):
- SHA1 should be at least 12 digits long
This Can be fixed for the future by setting core.abbrev to 12 (or
more) or (for git v2.11 or later) just making sure it is not set
(or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] dpaa2-ethsw: move the DPAA2 Ethernet Switch driver out of staging
From: Ioana Ciornei @ 2019-08-11 21:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: davem@davemloft.net, gregkh@linuxfoundation.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
f.fainelli@gmail.com, Ioana Ciocoi Radulescu
In-Reply-To: <20190811032235.GK30120@lunn.ch>
On 8/11/19 6:22 AM, Andrew Lunn wrote:
> Hi Ioana
>
>> >> + struct ethsw_port_priv *port_priv = netdev_priv(netdev);
>> >> + struct ethsw_core *ethsw = port_priv->ethsw_data;
>> >> + int i, err;
>> >> +
>> >> + for (i = 0; i < ethsw->sw_attr.num_ifs; i++)
>> >> + if (ethsw->ports[i]->bridge_dev &&
>> >> + (ethsw->ports[i]->bridge_dev != upper_dev)) {
>> >> + netdev_err(netdev,
>> >> + "Another switch port is connected to %s\n",
>> >> + ethsw->ports[i]->bridge_dev->name);
>> >> + return -EINVAL;
>> >> + }
>> >
>> > Am i reading this correct? You only support a single bridge? The
>> > error message is not very informative. Also, i think you should be
>> > returning EOPNOTSUPP, indicating the offload is not possible. Linux
>> > will then do it in software. If it could actually receive/transmit the
>> > frames....
>> >
>>
>> Yes, we only support a single bridge.
>
> That is a pretty severe restriction for a device of this class. Some
> of the very simple switches DSA support have a similar restriction,
> but in general, most do support multiple bridges.
>
Let me make a distinction here: we do no support multiple bridges on the
same DPSW object but we do support multiple DPSW objects, each with its
bridge.
> Are there any plans to fix this?
>
We had some internal discussions on this, the hardware could support
this kind of further partitioning the switch object but, at the moment,
the firmware doesn't.
> Thanks
> Andrew
>
^ permalink raw reply
* Re: [PATCH] net: ixgbe: fix memory leaks
From: Alexander Duyck @ 2019-08-11 20:22 UTC (permalink / raw)
To: Wenwen Wang
Cc: Jeff Kirsher, David S. Miller,
moderated list:INTEL ETHERNET DRIVERS,
open list:NETWORKING DRIVERS, open list, Amritha Nambiar
In-Reply-To: <1565554067-4994-1-git-send-email-wenwen@cs.uga.edu>
On Sun, Aug 11, 2019 at 1:08 PM Wenwen Wang <wenwen@cs.uga.edu> wrote:
>
> In ixgbe_configure_clsu32(), 'jump', 'input', and 'mask' are allocated
> through kzalloc() respectively in a for loop body. Then,
> ixgbe_clsu32_build_input() is invoked to build the input. If this process
> fails, next iteration of the for loop will be executed. However, the
> allocated 'jump', 'input', and 'mask' are not deallocated on this execution
> path, leading to memory leaks.
>
> Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index cbaf712..6b7ea87 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -9490,6 +9490,10 @@ static int ixgbe_configure_clsu32(struct ixgbe_adapter *adapter,
> jump->mat = nexthdr[i].jump;
> adapter->jump_tables[link_uhtid] = jump;
> break;
> + } else {
> + kfree(mask);
> + kfree(input);
> + kfree(jump);
> }
> }
> return 0;
So I think this fix is still missing a good chunk of the exception
handling it should have. Specifically we will end up failing and then
trying to allocate for the next rule. It seems like we should probably
stop trying to program rules and unwind the work we have already done.
Also it would probably make sense to return an error if we are unable
to program one of the rules into the hardware. Otherwise things will
fail and the user will never know why.
^ permalink raw reply
* [PATCH v3] tipc: initialise addr_trail_end when setting node addresses
From: Chris Packham @ 2019-08-11 20:18 UTC (permalink / raw)
To: jon.maloy, ying.xue, davem
Cc: netdev, tipc-discussion, linux-kernel, Chris Packham
We set the field 'addr_trial_end' to 'jiffies', instead of the current
value 0, at the moment the node address is initialized. This guarantees
we don't inadvertently enter an address trial period when the node
address is explicitly set by the user.
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Acked-by: Jon Maloy <jon.maloy@ericsson.com>
---
Notes:
Changes in v3:
- Reword commit message as suggested
- Include acl from Jon
Changes in v2:
- move setting to tipc_set_node_addr() as suggested
- reword commit message
net/tipc/addr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/addr.c b/net/tipc/addr.c
index b88d48d00913..0f1eaed1bd1b 100644
--- a/net/tipc/addr.c
+++ b/net/tipc/addr.c
@@ -75,6 +75,7 @@ void tipc_set_node_addr(struct net *net, u32 addr)
tipc_set_node_id(net, node_id);
}
tn->trial_addr = addr;
+ tn->addr_trial_end = jiffies;
pr_info("32-bit node address hash set to %x\n", addr);
}
--
2.22.0
^ permalink raw reply related
* [PATCH] net: ixgbe: fix memory leaks
From: Wenwen Wang @ 2019-08-11 20:07 UTC (permalink / raw)
To: Wenwen Wang
Cc: Jeff Kirsher, David S. Miller,
moderated list:INTEL ETHERNET DRIVERS,
open list:NETWORKING DRIVERS, open list
In ixgbe_configure_clsu32(), 'jump', 'input', and 'mask' are allocated
through kzalloc() respectively in a for loop body. Then,
ixgbe_clsu32_build_input() is invoked to build the input. If this process
fails, next iteration of the for loop will be executed. However, the
allocated 'jump', 'input', and 'mask' are not deallocated on this execution
path, leading to memory leaks.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index cbaf712..6b7ea87 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -9490,6 +9490,10 @@ static int ixgbe_configure_clsu32(struct ixgbe_adapter *adapter,
jump->mat = nexthdr[i].jump;
adapter->jump_tables[link_uhtid] = jump;
break;
+ } else {
+ kfree(mask);
+ kfree(input);
+ kfree(jump);
}
}
return 0;
--
2.7.4
^ permalink raw reply related
* pull-request: bpf 2019-08-11
From: Daniel Borkmann @ 2019-08-11 19:58 UTC (permalink / raw)
To: davem; +Cc: daniel, ast, netdev, bpf
Hi David,
The following pull-request contains BPF updates for your *net* tree.
The main changes are:
1) x64 JIT code generation fix for backward-jumps to 1st insn, from Alexei.
2) Fix buggy multi-closing of BTF file descriptor in libbpf, from Andrii.
3) Fix libbpf_num_possible_cpus() to make it thread safe, from Takshak.
4) Fix bpftool to dump an error if pinning fails, from Jakub.
Please consider pulling these changes from:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
Thanks a lot!
----------------------------------------------------------------
The following changes since commit 0a062ba725cdad3b167782179ee914a8402a0184:
Merge tag 'mlx5-fixes-2019-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux (2019-07-26 14:26:41 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git
for you to fetch changes up to 4f7aafd78aeaf18a4f6dea9415df60e745c9dfa7:
Merge branch 'bpf-bpftool-pinning-error-msg' (2019-08-09 17:38:53 +0200)
----------------------------------------------------------------
Alexei Starovoitov (2):
bpf: fix x64 JIT code generation for jmp to 1st insn
selftests/bpf: tests for jmp to 1st insn
Andrii Nakryiko (2):
libbpf: fix erroneous multi-closing of BTF FD
libbpf: set BTF FD for prog only when there is supported .BTF.ext data
Daniel Borkmann (1):
Merge branch 'bpf-bpftool-pinning-error-msg'
Jakub Kicinski (2):
tools: bpftool: fix error message (prog -> object)
tools: bpftool: add error message on pin failure
Takshak Chahande (1):
libbpf : make libbpf_num_possible_cpus function thread safe
arch/x86/net/bpf_jit_comp.c | 9 ++++----
tools/bpf/bpftool/common.c | 8 +++++--
tools/lib/bpf/libbpf.c | 33 +++++++++++++++------------
tools/testing/selftests/bpf/verifier/loops1.c | 28 +++++++++++++++++++++++
4 files changed, 57 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [PATCH net-next v2 00/10] drop_monitor: Capture dropped packets and metadata
From: David Miller @ 2019-08-11 18:57 UTC (permalink / raw)
To: idosch
Cc: netdev, nhorman, jiri, toke, dsahern, roopa, nikolay,
jakub.kicinski, andy, f.fainelli, andrew, vivien.didelot, mlxsw,
idosch
In-Reply-To: <20190811073555.27068-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Sun, 11 Aug 2019 10:35:45 +0300
> From: Ido Schimmel <idosch@mellanox.com>
>
> So far drop monitor supported only one mode of operation in which a
> summary of recent packet drops is periodically sent to user space as a
> netlink event. The event only includes the drop location (program
> counter) and number of drops in the last interval.
>
> While this mode of operation allows one to understand if the system is
> dropping packets, it is not sufficient if a more detailed analysis is
> required. Both the packet itself and related metadata are missing.
>
> This patchset extends drop monitor with another mode of operation where
> the packet - potentially truncated - and metadata (e.g., drop location,
> timestamp, netdev) are sent to user space as a netlink event. Thanks to
> the extensible nature of netlink, more metadata can be added in the
> future.
...
Series applied.
^ permalink raw reply
* Re: [PATCH net v3] net: dsa: Check existence of .port_mdb_add callback before calling it
From: Vivien Didelot @ 2019-08-11 18:27 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Andrew Lunn, Florian Fainelli, David S. Miller, Chen-Yu Tsai,
netdev, linux-kernel
In-Reply-To: <20190811141825.11566-1-wens@kernel.org>
Hi Chen-Yu,
On Sun, 11 Aug 2019 22:18:25 +0800, Chen-Yu Tsai <wens@kernel.org> wrote:
> From: Chen-Yu Tsai <wens@csie.org>
>
> The dsa framework has optional .port_mdb_{prepare,add,del} callback fields
> for drivers to handle multicast database entries. When adding an entry, the
> framework goes through a prepare phase, then a commit phase. Drivers not
> providing these callbacks should be detected in the prepare phase.
>
> DSA core may still bypass the bridge layer and call the dsa_port_mdb_add
> function directly with no prepare phase or no switchdev trans object,
> and the framework ends up calling an undefined .port_mdb_add callback.
> This results in a NULL pointer dereference, as shown in the log below.
>
> The other functions seem to be properly guarded. Do the same for
> .port_mdb_add in dsa_switch_mdb_add_bitmap() as well.
>
> 8<--- cut here ---
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = (ptrval)
> [00000000] *pgd=00000000
> Internal error: Oops: 80000005 [#1] SMP ARM
> Modules linked in: rtl8xxxu rtl8192cu rtl_usb rtl8192c_common rtlwifi mac80211 cfg80211
> CPU: 1 PID: 134 Comm: kworker/1:2 Not tainted 5.3.0-rc1-00247-gd3519030752a #1
> Hardware name: Allwinner sun7i (A20) Family
> Workqueue: events switchdev_deferred_process_work
> PC is at 0x0
> LR is at dsa_switch_event+0x570/0x620
> pc : [<00000000>] lr : [<c08533ec>] psr: 80070013
> sp : ee871db8 ip : 00000000 fp : ee98d0a4
> r10: 0000000c r9 : 00000008 r8 : ee89f710
> r7 : ee98d040 r6 : ee98d088 r5 : c0f04c48 r4 : ee98d04c
> r3 : 00000000 r2 : ee89f710 r1 : 00000008 r0 : ee98d040
> Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
> Control: 10c5387d Table: 6deb406a DAC: 00000051
> Process kworker/1:2 (pid: 134, stack limit = 0x(ptrval))
> Stack: (0xee871db8 to 0xee872000)
> 1da0: ee871e14 103ace2d
> 1dc0: 00000000 ffffffff 00000000 ee871e14 00000005 00000000 c08524a0 00000000
> 1de0: ffffe000 c014bdfc c0f04c48 ee871e98 c0f04c48 ee9e5000 c0851120 c014bef0
> 1e00: 00000000 b643aea2 ee9b4068 c08509a8 ee2bf940 ee89f710 ee871ecb 00000000
> 1e20: 00000008 103ace2d 00000000 c087e248 ee29c868 103ace2d 00000001 ffffffff
> 1e40: 00000000 ee871e98 00000006 00000000 c0fb2a50 c087e2d0 ffffffff c08523c4
> 1e60: ffffffff c014bdfc 00000006 c0fad2d0 ee871e98 ee89f710 00000000 c014c500
> 1e80: 00000000 ee89f3c0 c0f04c48 00000000 ee9e5000 c087dfb4 ee9e5000 00000000
> 1ea0: ee89f710 ee871ecb 00000001 103ace2d 00000000 c0f04c48 00000000 c087e0a8
> 1ec0: 00000000 efd9a3e0 0089f3c0 103ace2d ee89f700 ee89f710 ee9e5000 00000122
> 1ee0: 00000100 c087e130 ee89f700 c0fad2c8 c1003ef0 c087de4c 2e928000 c0fad2ec
> 1f00: c0fad2ec ee839580 ef7a62c0 ef7a9400 00000000 c087def8 c0fad2ec c01447dc
> 1f20: ef315640 ef7a62c0 00000008 ee839580 ee839594 ef7a62c0 00000008 c0f03d00
> 1f40: ef7a62d8 ef7a62c0 ffffe000 c0145b84 ffffe000 c0fb2420 c0bfaa8c 00000000
> 1f60: ffffe000 ee84b600 ee84b5c0 00000000 ee870000 ee839580 c0145b40 ef0e5ea4
> 1f80: ee84b61c c014a6f8 00000001 ee84b5c0 c014a5b0 00000000 00000000 00000000
> 1fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000
> 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
> [<c014bdfc>] (notifier_call_chain) from [<c014bef0>] (raw_notifier_call_chain+0x18/0x20)
> [<c014bef0>] (raw_notifier_call_chain) from [<c08509a8>] (dsa_port_mdb_add+0x48/0x74)
> [<c08509a8>] (dsa_port_mdb_add) from [<c087e248>] (__switchdev_handle_port_obj_add+0x54/0xd4)
> [<c087e248>] (__switchdev_handle_port_obj_add) from [<c087e2d0>] (switchdev_handle_port_obj_add+0x8/0x14)
> [<c087e2d0>] (switchdev_handle_port_obj_add) from [<c08523c4>] (dsa_slave_switchdev_blocking_event+0x94/0xa4)
> [<c08523c4>] (dsa_slave_switchdev_blocking_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
> [<c014bdfc>] (notifier_call_chain) from [<c014c500>] (blocking_notifier_call_chain+0x50/0x68)
> [<c014c500>] (blocking_notifier_call_chain) from [<c087dfb4>] (switchdev_port_obj_notify+0x44/0xa8)
> [<c087dfb4>] (switchdev_port_obj_notify) from [<c087e0a8>] (switchdev_port_obj_add_now+0x90/0x104)
> [<c087e0a8>] (switchdev_port_obj_add_now) from [<c087e130>] (switchdev_port_obj_add_deferred+0x14/0x5c)
> [<c087e130>] (switchdev_port_obj_add_deferred) from [<c087de4c>] (switchdev_deferred_process+0x64/0x104)
> [<c087de4c>] (switchdev_deferred_process) from [<c087def8>] (switchdev_deferred_process_work+0xc/0x14)
> [<c087def8>] (switchdev_deferred_process_work) from [<c01447dc>] (process_one_work+0x218/0x50c)
> [<c01447dc>] (process_one_work) from [<c0145b84>] (worker_thread+0x44/0x5bc)
> [<c0145b84>] (worker_thread) from [<c014a6f8>] (kthread+0x148/0x150)
> [<c014a6f8>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c)
> Exception stack(0xee871fb0 to 0xee871ff8)
> 1fa0: 00000000 00000000 00000000 00000000
> 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Code: bad PC value
> ---[ end trace 1292c61abd17b130 ]---
>
> [<c08533ec>] (dsa_switch_event) from [<c014bdfc>] (notifier_call_chain+0x48/0x84)
> corresponds to
>
> $ arm-linux-gnueabihf-addr2line -C -i -e vmlinux c08533ec
>
> linux/net/dsa/switch.c:156
> linux/net/dsa/switch.c:178
> linux/net/dsa/switch.c:328
>
> Fixes: e6db98db8a95 ("net: dsa: add switch mdb bitmap functions")
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Thanks for your patience,
Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: fixed_phy: set is_gigabit_capable member when needed
From: Heiner Kallweit @ 2019-08-11 16:59 UTC (permalink / raw)
To: Marek Behun, Andrew Lunn
Cc: netdev, Sebastian Reichel, Vivien Didelot, Florian Fainelli,
David S . Miller
In-Reply-To: <20190811180815.024870da@nic.cz>
On 11.08.2019 18:08, Marek Behun wrote:
> On Sun, 11 Aug 2019 17:40:01 +0200
> Andrew Lunn <andrew@lunn.ch> wrote:
>
>> On Sun, Aug 11, 2019 at 05:08:12PM +0200, Marek Behún wrote:
>>> The fixed_phy driver does not set the phydev->is_gigabit_capable member
>>> when the fixed_phy is gigabit capable.
>>
>> Neither does any other PHY driver. It should be possible to tell if a
>> PHY supports 1G by looking at register values. If this does not work
>> for fixed_link, it means we are missing something in the emulation.
>> That is what we should be fixing.
>>
>> Also, this change has nothing to do the lp_advertise, what you
>> previously said the problem was. At the moment, i don't get the
>> feeling you have really dug all the way down and really understand the
>> root causes.
>>
>> Andrew
>
> Andrew,
> is_gigabit_capable is otherwise set only in the phy_probe function.
> This function is not called at all for the DSA cpu port fixed_link phy.
> Why is that? But I guess it is not important anymore, if CPU and DSA
> were converted to phylink in net-next. I shall test it and let you know.
> In any case, sorry for the spam.
> Marek
>
A fixed phy should be bound to the genphy driver, but that happens later
in phy_attach_direct(). Maybe the fixed phy device of a CPU port gets
never attached to a net device? This would explain why phy_probe()
doesn't get called.
Following idea: We could swphy let return PHY ID 0xffffffff
(instead of current value 0x00000000). Then the fixed phy device would
be bound to the genphy driver immediately at device registration time.
As a consequence phy_probe() would call genphy_read_abilities() that
sets supported modes properly. This should allow to remove the manual
adding of supported modes in dsa_port_fixed_link_register_of().
One more thing regarding genphy_read_abilities() and fixed phys in general:
swphy sets bit BMSR_ESTATEN, then genphy_read_abilities() reads
MII_ESTATUS to check if and which 1Gbps modes are supported.
MII_ESTATUS however isn't defined in swphy. We're just fortunate
that therefore the default value 0xffff is returned and both
1Gbps modes seem to be supported.
Last but not least I think the calls to genphy_config_init() and
genphy_read_status() in dsa_port_fixed_link_register_of() are
both not needed and could be removed.
Heiner
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: fix RGMII-ID port setup
From: Andrew Lunn @ 2019-08-11 16:51 UTC (permalink / raw)
To: Marek Behun
Cc: netdev, Heiner Kallweit, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811181445.71048d2c@nic.cz>
> what if we added a phy_mode member to struct mv88e6xxx_port, and either
> set it to PHY_INTERFACE_MODE_NA in mv88e6xxx_setup, or implemented
> methods for converting the switch register values to
> PHY_INTERFACE_MODE_* values.
We should read the switch registers. I think you can set the defaults
using strapping pins. And in general, the driver always reads state
from the hardware rather than caching it.
Andrew
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:44 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-arm-kernel, Fabio Estevam, netdev, Florian Fainelli,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
> Maybe phylib should retry a number of times - but with read-sensitive
> registers, if the read has already completed successfully, and its
> just a problem with the FEC MDIO hardware, that could cause issues.
Hi Russell
At the bus level, MDIO cannot fail. The bits get clocked out, and the
bits get clocked in. There is no way for the PHY to stretch the clock
as I2C slaves can. There is nothing like the USB NACK, try again
later.
If something fails, it fails at a higher level, which means it is a
driver issue. In this case, the interrupt got delayed, after the timer
interrupt.
The FEC is also quite unusual in using an interrupt. Most MDIO drivers
poll. And if time gets 'stretched' because the system is too busy,
generally, the right thing happens anyway.
So i don't think it is phylib job to work around this issue.
Andrew
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:31 UTC (permalink / raw)
To: Russell King - ARM Linux admin
Cc: linux-arm-kernel, Fabio Estevam, netdev, Florian Fainelli,
Heiner Kallweit
In-Reply-To: <20190811133707.GC13294@shell.armlinux.org.uk>
On Sun, Aug 11, 2019 at 02:37:07PM +0100, Russell King - ARM Linux admin wrote:
> Hi Fabio,
>
> When I woke up this morning, I found that one of the Hummingboards
> had gone offline (as in, lost network link) during the night.
> Investigating, I find that the system had gone into OOM, and at
> that time, triggered an unrelated:
>
> [4111697.698776] fec 2188000.ethernet eth0: MDIO read timeout
> [4111697.712996] MII_DATA: 0x6006796d
> [4111697.729415] MII_SPEED: 0x0000001a
> [4111697.745232] IEVENT: 0x00000000
> [4111697.745242] IMASK: 0x0a8000aa
> [4111698.002233] Atheros 8035 ethernet 2188000.ethernet-1:00: PHY state change RUNNING -> HALTED
> [4111698.009882] fec 2188000.ethernet eth0: Link is Down
>
> This is on a dual-core iMX6.
>
> It looks like the read actually completed (since MII_DATA contains
> the register data) but we somehow lost the interrupt (or maybe
> received the interrupt after wait_for_completion_timeout() timed
> out.)
Hi Russell
The timeout is quite short,
#define FEC_MII_TIMEOUT 30000 /* us */
Looking at the Vybrid datasheet, there does not appear to be any way
to determine if the hardware is busy other than waiting for the
interrupt. There is no 'busy' bit which gets cleared on completion.
So about the only option is to make the timeout bigger.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] net: dsa: fix fixed-link port registration
From: Marek Behun @ 2019-08-11 16:21 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Heiner Kallweit, Andrew Lunn, netdev, Sebastian Reichel,
Vivien Didelot, Florian Fainelli, David S . Miller
In-Reply-To: <CA+h21hoOZQ79rj0SLZGLnkSjrKD3aLNos0GcnRjre-Ls=Tq=4w@mail.gmail.com>
On Sun, 11 Aug 2019 18:16:11 +0300
Vladimir Oltean <olteanv@gmail.com> wrote:
> The DSA fixed-link port functionality *has* been converted to phylink.
> See:
> - https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0e27921816ad9
> - https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=7fb5a711545d7d25fe9726a9ad277474dd83bd06
>
/o\ my bad. I did not realize that I was working on 5.2 :(. Sorry.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: fix RGMII-ID port setup
From: Marek Behun @ 2019-08-11 16:14 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Heiner Kallweit, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811153153.GB14290@lunn.ch>
On Sun, 11 Aug 2019 17:31:53 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, Aug 11, 2019 at 05:08:11PM +0200, Marek Behún wrote:
> > The mv88e6xxx_port_setup_mac looks if one of the {link, speed, duplex}
> > parameters is being changed from the current setting, and if not, does
> > not do anything. This test is wrong in some situations: this method also
> > has the mode argument, which can also be changed.
> >
> > For example on Turris Omnia, the mode is PHY_INTERFACE_MODE_RGMII_ID,
> > which has to be set byt the ->port_set_rgmii_delay method. The test does
> > not look if mode is being changed (in fact there is currently no method
> > to determine port mode as phy_interface_t type).
> >
> > The simplest solution seems to be to drop this test altogether and
> > simply do the setup when requested.
>
> Hi Marek
>
> Unfortunately, that code is there for a reason. phylink can call the
> ->mac_config() method once per second. It is documented that
> mac_config() should only reconfigure what, if anything, has changed.
> And mv88e6xxx_port_setup_mac() needs to disable the port in order to
> change anything. So the change you propose here, under some
> conditions, will cause the port to be disabled/enables once per
> second.
>
> We need to fix this by expanding the test, not removing it. My
> current _guess_ would be, we need to add a ops->port_get_rgmii_delay()
> so we can see if that is what needs configuring.
>
> Andrew
Hi Andrew,
what if we added a phy_mode member to struct mv88e6xxx_port, and either
set it to PHY_INTERFACE_MODE_NA in mv88e6xxx_setup, or implemented
methods for converting the switch register values to
PHY_INTERFACE_MODE_* values.
This way we could just add port.mode == mode check to port_setup_mac
method.
I am willing to implement this if you think this could work.
Marek
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: fixed_phy: set is_gigabit_capable member when needed
From: Marek Behun @ 2019-08-11 16:08 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Heiner Kallweit, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811154001.GC14290@lunn.ch>
On Sun, 11 Aug 2019 17:40:01 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> On Sun, Aug 11, 2019 at 05:08:12PM +0200, Marek Behún wrote:
> > The fixed_phy driver does not set the phydev->is_gigabit_capable member
> > when the fixed_phy is gigabit capable.
>
> Neither does any other PHY driver. It should be possible to tell if a
> PHY supports 1G by looking at register values. If this does not work
> for fixed_link, it means we are missing something in the emulation.
> That is what we should be fixing.
>
> Also, this change has nothing to do the lp_advertise, what you
> previously said the problem was. At the moment, i don't get the
> feeling you have really dug all the way down and really understand the
> root causes.
>
> Andrew
Andrew,
is_gigabit_capable is otherwise set only in the phy_probe function.
This function is not called at all for the DSA cpu port fixed_link phy.
Why is that? But I guess it is not important anymore, if CPU and DSA
were converted to phylink in net-next. I shall test it and let you know.
In any case, sorry for the spam.
Marek
^ permalink raw reply
* Re: [BUG] fec mdio times out under system stress
From: Andrew Lunn @ 2019-08-11 16:03 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Russell King - ARM Linux admin, Florian Fainelli, netdev,
Hubert Feurstein, Fabio Estevam, linux-arm-kernel,
Heiner Kallweit
In-Reply-To: <CA+h21hqkVoQWRweKKCFdvLLOLyP4gEtXQvJ9CO_J7i+YQW+TWw@mail.gmail.com>
> I think a better question is why is the FEC MDIO controller configured
> to emit interrupts anyway (especially since the API built on top does
> not benefit in any way from this)? Hubert (copied) sent an interesting
> email very recently where he pointed out that this is one of the main
> sources of jitter when reading the PTP clock on a Marvell switch
> attached over MDIO.
Hi Vladimir
One reason is runtime power management.
For a write operation, you could set it going and return
immediately. Many drivers do, and then when the next read/write
operation comes along, they poll in a loop waiting for the device to
go idle, if it was still busy from the last operation.
However, FEC supports runtime PM. When an MDIO read/write call is
made, it calls runtime PM functions to indicate the device is active.
Once it has completed the MDIO transaction, it calls runtime PM
functions to indicate the device is inactive. These transitions can
cause clocks to be enabled/disabled. If we don't wait around for the
operation to complete, the clock could be disabled too early, and bad
things would happen.
You could replace the interrupt with a sleeping poll, but my guess
would be, that has more jitter than using an interrupt.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: fixed_phy: set is_gigabit_capable member when needed
From: Andrew Lunn @ 2019-08-11 15:40 UTC (permalink / raw)
To: Marek Behún
Cc: netdev, Heiner Kallweit, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811150812.6780-2-marek.behun@nic.cz>
On Sun, Aug 11, 2019 at 05:08:12PM +0200, Marek Behún wrote:
> The fixed_phy driver does not set the phydev->is_gigabit_capable member
> when the fixed_phy is gigabit capable.
Neither does any other PHY driver. It should be possible to tell if a
PHY supports 1G by looking at register values. If this does not work
for fixed_link, it means we are missing something in the emulation.
That is what we should be fixing.
Also, this change has nothing to do the lp_advertise, what you
previously said the problem was. At the moment, i don't get the
feeling you have really dug all the way down and really understand the
root causes.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: fix RGMII-ID port setup
From: Andrew Lunn @ 2019-08-11 15:31 UTC (permalink / raw)
To: Marek Behún
Cc: netdev, Heiner Kallweit, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811150812.6780-1-marek.behun@nic.cz>
On Sun, Aug 11, 2019 at 05:08:11PM +0200, Marek Behún wrote:
> The mv88e6xxx_port_setup_mac looks if one of the {link, speed, duplex}
> parameters is being changed from the current setting, and if not, does
> not do anything. This test is wrong in some situations: this method also
> has the mode argument, which can also be changed.
>
> For example on Turris Omnia, the mode is PHY_INTERFACE_MODE_RGMII_ID,
> which has to be set byt the ->port_set_rgmii_delay method. The test does
> not look if mode is being changed (in fact there is currently no method
> to determine port mode as phy_interface_t type).
>
> The simplest solution seems to be to drop this test altogether and
> simply do the setup when requested.
Hi Marek
Unfortunately, that code is there for a reason. phylink can call the
->mac_config() method once per second. It is documented that
mac_config() should only reconfigure what, if anything, has changed.
And mv88e6xxx_port_setup_mac() needs to disable the port in order to
change anything. So the change you propose here, under some
conditions, will cause the port to be disabled/enables once per
second.
We need to fix this by expanding the test, not removing it. My
current _guess_ would be, we need to add a ops->port_get_rgmii_delay()
so we can see if that is what needs configuring.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] net: dsa: fix fixed-link port registration
From: Andrew Lunn @ 2019-08-11 15:18 UTC (permalink / raw)
To: Marek Behun
Cc: Heiner Kallweit, netdev, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811160404.06450685@nic.cz>
On Sun, Aug 11, 2019 at 04:04:04PM +0200, Marek Behun wrote:
> OK guys, something is terribly wrong here.
>
> I bisected to the commit mentioned (88d6272acaaa), looked around at the
> genphy functions, tried adding the link=0 workaround and it did work,
> so I though this was the issue.
>
> What I realized now is that before the commit 88d6272acaaa things
> worked because of two bugs, which negated each other. This commit caused
> one of this bugs not to fire, and thus the second bug was not negated.
>
> What actually happened before the commit that broke it is this:
> - after the fixed_phy is created, the parameters are corrent
> - genphy_read_status breaks the parameters:
> - first it sets the parameters to unknown (SPEED_UNKNOWN,
> DUPLEX_UNKNOWN)
> - then read the registers, which are simulated for fixed_phy
> - then it uses phy-core.c:phy_resolve_aneg_linkmode function, which
> looks for correct settings by bit-anding the ->advertising and
> ->lp_advertigins bit arrays. But in fixed_phy, ->lp_advertising
> is set to zero, so the parameters are left at SPEED_UNKNOWN, ...
> (this is the first bug)
> - then adjust_link is called, which then goes to
> mv88e6xxx_port_setup_mac, where there is a test if it should change
> something:
> if (state.link == link && state.speed == speed &&
> state.duplex == duplex)
> return 0;
> - since current speed on the switch port (state.speed) is SPEED_1000,
> and new speed is SPEED_UNKNOWN, this test fails, and so the rest of
> this function is called, which makes the port work
> (the if test is the second bug)
>
> After the commit that broke things:
> - after the fixed_phy is created, the parameters are corrent
> - genphy_read_status doesn't change them
> - mv88e6xxx_port_setup_mac does nothing, since the if condition above
> is true
>
> So, there are two things that are broken:
> - the test in mv88e6xxx_port_setup_mac whether there is to be a change
> should be more sophisticated
> - fixed_phy should also simulate the lp_advertising register
>
> What do you think of this?
Marek
This is the sort of information i like. I was having trouble
understanding what was really wrong and how it was fixed by your
previous patch.
So setting the emulated lp_advertise to advertise makes a lot of sense
for fixed phy. And it is something worthy of stable.
As for mv88e6xxx_port_setup_mac(), which parameter is actually
important here? My assumption was, if one of the other parameters
changes, it would not happen alone. The link would also go down, and
later come up again, etc. But it seems that assumption is wrong.
At a guess, it is the RGMII delays. That would explain CRC errors in
frames received by the master interface.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v2 1/1] net: dsa: fix fixed-link port registration
From: Vladimir Oltean @ 2019-08-11 15:16 UTC (permalink / raw)
To: Marek Behun
Cc: Heiner Kallweit, Andrew Lunn, netdev, Sebastian Reichel,
Vivien Didelot, Florian Fainelli, David S . Miller
In-Reply-To: <20190811160404.06450685@nic.cz>
Hi Marek,
On Sun, 11 Aug 2019 at 17:06, Marek Behun <marek.behun@nic.cz> wrote:
>
> OK guys, something is terribly wrong here.
>
> I bisected to the commit mentioned (88d6272acaaa), looked around at the
> genphy functions, tried adding the link=0 workaround and it did work,
> so I though this was the issue.
>
> What I realized now is that before the commit 88d6272acaaa things
> worked because of two bugs, which negated each other. This commit caused
> one of this bugs not to fire, and thus the second bug was not negated.
>
> What actually happened before the commit that broke it is this:
> - after the fixed_phy is created, the parameters are corrent
> - genphy_read_status breaks the parameters:
> - first it sets the parameters to unknown (SPEED_UNKNOWN,
> DUPLEX_UNKNOWN)
> - then read the registers, which are simulated for fixed_phy
> - then it uses phy-core.c:phy_resolve_aneg_linkmode function, which
> looks for correct settings by bit-anding the ->advertising and
> ->lp_advertigins bit arrays. But in fixed_phy, ->lp_advertising
> is set to zero, so the parameters are left at SPEED_UNKNOWN, ...
> (this is the first bug)
> - then adjust_link is called, which then goes to
> mv88e6xxx_port_setup_mac, where there is a test if it should change
> something:
> if (state.link == link && state.speed == speed &&
> state.duplex == duplex)
> return 0;
> - since current speed on the switch port (state.speed) is SPEED_1000,
> and new speed is SPEED_UNKNOWN, this test fails, and so the rest of
> this function is called, which makes the port work
> (the if test is the second bug)
>
> After the commit that broke things:
> - after the fixed_phy is created, the parameters are corrent
> - genphy_read_status doesn't change them
> - mv88e6xxx_port_setup_mac does nothing, since the if condition above
> is true
>
> So, there are two things that are broken:
> - the test in mv88e6xxx_port_setup_mac whether there is to be a change
> should be more sophisticated
> - fixed_phy should also simulate the lp_advertising register
>
> What do you think of this?
>
I don't know. But I think Heiner was asking you what kernel you're on
because of what you said here:
> Hopefully DSA fixed-link port functionality will be converted to phylink
> API soon.
The DSA fixed-link port functionality *has* been converted to phylink.
See:
- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0e27921816ad9
- https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=7fb5a711545d7d25fe9726a9ad277474dd83bd06
> Marek
>
> On Sun, 11 Aug 2019 13:35:20 +0200
> Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> > On 11.08.2019 05:39, Andrew Lunn wrote:
> > > On Sun, Aug 11, 2019 at 05:18:57AM +0200, Marek Behún wrote:
> > >> Commit 88d6272acaaa ("net: phy: avoid unneeded MDIO reads in
> > >> genphy_read_status") broke fixed link DSA port registration in
> > >> dsa_port_fixed_link_register_of: the genphy_read_status does not do what
> > >> it is supposed to and the following adjust_link is given wrong
> > >> parameters.
> > >
> > > Hi Marek
> > >
> > > Which parameters are incorrect?
> > >
> > > In fixed_phy.c, __fixed_phy_register() there is:
> > >
> > > /* propagate the fixed link values to struct phy_device */
> > > phy->link = status->link;
> > > if (status->link) {
> > > phy->speed = status->speed;
> > > phy->duplex = status->duplex;
> > > phy->pause = status->pause;
> > > phy->asym_pause = status->asym_pause;
> > > }
> > >
> > > Are we not initialising something? Or is the initialisation done here
> > > getting reset sometime afterwards?
> > >
> > In addition to Andrew's question:
> > We talk about this DT config: armada-385-turris-omnia.dts ?
> > Which kernel version are you using?
> >
> > > Thanks
> > > Andrew
> > >
> > Heiner
>
Regards,
-Vladimir
^ permalink raw reply
* [PATCH 4/7] PCI/net: Use PCI_STD_NUM_BARS in loops instead of PCI_STD_RESOURCE_END
From: Denis Efremov @ 2019-08-11 15:08 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, Giuseppe Cavallaro, Alexandre Torgue, netdev,
linux-pci, linux-kernel
In-Reply-To: <20190811150802.2418-1-efremov@linux.com>
This patch refactors the loop condition scheme from
'i <= PCI_STD_RESOURCE_END' to 'i < PCI_STD_NUM_BARS'.
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++--
drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 86f9c07a38cf..cfe496cdd78b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -258,7 +258,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
}
/* Get the base address of device */
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
ret = pcim_iomap_regions(pdev, BIT(i), pci_name(pdev));
@@ -296,7 +296,7 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
stmmac_dvr_remove(&pdev->dev);
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
pcim_iounmap_regions(pdev, BIT(i));
diff --git a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
index 386bafe74c3f..fa8604d7b797 100644
--- a/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
+++ b/drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c
@@ -34,7 +34,7 @@ static int xlgmac_probe(struct pci_dev *pcidev, const struct pci_device_id *id)
return ret;
}
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pcidev, i) == 0)
continue;
ret = pcim_iomap_regions(pcidev, BIT(i), XLGMAC_DRV_NAME);
--
2.21.0
^ permalink raw reply related
* Re: [PATCH net-next v2 1/1] net: dsa: fix fixed-link port registration
From: Marek Behun @ 2019-08-11 15:08 UTC (permalink / raw)
To: Heiner Kallweit
Cc: Andrew Lunn, netdev, Sebastian Reichel, Vivien Didelot,
Florian Fainelli, David S . Miller
In-Reply-To: <20190811160404.06450685@nic.cz>
I have sent two new patches, each fixing one of the bugs that negated
each other.
Marek
^ permalink raw reply
* [PATCH 1/7] PCI: Add define for the number of standard PCI BARs
From: Denis Efremov @ 2019-08-11 15:07 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, Sebastian Ott, Gerald Schaefer, H. Peter Anvin,
Giuseppe Cavallaro, Alexandre Torgue, Matt Porter,
Alexandre Bounine, Peter Jones, Bartlomiej Zolnierkiewicz,
Cornelia Huck, Alex Williamson, kvm, linux-fbdev, netdev, x86,
linux-s390, linux-pci, linux-kernel
In-Reply-To: <20190811150802.2418-1-efremov@linux.com>
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END. However, it requires the "unusual" loop condition
"i <= PCI_STD_RESOURCE_END" rather than something more standard like
"i < PCI_STD_NUM_BARS".
This patch adds the definition PCI_STD_NUM_BARS which is equivalent to
"PCI_STD_RESOURCE_END + 1" and updates loop conditions to use it.
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/pci/quirks.c | 2 +-
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 208aacf39329..02bdf3a0231e 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -475,7 +475,7 @@ static void quirk_extend_bar_to_page(struct pci_dev *dev)
{
int i;
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
struct resource *r = &dev->resource[i];
if (r->flags & IORESOURCE_MEM && resource_size(r) < PAGE_SIZE) {
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9e700d9f9f28..7b9590d5dc2d 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -76,7 +76,7 @@ enum pci_mmap_state {
enum {
/* #0-5: standard PCI resources */
PCI_STD_RESOURCES,
- PCI_STD_RESOURCE_END = 5,
+ PCI_STD_RESOURCE_END = PCI_STD_RESOURCES + PCI_STD_NUM_BARS - 1,
/* #6: expansion ROM resource */
PCI_ROM_RESOURCE,
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
index f28e562d7ca8..68b571d491eb 100644
--- a/include/uapi/linux/pci_regs.h
+++ b/include/uapi/linux/pci_regs.h
@@ -34,6 +34,7 @@
* of which the first 64 bytes are standardized as follows:
*/
#define PCI_STD_HEADER_SIZEOF 64
+#define PCI_STD_NUM_BARS 6 /* Number of standard BARs */
#define PCI_VENDOR_ID 0x00 /* 16 bits */
#define PCI_DEVICE_ID 0x02 /* 16 bits */
#define PCI_COMMAND 0x04 /* 16 bits */
--
2.21.0
^ permalink raw reply related
* [PATCH 0/7] Add definition for the number of standard PCI BARs
From: Denis Efremov @ 2019-08-11 15:07 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Denis Efremov, Sebastian Ott, Gerald Schaefer, H. Peter Anvin,
Giuseppe Cavallaro, Alexandre Torgue, Matt Porter,
Alexandre Bounine, Peter Jones, Bartlomiej Zolnierkiewicz,
Cornelia Huck, Alex Williamson, kvm, linux-fbdev, netdev, x86,
linux-s390, linux-pci, linux-kernel
Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END, but this is error-prone because it requires
"i <= PCI_STD_RESOURCE_END" rather than something like
"i < PCI_STD_NUM_BARS". We could add such a definition and use it the same
way PCI_SRIOV_NUM_BARS is used. There is already the definition
PCI_BAR_COUNT for s390 only. Thus, this patchset introduces it globally.
The patch is splitted into 7 parts for different drivers/subsystems for
easy readability.
Denis Efremov (7):
PCI: Add define for the number of standard PCI BARs
s390/pci: Replace PCI_BAR_COUNT with PCI_STD_NUM_BARS
x86/PCI: Use PCI_STD_NUM_BARS in loops instead of PCI_STD_RESOURCE_END
PCI/net: Use PCI_STD_NUM_BARS in loops instead of PCI_STD_RESOURCE_END
rapidio/tsi721: use PCI_STD_NUM_BARS in loops instead of
PCI_STD_RESOURCE_END
efifb: Use PCI_STD_NUM_BARS in loops instead of PCI_STD_RESOURCE_END
vfio_pci: Use PCI_STD_NUM_BARS in loops instead of
PCI_STD_RESOURCE_END
arch/s390/include/asm/pci.h | 5 +----
arch/s390/include/asm/pci_clp.h | 6 +++---
arch/s390/pci/pci.c | 16 ++++++++--------
arch/s390/pci/pci_clp.c | 6 +++---
arch/x86/pci/common.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++--
drivers/net/ethernet/synopsys/dwc-xlgmac-pci.c | 2 +-
drivers/pci/quirks.c | 2 +-
drivers/rapidio/devices/tsi721.c | 2 +-
drivers/vfio/pci/vfio_pci.c | 4 ++--
drivers/vfio/pci/vfio_pci_config.c | 2 +-
drivers/vfio/pci/vfio_pci_private.h | 4 ++--
drivers/video/fbdev/efifb.c | 2 +-
include/linux/pci.h | 2 +-
include/uapi/linux/pci_regs.h | 1 +
15 files changed, 29 insertions(+), 31 deletions(-)
--
2.21.0
^ permalink raw reply
* [PATCH net-next 2/2] net: fixed_phy: set is_gigabit_capable member when needed
From: Marek Behún @ 2019-08-11 15:08 UTC (permalink / raw)
To: netdev
Cc: Marek Behún, Heiner Kallweit, Sebastian Reichel,
Vivien Didelot, Andrew Lunn, Florian Fainelli, David S . Miller
In-Reply-To: <20190811150812.6780-1-marek.behun@nic.cz>
The fixed_phy driver does not set the phydev->is_gigabit_capable member
when the fixed_phy is gigabit capable. This in turn causes
phy_device.c:genphy_read_status function to return unknown phy
parameters (SPEED_UNKNOWN, DUPLEX_UNKNOWN, ...), if the fixed_phy is
created with SPEED_1000.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
Cc: Heiner Kallweit <hkallweit1@gmail.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Vivien Didelot <vivien.didelot@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/net/phy/fixed_phy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/phy/fixed_phy.c b/drivers/net/phy/fixed_phy.c
index 3ffe46df249e..424b02ad7b7b 100644
--- a/drivers/net/phy/fixed_phy.c
+++ b/drivers/net/phy/fixed_phy.c
@@ -286,6 +286,7 @@ static struct phy_device *__fixed_phy_register(unsigned int irq,
phy->supported);
linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT,
phy->supported);
+ phy->is_gigabit_capable = 1;
/* fall through */
case SPEED_100:
linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT,
--
2.21.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox