We tends to batch submitting packets during XDP_TX. This requires to
kick virtqueue after a batch, we tried to do it through
xdp_do_flush_map() which only makes sense for devmap not XDP_TX. So
explicitly kick the virtqueue in this case.
Reported-by: Kimitoshi Takahashi
Tested-by: Kimitoshi Takaha
stmmac reception handler calls stmmac_rx_vlan() to strip the vlan before
calling napi_gro_receive().
The function assumes VLAN tagged frames are always tagged with 802.1Q
protocol,
and assigns ETH_P_8021Q to the skb by hard-coding the parameter on call
to __vlan_hwaccel_put_tag() .
This caus
syzbot has found reproducer for the following crash on net-next commit
17dec0a949153d9ac00760ba2f5b78cb583e995f (Wed Apr 4 02:15:32 2018 +)
Merge branch 'userns-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace
syzbot dashboard link:
https://syzkaller.appspot.
Hi Chen-Yu,
I love your patch! Perhaps something to improve:
[auto build test WARNING on robh/for-next]
[also build test WARNING on v4.16 next-20180412]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
Fixes: 529123418105 ("net: stmmac: dwmac-sun8i: Allow getting syscon regmap
from device")
Signed-off-by: Fengguang Wu
---
dwmac-sun8i.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
b/drivers/net/ethernet/stmicro/stmmac
syzbot has found reproducer for the following crash on
https://github.com/google/kmsan.git/master commit
35ff515e4bda2646f6c881d33951c306ea9c282a (Tue Apr 10 08:59:43 2018 +)
Merge pull request #11 from parkerduckworth/readme
syzbot dashboard link:
https://syzkaller.appspot.com/bug?extid=b
On 4/12/18 6:41 AM, Thomas Deutschmann wrote:
> Hi,
>
> well, it isn't just "fe80::1", it is any IPv6 address which
> will be rejected if not called with "-6". I run bisect:
>
>> git bisect start
>> # good: [50b8a842e8c098cddb213f5b3076526df88826e8] v4.15.0
>> git bisect good 50b8a842e8c098cddb21
On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> + if (bw_avail >= bw_cap)
> + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> + bw_cap, PCIE_SPEED2STR(speed_cap), width_cap);
> + else
> + pci_info(dev, "%d Mb/s available
On 2018年04月01日 22:12, Tiwei Bie wrote:
Hello everyone,
This RFC implements packed ring support for virtio driver.
The code was tested with DPDK vhost (testpmd/vhost-PMD) implemented
by Jens at http://dpdk.org/ml/archives/dev/2018-January/089417.html
Minor changes are needed for the vhost code
Chris,
> Instead of always multicasting responses, send a unicast netlink message
> directed at the correct pid. This will be needed if we ever want to
> support multiple userspace processes interacting with the kernel over
> iSCSI netlink simultaneously. Limitations can currently be seen if yo
On 4/12/18 10:54 AM, Jeff Barnhill wrote:
> Hi David,
>
> In the slides referenced, you recommend adding an "unreachable
> default" route to the end of each VRF route table. In my testing (for
> v4) this results in a change to fib lookup failures such that instead
> of ENETUNREACH being returned,
From: Richard Cochran
Date: Thu, 12 Apr 2018 10:35:40 -0700
> On Mon, Apr 09, 2018 at 07:19:31AM -0700, Richard Cochran wrote:
>> Dave, please hold off on this patch. I am seeing new problems in my
>> testing with this applied. I still need to get to the bottom of
>> this.
>
> Looks like the n
From: Xin Long
Date: Thu, 12 Apr 2018 14:24:31 +0800
> pf->cmp_addr() is called before binding a v6 address to the sock. It
> should not check ports, like in sctp_inet_cmp_addr.
>
> But sctp_inet6_cmp_addr checks the addr by invoking af(6)->cmp_addr,
> sctp_v6_cmp_addr where it also compares the
From: Wolfgang Bumiller
Date: Thu, 12 Apr 2018 10:46:55 +0200
> When coming from ndisc_netdev_event() in net/ipv6/ndisc.c,
> neigh_ifdown() is called with &nd_tbl, locking this while
> clearing the proxy neighbor entries when eg. deleting an
> interface. Calling the table's pndisc_destructor() wi
From: Jakub Kicinski
Date: Wed, 11 Apr 2018 16:47:34 -0700
> The first part of this set aims to improve handling of interrupted
> waits. Patch 1 makes waiting for management FW responses
> uninterruptible while patch 2 adds a message when signal arrives
> while waiting for an NFP mutex. We can'
From: Jon Maloy
Date: Thu, 12 Apr 2018 01:15:48 +0200
> The stack variable 'dnode' in __tipc_sendmsg() may theoretically
> end up tipc_node_get_mtu() as an unitilalized variable.
>
> We fix this by intializing the variable at declaration. We also add
> a default else clause to the two conditiona
From: Doron Roberts-Kedes
Date: Wed, 11 Apr 2018 15:05:16 -0700
> strp_data_ready resets strp->need_bytes to 0 if strp_peek_len indicates
> that the remainder of the message has been received. However,
> do_strp_work does not reset strp->need_bytes to 0. If do_strp_work
> completes a partial mess
From: Anders Roxell
Date: Wed, 11 Apr 2018 17:17:34 +0200
> Script in_netns.sh isn't installed.
>
> running psock_fanout test
>
> ./run_afpackettests: line 12: ./in_netns.sh: No such file or directory
> [FAIL]
>
> running psock_tpacke
From: Nathan Fontenot
Date: Wed, 11 Apr 2018 10:09:26 -0500
> When updating parameters for the ibmvnic driver there is a possibility
> of entering an infinite loop if a return value other that a partial
> success is received from sending the login CRQ.
>
> Also, a deadlock can occur on the rtnl
From: Eric Dumazet
Date: Wed, 11 Apr 2018 14:46:00 -0700
> Since neigh_dump_table() calls nlmsg_parse() without giving policy
> constraints, attributes can have arbirary size that we must validate
>
> Reported by syzbot/KMSAN :
...
> Fixes: 21fdd092acc7 ("net: Add support for filtering neigh du
From: Eric Dumazet
Date: Wed, 11 Apr 2018 14:36:28 -0700
> syzbot/KMSAN reported an uninit-value in tcp_parse_options() [1]
>
> I believe this was caused by a TCP_MD5SIG being set on live
> flow.
>
> This is highly unexpected, since TCP option space is limited.
>
> For instance, presence of TC
From: Jon Maloy
Date: Wed, 11 Apr 2018 22:52:09 +0200
> When a topology subscription is created, we may encounter (or KASAN
> may provoke) a failure to create a corresponding service instance in
> the binding table. Instead of letting the tipc_nametbl_subscribe()
> report the failure back to the
From: Raghuram Chary J
Date: Wed, 11 Apr 2018 20:36:36 +0530
> The patch is to configure DSP registers of PHY device
> to handle Gbe-EEE failures with >40m cable length.
>
> Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000
> Ethernet device driver")
> Signed-off-by: Raghu
From: Elad Nachman
Date: Wed, 11 Apr 2018 15:07:40 +
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11
> 17:04:00.586057300 +0300
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c2018-04-11
> 17:05:33.601992400 +0300
> @@ -3293,17 +3293,19 @@ dma_map_err:
>
> sta
From: Laura Abbott
Date: Tue, 10 Apr 2018 18:04:29 -0700
> There's an ongoing effort to remove VLAs[1] from the kernel to eventually
> turn on -Wvla. Remove the VLAs from the mISDN code by switching to using
> kstrdup in one place and using an upper bound in another.
>
> Signed-off-by: Laura Abb
From: Kees Cook
Date: Tue, 10 Apr 2018 17:52:34 -0700
> In the quest to remove VLAs from the kernel[1], this replaces the VLA
> size with the only possible size used in the code, and adds a mechanism
> to double-check future IV sizes.
>
> [1]
> https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpa
On 04/12/2018 01:56 AM, John Fastabend wrote:
> While testing sockmap with more programs (besides our test programs)
> I found a couple issues.
>
> The attached series fixes an issue where pinned maps were not
> working correctly, blocking sockets returned zero, and an error
> path that when the s
On Tue, Apr 10, 2018 at 03:41:53PM +0100, Quentin Monnet wrote:
> Add documentation for eBPF helper functions to bpf.h user header file.
> This documentation can be parsed with the Python script provided in
> another commit of the patch series, in order to provide a RST document
> that can later be
Add a simple set of tests for the IPsec xfrm commands.
Signed-off-by: Shannon Nelson
---
tools/testing/selftests/net/rtnetlink.sh | 103 +++
1 file changed, 103 insertions(+)
diff --git a/tools/testing/selftests/net/rtnetlink.sh
b/tools/testing/selftests/net/rtnetli
On Mon, 2018-04-09 at 13:43 +0100, Colin King wrote:
> From: Colin Ian King
>
> There are several lines where there is an extraneous space causing
> indentation misalignment. Remove them.
>
> Cleans up Cocconelle warnings:
>
> ./drivers/net/ethernet/mellanox/mlx5/core/qp.c:409:3-18: code aligne
On Mon 2018-03-19 18:33:56, Pavel Machek wrote:
> On Mon 2018-03-19 10:40:08, Dan Williams wrote:
> > On Mon, 2018-03-19 at 10:21 +0100, Pavel Machek wrote:
> > > On Mon 2018-03-19 05:17:45, Woody Suwalski wrote:
> > > > Pavel Machek wrote:
> > > > > Hi!
> > > > >
> > > > > With recent linux-next,
On 4/12/2018 1:20 PM, Or Gerlitz wrote:
On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
wrote:
On 11/12/2017 11:49 AM, Or Gerlitz wrote:
Hi Dave and all,
During and after the BoF on SRIOV switchdev mode, we came into a
consensus among the developers from four different HW vendors (CC
audi
On Thu, Apr 12, 2018 at 8:05 PM, Samudrala, Sridhar
wrote:
> On 11/12/2017 11:49 AM, Or Gerlitz wrote:
>>
>> Hi Dave and all,
>>
>> During and after the BoF on SRIOV switchdev mode, we came into a
>> consensus among the developers from four different HW vendors (CC
>> audience) that a correct thin
On 04/12/2018 09:25 AM, Ivan Khoronzhuk wrote:
> The CPDMA_TX_PRIORITY_MAP in real is vlan pcp field priority mapping
> register and basically replaces vlan pcp field for tagged packets.
> So, set it to be 1:1 mapping.
"Otherwise, it will cause unexpected change of egress vlan tagged packets,
l
Hello,
On Thu, 12 Apr 2018, Stephen Suryaputra wrote:
> Thanks for the feedbacks. Please see the detail below:
>
> On Wed, Apr 11, 2018 at 3:37 PM, Julian Anastasov wrote:
> [snip]
> >> - __IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
> >> + __IP_INC_STATS(net, skb_dst(skb)->dev
Many distributions and users prefer to handle router advertisements in
userspace; one example is OpenWrt, which includes a combined RA and DHCPv6
client. For such configurations, accept_ra should not be enabled by
default.
As setting net.ipv6.conf.default.accept_ra via sysctl.conf or similar
facil
On Wed, 2018-04-11 at 19:59 -0700, Eric Dumazet wrote:
>
> On 04/11/2018 04:47 PM, Saeed Mahameed wrote:
> >
> > Well if we allow devices to access HW counters via FW command
> > interfaces in ndo_get_stats and by testing mlx5 where we query up
> > to 5
> > hw registers, it could take 100us, stil
Call to flush SAs doesn't release xfrm_state in case there was a
traffic associated with that state and state was already deleted.
Given patch calls xfrm_policy_cache_flush despite of actual states
deleted in xfrm_state_flush function.
Signed-off-by: Jacek Kalwas
---
net/xfrm/xfrm_state.c | 6 +
Status checking in xfrm_input doesn't cover CRYPTO_GENERIC_ERROR and
CRYPTO_INVALID_PACKET_SYNTAX.
Given patch adds additional check for CRYPTO_INVALID_PACKET_SYNTAX and
treats CRYPTO_GENERIC_ERROR as status matching LINUX_MIB_XFRMINERROR.
Signed-off-by: Jacek Kalwas
---
net/xfrm/xfrm_input.c |
In case NIC has support for ESP TX CSUM offload skb->ip_summed is not
set to CHECKSUM_PARTIAL which results in checksum calculated by SW.
Fix enables ESP TX CSUM for UDP by extending condition with check for
NETIF_F_HW_ESP_TX_CSUM.
Signed-off-by: Jacek Kalwas
---
net/ipv4/ip_output.c | 2 +-
1
Use l2tp_tunnel_get_nth() instead of l2tp_tunnel_find_nth(), to be safe
against concurrent tunnel deletion.
Use the same mechanism as in l2tp_ppp.c for dropping the reference
taken by l2tp_tunnel_get_nth(). That is, drop the reference just
before looking up the next tunnel. In case of error, drop
Using l2tp_tunnel_find_nth() is racy, because the returned tunnel can
go away as soon as this function returns. This series introduce
l2tp_tunnel_get_nth() as a safe replacement to fixes these races.
With this series, all unsafe tunnel/session lookups are finally gone.
Guillaume Nault (3):
l2tp
Use l2tp_tunnel_get_nth() instead of l2tp_tunnel_find_nth(), to be safe
against concurrent tunnel deletion.
Unlike sessions, we can't drop the reference held on tunnels in
pppol2tp_seq_show(). Tunnels are reused across several calls to
pppol2tp_seq_start() when iterating over sessions. These itera
l2tp_tunnel_find_nth() is unsafe: no reference is held on the returned
tunnel, therefore it can be freed whenever the caller uses it.
This patch defines l2tp_tunnel_get_nth() which works similarly, but
also takes a reference on the returned tunnel. The caller then has to
drop it after it stops usin
Hello Jason,
The patch fixed the issue.
Thank you very much!
On 04/11/2018 10:50 AM, Jason Wang wrote:
I suspect a kick is missed in the XDP_TX case.
Could you please try the attached patch to see if it fixes the issue?
Thanks
--
Kimitoshi Takahashi
On Mon, Apr 09, 2018 at 07:19:31AM -0700, Richard Cochran wrote:
> Dave, please hold off on this patch. I am seeing new problems in my
> testing with this applied. I still need to get to the bottom of
> this.
Looks like the new problems are a HW/board glitch.
The patch is good to go.
Thanks,
Send a netlink notification when userspace adds a manually configured
address if DAD is enabled and optimistic flag isn't set.
Moreover send RTM_DELADDR notifications for tentative addresses.
Some userspace applications (e.g. NetworkManager) are interested in
addr netlink events albeit the address
On 11/12/2017 11:49 AM, Or Gerlitz wrote:
Hi Dave and all,
During and after the BoF on SRIOV switchdev mode, we came into a
consensus among the developers from four different HW vendors (CC
audience) that a correct thing to do would be to disallow any new
extensions to the legacy mode.
The idea
- Original Message -
> Here's a second version of the patch (now a patch set) to eliminate
> rhashtable_walk_peek in gfs2.
>
> The first patch introduces lockref_put_not_zero, the inverse of
> lockref_get_not_zero.
>
> The second patch eliminates rhashtable_walk_peek in gfs2. In
> gfs2_g
nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
attribute being present, but doesn't check whether it is actually
provided by the user. Same goes for nfc_genl_fw_download() and
NFC_ATTR_FIRMWARE_NAME.
This patch adds appropriate checks.
Found with syzkaller.
Signed-off-by: Andre
Mark Brown writes:
> On Mon, Apr 02, 2018 at 04:26:49PM +0200, Robert Jarzmik wrote:
>> As the pxa architecture switched towards the dmaengine slave map, the
>> old compatibility mechanism to acquire the dma requestor line number and
>> priority are not needed anymore.
>
> Acked-by: Mark Brown
>
Hi David,
In the slides referenced, you recommend adding an "unreachable
default" route to the end of each VRF route table. In my testing (for
v4) this results in a change to fib lookup failures such that instead
of ENETUNREACH being returned, EHOSTUNREACH is returned since the fib
finds the unre
On 04/11/2018 06:48 PM, Jia-Ju Bai wrote:
> b53_switch_reset_gpio() is never called in atomic context.
>
> The call chain ending up at b53_switch_reset_gpio() is:
> [1] b53_switch_reset_gpio() <- b53_switch_reset() <-
> b53_reset_switch() <- b53_setup()
>
> b53_switch_reset_gpio() is set as
On Wed, Apr 11, 2018 at 5:06 AM, Michal Kubecek wrote:
> On Wed, Apr 11, 2018 at 12:58:37PM +0200, Michal Kubecek wrote:
>> There is something else I don't understand, though. In the case of
>> acking previously sacked and never retransmitted segment,
>> tcp_clean_rtx_queue() calculates the parame
On Wed, Apr 11, 2018 at 2:36 PM, Eric Dumazet wrote:
>
> syzbot/KMSAN reported an uninit-value in tcp_parse_options() [1]
>
> I believe this was caused by a TCP_MD5SIG being set on live
> flow.
>
> This is highly unexpected, since TCP option space is limited.
>
> For instance, presence of TCP MD5
Thanks for the feedbacks. Please see the detail below:
On Wed, Apr 11, 2018 at 3:37 PM, Julian Anastasov wrote:
[snip]
>> - __IP_INC_STATS(net, IPSTATS_MIB_INHDRERRORS);
>> + __IP_INC_STATS(net, skb_dst(skb)->dev, IPSTATS_MIB_INHDRERRORS);
>
> May be skb->dev if we want to account
From: Edward Cree
Date: Thu, 12 Apr 2018 16:24:46 +0100
> This code is not handling expiration of old ARFS filters, it's inserting
> new ones.
Then simply make the work process a queue, and add entries to the queue
here if the work is already scheduled.
Is there a reason why that wouldn't work
On Thu, 12 Apr 2018 16:56:53 +0200 Christoph Hellwig wrote:
> On Thu, Apr 12, 2018 at 04:51:23PM +0200, Christoph Hellwig wrote:
> > On Thu, Apr 12, 2018 at 03:50:29PM +0200, Jesper Dangaard Brouer wrote:
> > > ---
> > > Implement support for keeping the DMA mapping through the XDP
On Mon, Apr 02, 2018 at 04:26:49PM +0200, Robert Jarzmik wrote:
> As the pxa architecture switched towards the dmaengine slave map, the
> old compatibility mechanism to acquire the dma requestor line number and
> priority are not needed anymore.
Acked-by: Mark Brown
If there's no dependency I'm
On 12/04/18 16:11, David Miller wrote:
> From: Edward Cree
> Date: Thu, 12 Apr 2018 15:02:50 +0100
>
>> A misconfigured system (e.g. with all interrupts affinitised to all CPUs)
>> may produce a storm of ARFS steering events. With the existing sfc ARFS
>> implementation, that could create a bac
On Thu, Apr 12, 2018 at 11:11 PM, Icenowy Zheng wrote:
>
>
> 于 2018年4月12日 GMT+08:00 下午10:56:28, Maxime Ripard
> 写到:
>>On Wed, Apr 11, 2018 at 10:16:39PM +0800, Icenowy Zheng wrote:
>>> From: Chen-Yu Tsai
>>>
>>> On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
>>> address space
> > @@ -2097,6 +2098,25 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
> > (void)lan78xx_set_eee(dev->net, &edata);
> > }
> >
> > + if (!of_property_read_u32_array(dev->udev->dev.of_node,
> > + "microchip,led-modes",
> > +
> -Original Message-
> From: Michael S. Tsirkin [mailto:m...@redhat.com]
> Sent: Thursday, April 12, 2018 4:05 PM
> To: Karlsson, Magnus
> Cc: Björn Töpel ; Duyck, Alexander H
> ; alexander.du...@gmail.com;
> john.fastab...@gmail.com; a...@fb.com; bro...@redhat.com;
> willemdebruijn.ker.
On Thu, Apr 12, 2018 at 08:03:49AM -0700, Richard Cochran wrote:
> On Wed, Apr 11, 2018 at 04:38:44PM -0700, Jesus Sanchez-Palencia wrote:
> > Just breaking this down a bit, yes, TAI is the network time base, and the
> > NICs
> > PTP clock use that because PTP is (commonly) based on TAI. After the
Andrew,
On 12/04/2018 15:16, Andrew Lunn wrote:
> On Thu, Apr 12, 2018 at 02:55:34PM +0100, Phil Elwell wrote:
>> Add two new Device Tree properties:
>> * microchip,eee-enabled - a boolean to enable EEE
>> * microchip,tx-lpi-timer - time in microseconds to wait after TX goes
>>
于 2018年4月12日 GMT+08:00 下午10:56:28, Maxime Ripard 写到:
>On Wed, Apr 11, 2018 at 10:16:39PM +0800, Icenowy Zheng wrote:
>> From: Chen-Yu Tsai
>>
>> On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
>> address space; on the A64 SoC this register is in the SRAM controller
>> address
From: Edward Cree
Date: Thu, 12 Apr 2018 15:02:50 +0100
> A misconfigured system (e.g. with all interrupts affinitised to all CPUs)
> may produce a storm of ARFS steering events. With the existing sfc ARFS
> implementation, that could create a backlog of workitems that grinds the
> system to
On Wed, Apr 11, 2018 at 04:38:44PM -0700, Jesus Sanchez-Palencia wrote:
> Just breaking this down a bit, yes, TAI is the network time base, and the NICs
> PTP clock use that because PTP is (commonly) based on TAI. After the PHCs have
> been synchronized over the network (e.g. with ptp4l), my unders
Hi,
On Wed, Apr 11, 2018 at 10:16:41PM +0800, Icenowy Zheng wrote:
> Allwinner A64 has a SRAM controller, and in the device tree currently
> we have a syscon node to enable EMAC driver to access the EMAC clock
> register. As SRAM controller driver can now export regmap for this
> register, replace
On Thu, Apr 12, 2018 at 04:51:23PM +0200, Christoph Hellwig wrote:
> On Thu, Apr 12, 2018 at 03:50:29PM +0200, Jesper Dangaard Brouer wrote:
> > ---
> > Implement support for keeping the DMA mapping through the XDP return
> > call, to remove RX map/unmap calls. Implement bulking for XD
On Wed, Apr 11, 2018 at 10:16:39PM +0800, Icenowy Zheng wrote:
> From: Chen-Yu Tsai
>
> On the Allwinner R40 SoC, the "GMAC clock" register is in the CCU
> address space; on the A64 SoC this register is in the SRAM controller
> address space, and with a different offset.
>
> To access the regist
On Thu, Apr 12, 2018 at 03:50:29PM +0200, Jesper Dangaard Brouer wrote:
> ---
> Implement support for keeping the DMA mapping through the XDP return
> call, to remove RX map/unmap calls. Implement bulking for XDP
> ndo_xdp_xmit and XDP return frame API. Bulking allows to perform DMA
>
> @@ -2097,6 +2098,25 @@ static int lan78xx_phy_init(struct lan78xx_net *dev)
> (void)lan78xx_set_eee(dev->net, &edata);
> }
>
> + if (!of_property_read_u32_array(dev->udev->dev.of_node,
> + "microchip,led-modes",
> +
Hi Andrew,
On 12/04/2018 15:30, Andrew Lunn wrote:
> On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
>> The Microchip LAN78XX family of devices are Ethernet controllers with
>> a USB interface. Despite being discoverable devices it can be useful to
>> be able to configure them from De
Hi Andrew,
On 12/04/2018 15:26, Andrew Lunn wrote:
> On Thu, Apr 12, 2018 at 02:55:35PM +0100, Phil Elwell wrote:
>> Add support for DT property "microchip,led-modes", a vector of two
>> cells (u32s) in the range 0-15, each of which sets the mode for one
>> of the two LEDs. Some possible values ar
On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications withou
On Thu, Apr 12, 2018 at 02:55:35PM +0100, Phil Elwell wrote:
> Add support for DT property "microchip,led-modes", a vector of two
> cells (u32s) in the range 0-15, each of which sets the mode for one
> of the two LEDs. Some possible values are:
>
> 0=link/activity 1=link1000/activity
The CPDMA_TX_PRIORITY_MAP in real is vlan pcp field priority mapping
register and basically replaces vlan pcp field for tagged packets.
So, set it to be 1:1 mapping.
Signed-off-by: Ivan Khoronzhuk
---
Based on net/master
drivers/net/ethernet/ti/cpsw.c | 2 +-
1 file changed, 1 insertion(+), 1 d
Hi Andrew,
On 12/04/2018 15:06, Andrew Lunn wrote:
> Hi Phil
>
>> -ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
>> -ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
>> +mac_addr = of_get_mac_address(dev->udev->dev.of_node);
>
> It might be
On Thu, Apr 12, 2018 at 03:10:57PM +0100, Phil Elwell wrote:
> Hi Andrew,
>
> On 12/04/2018 15:04, Andrew Lunn wrote:
> > On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> >> The Microchip LAN78XX family of devices are Ethernet controllers with
> >> a USB interface. Despite being disc
On Thu, Apr 12, 2018 at 02:55:34PM +0100, Phil Elwell wrote:
> Add two new Device Tree properties:
> * microchip,eee-enabled - a boolean to enable EEE
> * microchip,tx-lpi-timer - time in microseconds to wait after TX goes
>idle before entering the low power state
>
2018-04-11 20:43 GMT+02:00 Alexei Starovoitov :
> On 4/11/18 5:17 AM, Björn Töpel wrote:
>>
>>
>> In the current RFC you are required to create both an Rx and Tx
>> queue to bind the socket, which is just weird for your "Rx on one
>> device, Tx to another" scenario. I'll fix that in the next RFC.
>
Hi Andrew,
On 12/04/2018 15:04, Andrew Lunn wrote:
> On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
>> The Microchip LAN78XX family of devices are Ethernet controllers with
>> a USB interface. Despite being discoverable devices it can be useful to
>> be able to configure them from De
Hi Stephen,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Stephen-Suryaputra/Per-interface-IPv4-stats-CONFIG_IP_IFSTATS_TABLE/20180412-181719
reproduce:
# apt-get install sparse
Hi Phil
> - ret = lan78xx_write_reg(dev, RX_ADDRL, addr_lo);
> - ret = lan78xx_write_reg(dev, RX_ADDRH, addr_hi);
> + mac_addr = of_get_mac_address(dev->udev->dev.of_node);
It might be better to use the higher level eth_platform_get_mac_address(
On Thu, Apr 12, 2018 at 07:38:25AM +, Karlsson, Magnus wrote:
> I think you are definitely right in that there are ways in which
> we can improve performance here. That said, the current queue
> performs slightly better than the previous one we had that was
> more or less a copy of one of your
On Thu, Apr 12, 2018 at 02:55:36PM +0100, Phil Elwell wrote:
> The Microchip LAN78XX family of devices are Ethernet controllers with
> a USB interface. Despite being discoverable devices it can be useful to
> be able to configure them from Device Tree, particularly in low-cost
> applications withou
A misconfigured system (e.g. with all interrupts affinitised to all CPUs)
may produce a storm of ARFS steering events. With the existing sfc ARFS
implementation, that could create a backlog of workitems that grinds the
system to a halt. To prevent this, limit the number of workitems that
may
Necessary to allow redirecting a flow when the application moves.
Fixes: 3af0f34290f6 ("sfc: replace asynchronous filter operations")
Signed-off-by: Edward Cree
---
drivers/net/ethernet/sfc/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/sfc/rx.c b/d
Two issues introduced by my recent asynchronous filter handling changes:
1. The old filter_rfs_insert would replace a matching filter of equal
priority; we need to pass the appropriate argument to filter_insert to
make it do the same.
2. It's possible to cause the kernel to hammer ndo_rx_flow
On Thu, Apr 12, 2018 at 02:24:31PM +0800, Xin Long wrote:
> pf->cmp_addr() is called before binding a v6 address to the sock. It
> should not check ports, like in sctp_inet_cmp_addr.
>
> But sctp_inet6_cmp_addr checks the addr by invoking af(6)->cmp_addr,
> sctp_v6_cmp_addr where it also compares
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
This patch set adds support for readi
Add two new Device Tree properties:
* microchip,eee-enabled - a boolean to enable EEE
* microchip,tx-lpi-timer - time in microseconds to wait after TX goes
idle before entering the low power state
(default 600)
Signed-off-by: Phil Elwell
---
The Microchip LAN78XX family of devices are Ethernet controllers with
a USB interface. Despite being discoverable devices it can be useful to
be able to configure them from Device Tree, particularly in low-cost
applications without an EEPROM or programmed OTP.
Document the supported properties in
Add support for DT property "microchip,led-modes", a vector of two
cells (u32s) in the range 0-15, each of which sets the mode for one
of the two LEDs. Some possible values are:
0=link/activity 1=link1000/activity
2=link100/activity 3=link10/activity
4=link100/1000/activ
There is a standard mechanism for locating and using a MAC address from
the Device Tree. Use this facility in the lan78xx driver to support
applications without programmed EEPROM or OTP. At the same time,
regularise the handling of the different address sources.
Signed-off-by: Phil Elwell
---
dr
Heads-up XDP performance nerds!
I got an unpleasant surprise when I updated my GCC compiler (to support
the option -mindirect-branch=thunk-extern). My XDP redirect
performance numbers when cut in half; from approx 13Mpps to 6Mpps
(single CPU core). I've identified the issue, which is caused by
k
On Sun, Apr 01, 2018 at 08:00:54AM -0700, John Fastabend wrote:
> If a socket with pending cork data is closed we do not return the
> memory to the socket until the garbage collector free's the psock
> structure. The garbage collector though can run after the sock has
> completed its close operatio
Hi,
well, it isn't just "fe80::1", it is any IPv6 address which
will be rejected if not called with "-6". I run bisect:
> git bisect start
> # good: [50b8a842e8c098cddb213f5b3076526df88826e8] v4.15.0
> git bisect good 50b8a842e8c098cddb213f5b3076526df88826e8
> # bad: [4b6c4177ee66421770f0bbcc765c
On Wed, Feb 21, 2018 at 3:53 PM, Tommi Rantala
wrote:
> On 20.02.2018 18:26, Neil Horman wrote:
>>
>> On Tue, Feb 20, 2018 at 09:14:41AM +0100, Dmitry Vyukov wrote:
>>>
>>> On Tue, Feb 20, 2018 at 8:56 AM, Tommi Rantala
>>> wrote:
On 19.02.2018 20:59, Dmitry Vyukov wrote:
>
> Is
1 - 100 of 114 matches
Mail list logo
