Tue, Jun 04, 2019 at 04:28:19PM CEST, richardcoch...@gmail.com wrote:
>On Mon, Jun 03, 2019 at 03:12:42PM +0300, Ido Schimmel wrote:
>
>> +static int
>> +mlxsw_sp1_ptp_update_phc_settime(struct mlxsw_sp_ptp_clock *clock, u64 nsec)
>
>Six words ^^^
It is aligned with the rest of mlxsw code.
Let's factor out firmware handling into a separate source code file.
This simplifies reading the code and makes clearer what the interface
between driver and firmware handling is.
Signed-off-by: Heiner Kallweit
---
v2:
- fix small whitespace issue
---
drivers/net/ethernet/realtek/Makefile
On Tue, Jun 04, 2019 at 08:05:58PM -0600, David Ahern wrote:
> On 6/4/19 6:39 PM, Martin Lau wrote:
> > IMO, ip6_create_rt_rcu(), which returns untracked rt, was a mistake
> > and removing it has been overdue. Tracking down the unregister dev
> > bug is not easy.
>
> I must be missing something b
In preparation of factoring out firmware handling rename r8169.c to
r8169_main.c.
Signed-off-by: Heiner Kallweit
---
v2:
- no changes
---
drivers/net/ethernet/realtek/Makefile | 1 +
drivers/net/ethernet/realtek/{r8169.c => r8169_main.c} | 0
2 files changed, 1 insertion(+)
ren
Let's factor out firmware handling into a separate source code file.
This simplifies reading the code and makes clearer what the interface
between driver and firmware handling is.
v2:
- fix small whitespace issue in patch 2
Heiner Kallweit (2):
r8169: rename r8169.c to r8169_main.c
r8169: fac
On 05.06.2019 04:35, David Miller wrote:
> From: Heiner Kallweit
> Date: Tue, 4 Jun 2019 07:44:53 +0200
>
>> Let's factor out firmware handling into a separate source code file.
>> This simplifies reading the code and makes clearer what the interface
>> between driver and firmware handling is.
>
On Wed, Jun 05, 2019 at 12:27:14PM +0800, Hangbin Liu wrote:
> This reverts commit e9919a24d3022f72bcadc407e73a6ef17093a849.
>
> Nathan reported the new behaviour breaks Android, as Android just add
> new rules and delete old ones.
>
> If we return 0 without adding dup rules, Android will remove
This is introduced for admins to check what is happening on XDP_TX when
bulk XDP_TX is in use, which will be first introduced in veth in next
commit.
Signed-off-by: Toshiaki Makita
---
include/trace/events/xdp.h | 25 +
kernel/bpf/core.c | 1 +
2 files changed,
This introduces bulk XDP_TX in veth.
Improves XDP_TX performance by approximately 9%. The detailed
explanation and performance numbers are shown in patch 2.
v2:
- Use stack for bulk queue instead of a global variable.
Signed-off-by: Toshiaki Makita
Toshiaki Makita (2):
xdp: Add tracepoint for
XDP_TX is similar to XDP_REDIRECT as it essentially redirects packets to
the device itself. XDP_REDIRECT has bulk transmit mechanism to avoid the
heavy cost of indirect call but it also reduces lock acquisition on the
destination device that needs locks like veth and tun.
XDP_TX does not use indir
On Wed, Jun 5, 2019 at 12:58 PM David Ahern wrote:
> I think it is crazy to add multiple identical rules given the linear
> effect on performance.
Not sure if this is what you were implying or not, but our code
doesn't maintain multiple identical rules in steady state. It only
uses them for make-
Hey Andrew,
thanks for you reply.
I got the devicetree from somebody that is why German is in it. But first I
wanted to get it running before I tidy it up.
The switch is strapped to single mode (so I can read SMI addresses 0x10-0x16
and 0x1b-0x1e directly). Do I have to
tell this the devicetree?
On Thu, May 30, 2019 at 2:08 AM Steinar H. Gunderson
wrote:
>
> Hi,
>
> I'm trying to connect some VMs over EoGRE (using gretap on my side):
>
> ip link add foo type gretap remote local
>
> This works fine for large packets, but the system in the other end
> drops smaller packets, such as ARP
This reverts commit e9919a24d3022f72bcadc407e73a6ef17093a849.
Nathan reported the new behaviour breaks Android, as Android just add
new rules and delete old ones.
If we return 0 without adding dup rules, Android will remove the new
added rules and causing system to soft-reboot.
Reported-by: Nath
On Tue, Jun 4, 2019 at 9:06 PM Baruch Siach wrote:
>
> Hi Alexei,
>
> (Adding Arnd and linux-arch to Cc)
>
> On Tue, Jun 04, 2019 at 08:30:29AM -0700, Alexei Starovoitov wrote:
> > On Tue, Jun 04, 2019 at 05:23:46PM +0200, Geert Uytterhoeven wrote:
> > > On Tue, Jun 4, 2019 at 5:17 PM Alexei Staro
On Tue, Jun 04, 2019 at 09:57:56PM -0600, David Ahern wrote:
> On 6/4/19 7:43 PM, Hangbin Liu wrote:
> > Hi David Ahern,
> >
> > On Fri, May 31, 2019 at 06:43:42PM -0700, Maciej Żenczykowski wrote:
> >> FYI, this userspace visible change in behaviour breaks Android.
> >>
> >> We rely on being able
Hi Alexei,
(Adding Arnd and linux-arch to Cc)
On Tue, Jun 04, 2019 at 08:30:29AM -0700, Alexei Starovoitov wrote:
> On Tue, Jun 04, 2019 at 05:23:46PM +0200, Geert Uytterhoeven wrote:
> > On Tue, Jun 4, 2019 at 5:17 PM Alexei Starovoitov
> > wrote:
> > > On Tue, Jun 4, 2019 at 4:40 AM Baruch Sia
On Wed, Jun 05, 2019 at 12:43:44PM +0900, Lorenzo Colitti wrote:
> On Wed, Jun 5, 2019 at 12:29 PM Hangbin Liu wrote:
> > > We rely on being able to add a rule and either have a dup be created
> > > (in which case we'll remove it later) or have it fail with EEXIST (in
> > > which case we won't rem
On 6/4/19 7:43 PM, Hangbin Liu wrote:
> Hi David Ahern,
>
> On Fri, May 31, 2019 at 06:43:42PM -0700, Maciej Żenczykowski wrote:
>> FYI, this userspace visible change in behaviour breaks Android.
>>
>> We rely on being able to add a rule and either have a dup be created
>> (in which case we'll rem
On Wed, Jun 5, 2019 at 12:29 PM Hangbin Liu wrote:
> > We rely on being able to add a rule and either have a dup be created
> > (in which case we'll remove it later) or have it fail with EEXIST (in
> > which case we won't remove it later).
>
> With Maciej said, how about add NLM_F_EXCL flag when y
On Wed, Jun 05, 2019 at 11:25:11AM +0900, Lorenzo Colitti wrote:
> On Wed, Jun 5, 2019 at 11:15 AM Hangbin Liu wrote:
> > How do you add the rules? with ip cmd it should has NLM_F_EXCL flag and
> > you will get -EEXIST error out.
>
> The fact that the code worked before this commit implies that i
From: Paolo Abeni
Date: Tue, 4 Jun 2019 11:44:06 +0200
> As Eric noted, the current wrapper for ptype func hook inside
> __netif_receive_skb_list_ptype() has no chance of avoiding the indirect
> call: we enter such code path only for protocols other than ipv4 and
> ipv6.
>
> Instead we can wrap
From: Julian Wiedmann
Date: Tue, 4 Jun 2019 10:15:05 +0200
> same patch series as yesterday, except that patch 2 has been adjusted
> as per your review to use dst_check(). Please have another look.
The correct usage is:
dst = dst_check();
On 6/4/2019 4:46 PM, Vladimir Oltean wrote:
> On Wed, 5 Jun 2019 at 02:24, Russell King - ARM Linux admin
> wrote:
>>
>> On Wed, Jun 05, 2019 at 02:03:19AM +0300, Vladimir Oltean wrote:
>>> On Wed, 5 Jun 2019 at 01:59, Russell King - ARM Linux admin
>>> wrote:
On Wed, Jun 05, 2019 at
From: Ronak Doshi
Date: Mon, 3 Jun 2019 23:58:38 -0700
> Currently, when rx csum is disabled, vmxnet3 driver does not turn
> off lro, which can cause performance issues if user does not turn off
> lro explicitly. This patch adds fix_features support which is used to
> turn off LRO whenever RXCSUM
On 6/4/19 9:03 PM, Alexei Starovoitov wrote:
> As far as I can see the discussion on a better path forward
> was still ongoing in v2 thread between David, Martin and Wei.
> Since the set is already applied it demotivated everyone
> to review and discuss it further.
> Please reconsider such decision
On Tue, Jun 4, 2019 at 7:28 PM David Miller wrote:
>
> From: David Ahern
> Date: Mon, 3 Jun 2019 20:19:48 -0700
>
> > Set 10 of 11 to improve route scalability via support for nexthops as
> > standalone objects for fib entries.
> > https://lwn.net/Articles/763950/
>
> Series applied, thanks
From: Heiner Kallweit
Date: Tue, 4 Jun 2019 07:44:53 +0200
> Let's factor out firmware handling into a separate source code file.
> This simplifies reading the code and makes clearer what the interface
> between driver and firmware handling is.
This doesn't apply cleanly to net-next, specificall
From: David Ahern
Date: Mon, 3 Jun 2019 20:19:48 -0700
> Set 10 of 11 to improve route scalability via support for nexthops as
> standalone objects for fib entries.
> https://lwn.net/Articles/763950/
Series applied, thanks David.
On 6/4/2019 2:36 PM, Russell King - ARM Linux admin wrote:
> Normally the PHY receives traffic, and passes it to the MAC which
> just ignores the signals it receives from the PHY, so no processing
> beyond the PHY receiving the traffic happens.
>
> Ultimately, whether you want the PHY to stay link
On Wed, Jun 5, 2019 at 11:15 AM Hangbin Liu wrote:
> How do you add the rules? with ip cmd it should has NLM_F_EXCL flag and
> you will get -EEXIST error out.
The fact that the code worked before this commit implies that it was
*not* using NLM_F_EXCL. :-)
The code is here if you want to take a lo
On Wed, Jun 05, 2019 at 10:47:58AM +0900, Lorenzo Colitti wrote:
> On Wed, Jun 5, 2019 at 10:43 AM Hangbin Liu wrote:
> > Although I'm still not clear what's the difference between
> >
> > a) adding a dup rule and remove it later
> > and
> > b) return 0 directly if the rule exactally the same.
>
On 6/4/19 6:39 PM, Martin Lau wrote:
> IMO, ip6_create_rt_rcu(), which returns untracked rt, was a mistake
> and removing it has been overdue. Tracking down the unregister dev
> bug is not easy.
I must be missing something because I don't have the foggiest idea why
you are barking up this tree.
On Wed, Jun 5, 2019 at 10:43 AM Hangbin Liu wrote:
> Although I'm still not clear what's the difference between
>
> a) adding a dup rule and remove it later
> and
> b) return 0 directly if the rule exactally the same.
The Android code updates ip rules by adding the new rule and then
deleting the
Hi David Ahern,
On Fri, May 31, 2019 at 06:43:42PM -0700, Maciej Żenczykowski wrote:
> FYI, this userspace visible change in behaviour breaks Android.
>
> We rely on being able to add a rule and either have a dup be created
> (in which case we'll remove it later) or have it fail with EEXIST (in
>
From: Tim Beale
Date: Tue, 4 Jun 2019 13:56:23 +1200
> By default, packets received in another VRF should not be passed to an
> unbound socket in the default VRF. This patch updates the IPv4 UDP
> multicast logic to match the unicast VRF logic (in compute_score()),
> as well as the IPv6 mcast lo
From: Eric Dumazet
Date: Tue, 4 Jun 2019 18:16:00 -0700
> On 6/4/19 12:29 PM, Eric Dumazet wrote:
>> This extends commit 22b6722bfa59 ("ipv6: Add sysctl for per
>> namespace flow label reflection"), for some TCP RST packets.
>>
>> When RST packets are sent because no socket could be found,
>> it
On 6/4/19 12:29 PM, Eric Dumazet wrote:
> This extends commit 22b6722bfa59 ("ipv6: Add sysctl for per
> namespace flow label reflection"), for some TCP RST packets.
>
> When RST packets are sent because no socket could be found,
> it makes sense to use flowlabel_reflect sysctl to decide
> if a
On Tue, Jun 04, 2019 at 02:36:27PM -0700, Wei Wang wrote:
> On Tue, Jun 4, 2019 at 2:13 PM David Ahern wrote:
> >
> > On 6/4/19 3:06 PM, Martin Lau wrote:
> > > On Tue, Jun 04, 2019 at 02:17:28PM -0600, David Ahern wrote:
> > >> On 6/3/19 11:29 PM, Martin Lau wrote:
> > >>> On Mon, Jun 03, 2019 at
On Wed, Jun 05, 2019 at 02:46:13AM +0300, Vladimir Oltean wrote:
> On Wed, 5 Jun 2019 at 02:24, Russell King - ARM Linux admin
> wrote:
> >
> > On Wed, Jun 05, 2019 at 02:03:19AM +0300, Vladimir Oltean wrote:
> > > On Wed, 5 Jun 2019 at 01:59, Russell King - ARM Linux admin
> > > wrote:
> > > >
>
On Wed, 5 Jun 2019 at 02:24, Russell King - ARM Linux admin
wrote:
>
> On Wed, Jun 05, 2019 at 02:03:19AM +0300, Vladimir Oltean wrote:
> > On Wed, 5 Jun 2019 at 01:59, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Wed, Jun 05, 2019 at 01:44:08AM +0300, Vladimir Oltean wrote:
> > > > Y
On 6/4/19 3:36 PM, Wei Wang wrote:
> instead of trying to convert ip6_create_rt_rcu() to use the pcpu_dst
> logic, completely get rid of the calling to ip6_create_rt_rcu(), and
> directly return f6i in those cases to the caller. Is that correct?
yes
On Wed, Jun 05, 2019 at 02:03:19AM +0300, Vladimir Oltean wrote:
> On Wed, 5 Jun 2019 at 01:59, Russell King - ARM Linux admin
> wrote:
> >
> > On Wed, Jun 05, 2019 at 01:44:08AM +0300, Vladimir Oltean wrote:
> > > You caught me.
> > >
> > > But even ignoring the NIC case, isn't the PHY state mach
On Wed, 5 Jun 2019 at 01:59, Russell King - ARM Linux admin
wrote:
>
> On Wed, Jun 05, 2019 at 01:44:08AM +0300, Vladimir Oltean wrote:
> > You caught me.
> >
> > But even ignoring the NIC case, isn't the PHY state machine
> > inconsistent with itself? It is ok with callink phy_suspend upon
> > nd
On Wed, Jun 05, 2019 at 01:44:08AM +0300, Vladimir Oltean wrote:
> You caught me.
>
> But even ignoring the NIC case, isn't the PHY state machine
> inconsistent with itself? It is ok with callink phy_suspend upon
> ndo_stop, but it won't call phy_suspend after phy_connect, when the
> netdev is imp
On Wed, 5 Jun 2019 at 01:16, Russell King - ARM Linux admin
wrote:
>
> On Wed, Jun 05, 2019 at 01:03:27AM +0300, Vladimir Oltean wrote:
> > On Wed, 5 Jun 2019 at 00:48, Russell King - ARM Linux admin
> > wrote:
> > >
> > > On Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote:
> > > >
On 2019-06-04 4:18 p.m., Andrew Lunn wrote:
>> -axienet_iow(lp, XAE_MDIO_MC_OFFSET,
>> -(mdio_mcreg & (~XAE_MDIO_MC_MDIOEN_MASK)));
>> +mutex_lock(&lp->mii_bus->mdio_lock);
>> +axienet_mdio_disable(lp);
>
> I wonder if it would look better structured if the lock was in
the following TDC test case:
b776 - Replace simple action with invalid goto chain control
checks if the kernel correctly validates the 'goto chain' control action,
when it is specified in 'act_simple' rules. The test systematically fails
because the control action is hardcoded in parse_simple(),
> - axienet_iow(lp, XAE_MDIO_MC_OFFSET,
> - (mdio_mcreg & (~XAE_MDIO_MC_MDIOEN_MASK)));
> + mutex_lock(&lp->mii_bus->mdio_lock);
> + axienet_mdio_disable(lp);
I wonder if it would look better structured if the lock was in
axienet_mdio_disable() and the unlock in axienet
On Wed, Jun 05, 2019 at 01:03:27AM +0300, Vladimir Oltean wrote:
> On Wed, 5 Jun 2019 at 00:48, Russell King - ARM Linux admin
> wrote:
> >
> > On Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote:
> > > The firmware/boot loader transition to a full fledged OS with a switch
> > > is a
Add 1000BaseX to the link modes which are detected based on the
MII_ESTATUS register as per 802.3 Clause 22. This allows PHYs which
support 1000BaseX to work properly with drivers using phylink.
Previously 1000BaseX support was not detected, and if that was the only
mode the PHY indicated support
On Tue, Jun 04, 2019 at 03:43:32PM -0600, Robert Hancock wrote:
> This driver was previously always calculating the MDIO clock divisor
> (from AXI bus clock to MDIO bus clock) based on the CPU clock frequency,
> assuming that it is the same as the AXI bus frequency, but that
> simplistic method onl
On Wed, 5 Jun 2019 at 00:48, Russell King - ARM Linux admin
wrote:
>
> On Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote:
> > The firmware/boot loader transition to a full fledged OS with a switch
> > is a tricky one to answer though, and there are no perfect answers
> > AFAICT. If
> This could potentially break existing device trees if they don't use
> "mdio" as the name for the MDIO bus, but I did not find any with various
> searches and Xilinx's examples all use mdio as the name so it seems like
> this should be relatively safe.
Hi Robert
Please add this mdio node to the
On Tue, Jun 04, 2019 at 03:43:27PM -0600, Robert Hancock wrote:
> This is a series of enhancements and bug fixes in order to get the mainline
> version of this driver into a more generally usable state, including on
> x86 or ARM platforms. It also converts the driver to use the phylink API
> in ord
> For a switch, there are four stages, not two:
Agreed.
> 1. The out-of-reset state, which from what I've seen seems to be to
>behave like a dumb switch.
For the Marvell Switches, there is a pin you can strap to control
this, NO_CPU. If you say there is no CPU, it will power up in dumb
swit
On Tue, 4 Jun 2019 14:35:24 -0700, Stanislav Fomichev wrote:
> Support sockopt prog type and cgroup hooks in the bpftool.
>
> Signed-off-by: Stanislav Fomichev
Acked-by: Jakub Kicinski
From: David Ahern
Date: Mon, 3 Jun 2019 18:37:03 -0700
> From: David Ahern
>
> A recent commit had an unintended side effect with reject routes:
> rt6i_pcpu is expected to always be initialized for all fib6_info except
> the null entry. The commit mentioned below skips it for reject routes
> a
On Tue, Jun 04, 2019 at 03:13:38PM -0600, David Ahern wrote:
> On 6/4/19 3:06 PM, Martin Lau wrote:
> > On Tue, Jun 04, 2019 at 02:17:28PM -0600, David Ahern wrote:
> >> On 6/3/19 11:29 PM, Martin Lau wrote:
> >>> On Mon, Jun 03, 2019 at 07:36:06PM -0600, David Ahern wrote:
> On 6/3/19 6:58 PM
From: Ariel Levkovich
Date: Mon, 3 Jun 2019 22:36:45 +
> Netdevice HW MPLS features are not passed from device driver's netdevice to
> upper netdevice, specifically VLAN and bonding netdevice which are created
> by the kernel when needed.
>
> This prevents enablement and usage of HW offloads
On Tue, Jun 04, 2019 at 02:37:31PM -0700, Florian Fainelli wrote:
> The firmware/boot loader transition to a full fledged OS with a switch
> is a tricky one to answer though, and there are no perfect answers
> AFAICT. If your SW is totally hosed, you might want the switch to
> forward traffic betwe
On some platforms, such as iMX6 with PCIe devices, crashes or hangs can
occur if the axienet device continues to perform DMA transfers after
parent devices/busses have been shut down. Shut down the axienet
interface during its shutdown callback in order to avoid this.
Signed-off-by: Robert Hancock
The Xilinx DMA blocks each have their own reset register, but they both
reset the entire DMA engine, so only one of them needs to be reset.
Also, when stopping the device, we need to not just command the DMA
blocks to stop, but wait for them to stop, and trigger a device reset
to ensure that they
Convert this driver to use the phylink API rather than the legacy PHY
API. This allows for better support for SFP modules connected using a
1000BaseX or SGMII interface.
Signed-off-by: Robert Hancock
---
drivers/net/ethernet/xilinx/Kconfig | 2 +-
drivers/net/ethernet/xilinx/xili
These registers are important for troubleshooting the state of the DMA
cores.
Signed-off-by: Robert Hancock
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
b/dri
This driver should now build on (at least) X86 and ARM platforms, so add
them as supported platforms for the driver in Kconfig.
Signed-off-by: Robert Hancock
---
drivers/net/ethernet/xilinx/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilin
The MDIO bus for this driver was being named using the result of
of_address_to_resource on a node which may not have any resource on it,
but the return value of that call was not checked so it was using some
random value in the bus name. Change to name the MDIO bus based on the
resource start of th
This driver was previously using the parent node of the specified PHY
node as the device node to register the MDIO bus on. Andrew Lunn
pointed out this is wrong as the PHY node is potentially not even
underneath the MDIO bus for the current device instance. Find the MDIO
node explicitly by looking
Since the MDIO is is brought up before the netdev is registered, it
should be torn down after the netdev is removed. Otherwise, PHY accesses
can potentially access freed MDIO bus references and cause a crash.
Signed-off-by: Robert Hancock
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 2
This driver was using in_be32 and out_be32 IO accessors which do not
exist on most platforms. Also, the use of big-endian accessors does not
seem correct as this hardware is accessed over an AXI bus which, to the
extent it has an endian-ness, is little-endian. Switch to standard
ioread32/iowrite32
This driver was previously always calculating the MDIO clock divisor
(from AXI bus clock to MDIO bus clock) based on the CPU clock frequency,
assuming that it is the same as the AXI bus frequency, but that
simplistic method only works on the MicroBlaze platform.
Add support for specifying the cloc
It is possible that the interrupt handler fires and frees up space in
the TX ring in between checking for sufficient TX ring space and
stopping the TX queue in axienet_start_xmit. If this happens, the
queue wake from the interrupt handler will occur before the queue is
stopped, causing a lost wakeu
Previously this driver only handled interrupts from the DMA RX and TX
blocks, not from the Ethernet core itself. Add optional support for
the Ethernet core interrupt, which is used to detect rx_missed and
framing errors signalled by the hardware. In order to use this
interrupt, a third interrupt ne
Currently the axienet driver requires the use of a second devicetree
node, referenced by an axistream-connected attribute on the Ethernet
device node, which contains the resources for the AXI DMA block used by the
device. This setup is problematic for a use case we have where the Ethernet
and DMA c
Specify IRQF_SHARED to support shared interrupts. If the interrupt
handler is called and the device is not indicating an interrupt,
just return IRQ_NONE rather than spewing error messages.
Signed-off-by: Robert Hancock
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 14 --
1
The MDIO clock divisor register setting was only applied on the initial
startup when the driver was loaded. However, this setting is cleared
when the device is reset, such as would occur when the interface was
taken down and brought up again, and so the MDIO bus would be
non-functional afterwards.
Failing initialization on a missing MAC address property is excessive.
We can just fall back to using a random MAC instead, which at least
leaves the interface in a functioning state.
Signed-off-by: Robert Hancock
---
drivers/net/ethernet/xilinx/xilinx_axienet_main.c | 5 +++--
1 file changed, 3
Add support for setting the RX and TX ring sizes for this driver using
ethtool. Also increase the default RX ring size as the previous default
was far too low for good performance in some configurations.
Signed-off-by: Robert Hancock
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 2 +
The axienet driver requires the use of an axistream-connected attribute,
but this isn't documented in the devicetree bindings. Document how this
attribute is supposed to be used, including the upcoming change to make
the usage of this attribute optional.
Signed-off-by: Robert Hancock
---
.../dev
This driver was casting skb pointers to u32 and storing them as such in
the DMA buffer descriptor, which is obviously broken on 64-bit. The area
of the buffer descriptor being used is not accessed by the hardware and
has sufficient room for a 32 or 64-bit pointer, so just store the skb
pointer as s
This is a series of enhancements and bug fixes in order to get the mainline
version of this driver into a more generally usable state, including on
x86 or ARM platforms. It also converts the driver to use the phylink API
in order to provide support for SFP modules.
Changes since v2:
-Fixed MDIO bu
On 6/4/2019 2:29 PM, Vladimir Oltean wrote:
> On Wed, 5 Jun 2019 at 00:12, Andrew Lunn wrote:
>>
>>> But now the second question: between a phy_connect and a phy_start,
>>> shouldn't the PHY be suspended too? Experimentally it looks like it
>>> still isn't.
>>
>> This is not always clear cut. D
On Tue, Jun 04, 2019 at 10:58:41PM +0300, Vladimir Oltean wrote:
> Hi,
>
> I've been wondering what is the correct approach to cut the Ethernet link
> when the user requests it to be administratively down (aka ip link set dev
> eth0 down).
> Most of the Ethernet drivers simply call phy_stop or the
On Tue, Jun 4, 2019 at 2:13 PM David Ahern wrote:
>
> On 6/4/19 3:06 PM, Martin Lau wrote:
> > On Tue, Jun 04, 2019 at 02:17:28PM -0600, David Ahern wrote:
> >> On 6/3/19 11:29 PM, Martin Lau wrote:
> >>> On Mon, Jun 03, 2019 at 07:36:06PM -0600, David Ahern wrote:
> On 6/3/19 6:58 PM, Martin
Make libbpf aware of new sockopt hooks so it can derive prog type
and hook point from the section names.
Signed-off-by: Stanislav Fomichev
---
tools/lib/bpf/libbpf.c| 5 +
tools/lib/bpf/libbpf_probes.c | 1 +
2 files changed, 6 insertions(+)
diff --git a/tools/lib/bpf/libbpf.c b/too
Add tests that make sure libbpf section detection works.
Signed-off-by: Stanislav Fomichev
---
tools/testing/selftests/bpf/test_section_names.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/tools/testing/selftests/bpf/test_section_names.c
b/tools/testing/selftests/bpf/test_sec
Support sockopt prog type and cgroup hooks in the bpftool.
Signed-off-by: Stanislav Fomichev
---
tools/bpf/bpftool/Documentation/bpftool-cgroup.rst | 7 +--
tools/bpf/bpftool/Documentation/bpftool-prog.rst | 2 +-
tools/bpf/bpftool/bash-completion/bpftool | 8 +---
tools/bpf/b
Provide user documentation about sockopt prog type and cgroup hooks.
Signed-off-by: Stanislav Fomichev
---
Documentation/bpf/index.rst | 1 +
Documentation/bpf/prog_cgroup_sockopt.rst | 42 +++
2 files changed, 43 insertions(+)
create mode 100644 Documentation
Export new prog type and hook points to the libbpf.
Signed-off-by: Stanislav Fomichev
---
tools/include/uapi/linux/bpf.h | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 7c6aef253173..b6c38
Add sockopt selftests:
* require proper expected_attach_type
* enforce context field read/write access
* test bpf_sockopt_handled handler
* test EPERM
* test limiting optlen from getsockopt
* test out-of-bounds access
Signed-off-by: Stanislav Fomichev
---
tools/testing/selftests/bpf/.gitignore
Implement new BPF_PROG_TYPE_CGROUP_SOCKOPT program type and
BPF_CGROUP_{G,S}ETSOCKOPT cgroup hooks.
BPF_CGROUP_SETSOCKOPT get a read-only view of the setsockopt arguments.
BPF_CGROUP_GETSOCKOPT can modify the supplied buffer.
Both of them reuse existing PTR_TO_PACKET{,_END} infrastructure.
The bu
This series implements two new per-cgroup hooks: getsockopt and
setsockopt along with a new sockopt program type. The idea is pretty
similar to recently introduced cgroup sysctl hooks, but
implementation is simpler (no need to convert to/from strings).
What this can be applied to:
* move business
From: Jakub Kicinski
Date: Mon, 3 Jun 2019 15:16:57 -0700
> This series cleans up and improves the tls code, mostly the offload
> parts.
>
> First a slight performance optimization - avoiding unnecessary re-
> -encryption of records in patch 1. Next patch 2 makes the code
> more resilient by c
On Wed, 5 Jun 2019 at 00:12, Andrew Lunn wrote:
>
> > But now the second question: between a phy_connect and a phy_start,
> > shouldn't the PHY be suspended too? Experimentally it looks like it
> > still isn't.
>
> This is not always clear cut. Doing auto-neg is slow. Some systems
> want to get ne
On Tue, 4 Jun 2019 at 23:57, Florian Fainelli wrote:
>
>
>
> On 6/4/2019 1:42 PM, Vladimir Oltean wrote:
> > On Tue, 4 Jun 2019 at 23:07, Andrew Lunn wrote:
> >>
> >> On Tue, Jun 04, 2019 at 10:58:41PM +0300, Vladimir Oltean wrote:
> >>> Hi,
> >>>
> >>> I've been wondering what is the correct app
On Tue, 4 Jun 2019 at 23:55, Heiner Kallweit wrote:
>
> On 04.06.2019 22:42, Vladimir Oltean wrote:
> > On Tue, 4 Jun 2019 at 23:07, Andrew Lunn wrote:
> >>
> >> On Tue, Jun 04, 2019 at 10:58:41PM +0300, Vladimir Oltean wrote:
> >>> Hi,
> >>>
> >>> I've been wondering what is the correct approach
From: Florian Westphal
Date: Mon, 3 Jun 2019 22:41:44 +0200
> syzbot triggered following splat when strict netlink
> validation is enabled:
>
> net/ipv4/devinet.c:1766 suspicious rcu_dereference_check() usage!
>
> This occurs because we hold RTNL mutex, but no rcu read lock.
> The second call
On Tue, Jun 4, 2019 at 2:07 PM Stanislav Fomichev wrote:
>
> On 06/04, Andrii Nakryiko wrote:
> > On Tue, Jun 4, 2019 at 6:45 AM Stanislav Fomichev wrote:
> > >
> > > On 06/03, Stanislav Fomichev wrote:
> > > > > BTF is mandatory for _any_ new feature.
> > > > If something is easy to support with
From: Sean Wang
Fixed several errors caused by undefined symbols catched by kbuild test
robot.
ERROR: "mtk_sgmii_init" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko]
undefined!
ERROR: "mtk_setup_hw_path" [drivers/net/ethernet/mediatek/mtk_eth_soc.ko]
undefined!
ERROR: "mtk_sgmii_setup_mode_for
From: Jiri Pirko
Date: Tue, 4 Jun 2019 15:40:36 +0200
> From: Jiri Pirko
>
> When user is flashing device using devlink, he currenly does not see any
> information about what is going on, percentages, etc.
> Drivers, for example mlxsw and mlx5, have notion about the progress
> and what is happ
1 - 100 of 230 matches
Mail list logo
