> -Original Message-
> From: Jakub Kicinski
> Sent: 2020年12月6日 5:40
> To: Joakim Zhang
> Cc: peppe.cavall...@st.com; alexandre.tor...@st.com;
> joab...@synopsys.com; da...@davemloft.net; netdev@vger.kernel.org;
> dl-linux-imx
> Subject: Re: [PATCH V2 0/5] patche
On Fri, 4 Dec 2020 10:46:33 +0800 Joakim Zhang wrote:
> A patch set for stmmac, fix some driver issues.
These don't apply cleanly to the net tree where fixes go:
https://patchwork.kernel.org/project/netdevbpf/list/?delegate=netdev¶m=1&order=date
Please rebase / retest / repost.
A patch set for stmmac, fix some driver issues.
ChangeLogs:
V1->V2:
* add Fixes tag.
* add patch 5/5 into this patch set.
Fugang Duan (5):
net: stmmac: increase the timeout for dma reset
net: stmmac: start phylink instance before stmmac_hw_setup()
net: stmmac: free tx skb bu
> > > On Wed, 2 Dec 2020 10:17:43 -0600 Mario Limonciello wrote:
> > > > commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
> > > systems")
> > > > disabled s0ix flows for systems that have various incarnations of the
> > > > i219-LM ethernet controller. This was done because
tdev;
> > Alexander
> > Duyck; Sasha Netfin; Aaron Brown; Stefan Assmann; David Miller;
> > darc...@redhat.com; Shen, Yijun; Yuan, Perry
> > Subject: Re: [PATCH v2 0/5] Improve s0ix flows for systems i219LM
> >
> >
> > [EXTERNAL EMAIL]
> >
> > O
c...@redhat.com; Shen, Yijun; Yuan, Perry
> Subject: Re: [PATCH v2 0/5] Improve s0ix flows for systems i219LM
>
>
> [EXTERNAL EMAIL]
>
> On Wed, 2 Dec 2020 10:17:43 -0600 Mario Limonciello wrote:
> > commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for
On Wed, 2 Dec 2020 10:17:43 -0600 Mario Limonciello wrote:
> commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME
> systems")
> disabled s0ix flows for systems that have various incarnations of the
> i219-LM ethernet controller. This was done because of some regressions
> cause
commit e086ba2fccda ("e1000e: disable s0ix entry and exit flows for ME systems")
disabled s0ix flows for systems that have various incarnations of the
i219-LM ethernet controller. This was done because of some regressions
caused by an earlier
commit 632fbd5eb5b0e ("e1000e: fix S0ix flows for cable
On Tue, Nov 10, 2020 at 09:44:27AM -0800, Jakub Kicinski wrote:
> On Tue, 10 Nov 2020 10:03:29 +0100 Loic Poulain wrote:
> > On Mon, 9 Nov 2020 at 19:39, Jakub Kicinski wrote:
> > >
> > > On Mon, 9 Nov 2020 09:49:24 +0100 Loic Poulain wrote:
> > > > > Looks like patch 1 is a bug fix and patches
On Tue, 10 Nov 2020 09:44:27 -0800 Jakub Kicinski wrote:
> Thanks! Sounds like net-next will work just fine, but won't you need
> these changes in mhi-next, then? In which case you should send a pull
> request based on Linus' tree so that both Mani and netdev can pull it
> in.
>
> Mani, WDYT?
App
On Tue, 10 Nov 2020 10:03:29 +0100 Loic Poulain wrote:
> On Mon, 9 Nov 2020 at 19:39, Jakub Kicinski wrote:
> >
> > On Mon, 9 Nov 2020 09:49:24 +0100 Loic Poulain wrote:
> > > > Looks like patch 1 is a bug fix and patches 2-5 add a new feature.
> > > > Is that correct?
> > >
> > > That's corre
Hi Jakub,
On Mon, 9 Nov 2020 at 19:39, Jakub Kicinski wrote:
>
> On Mon, 9 Nov 2020 09:49:24 +0100 Loic Poulain wrote:
> > > Looks like patch 1 is a bug fix and patches 2-5 add a new feature.
> > > Is that correct?
> >
> > That's correct, though strictly speaking 2-5 are also bug fix since remote
On Mon, 9 Nov 2020 09:49:24 +0100 Loic Poulain wrote:
> > Looks like patch 1 is a bug fix and patches 2-5 add a new feature.
> > Is that correct?
>
> That's correct, though strictly speaking 2-5 are also bug fix since remote
> node
> communication is supposed to be supported in QRTR to be compa
Hi Jakub,
On Sun, 8 Nov 2020 at 01:26, Jakub Kicinski wrote:
>
> On Fri, 6 Nov 2020 18:33:25 +0100 Loic Poulain wrote:
> > QRTR protocol allows a node to communicate with an other non-immediate
> > node via an intermdediate immediate node acting as a 'bridge':
> >
> > node-0 <=> node-1 <=> node-
On Fri, 6 Nov 2020 18:33:25 +0100 Loic Poulain wrote:
> QRTR protocol allows a node to communicate with an other non-immediate
> node via an intermdediate immediate node acting as a 'bridge':
>
> node-0 <=> node-1 <=> node-2
>
> This is currently not supported in this upstream version and this
QRTR protocol allows a node to communicate with an other non-immediate
node via an intermdediate immediate node acting as a 'bridge':
node-0 <=> node-1 <=> node-2
This is currently not supported in this upstream version and this
series aim to fix that.
This series is V2 because changes 1, 2 and
On Sat, Oct 31, 2020 at 11:31 AM Alexander Duyck
wrote:
>
> Move the test functionality from test_tcpbpf_user into the test_progs
> framework so that it will be run any time the test_progs framework is run.
> This will help to prevent future test escapes as the individual tests, such
> as test_tcp
Move the test functionality from test_tcpbpf_user into the test_progs
framework so that it will be run any time the test_progs framework is run.
This will help to prevent future test escapes as the individual tests, such
as test_tcpbpf_user, are less likely to be run by developers and CI
tests.
As
From: Fabian Frederick
Date: Fri, 25 Sep 2020 15:15:41 +0200
> This small patchet does some clean-up on vxlan.
> Second version removes VXLAN_NL2FLAG macro relevant patches as suggested by
> Michal and David
>
> I hope to have some feedback/ACK from vxlan developers.
Series applied, thanks.
This small patchet does some clean-up on vxlan.
Second version removes VXLAN_NL2FLAG macro relevant patches as suggested by
Michal and David
I hope to have some feedback/ACK from vxlan developers.
Fabian Frederick (5):
vxlan: don't collect metadata if remote checksum is wrong
vxlan: add unli
Hi,
this small series cleans the smsc-phy code a bit and adds the support to
specify the phy clock source. Adding the phy clock source support is
also the main purpose of this series.
Each file has its own changelog.
Regards,
Marco
Marco Felsch (5):
net: phy: smsc: skip ENERGYON interrupt i
On Wed, Jul 29, 2020 at 09:22:36AM -0700, John Fastabend wrote:
> Doing some refactoring resulted in a kernel splat when reading sock_ops
> fields.
>
> Patch 1, has the details and proposed fix for sock_ops sk field access.
>
> Patch 2, has the details and proposed fix for reading sock_ops->sk fi
Doing some refactoring resulted in a kernel splat when reading sock_ops
fields.
Patch 1, has the details and proposed fix for sock_ops sk field access.
Patch 2, has the details and proposed fix for reading sock_ops->sk field
Patch 3, Gives a reproducer and test to verify the fix. I used the netc
From: Bartosz Golaszewski
Date: Sat, 23 May 2020 15:27:06 +0200
> From: Bartosz Golaszewski
>
> Using devres helpers allows to shrink the probing code, avoid memory leaks in
> error paths make sure the order in which resources are freed is the exact
> opposite of their allocation. This series p
From: Bartosz Golaszewski
Using devres helpers allows to shrink the probing code, avoid memory leaks in
error paths make sure the order in which resources are freed is the exact
opposite of their allocation. This series proposes to add a devres variant
of register_netdev() that will only work wit
This series adds helpers for sk_msg program type and based on feedback
from v1 adds *_task_* helpers and probe_* helpers to all networking
programs with perfmon_capable() capabilities.
The list of helpers breaks down as follows,
Networking with perfmon_capable() guard (patch2):
BPF_FUNC_get_cur
This adds bridge offloading for the Intel / Lantiq GSWIP 2.1 switch.
Changes since:
v1:
- fix typo signle -> single
Hauke Mehrtens (5):
net: dsa: lantiq: Allow special tags only on CPU port
net: dsa: lantiq: Add VLAN unaware bridge offloading
net: dsa: lantiq: Add VLAN aware bridge offload
On 4/28/19 1:32 PM, Johannes Berg wrote:
> On Fri, 2019-04-26 at 20:28 -0600, David Ahern wrote:
>>
>> I agree with this set and will help moving forward. As I recall it
>> requires follow up patches for each policy to set strict_start_type
>> opting in to the strict checking. With that in place ne
On Fri, 2019-04-26 at 20:28 -0600, David Ahern wrote:
>
> I agree with this set and will help moving forward. As I recall it
> requires follow up patches for each policy to set strict_start_type
> opting in to the strict checking. With that in place new userspace on
> old kernels will get a failur
From: David Ahern
Date: Fri, 26 Apr 2019 20:28:20 -0600
> On 4/26/19 6:07 AM, Johannes Berg wrote:
>> Here's a respin, with the following changes:
>> * change message when rejecting unknown attribute types (David Ahern)
>> * drop nl80211 patch - I'll apply it separately
>> * remove NL_VALIDATE
On 4/26/19 6:07 AM, Johannes Berg wrote:
> Here's a respin, with the following changes:
> * change message when rejecting unknown attribute types (David Ahern)
> * drop nl80211 patch - I'll apply it separately
> * remove NL_VALIDATE_POLICY - we have a lot of calls to nla_parse()
>that really
When isdn4linux came up in the context of another patch series, I
remembered that we had discussed removing it a while ago.
It turns out that the suggestion from Karsten Keil wa to remove I4L
in 2018 after the last public ISDN networks are shut down. This has
happened now (with a very small number
Here's a respin, with the following changes:
* change message when rejecting unknown attribute types (David Ahern)
* drop nl80211 patch - I'll apply it separately
* remove NL_VALIDATE_POLICY - we have a lot of calls to nla_parse()
that really should be without a policy as it has previously be
Hi Dave,
This patch series addresses the compiler warnings reported when
building the code in net/core with W=1. Please consider this patch
series for kernel v5.2.
Thanks,
Bart.
Changes compared to v1:
- Dropped two patches from this series.
- Rebased this patch series on top of
git://git.ker
Hi Jian-Hong,
Am 31.01.19 um 17:21 schrieb Jian-Hong Pan:
> This series refines the commit 48e5bb6cec79 ("net: Prepare LoRaWAN
> socket module") for coding style.
> Besides, sperates LoRaWAN related skb definitions from
> lora/lorawan_netdev.h into another header lora/lorawan/skb.h.
Sorry for the
On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote:
> This series tries to access virtqueue metadata through kernel virtual
> address instead of copy_user() friends since they had too much
> overheads like checks, spec barriers or even hardware feature
> toggling. This is done through setup
This series tries to access virtqueue metadata through kernel virtual
address instead of copy_user() friends since they had too much
overheads like checks, spec barriers or even hardware feature
toggling. This is done through setup kernel address through vmap() and
resigter MMU notifier for invalid
Hello,
This series refines the commit 48e5bb6cec79 ("net: Prepare LoRaWAN
socket module") for coding style.
Besides, sperates LoRaWAN related skb definitions from
lora/lorawan_netdev.h into another header lora/lorawan/skb.h.
Thanks,
Jian-Hong Pan
Jian-Hong Pan (5):
net: lorawan: Refine the cod
Some Qualcomm SoCs sport a ethqos controller which use DW ip, so add
the glue driver which uses stmmac driver along with DT bindings for
this device.
This controller supports rgmii mode and doesn't work with existing
phy drivers as they do not remove the phy delay delay in this mode,
so fix the tw
On Fri, Dec 14, 2018 at 06:24:40PM +0800, jiangyiwen wrote:
> On 2018/12/12 23:09, Michael S. Tsirkin wrote:
> > On Wed, Dec 12, 2018 at 05:25:50PM +0800, jiangyiwen wrote:
> >> Now vsock only support send/receive small packet, it can't achieve
> >> high performance. As previous discussed with Jaso
On 2018/12/12 23:09, Michael S. Tsirkin wrote:
> On Wed, Dec 12, 2018 at 05:25:50PM +0800, jiangyiwen wrote:
>> Now vsock only support send/receive small packet, it can't achieve
>> high performance. As previous discussed with Jason Wang, I revisit the
>> idea of vhost-net about mergeable rx buffer
On 2018/12/14 0:34, Stefan Hajnoczi wrote:
> On Wed, Dec 12, 2018 at 05:25:50PM +0800, jiangyiwen wrote:
>> Now vsock only support send/receive small packet, it can't achieve
>> high performance. As previous discussed with Jason Wang, I revisit the
>> idea of vhost-net about mergeable rx buffer and
On Wed, Dec 12, 2018 at 05:25:50PM +0800, jiangyiwen wrote:
> Now vsock only support send/receive small packet, it can't achieve
> high performance. As previous discussed with Jason Wang, I revisit the
> idea of vhost-net about mergeable rx buffer and implement the mergeable
> rx buffer in vhost-vs
On 2018/12/12 23:09, Michael S. Tsirkin wrote:
> On Wed, Dec 12, 2018 at 05:25:50PM +0800, jiangyiwen wrote:
>> Now vsock only support send/receive small packet, it can't achieve
>> high performance. As previous discussed with Jason Wang, I revisit the
>> idea of vhost-net about mergeable rx buffer
On Wed, Dec 12, 2018 at 05:25:50PM +0800, jiangyiwen wrote:
> Now vsock only support send/receive small packet, it can't achieve
> high performance. As previous discussed with Jason Wang, I revisit the
> idea of vhost-net about mergeable rx buffer and implement the mergeable
> rx buffer in vhost-vs
Now vsock only support send/receive small packet, it can't achieve
high performance. As previous discussed with Jason Wang, I revisit the
idea of vhost-net about mergeable rx buffer and implement the mergeable
rx buffer in vhost-vsock, it can allow big packet to be scattered in
into different buffe
On 2018-10-05 06:59, Björn Töpel wrote:
On 2018-10-04 23:18, Jesper Dangaard Brouer wrote:
I see similar performance numbers, but my system can crash with 'txonly'.
Thanks for finding this, Jesper!
Can you give me your "lspci -vvv" dump of your NIC, so I know what ixgbe
flavor you've got?
I'
On 2018-10-04 23:18, Jesper Dangaard Brouer wrote:
I see similar performance numbers, but my system can crash with 'txonly'.
Thanks for finding this, Jesper!
Can you give me your "lspci -vvv" dump of your NIC, so I know what ixgbe
flavor you've got?
I'll dig into it right away.
Björn
On Tue, 2 Oct 2018 10:00:29 +0200
Björn Töpel wrote:
> From: Björn Töpel
>
> Jeff: Please remove the v1 patches from your dev-queue!
>
> This patch set introduces zero-copy AF_XDP support for Intel's ixgbe
> driver.
>
> The ixgbe zero-copy code is located in its own file ixgbe_xsk.[ch],
> an
On Tue, Oct 2, 2018 at 11:39 AM Björn Töpel wrote:
>
> On 2018-10-02 20:23, William Tu wrote:
> > On Tue, Oct 2, 2018 at 1:01 AM Björn Töpel wrote:
> >>
> >> From: Björn Töpel
> >>
> >> Jeff: Please remove the v1 patches from your dev-queue!
> >>
> >> This patch set introduces zero-copy AF_XDP s
On 2018-10-02 20:23, William Tu wrote:
On Tue, Oct 2, 2018 at 1:01 AM Björn Töpel wrote:
From: Björn Töpel
Jeff: Please remove the v1 patches from your dev-queue!
This patch set introduces zero-copy AF_XDP support for Intel's ixgbe
driver.
The ixgbe zero-copy code is located in its own fil
On Tue, Oct 2, 2018 at 1:01 AM Björn Töpel wrote:
>
> From: Björn Töpel
>
> Jeff: Please remove the v1 patches from your dev-queue!
>
> This patch set introduces zero-copy AF_XDP support for Intel's ixgbe
> driver.
>
> The ixgbe zero-copy code is located in its own file ixgbe_xsk.[ch],
> analogou
From: Björn Töpel
Jeff: Please remove the v1 patches from your dev-queue!
This patch set introduces zero-copy AF_XDP support for Intel's ixgbe
driver.
The ixgbe zero-copy code is located in its own file ixgbe_xsk.[ch],
analogous to the i40e ZC support. Again, as in i40e, code paths have
been co
Build warnings cleanup reported for
- using only 128b key
- wait for buffer in sendmsg/sendpage
- check for null before using skb
- free rspq_skb_cache in error path
- indentation
v2:
Added bug report description for 0002
Incorported comments from Dan Carpenter
Atul Gupta (5):
crypto:chtls:
Hi,
This a second version of a patchset, which introduces ACPI support
in mvpp2 driver. Comparing to the initial one, all patches
touching generic ACPI MDIO bus / PHY handling were removed
and after some modifications will be resend separately. They
may require a longer discussion in terms of phyl
On Mon, Dec 18, 2017 at 07:39:50PM +0100, Knut Omang wrote:
> On Mon, 2017-12-18 at 17:56 +, Bart Van Assche wrote:
> > On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> > > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
> > >
> > > > > Today when we run checkers we get
On Mon, 2017-12-18 at 17:56 +, Bart Van Assche wrote:
> On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> > On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
> >
> > > > Today when we run checkers we get so many warnings it is too hard to
> > > > make any sense of it.
> >
On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
>
> > > Today when we run checkers we get so many warnings it is too hard to
> > > make any sense of it.
> >
> > Here is a list of the checkpatch messages for drivers/infiniban
On Mon, 2017-12-18 at 10:46 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
>
> > > Today when we run checkers we get so many warnings it is too hard to
> > > make any sense of it.
> >
> > Here is a list of the checkpatch messages for drivers/infiniban
On Mon, Dec 18, 2017 at 02:05:15PM +0100, Knut Omang wrote:
> https://github.com/torvalds/linux/compare/master...knuto:runchecks
Several of these to rdma/core do not look so big, you should think
about sending them..
Jason
On Sun, Dec 17, 2017 at 10:00:17PM -0800, Joe Perches wrote:
> > Today when we run checkers we get so many warnings it is too hard to
> > make any sense of it.
>
> Here is a list of the checkpatch messages for drivers/infiniband
> sorted by type.
>
> Many of these might be corrected by using
>
On Mon, 2017-12-18 at 07:30 -0800, Joe Perches wrote:
> On Mon, 2017-12-18 at 14:05 +0100, Knut Omang wrote:
> > > Here is a list of the checkpatch messages for drivers/infiniband
> > > sorted by type.
> > >
> > > Many of these might be corrected by using
> > >
> > > $ ./scripts/checkpatch.pl -f
On Mon, 2017-12-18 at 14:05 +0100, Knut Omang wrote:
> > Here is a list of the checkpatch messages for drivers/infiniband
> > sorted by type.
> >
> > Many of these might be corrected by using
> >
> > $ ./scripts/checkpatch.pl -f --fix-inplace --types= \
> > $(git ls-files drivers/infiniband/)
>
On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
>
> > > I like the ability to add more checkers and keep then in the main
> > > upstream tree. But adding overrides for specific subsystems goes against
> > > the policy that all
On Sun, 2017-12-17 at 22:00 -0800, Joe Perches wrote:
> On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote:
> > On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
> >
> > > > I like the ability to add more checkers and keep then in the main
> > > > upstream tree. But adding override
On Sun, 2017-12-17 at 22:00 -0700, Jason Gunthorpe wrote:
> On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
>
> > > I like the ability to add more checkers and keep then in the main
> > > upstream tree. But adding overrides for specific subsystems goes against
> > > the policy that all
On Sun, Dec 17, 2017 at 03:14:10AM +0100, Knut Omang wrote:
> > I like the ability to add more checkers and keep then in the main
> > upstream tree. But adding overrides for specific subsystems goes against
> > the policy that all subsystems should be treated equally.
>
> This is a tool to enable
On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote:
> On Sat, 16 Dec 2017 15:42:25 +0100
> Knut Omang wrote:
>
> > This patch series implements features to make it easier to run checkers on
> > the
> > entire kernel as part of automatic and developer testing.
> >
> > This is done by rep
On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote:
> On Sat, 16 Dec 2017 15:42:25 +0100
> Knut Omang wrote:
>
> > This patch series implements features to make it easier to run checkers on
> > the
> > entire kernel as part of automatic and developer testing.
> >
> > This is done by rep
On Sat, 16 Dec 2017 15:42:25 +0100
Knut Omang wrote:
> This patch series implements features to make it easier to run checkers on the
> entire kernel as part of automatic and developer testing.
>
> This is done by replacing the sparse specific setup for the C={1,2} variable
> in the makefiles wi
This patch series implements features to make it easier to run checkers on the
entire kernel as part of automatic and developer testing.
This is done by replacing the sparse specific setup for the C={1,2} variable
in the makefiles with setup for running scripts/runchecks, a new program that
can ru
Hello,
after the round of review on our v1 patch (you can find the relevant
thread here [1]) we have improved our code of TCP Wave, a new congestion
control algorithm.
Context: TCP Wave (TCPW) replaces the window-based transmission paradigm
of the standard TCP with a burst-based transmission, the
Junote Cai reported that he was not able to get a DSA setup involving the
DPAA/FMAN driver to work and narrowed it down to of_find_net_device_by_node()
call in DSA setup. The initial attempt to fix this by adding of_node to the
platform device results in a second, failed, probing of the FMan MAC dr
v2:
* Moved tests to tools/testing/vsock/. I was unable to put them in selftests/
because they require manual setup of a VMware/KVM guest.
* Moved to __vsock_in_bound/connected_table() to af_vsock.h
* Fixed local variable ordering in Patch 4
There is currently no way for userspace to query
Hi,
Changes since v1:
- Solved the mqprio dependency;
- Fixed a mqprio bug, that caused the inner qdisc to have a wrong
dev_queue associated with it;
Changes from the RFC:
- Fixed comments from Henrik Austad;
- Simplified the Qdisc, using the generic implementation of callbacks
where po
From: Corentin Labbe
Date: Fri, 1 Sep 2017 13:55:59 +0200
> This patch series fix minor problems found when working on the
> dwmac-sun8i syscon mdio-mux.
...
> Changes since v1:
> - Removed obsolete comment about of_mdio_find_bus/put_device
> - removed more DRV_VERSION
Series applied to net-ne
Hello
This patch series fix minor problems found when working on the
dwmac-sun8i syscon mdio-mux.
Regards
Changes since v1:
- Removed obsolete comment about of_mdio_find_bus/put_device
- removed more DRV_VERSION
Corentin Labbe (5):
net: mdio-mux: Fix NULL Comparison style
net: mdio-mux: Rem
On Fri, Aug 18, 2017 at 11:11:33AM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> Currently Renesas R-Car Gen2 SoCs use the common clk-rcar-gen2,
> clk-mstp, and clk-div6 drivers, which depend on most clocks being
> described in DT. Especially the module (MSTP) clocks are cumberso
Hi Simon, Magnus,
Currently Renesas R-Car Gen2 SoCs use the common clk-rcar-gen2,
clk-mstp, and clk-div6 drivers, which depend on most clocks being
described in DT. Especially the module (MSTP) clocks are cumbersome and
error prone, due to 3 arrays (clocks, clock-indices, and
clock-output
This series collects patches from v1 which deal with potential memory leaks.
No changes to the actual patches, just splitting into smaller series.
Phil Sutter (5):
ipvrf: Fix error path of vrf_switch()
ifstat: Fix memleak in error case
ifstat: Fix memleak in dump_kern_db() for json output
This series collects patches from v1 which eliminate possible cases of
NULL pointer dereferences.
No changes to the actual patches, just splitting into smaller series.
Phil Sutter (5):
ifstat, nstat: Check fdopen() return value
nstat: Fix for potential NULL pointer dereference
tc/q_netem: D
On Tue, Jun 13, 2017 at 03:28:42PM -0700, David Daney wrote:
> Changes in v2:
>
> - Squash a couple of the uasm cleanups.
>
> - Make insn_table_MM const (suggested by Matt Redfearn)
>
> - Put the eBPF in its own source file (should fix build
> warnings/errors on 32-bit kernel builds).
Changes in v2:
- Squash a couple of the uasm cleanups.
- Make insn_table_MM const (suggested by Matt Redfearn)
- Put the eBPF in its own source file (should fix build
warnings/errors on 32-bit kernel builds).
- Use bpf_jit_binary_alloc() (suggested by Daniel Borkmann)
- Implement
Changes since v1:
* credit Pablo and Jamal
* incorporate suggestion from David Ahern
* fix compilation in decnet
On Tue, Mar 14, 2017 at 05:34:02PM -0700, David Daney wrote:
> > What tree are you targetting with these changes? Do you expect
> > them to go via the MIPS or the net-next tree?
> >
> > Please be explicit about this in the future.
> >
>
> Sorry I didn't mention it.
>
> My expectation is that
From: David Daney
Date: Tue, 14 Mar 2017 17:34:02 -0700
> On 03/14/2017 05:29 PM, David Miller wrote:
>> From: David Daney
>> Date: Tue, 14 Mar 2017 14:21:39 -0700
>>
>>> Changes from v1:
>>>
>>> - Use unsigned access for SKF_AD_HATYPE
>>>
>>> - Added three more patches for other problems fo
On 03/14/2017 05:29 PM, David Miller wrote:
From: David Daney
Date: Tue, 14 Mar 2017 14:21:39 -0700
Changes from v1:
- Use unsigned access for SKF_AD_HATYPE
- Added three more patches for other problems found.
Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module
ident
From: David Daney
Date: Tue, 14 Mar 2017 14:21:39 -0700
> Changes from v1:
>
> - Use unsigned access for SKF_AD_HATYPE
>
> - Added three more patches for other problems found.
>
>
> Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module
> identified some failures and unimp
On 03/14/2017 03:49 PM, Alexei Starovoitov wrote:
On Tue, Mar 14, 2017 at 02:21:39PM -0700, David Daney wrote:
Changes from v1:
- Use unsigned access for SKF_AD_HATYPE
- Added three more patches for other problems found.
Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf mod
On Tue, Mar 14, 2017 at 02:21:39PM -0700, David Daney wrote:
> Changes from v1:
>
> - Use unsigned access for SKF_AD_HATYPE
>
> - Added three more patches for other problems found.
>
>
> Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module
> identified some failures and un
On 03/14/2017 03:29 PM, Daniel Borkmann wrote:
On 03/14/2017 10:21 PM, David Daney wrote:
Changes from v1:
- Use unsigned access for SKF_AD_HATYPE
- Added three more patches for other problems found.
Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module
identified some
On 03/14/2017 10:21 PM, David Daney wrote:
Changes from v1:
- Use unsigned access for SKF_AD_HATYPE
- Added three more patches for other problems found.
Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module
identified some failures and unimplemented features.
Nice, th
Changes from v1:
- Use unsigned access for SKF_AD_HATYPE
- Added three more patches for other problems found.
Testing the BPF JIT on Cavium OCTEON (mips64) with the test-bpf module
identified some failures and unimplemented features.
With this patch set we get:
test_bpf: Summary: 305
On Wed, Feb 08, 2017 at 08:39:13AM -0800, John Fastabend wrote:
> [...]
>
> > However, I came up with a new idea for the future and I'd like to show
> > where I'm going. The idea is that we don't use s/g buffers on RX, so we
> > have a pointer per descriptor untapped. So we can allow users to st
[...]
> However, I came up with a new idea for the future and I'd like to show
> where I'm going. The idea is that we don't use s/g buffers on RX, so we
> have a pointer per descriptor untapped. So we can allow users to stick
> their own pointer in there, if they promise not to use s/g on this v
From: "Michael S. Tsirkin"
Date: Tue, 7 Feb 2017 06:15:13 +0200
> On Thu, Feb 02, 2017 at 07:14:05PM -0800, John Fastabend wrote:
>> This series adds adjust head support for virtio. The following is my
>> test setup. I use qemu + virtio as follows,
>>
>> ./x86_64-softmmu/qemu-system-x86_64 \
>>
On Thu, Feb 02, 2017 at 07:14:05PM -0800, John Fastabend wrote:
> This series adds adjust head support for virtio. The following is my
> test setup. I use qemu + virtio as follows,
>
> ./x86_64-softmmu/qemu-system-x86_64 \
> -hda /var/lib/libvirt/images/Fedora-test0.img \
> -m 4096 -enable-kv
From: "Michael S. Tsirkin"
Date: Mon, 6 Feb 2017 06:39:54 +0200
> Well the point is to avoid resets completely, at the cost of extra 256 bytes
> for packets > 128 bytes on ppc (64k pages) only.
>
> Found a volunteer so I hope to have this idea tested on ppc Tuesday.
>
> And really all we need t
On 2017年02月06日 12:39, Michael S. Tsirkin wrote:
On Sun, Feb 05, 2017 at 05:36:34PM -0500, David Miller wrote:
From: John Fastabend
Date: Thu, 02 Feb 2017 19:14:05 -0800
This series adds adjust head support for virtio. The following is my
test setup. I use qemu + virtio as follows,
./x86_64
On Sun, Feb 05, 2017 at 05:36:34PM -0500, David Miller wrote:
> From: John Fastabend
> Date: Thu, 02 Feb 2017 19:14:05 -0800
>
> > This series adds adjust head support for virtio. The following is my
> > test setup. I use qemu + virtio as follows,
> >
> > ./x86_64-softmmu/qemu-system-x86_64 \
>
1 - 100 of 157 matches
Mail list logo
