Function tls_sw_recvmsg() dequeues multiple records from stream parser
and decrypts them. In case the decryption is done by async accelerator,
the records may get submitted for decryption while the previous ones may
not have been decryted yet. For tls1.3, the record type is known only
after decrypt
From: Heiner Kallweit
Date: Fri, 8 Feb 2019 19:25:22 +0100
> Bit 0 in register 1.5 doesn't represent a device but is a flag that
> Clause 22 registers are present. Therefore disregard this bit when
> populating the device list. If code needs this information it
> should read register 1.5 directly
From: Russell King - ARM Linux admin
Date: Fri, 8 Feb 2019 15:34:32 +
> Having spent a while debugging issues with Sven Auhagen, it appears
> that the mvpp2 network driver's phylink support isn't quite correct.
>
> This series fixes that up, but, despite being tested locally, by
> Sven, and
From: Vasundhara Volam
Date: Fri, 8 Feb 2019 14:43:08 +0530
> As per discussion with Jakub Kicinski and Michal Kubecek,
> this will be better addressed by soon-too-come ethtool netlink
> API with additional indication that given WoL configuration request
> is supposed to be persisted.
>
> Retai
From: Nathan Chancellor
Date: Thu, 7 Feb 2019 21:46:53 -0700
> net/core/ethtool.c:3023:19: warning: address of array
> 'ext_m_spec->h_dest' will always evaluate to 'true'
> [-Wpointer-bool-conversion]
> if (ext_m_spec->h_dest) {
> ~~ ^~
>
> h_des
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 22:19:45 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 22:15:40 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 22:22:58 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: Heiner Kallweit
Date: Thu, 7 Feb 2019 20:22:20 +0100
> The link status register latches link-down events. Therefore, if link
> is reported as being up, there's no need for a second read.
>
> Signed-off-by: Heiner Kallweit
Looks good.
Applied, thanks.
From: Yizhuo
Date: Thu, 7 Feb 2019 09:46:23 -0800
> In function sun8i_dwmac_set_syscon(), local variable "val" could
> be uninitialized if function regmap_read() returns -EINVAL.
> However, it will be used directly in the if statement, which
> is potentially unsafe.
>
> Signed-off-by: Yizhuo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 21:16:48 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 21:42:41 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 21:55:37 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 21:47:25 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 21:22:17 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 19:16:03 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 19:10:52 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 18:58:56 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 21:29:10 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 19:02:52 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: "Gustavo A. R. Silva"
Date: Thu, 7 Feb 2019 21:13:13 -0600
> One of the more common cases of allocation size calculations is finding
> the size of a structure that has a zero-sized array at the end, along
> with memory for some number of elements for that array. For example:
>
> struct foo
From: Jakub Kicinski
Date: Fri, 8 Feb 2019 08:04:29 -0800
> Thanks! Yes, that's exactly the same thing. In a nutshell trying
> different serdes and FEC speeds. I guess I'll just put adding an API
> for this down as a TODO, and add it once we have ethtool netlink. And
> keep IOCTL ethtool froz
From: Paolo Abeni
Date: Thu, 7 Feb 2019 14:13:18 +0100
> In the unlikely event that the kmalloc call in vmci_transport_socket_init()
> fails, we end-up calling vmci_transport_destruct() with a NULL vmci_trans()
> and oopsing.
>
> This change addresses the above explicitly checking for zero vmci
By adding this test to test_verifier:
{
"reference tracking: access sk->src_ip4 (narrow load)",
.insns = {
BPF_SK_LOOKUP,
BPF_MOV64_REG(BPF_REG_6, BPF_REG_0),
BPF_JMP_IMM(BPF_JEQ, BPF_REG_0, 0, 3),
BPF_LDX_MEM(BPF_H, BPF_REG_2, BPF_REG_0, offsetof(str
From: Florian Fainelli
Date: Wed, 6 Feb 2019 12:45:56 -0800
> The Broadcom SF2 switch has a Compact Field Processor (CFP) which not
> only can perform matching + action, but also counts the number of times
> a rule has been hit. This is invaluable while debugging when/if rules
> are not matched.
From: Heiner Kallweit
Date: Wed, 6 Feb 2019 19:39:52 +0100
> The link status value latches link-down events. To get the current
> status we read the register twice in genphy_update_link(). There's
> a potential risk that we miss a link-down event in polling mode.
> This may cause issues if the us
From: Lorenzo Bianconi
Date: Wed, 6 Feb 2019 19:18:04 +0100
> According to the algorithm described in the comment block at the
> beginning of ip_rt_send_redirect, the host should try to send
> 'ip_rt_redirect_number' ICMP redirect packets with an exponential
> backoff and then stop sending them
From: "Yavuz, Tuba"
Date: Sat, 9 Feb 2019 00:02:56 +
> I just resubmitted the patch and made sure to send it in
> plaintext. Hopefully, it will work this time.
That's not the problem.
It's still corrupted.
Your email client is formatting the text, and this makes the
patch unusable. Specif
Number of devlink attributes has grown over 128, causing the
following warning:
../net/core/devlink.c: In function ‘devlink_nl_cmd_region_read_dumpit’:
../net/core/devlink.c:3740:1: warning: the frame size of 1064 bytes is larger
than 1024 bytes [-Wframe-larger-than=]
}
^
Since the number of
Vendor may sound ambiguous, let's rename the fab string to
"board.manufacture".
Signed-off-by: Jakub Kicinski
Reviewed-by: Dirk van der Merwe
---
drivers/net/ethernet/netronome/nfp/nfp_devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/netronome/n
Hi!
This series contains two minor touch ups for devlink code. First
|| is corrected to && in the ethtool compat code. Next patch
decreases the stack allocation size.
On the nfp side after further discussions with the manufacturing
team we decided to realign the serial number contents slightly a
The manufacturing team requests we include vendor and product
in the serial number field, as the serial number itself is not
unique across manufacturing facilities and products.
Signed-off-by: Jakub Kicinski
Reviewed-by: Dirk van der Merwe
---
.../net/ethernet/netronome/nfp/nfp_devlink.c | 21
We need the port to be both ethernet and have the rigth netdev,
not one or the other.
Fixes: ddb6e99e2db1 ("ethtool: add compat for devlink info")
Signed-off-by: Jakub Kicinski
---
net/core/devlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/devlink.c b/net/cor
On Sat, 9 Feb 2019 00:18:31 +, Saeed Mahameed wrote:
> On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote:
> > On Thu, 2019-02-07 at 19:08 +, Saeed Mahameed wrote:
> > >
> > > So
> > > 1) on dev_map_update_elem() we will call
> > > dev->dev->ndo_bpf() to notify the device on the in
> You touched powerpc in the previous patch but not this one.
>
> That's because we use the asm-generic version I assume.
That is correct.
> Would be good to mention in the change log though to avoid any confusion.
I'm not sure how to do that now. It looks like the series has already
been applie
bpf events are only tracked when opts->bpf_event is enabled. This patch
adds command line flag to enable this for perf-top.
Signed-off-by: Song Liu
---
tools/perf/builtin-top.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index 27d8d42e0
To annotate bpf programs in perf, it is necessary to save information in
bpf_prog_info and btf. For short living bpf program, it is necessary to
save these information before it is unloaded.
This patch saves these information in a separate thread. This thread
creates its own evlist, that only trac
This patch enables the annotation of bpf program.
A new dso type DSO_BINARY_TYPE__BPF_PROG_INFO is introduced to for BPF
programs. In symbol__disassemble(), DSO_BINARY_TYPE__BPF_PROG_INFO dso
calls into a new function symbol__disassemble_bpf(), where annotation
line information is filled based bpf
btf contains information necessary to annotate bpf programs. This patch
saves btf for bpf programs loaded in the system.
perf-record saves btf information as headers to perf.data. A new header
type HEADER_BTF is introduced for this data.
Signed-off-by: Song Liu
---
tools/perf/util/bpf-event.c |
Currently, bpf_prog_info includes 9 arrays. The user has the option to
fetch any combination of these arrays. However, this requires a lot of
handling of these arrays. This work becomes more tricky when we need to
store bpf_prog_info to a file, because these arrays are allocated
independently.
Thi
This patches uses bpf_program__get_prog_info_linear() to simplify the
logic in prog.c do_dump().
Cc: Daniel Borkmann
Cc: Alexei Starovoitov
Signed-off-by: Song Liu
---
tools/bpf/bpftool/prog.c | 266 +--
1 file changed, 59 insertions(+), 207 deletions(-)
di
bpf_prog_info contains information necessary to annotate bpf programs.
This patch saves bpf_prog_info for bpf programs loaded in the system.
perf-record saves bpf_prog_info information as headers to perf.data.
A new header type HEADER_BPF_PROG_INFO is introduced for this data.
Signed-off-by: Song
This series enables annotation of BPF programs in perf.
perf tool gathers information via sys_bpf and (optionally) stores them in
perf.data as headers.
Patch 1/9 fixes a minor issue in kernel;
Patch 2/9 to 4/9 introduce new helper functions and use them in perf and
bpftool;
Patch 5/9 and 6/9
With bpf_program__get_prog_info_linear, we can simplify the logic that
synthesizes bpf events.
This patch doesn't change the behavior of the code.
Signed-off-by: Song Liu
---
tools/perf/util/bpf-event.c | 118
1 file changed, 40 insertions(+), 78 deletions(-
Events with bpf_event should be considered as side-band event, as they
carry information about BPF programs.
Fixes: 6ee52e2a3fe4 ("perf, bpf: Introduce PERF_RECORD_BPF_EVENT")
Signed-off-by: Song Liu
---
kernel/events/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/k
Hi Simon,
On Thu, Feb 7, 2019 at 8:30 PM Simon Huelck wrote:
>
> Hi Guys,
>
>
> i can confirm better performance with 4.14.29
>
> - ~900 MBits with iperf2 in one way
> -~ 500 - 600MBits with iperf2 in duplex in both directions
>
>
> This wasnt the case with 4.17.9, not with 4.18, 4.19 or the 5.0
On 2/8/19 4:32 PM, Florian Fainelli wrote:
> Drop switchdev_ops.switchdev_port_attr_set. Drop the uses of this field
> from all clients, which were migrated to use switchdev notification in
> the previous patches.
>
> Add a new function switchdev_port_attr_notify() that sends the switchdev
> notif
Hi all,
This patch series finishes by the removal of switchdev_ops. To get there
we need to do a few things:
- get rid of the one and only call to switchdev_port_attr_get() which is
used to fetch the device's bridge port flags capabilities, instead we
can just check what flags are being progr
In preparation for allowing switchdev enabled drivers to veto specific
attribute settings from within the context of the caller, introduce a
new switchdev notifier type for port attributes.
Suggested-by: Ido Schimmel
Signed-off-by: Florian Fainelli
---
include/net/switchdev.h | 9 +
1 f
In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
add support for a function that processes the
SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute and returns not supported
for any flag set, since DSA does not currently support toggling those
bridge port attributes (yet).
Signed-
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare rocker to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
rocker_port_attr_set call
Now that we have converted the bridge code and the drivers to check for
bridge port(s) flags at the time we try to set them, there is no need
for a get() -> set() sequence anymore and
SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT therefore becomes unused.
Signed-off-by: Florian Fainelli
---
.../ne
Drop switchdev_ops.switchdev_port_attr_set. Drop the uses of this field
from all clients, which were migrated to use switchdev notification in
the previous patches.
Add a new function switchdev_port_attr_notify() that sends the switchdev
notifications SWITCHDEV_PORT_ATTR_SET.
Drop __switchdev_por
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare DSA to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
dsa_slave_port_attr_set() ca
In preparation for removing SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS_SUPPORT,
have ethsw check that the bridge port flags that are being set are
supported.
Signed-off-by: Florian Fainelli
---
drivers/staging/fsl-dpaa2/ethsw/ethsw.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare ethsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
swdev_port_attr_set() call
Now that we have converted all possible callers to using a switchdev
notifier for attributes we do not have a need for implementing
switchdev_ops anymore, and this can be removed from all drivers the
net_device structure.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/mellanox/mlxsw/sp
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare mlxsw to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
mlxsw_sp_port_attr_set() c
In preparation for getting rid of switchdev_port_attr_get(), have rocker
check for the bridge flags being set through switchdev_port_attr_set()
with the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute identifier.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/rocker/rocker_main.c | 40 ++
With the bridge no longer calling switchdev_port_attr_get() to obtain
the supported bridge port flags from a driver but instead trying to set
the bridge port flags directly and relying on driver to reject
unsupported configurations, we can effectively get rid of
switchdev_port_attr_get() entirely s
Following patches will change the way we communicate getting or setting
a port's attribute and use a blocking notifier to perform those tasks.
Prepare ocelot to support receiving notifier events targeting
SWITCHDEV_PORT_ATTR_SET and simply translate that into the existing
ocelot_port_attr_set() ca
Now that all switchdev drivers have been converted to checking the
bridge port flags during the prepare phase of the
switchdev_port_attr_set(), we can move straight to trying to set the
desired flag through SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS.
Signed-off-by: Florian Fainelli
---
net/bridge/br_sw
In preparation for getting rid of switchdev_port_attr_get(), have mlxsw
check for the bridge flags being set through switchdev_port_attr_set()
with the SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS attribute identifier.
Signed-off-by: Florian Fainelli
---
drivers/net/ethernet/mellanox/mlxsw/spectrum_switc
Update the section about switchdev drivers having to implement a
switchdev_port_attr_get() function to return
SWITCHDEV_ATTR_ID_PORT_PARENT_ID since that is no longer valid after
commit bccb30254a4a ("net: Get rid of
SWITCHDEV_ATTR_ID_PORT_PARENT_ID").
Fixes: bccb30254a4a ("net: Get rid of SWITCHD
On Fri, 2019-02-08 at 15:17 -0800, Saeed Mahameed wrote:
> On Thu, 2019-02-07 at 19:08 +, Saeed Mahameed wrote:
> >
> > So
> > 1) on dev_map_update_elem() we will call
> > dev->dev->ndo_bpf() to notify the device on the intention to
> > start/stop
> > redirect, and wait for it to create/destr
On Wed, Feb 06, 2019 at 10:54:41PM +0530, Raju Rangoju wrote:
> This series adds support for completing the SRQ buffers that were
> fetched but could not be completed by hw due to connection aborts,
> also fixes the potential srqidx leak during the connection abort.
>
> This series has both net(cx
I just resubmitted the patch and made sure to send it in plaintext. Hopefully,
it will work this time.
Best,
Tuba
From: David Miller
Sent: Friday, February 8, 2019 6:08 PM
To: Yavuz, Tuba
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH] net: hso: do not
On an error path inside the hso_create_net_device function of the hso
driver, hso_free_net_device gets called. This causes potentially a
negative reference count in the net device if register_netdev has not
been called yet as hso_free_net_device calls unregister_netdev
regardless. I think the dr
From: Russell King - ARM Linux admin
Date: Fri, 8 Feb 2019 23:36:51 +
> On Fri, Feb 08, 2019 at 03:11:39PM -0800, David Miller wrote:
>> From: Russell King
>> Date: Wed, 06 Feb 2019 10:52:30 +
>>
>> > When we probe a SFP module, we expect to be able to call the upstream
>> > device's mo
On Fri, Feb 08, 2019 at 03:11:39PM -0800, David Miller wrote:
> From: Russell King
> Date: Wed, 06 Feb 2019 10:52:30 +
>
> > When we probe a SFP module, we expect to be able to call the upstream
> > device's module_insert() function so that the upstream link can be
> > configured. However, w
#x27;t that unneeded as assumed.
>
> The barriers were removed after adding xmit_more handling. Therefore it would
> be good to
> test also with only
> bd7153bd83b806bfcc2e79b7a6f43aa653d06ef3 r8169: remove unneeded mmiowb
> barriers
> removed.
*arghh* *grmbl*
with both:
On Thu, Feb 07, 2019 at 01:19:01PM +0200, Adrian Hunter wrote:
> Subject to memory pressure and other limits, retain executable code, such
> as JIT-compiled bpf, in memory instead of freeing it immediately it is no
> longer needed for execution.
>
> While perf is primarily aimed at statistical ana
On 2/8/19 8:38 AM, Peter Oskolkov wrote:
> This patch builds on top of the previous patch in the patchset,
> which added BPF_LWT_ENCAP_IP mode to bpf_lwt_push_encap. As the
> encapping can result in the skb needing to go via a different
> interface/route/dst, bpf programs can indicate this by retur
From: Nicolas Ferre
Date: Wed, 6 Feb 2019 18:56:08 +0100
> This removes a line left while adding the correct compatibility string for
> sama5d3 10/100 interface. Now use the "atmel,sama5d3-macb" string.
>
> Signed-off-by: Nicolas Ferre
> Reviewed-by: Rob Herring
Applied to net-next.
Hi Peter,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Peter-Oskolkov/bpf-add-BPF_LWT_ENCAP_IP-option-to-bpf_lwt_push_encap/20190209-030743
base: https://git.kernel.org/pub/scm/linux/kernel
From: Nicolas Ferre
Date: Wed, 6 Feb 2019 18:56:10 +0100
> Add a new compatibility string for this product. It's using
> at91sam9260-macb layout but has a newer hardware revision: it's safer
> to use its own string.
>
> Signed-off-by: Nicolas Ferre
Applied to net-next.
From: Nicolas Ferre
Date: Wed, 6 Feb 2019 18:56:09 +0100
> Add the compatibility sting documentation for sam9x60 10/100 interface.
>
> Signed-off-by: Nicolas Ferre
Applied to net-next.
On Thu, 2019-02-07 at 19:08 +, Saeed Mahameed wrote:
> On Thu, 2019-02-07 at 08:48 +0100, Jesper Dangaard Brouer wrote:
> > On Wed, 6 Feb 2019 00:06:33 + Saeed Mahameed <
> > sae...@mellanox.com
> > > wrote:
> > > On Mon, 2019-02-04 at 19:13 -0800, David Ahern wrote:
> > [...]
> > > > mlx5
From: Russell King
Date: Wed, 06 Feb 2019 10:52:30 +
> When we probe a SFP module, we expect to be able to call the upstream
> device's module_insert() function so that the upstream link can be
> configured. However, when the upstream device is delayed, we currently
> may end up probing the
On 02/08/2019 01:50 PM, Heiner Kallweit wrote:
> On 08.02.2019 22:45, Sander Eikelenboom wrote:
>> On 08/02/2019 22:22, Heiner Kallweit wrote:
>>> On 08.02.2019 21:55, Sander Eikelenboom wrote:
On 08/02/2019 19:52, Heiner Kallweit wrote:
> On 08.02.2019 19:29, Sander Eikelenboom wrote:
From: "Yavuz, Tuba"
Date: Wed, 6 Feb 2019 00:40:31 +
>
> On an error path inside the hso_create_net_device function of the hso
> driver, hso_free_net_device gets called. This causes potentially a
> negative reference count in the net device if register_netdev has not
> been called yet as hso
From: Ido Schimmel
Date: Thu, 7 Feb 2019 11:22:44 +
> Currently, an ERP set is created for each region according to rules
> inserted and order of their insertion. However that might lead to
> suboptimal ERP sets and possible unnecessary spillage into C-TCAM.
> This patchset aims to fix this p
On Fri, 2019-02-08 at 17:55 +0100, Toke Høiland-Jørgensen wrote:
> Saeed Mahameed writes:
>
> > But:
> > 2) this won't totally solve our problem, since sometimes the driver
> > can
> > decide to recreate (change of configuration) hw resources on the
> > fly
> > while redirect/devmap is already ha
Compliment of the day, I represent Nexen Petrochemical International
Trade based in the UK. My company exports and markets Petrochemical
Products
for world trade. Having gone through a methodical search, I decided
to contact you hoping that you will find this proposal interesting.
I am intereste
in for 5.1 ?
>
Before removing both it would be good to test with only the barrier-removal
removed.
> --
> Sander
>
Heiner
>
>>
>>> would be candidates, which were merged in 5.0.
>>>
>>> I have reverted the first two, see how that works out.
>&
revert cleanly, perhaps it should be considered at
this point in the RC's
to revert them for 5.0 and try again for 5.1 ?
--
Sander
>
>> would be candidates, which were merged in 5.0.
>>
>> I have reverted the first two, see how that works out.
>>
>> --
>&
On 08/02/2019 17:08, Nicolas Dichtel wrote:
> Le 08/02/2019 à 15:43, Nikolay Aleksandrov a écrit :
>> On 08/02/2019 16:18, Nicolas Dichtel wrote:
>>> Le 08/02/2019 à 05:11, Callum Sinclair a écrit :
Currently the only way to clear the mfc cache was to delete the entries
>>> mfc stands for 'mul
From: Andrew Lunn
By using an external PHY, ports 9 and 10 can support 2500BaseT.
So set this link mode in the mask when validating.
Signed-off-by: Andrew Lunn
Signed-off-by: Heiner Kallweit
---
drivers/net/dsa/mv88e6xxx/chip.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --g
Eric
Dumazet
as author of the underlying changes.
> would be candidates, which were merged in 5.0.
>
> I have reverted the first two, see how that works out.
>
> --
> Sander
>
Heiner
>
>>> --
>>> Sander
>>>
>> Heiner
>>
>>>
>>
On Fri, Feb 08, 2019 at 10:12:23PM +0100, Heiner Kallweit wrote:
> From: Nikita Yushchenko
> Add support for the AQCS109. From software point of view,
> it should be almost equivalent to AQR107.
>
> v2:
> - make Nikita the author
> - document what I changed
>
> Signed-off-by: Nikita Yushchenko
Add WARN_ON to make sure that all sub objects of a devlink device are
cleanedup before freeing the devlink device.
This helps to catch any driver bugs.
Signed-off-by: Parav Pandit
---
Changelog:
v0->v1:
- Added WARN_ON for reporter_list too
- Change the WARN_ON lists order to follow mirror of i
From: Nikita Yushchenko
Add support for the AQCS109. From software point of view,
it should be almost equivalent to AQR107.
v2:
- make Nikita the author
- document what I changed
Signed-off-by: Nikita Yushchenko
Signed-off-by: Andrew Lunn
[hkallwe...@gmail.com: use PHY_ID_MATCH_MODEL mascro]
S
> -Original Message-
> From: netdev-ow...@vger.kernel.org On
> Behalf Of Parav Pandit
> Sent: Friday, February 8, 2019 12:01 PM
> To: David Ahern ; netdev@vger.kernel.org;
> da...@davemloft.net
> Subject: RE: [PATCH net-next] devlink: Add WARN_ON to catch errors of not
> cleaning devlink
On 2/8/19 2:21 PM, David Miller wrote:
> From: "Gustavo A. R. Silva"
> Date: Fri, 8 Feb 2019 13:58:38 -0600
>
>> In preparation to enabling -Wimplicit-fallthrough, mark switch
>> cases where we are expecting to fall through.
>>
>> Warning level 3 was used: -Wimplicit-fallthrough=3
>>
>> This p
dates, which were merged in 5.0.
I have reverted the first two, see how that works out.
--
Sander
>> --
>> Sander
>>
> Heiner
>
>>
>> [ 6466.554866] kernel BUG at lib/dynamic_queue_limits.c:27!
>> [ 6466.571425] invalid opcode: [#1] SMP NOPTI
>> [ 6466
Due to quadratic behavior of x25_new_lci(), syzbot was able
to trigger an rcu stall.
Fix this by not blocking BH for the whole duration of
the function, and inserting a reschedule point when possible.
If we care enough, using a bitmap could get rid of the quadratic
behavior.
syzbot report :
rcu
On Wed, Feb 6, 2019 at 8:51 PM Mahesh Bandewar (महेश बंडेवार)
wrote:
>
> On Tue, Feb 5, 2019 at 11:36 AM Michael Chan
> wrote:
> >
> > On Wed, Jan 30, 2019 at 5:00 PM Mahesh Bandewar (महेश बंडेवार)
> > wrote:
> > >
> > > On Wed, Jan 30, 2019 at 1:07 AM Michael Chan
> > > wrote:
> > > >
> > >
From: "Gustavo A. R. Silva"
Date: Fri, 8 Feb 2019 13:58:38 -0600
> In preparation to enabling -Wimplicit-fallthrough, mark switch
> cases where we are expecting to fall through.
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling
> -W
On Fri, Feb 08, 2019 at 08:22:17PM +0100, Heiner Kallweit wrote:
> Bit 0 ("Clause 22 registers present") is a flag and doesn't represent
> a device, therefore don't define a MDIO_MMD_XYZ constant, just define
> a MDIO_DEVS_XYZ constant for the flag in the device list bitmap.
>
> Signed-off-by: Hei
On Fri, Feb 08, 2019 at 08:21:24PM +0100, Heiner Kallweit wrote:
> Bit 0 in register 1.5 doesn't represent a device but is a flag that
> Clause 22 registers are present. Therefore disregard this bit when
> populating the device list. If code needs this information it
> should read register 1.5 dire
1 - 100 of 236 matches
Mail list logo
