Hi Andrew,
On 21/12/2020 16.22, Andrew Lunn wrote:
On Mon, Dec 21, 2020 at 11:37:55AM +0100, Martin Hundebøll wrote:
Hi Andrew,
I've browsed the code in drivers/net/phy, but haven't found a place where
the SFP module status/change is reported to user-space. Is there a
"standard" way to report
On Sun, 20 Dec 2020 at 12:40, John Wang wrote:
>
> When aggregating ncsi interfaces and dedicated interfaces to bond
> interfaces, the ncsi response handler will use the wrong net device to
> find ncsi_dev, so that the ncsi interface will not work properly.
> Here, we use the net device registered
On Mon, Dec 21, 2020 at 01:25:47PM +0100, Oliver Hartkopp wrote:
>
>
> On 20.12.20 15:37, Oleksij Rempel wrote:
> > Hello Oliver,
> >
> > On Sun, Dec 20, 2020 at 02:18:27PM +0100, Oliver Hartkopp wrote:
> > > Hello Oleksij,
> > >
> > > I assume there is some ndev->ml_priv value set - but not fr
On 2020/12/22 上午7:07, Willem de Bruijn wrote:
On Wed, Dec 16, 2020 at 3:20 AM wangyunjian wrote:
From: Yunjian Wang
Currently we break the loop and wake up the vhost_worker when
sendmsg fails. When the worker wakes up again, we'll meet the
same error.
The patch is based on the assumption th
'memory-region' is a common property, so it doesn't need a type ref here.
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Alex Elder
Cc: netdev@vger.kernel.org
Signed-off-by: Rob Herring
---
I'll take this via the DT tree.
Documentation/devicetree/bindings/net/qcom,ipa.yaml | 1 -
1 file change
On 2020/12/22 上午11:36, Jeff Dike wrote:
virtnet_set_channels can recursively call cpus_read_lock if CONFIG_XPS
and CONFIG_HOTPLUG are enabled.
The path is:
virtnet_set_channels - calls get_online_cpus(), which is a trivial
wrapper around cpus_read_lock()
netif_set_real_num_tx_queues
Hi Hongwei,
The NCSI should run on 3.3V RMII. According your log, you enabled NCSI on
ftgmac100@1e66 which can only support 1.8V I/O voltage.
Did you observe the same error on ftgmac100@1e67 (MAC3) or
ftgmac100@1e69 (MAC4)?
--
Dylan
> -Original Message-
> From: Linux-aspee
On Mon, 21 Dec 2020 at 17:01, Hongwei Zhang wrote:
>
> Dear Reviewer,
>
> When FTGMAC100 driver is used on other NCSI Ethernet controllers, few
> controllers have compatible issue. One example is Intel I210 Ethernet
> controller on AST2600 BMC, with FTGMAC100 driver, it always trigger
> RXDES0_RX_
On Sat, 19 Dec 2020 20:58:33 +0100 Oleksij Rempel wrote:
> + stats->rx_nohandler += raw.filtered;
> + stats->rx_errors += raw.rxfcserr + raw.rxalignerr + raw.rxrunt +
> + raw.rxfragment + raw.rxoverflow + raw.filtered + raw.rxtoolong;
What happened to my suggestion to report fi
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Sat, 19 Dec 2020 13:19:24 +0100 you wrote:
> PPPIOCGL2TPSTATS already uses 54. This shouldn't be a problem in
> practice, but let's keep the logical decreasing assignment scheme.
>
> Fixes: 4cf476ced45d ("ppp: add PPPIOCBRID
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Sun, 20 Dec 2020 13:02:29 +0200 you wrote:
> From: Stefan Chulski
>
> During GoP port 2 Networking Complex Control mode of operation configurations,
> also GoP port 3 mode of operation was wrongly set.
> Patch removes these
Hello:
This series was applied to netdev/net.git (refs/heads/master):
On Fri, 18 Dec 2020 11:55:35 +0100 you wrote:
> This is three bug fixes that fell out of a series of cleanups of the
> ucc_geth driver. Please consider applying via the net tree.
>
> v2: reorder and split off from larger serie
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Sat, 19 Dec 2020 14:01:44 +0300 you wrote:
> This error path needs to disable the pci device before returning.
>
> Fixes: ede58ef28e10 ("atm: remove deprecated use of pci api")
> Signed-off-by: Dan Carpenter
> ---
> driver
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 18 Dec 2020 13:50:01 -0800 you wrote:
> Let the FW know we have enough receive buffer space for the
> vlan tag if it isn't stripped.
>
> Fixes: 0f3154e6bcb3 ("ionic: Add Tx and Rx handling")
> Signed-off-by: Shannon Nel
From: Cong Wang
Similar to regular hashmap test.
Acked-by: Andrey Ignatov
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Dongdong Wang
Signed-off-by: Cong Wang
---
.../selftests/bpf/progs/map_ptr_kern.c| 20 +++
1 file changed, 20 insertions(+)
diff --git a/tools/t
From: Cong Wang
Add some test cases in test_maps.c for timeout map, which focus
on testing timeout.
Cc: Alexei Starovoitov
Cc: Daniel Borkmann
Cc: Dongdong Wang
Signed-off-by: Cong Wang
---
tools/testing/selftests/bpf/test_maps.c | 46 +
1 file changed, 46 insertions
From: Cong Wang
This borrows the idea from conntrack and will be used for conntrack in
ebpf too. Each element in a timeout map has a user-specified timeout
in msecs, after it expires it will be automatically removed from the
map. Cilium already does the same thing, it uses a regular map or LRU
ma
From: Cong Wang
This patchset introduces a new bpf hash map which has timeout.
Patch 1 is the implementation of timeout map, patch 2 adds some test
cases for timeout map in test_maps, and patch 3 adds a test case in
map ptr test.
Please check each patch description for more details.
---
v3: mov
On Tue, 15 Dec 2020 09:42:11 +0200 Maxim Mikityanskiy wrote:
> + q->offload = nla_get_flag(tb[TCA_HTB_OFFLOAD]);
> +
> + if (q->offload) {
> + if (!tc_can_offload(dev) || !dev->netdev_ops->ndo_setup_tc)
> + return -EOPNOTSUPP;
Is there a check somewhere maki
There are use cases for which the existing tagger, based on the NPI
(Node Processor Interface) functionality, is insufficient.
Namely:
- Frames injected through the NPI port bypass the frame analyzer, so no
source address learning is performed, no TSN stream classification,
etc.
- Flow control
The sja1105 implementation can be blind about this, but the felix driver
doesn't do exactly what it's being told, so it needs to know whether it
is a TX or an RX VLAN, so it can install the appropriate type of TCAM
rule.
Signed-off-by: Vladimir Oltean
---
include/linux/dsa/8021q.h | 14 +
The Felix switch inside LS1028A has an issue. It has a 2.5G CPU port,
and the external ports, in the majority of use cases, run at 1G. This
means that, when the CPU injects traffic into the switch, it is very
easy to run into congestion. This is not to say that it is impossible to
enter congestion
From: Jonathan Lemon
Before this change, the caller of sock_zerocopy_callback would
need to save the zerocopy status, decrement and check the refcount,
and then call the callback function - the callback was only invoked
when the refcount reached zero.
Now, the caller just passes the status into
From: Jonathan Lemon
At Willem's suggestion, rename the sock_zerocopy_* functions
so that they match the MSG_ZEROCOPY flag, which makes it clear
they are specific to this zerocopy implementation.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 16
net/core/skbuff.c
From: Jonathan Lemon
Replace direct assignments with skb_zcopy_set() for clarity.
Signed-off-by: Jonathan Lemon
---
drivers/net/tap.c | 3 +--
drivers/net/tun.c | 3 +--
drivers/vhost/net.c | 1 +
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/tap.c b/drivers/ne
From: Jonathan Lemon
This is set of cleanup patches for zerocopy which are intended
to allow a introduction of a different zerocopy implementation.
The top level API will use the skb_zcopy_*() functions, while
the current TCP specific zerocopy ends up using msg_zerocopy_*()
calls.
There should
From: Jonathan Lemon
Add an optional skb parameter to the zerocopy callback parameter,
which is passed down from skb_zcopy_clear(). This gives access
to the original skb, which is needed for upcoming RX zero-copy
error handling.
Make the name of the the zerocopy success pararmeter consistent
fo
From: Jonathan Lemon
The sock_zerocopy_put_abort function contains logic which is
specific to the current zerocopy implementation. Add a wrapper
which checks the callback and dispatches apppropriately.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 10 ++
net/core/skbuff.c
From: Jonathan Lemon
RX zerocopy fragment pages which are not allocated from the
system page pool require special handling. Give the callback
in skb_zcopy_clear() a chance to process them first.
Signed-off-by: Jonathan Lemon
---
net/core/skbuff.c | 3 ++-
1 file changed, 2 insertions(+), 1 de
From: Jonathan Lemon
Currently, an ubuf is attached to a new skb, the skb zc_flags
is initialized to a fixed value. Instead of doing this, set
the default zc_flags in the ubuf, and have new skb's inherit
from this default.
This is needed when setting up different zerocopy types.
Signed-off-by:
From: Jonathan Lemon
Rename the get routines for consistency.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 12 ++--
net/core/skbuff.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 238166b
From: Jonathan Lemon
Replace sock_zerocopy_put with the generic skb_zcopy_put()
function. Pass 'true' as the success argument, as this
is identical to no change.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 7 ++-
net/core/skbuff.c | 9 +
net/ipv4/tcp.c
From: Jonathan Lemon
In preparation for expanded zerocopy (TX and RX), move
the ZC related bits out of tx_flags into their own flag
word.
Signed-off-by: Jonathan Lemon
---
drivers/net/tap.c | 3 +--
drivers/net/tun.c | 3 +--
drivers/net/xen-netback/interf
From: Jonathan Lemon
All 'struct ubuf_info' users should have a callback defined.
Remove the dead code path to consume_skb(), which makes
unwarranted assumptions about how the structure was allocated.
Signed-off-by: Jonathan Lemon
---
net/core/skbuff.c | 8 ++--
1 file changed, 2 insertion
From: Jonathan Lemon
skb_zcopy_abort() has no in-tree consumers, remove it.
Signed-off-by: Jonathan Lemon
---
include/linux/skbuff.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 69588b304f83..fb6dd6af0f82 100644
--- a/inc
On Mon, Dec 21, 2020 at 05:52:08PM -0500, Willem de Bruijn wrote:
> > > > - marking the skb data as inaccessible so skb_condense()
> > > > and skb_zeroocopy_clone() leave it alone.
> > >
> > > Yep. Skipping content access on the Rx path will be interesting. I
> > > wonder if that should be a
On 12/21/20 7:04 PM, Andrew Lunn wrote:
On Tue, Dec 22, 2020 at 12:59:08AM +0900, Masahiro Yamada wrote:
On Tue, Dec 22, 2020 at 12:26 AM Andrew Lunn wrote:
On Mon, Dec 21, 2020 at 02:43:23PM +0900, Masahiro Yamada wrote:
The declaration of request_irq() in is marked as
__must_check.
Witho
On Mon, Dec 21, 2020 at 03:17:02PM -0800, Florian Fainelli wrote:
> > Do you think we need some getters for dp->index and dp->ds->index, to
> > preserve
> > some sort of data structure encapsulation from the outside world (although
> > it's
> > not as if the members of struct dsa_switch and struc
On Mon, Dec 21, 2020 at 11:36 AM Antoine Tenart wrote:
>
> Two race conditions can be triggered in xps, resulting in various oops
> and invalid memory accesses:
>
> 1. Calling netdev_set_num_tc while netif_set_xps_queue:
>
>- netdev_set_num_tc sets dev->tc_num.
>
>- netif_set_xps_queue use
Hello:
This patch was applied to bpf/bpf.git (refs/heads/master):
On Mon, 21 Dec 2020 11:25:06 -0800 you wrote:
> From: Eric Dumazet
>
> We noticed that with a LOCKDEP enabled kernel,
> allocating a hash table with 65536 buckets would
> use more than 60ms.
>
> htab_init_buckets() runs from pro
On 12/21/2020 3:06 PM, Vladimir Oltean wrote:
> On Mon, Dec 21, 2020 at 02:33:16PM -0800, Florian Fainelli wrote:
>> On 12/20/2020 8:53 PM, Florian Fainelli wrote:
>>> The call to netif_set_real_num_tx_queues() succeeds and
>>> slave_dev->real_num_tx_queues is changed to 4 accordingly. The loop
On Wed, Dec 16, 2020 at 3:20 AM wangyunjian wrote:
>
> From: Yunjian Wang
>
> Currently we break the loop and wake up the vhost_worker when
> sendmsg fails. When the worker wakes up again, we'll meet the
> same error.
The patch is based on the assumption that such error cases always
return EAGAI
On Mon, Dec 21, 2020 at 02:33:16PM -0800, Florian Fainelli wrote:
> On 12/20/2020 8:53 PM, Florian Fainelli wrote:
> > The call to netif_set_real_num_tx_queues() succeeds and
> > slave_dev->real_num_tx_queues is changed to 4 accordingly. The loop that
> > assigns the internal queue mapping (priv->r
On 12/21/2020 2:25 PM, Vladimir Oltean wrote:
> On Mon, Dec 21, 2020 at 01:49:03PM -0800, Florian Fainelli wrote:
>> On 12/18/2020 1:17 PM, Florian Fainelli wrote:
> SYSTEMPORT Lite does not actually validate the frame length, so
> setting
> a maximum number to the buffe
> > > - marking the skb data as inaccessible so skb_condense()
> > > and skb_zeroocopy_clone() leave it alone.
> >
> > Yep. Skipping content access on the Rx path will be interesting. I
> > wonder if that should be a separate opaque skb feature, independent
> > from whether the data is owned
> > > All uargs should have a callback function, (unless nouarg
> > > is set), so push all special case logic handling down into
> > > the callbacks. This slightly pessimizes the refcounted cases,
> >
> > What does this mean?
>
> The current zerocopy_put() code does:
> 1) if uarg, dec refcount,
On Thu, Dec 17, 2020 at 9:26 AM Stanislav Fomichev wrote:
>
> When we attach any cgroup hook, the rest (even if unused/unattached) start
> to contribute small overhead. In particular, the one we want to avoid is
> __cgroup_bpf_run_filter_skb which does two redirections to get to
> the cgroup and p
On Mon, Dec 21, 2020 at 11:36 AM Antoine Tenart wrote:
>
> Accesses to dev->xps_cpus_map (when using dev->num_tc) should be
> protected by the xps_map mutex, to avoid possible race conditions when
> dev->num_tc is updated while the map is accessed. This patch moves the
> logic accessing dev->xps_c
On 12/20/2020 8:53 PM, Florian Fainelli wrote:
>
> The call to netif_set_real_num_tx_queues() succeeds and
> slave_dev->real_num_tx_queues is changed to 4 accordingly. The loop that
> assigns the internal queue mapping (priv->ring_map) is correctly limited
> to 4, however we get two calls per s
On Thu, Dec 17, 2020 at 9:24 AM Stanislav Fomichev wrote:
>
> When we attach a bpf program to cgroup/getsockopt any other getsockopt()
> syscall starts incurring kzalloc/kfree cost. While, in general, it's
> not an issue, sometimes it is, like in the case of TCP_ZEROCOPY_RECEIVE.
> TCP_ZEROCOPY_RE
The Intel I211 Ethernet Controller supports 2 Receive Side Scaling (RSS) queues.
It should not be excluded from having this feature enabled.
Via commit c883de9fd787b6f49bf825f3de3601aeb78a7114
E1000_MRQC_ENABLE_RSS_4Q was renamed to E1000_MRQC_ENABLE_RSS_MQ to
indicate that this is a generic bit f
On Mon, Dec 21, 2020 at 01:49:03PM -0800, Florian Fainelli wrote:
> On 12/18/2020 1:17 PM, Florian Fainelli wrote:
> >>> SYSTEMPORT Lite does not actually validate the frame length, so
> >>> setting
> >>> a maximum number to the buffer size we allocate could work, but I
> >>> don'
Currently tests for bpf_get_ns_current_pid_tgid() are outside test_progs.
This change folds test cases into test_progs.
Changes from v9:
- Added test in root namespace.
- Fixed changed tracepoint from sys_enter to sys_usleep.
- Fixed pid, tgid values were inverted.
- Used CLONE(2) for namespa
On Thu, Dec 17, 2020 at 9:24 AM Stanislav Fomichev wrote:
>
> When we attach a bpf program to cgroup/getsockopt any other getsockopt()
> syscall starts incurring kzalloc/kfree cost. While, in general, it's
> not an issue, sometimes it is, like in the case of TCP_ZEROCOPY_RECEIVE.
> TCP_ZEROCOPY_RE
On Mon, 21 Dec 2020 19:15:49 + Nick Lowe wrote:
> The Intel I211 Ethernet Controller supports 2 Receive Side Scaling (RSS)
> queues.
> It should not be excluded from having this feature enabled.
>
> Via commit c883de9fd787b6f49bf825f3de3601aeb78a7114
> E1000_MRQC_ENABLE_RSS_4Q was renamed to
On Mon, 21 Dec 2020 14:40:26 -0500 Hongwei Zhang wrote:
> When FTGMAC100 driver is used on other NCSI Ethernet controllers, few
When you say NCSI Ethernet controller here you mean the main system
NIC, right? The MAC on the NCSI side is FTGMAC100, correct?
In that case I'm not sure how user is sup
On 12/18/2020 1:17 PM, Florian Fainelli wrote:
>>> SYSTEMPORT Lite does not actually validate the frame length, so setting
>>> a maximum number to the buffer size we allocate could work, but I don't
>>> see a reason to differentiate the two types of MACs here.
>>
>> And if th
On Thu, Dec 17, 2020 at 08:51:27AM +0100, Steen Hegelund wrote:
> Document the Sparx5 switch device driver bindings
>
> Signed-off-by: Steen Hegelund
> Signed-off-by: Lars Povlsen
> ---
> .../bindings/net/microchip,sparx5-switch.yaml | 178 ++
> 1 file changed, 178 insertions(+)
Am 21.12.2020 um 21:51 schrieb Hongwei Zhang:
> Change the order of reading MAC address, try to read it from MAC chip
> first, if it's not availabe, then try to read it from device tree.
>
This commit message leaves a number of questions. It seems the change
isn't related at all to the change that
pon., 21 gru 2020 o 20:07 Sasha Levin napisał(a):
>
> On Mon, Dec 21, 2020 at 10:47:57AM -0800, Jakub Kicinski wrote:
> >On Mon, 21 Dec 2020 18:30:32 + Russell King - ARM Linux admin wrote:
> >> On Mon, Dec 21, 2020 at 10:25:39AM -0800, Jakub Kicinski wrote:
> >> > We need to work with stable
the following syzkaller reproducer:
r0 = socket$inet_mptcp(0x2, 0x1, 0x106)
bind$inet(r0, &(0x7f80)={0x2, 0x4e24, @multicast2}, 0x10)
connect$inet(r0, &(0x7f000480)={0x2, 0x4e24, @local}, 0x10)
sendto$inet(r0, &(0x7f000100)="f6", 0xffe7, 0xc000, 0x0, 0x0)
systematically tr
Lorenzo Bianconi writes:
Lorenzo Bianconi writes:
>> On Mon, 2020-12-07 at 17:32 +0100, Lorenzo Bianconi wrote:
>> > Introduce xdp_shared_info data structure to contain info
>> > about
>> > "non-linear" xdp frame. xdp_shared_info will alias
>> > skb_shared_info
>> > allowing to keep most
> On Dec 21, 2020, at 11:25 AM, Eric Dumazet wrote:
>
> From: Eric Dumazet
>
> We noticed that with a LOCKDEP enabled kernel,
> allocating a hash table with 65536 buckets would
> use more than 60ms.
>
> htab_init_buckets() runs from process context,
> it is safe to schedule to avoid latency
Change the order of reading MAC address, try to read it from MAC chip
first, if it's not availabe, then try to read it from device tree.
Fixes: 35c54922dc97 ("ARM: dts: tacoma: Add reserved memory for ramoops")
Signed-off-by: Hongwei Zhang
---
drivers/net/ethernet/faraday/ftgmac100.c | 22 ++
Dear Reviewer,
Use native MAC address is preferred over other choices, thus change the order
of reading MAC address, try to read it from MAC chip first, if it's not
availabe, then try to read it from device tree.
Hongwei Zhang (1):
net: ftgmac100: Change the order of getting MAC address
driv
On Sat, Dec 19, 2020 at 2:52 PM Martin Blumenstingl
wrote:
>
> The dwmac glue registers on Amlogic Meson8b and newer SoCs has two clock
> inputs:
> - Meson8b and Meson8m2: MPLL2 and MPLL2 (the same parent is wired to
> both inputs)
> - GXBB, GXL, GXM, AXG, G12A, G12B, SM1: FCLK_DIV2 and MPLL2
>
On Sat, Dec 19, 2020 at 02:00:55PM -0500, Willem de Bruijn wrote:
> On Fri, Dec 18, 2020 at 4:27 PM Jonathan Lemon
> wrote:
> >
> > On Fri, Dec 18, 2020 at 03:49:44PM -0500, Willem de Bruijn wrote:
> > > On Fri, Dec 18, 2020 at 3:23 PM Jonathan Lemon
> > > wrote:
> > > >
> > > > From: Jonathan
When FTGMAC100 driver is used on other NCSI Ethernet controllers, few
controllers have compatible issue, removing FTGMAC100_RXDES0_RX_ERR bit
from RXDES0_ANY_ERROR can fix the issue.
Fixes: 7ee2d5b4d4340353 ("ARM: dts: nuvoton: Add Fii Kudo system")
Signed-off-by: Hongwei Zhang
---
drivers/net/e
Dear Reviewer,
When FTGMAC100 driver is used on other NCSI Ethernet controllers, few
controllers have compatible issue. One example is Intel I210 Ethernet
controller on AST2600 BMC, with FTGMAC100 driver, it always trigger
RXDES0_RX_ERR error, cause NCSI initialization failure, removing
FTGMAC100_
Accesses to dev->xps_rxqs_map (when using dev->num_tc) should be
protected by the xps_map mutex, to avoid possible race conditions when
dev->num_tc is updated while the map is accessed. Make use of the now
available netif_show_xps_queue helper which does just that.
This also helps to keep xps_cpus
Accesses to dev->xps_cpus_map (when using dev->num_tc) should be
protected by the xps_map mutex, to avoid possible race conditions when
dev->num_tc is updated while the map is accessed. This patch moves the
logic accessing dev->xps_cpu_map and dev->num_tc to net/core/dev.c,
where the xps_map mutex
Hello all,
This series fixes race conditions in the xps code, where out of bound
accesses can occur when dev->num_tc is updated, triggering oops. The
root cause is linked to lock issues. An explanation is given in each of
the commit logs.
Reviews in v1 suggested to use the xps_map_mutex to protec
Two race conditions can be triggered in xps, resulting in various oops
and invalid memory accesses:
1. Calling netdev_set_num_tc while netif_set_xps_queue:
- netdev_set_num_tc sets dev->tc_num.
- netif_set_xps_queue uses dev->tc_num as one of the parameters to
compute the size of new_
On Mon, 21 Dec 2020 21:07:44 +0800 weichenchen wrote:
> pneigh_enqueue() tries to obtain a random delay by mod
> NEIGH_VAR(p, PROXY_DELAY). However, NEIGH_VAR(p, PROXY_DELAY)
> migth be zero at that point because someone could write zero
> to /proc/sys/net/ipv4/neigh/[device]/proxy_delay after the
On Mon, Dec 21, 2020 at 11:02 AM Guenter Roeck wrote:
>
> On 12/20/20 10:18 PM, Masahiro Yamada wrote:
> With a change like this, I'd have expected that there is a coccinelle
> script or similar to ensure that claims made in the commit message
> are true.
It is only a warning -- the compiler alre
On Wed, Dec 16, 2020 at 05:30:11PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtu3.txt to YAML schema mediatek,mtu3.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v4:
> 1. refer to usb-drd.yaml insstead of usb/generic.txt
> the following ones suggested by Rob:
> 2. add the number of phys s
From: Eric Dumazet
We noticed that with a LOCKDEP enabled kernel,
allocating a hash table with 65536 buckets would
use more than 60ms.
htab_init_buckets() runs from process context,
it is safe to schedule to avoid latency spikes.
Fixes: c50eb518e262 ("bpf: Use separate lockdep class for each ha
On Wed, Dec 16, 2020 at 05:30:10PM +0800, Chunfeng Yun wrote:
> Convert mediatek,mtk-xhci.txt to YAML schema mediatek,mtk-xhci.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v4: update it according to Rob's suggestion
> 1. modify dictionary of phys
> 2. fix endentation in "mediatek,syscon-wakeu
On Sat, Dec 19, 2020 at 01:46:13PM -0500, Willem de Bruijn wrote:
> On Fri, Dec 18, 2020 at 3:20 PM Jonathan Lemon
> wrote:
> >
> > From: Jonathan Lemon
> >
> > In preparation for further work, the zcopy* routines will
> > become basic building blocks, while the zerocopy* ones will
> > be specif
The Intel I211 Ethernet Controller supports 2 Receive Side Scaling (RSS) queues.
It should not be excluded from having this feature enabled.
Via commit c883de9fd787b6f49bf825f3de3601aeb78a7114
E1000_MRQC_ENABLE_RSS_4Q was renamed to E1000_MRQC_ENABLE_RSS_MQ to
indicate that this is a generic bit f
On Wed, 16 Dec 2020 17:30:08 +0800, Chunfeng Yun wrote:
> Convert MIPI DSI PHY binding to YAML schema mediatek,dsi-phy.yaml
>
> Cc: Chun-Kuang Hu
> Cc: Philipp Zabel
> Signed-off-by: Chunfeng Yun
> ---
> v4:
> 1. add maintainer Philipp add support mt8183 suggested by Chun-Kuang
> 2. use key
On Wed, 16 Dec 2020 17:30:03 +0800, Chunfeng Yun wrote:
> Due to usb-device.txt is converted into usb-device.yaml,
> so modify reference file names at the same time.
>
> Signed-off-by: Chunfeng Yun
> ---
> v2~v4: no changes
> ---
> Documentation/devicetree/bindings/net/btusb.txt | 2 +-
> 1 file
On Wed, Dec 16, 2020 at 05:30:02PM +0800, Chunfeng Yun wrote:
> Convert usb-device.txt to YAML schema usb-device.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> v4: no changes, update dependent series:
> https://patchwork.kernel.org/project/linux-usb/list/?series=399561
> [v6,00/19] dt-bindi
On Sun, Dec 20, 2020 at 01:05:19PM +0100, Jean-Philippe Brucker wrote:
Hi,
On Sat, Dec 19, 2020 at 10:34:55PM -0500, Sasha Levin wrote:
From: Jean-Philippe Brucker
[ Upstream commit 77ce220c0549dcc3db8226c61c60e83fc59dfafc ]
The test fails because of a recent fix to the verifier, even though
On Mon, Dec 21, 2020 at 10:47:57AM -0800, Jakub Kicinski wrote:
On Mon, 21 Dec 2020 18:30:32 + Russell King - ARM Linux admin wrote:
On Mon, Dec 21, 2020 at 10:25:39AM -0800, Jakub Kicinski wrote:
> We need to work with stable maintainers on this, let's see..
>
> Greg asked for a clear descr
On Sun, 20 Dec 2020 11:11:35 + Stefan Chulski wrote:
> > RFC patches sent for review only are obviously welcome at any time.
>
> If I post RFC patches for review only, should I add some prefix or tag for
> this?
Include RFC in the tag: [RFC net-next] or [PATCH RFC net-next],
this way patch
On Mon, 21 Dec 2020 19:46:23 +0100 Eric Dumazet wrote:
> So maybe the issue is coming from traffic coming from a VM through a
> tun device or something,
> and our handling of GSO_ROBUST / DODGY never cared about setting
> SKB_GSO_TCPV4 or SKB_GSO_TCPV6 if not already given by user space ?
>
> Or a
On Fri, Dec 18, 2020 at 04:58:56PM -0400, Jason Gunthorpe wrote:
> On Fri, Dec 18, 2020 at 08:32:11PM +, Mark Brown wrote:
>
> > Historically people did try to create custom bus types, as I have
> > pointed out before there was then pushback that these were duplicating
> > the platform bus so
On Mon, 21 Dec 2020 18:30:32 + Russell King - ARM Linux admin wrote:
> On Mon, Dec 21, 2020 at 10:25:39AM -0800, Jakub Kicinski wrote:
> > We need to work with stable maintainers on this, let's see..
> >
> > Greg asked for a clear description of what happens, from your
> > previous response i
The pull request you sent on Mon, 21 Dec 2020 10:48:28 +0100:
> https://github.com/martinetd/linux tags/9p-for-5.11-rc1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/70990afa34fbac03ade78e2ad0ccd418acecfc04
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs
04.12.2020 06:14, Howard Chung пишет:
> From: Abhishek Pandit-Subedi
>
> When suspending, mark SUSPEND_SCAN_ENABLE and SUSPEND_SCAN_DISABLE tasks
> correctly when either classic or le scanning is modified.
>
> Signed-off-by: Abhishek Pandit-Subedi
> Signed-off-by: Howard Chung
> Reviewed-by: A
On Sun, 20 Dec 2020 10:29:12 +0200 Baruch Siach wrote:
> > I think this and the following fixes should be folded into a single
> > line (unless it's possible in RST for header to span multiple lines):
> >
> > I sent a patch and I'm wondering what happened to it - how can I tell
> > whether it got
Hi Florian,
On Sun, 2020-12-20 at 16:58 -0800, Florian Fainelli wrote:
> >
> > The Sparx5 Switch chip register model can be browsed here:
> > Link:
> > https://microchip-ung.github.io/sparx-5_reginfo/reginfo_sparx-5.html
>
> Out of curiosity, what tool was used to generate the register
> infor
On Mon, Dec 21, 2020 at 10:25:39AM -0800, Jakub Kicinski wrote:
> We need to work with stable maintainers on this, let's see..
>
> Greg asked for a clear description of what happens, from your
> previous response it sounds like a null-deref in mvpp2_mac_config().
> Is the netdev -> config -> net
On Sun, 20 Dec 2020 18:08:19 +0100 Marcin Wojtas wrote:
> > > > > >> > > This patch fixes a regression that was introduced in v5.3:
> > > > > >> > > Commit 44cc27e43fa3 ("net: phylink: Add struct phylink_config
> > > > > >> > > to PHYLINK API")
> > > > > >> > >
> > > > > >> > > Above results in a
21.12.2020 20:58, Abhishek Pandit-Subedi пишет:
> Hi Dmitry,
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=295fa2a5647b13681594bb1bcc76c74619035218
> should fix this issue.
>
> Your issue seems the same as the one I encountered -- the
> SUSPEND_DISABL
Zekun Shen writes:
> Function ep_rx_complete is being called without NULL checking
> in ath10k_htc_rx_completion_handler. Without such check, mal-
> formed packet is able to cause jump to NULL.
>
> ep->service_id seems a good candidate for sanity check as it is
> used in usb.c.
>
> Signed-off-by:
On Mon, Dec 21, 2020 at 11:57 AM Richard Guy Briggs wrote:
>
> The audit-related parameters in struct task_struct should ideally be
> collected together and accessed through a standard audit API and the audit
> structures made opaque to other kernel subsystems.
>
> Collect the existing loginuid, s
On Mon, Dec 21, 2020 at 7:20 AM Masahiro Yamada wrote:
>
> Sorry for the delay.
No problem!
> Now I sent out the fix for lantiq_etop.c
>
> https://lore.kernel.org/patchwork/patch/1355595/
I saw it, thanks for the Cc!
> The reason of the complication was
> I was trying to merge the following pa
Hi Dmitry,
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=295fa2a5647b13681594bb1bcc76c74619035218
should fix this issue.
Your issue seems the same as the one I encountered -- the
SUSPEND_DISABLE bit (0x4) wasn't being cleared by the request
completion han
1 - 100 of 151 matches
Mail list logo
