Hi Willem,
On Thu, Dec 17 2020, Willem de Bruijn wrote:
> On Thu, Dec 17, 2020 at 2:48 PM Jakub Kicinski wrote:
>>
>> On Tue, 15 Dec 2020 18:51:17 +0200 Baruch Siach wrote:
>> > Before commit 889b8f964f2f ("packet: Kill CONFIG_PACKET_MMAP.") there
>> > used to be a CONFIG_PACKET_MMAP config symbo
On Fri, Dec 18, 2020 at 11:55:36AM +0100, Rasmus Villemoes wrote:
> All the buffers and registers are already set up appropriately for an
> MTU slightly above 1500, so we just need to expose this to the
> networking stack. AFAICT, there's no need to implement .ndo_change_mtu
> when the receive buff
Lorenzo Bianconi writes:
Introduce xdp_init_buff and xdp_prepare_buff utility routines to
initialize
xdp_buff data structure and remove duplicated code in all XDP
capable
drivers.
Changes since v3:
- use __always_inline instead of inline for
xdp_init_buff/xdp_prepare_buff
- add 'const boo
Hi Jakub,
On Thu, Dec 17 2020, Jakub Kicinski wrote:
> On Tue, 15 Dec 2020 19:18:19 +0200 Baruch Siach wrote:
>> Signed-off-by: Baruch Siach
>> ---
>> Documentation/networking/netdev-FAQ.rst | 18 +++---
>> 1 file changed, 11 insertions(+), 7 deletions(-)
>>
>> diff --git a/Document
When mvneta_port_power_up() fails, we should execute
cleanup functions after label err_netdev to avoid memleak.
Fixes: 41c2b6b4f0f80 ("net: ethernet: mvneta: Add back interface mode
validation")
Signed-off-by: Dinghao Liu
---
drivers/net/ethernet/marvell/mvneta.c | 2 +-
1 file changed, 1 inser
On Sun, Dec 20, 2020 at 3:49 PM Vladimir Oltean wrote:
> But still, what is at memory address 0x1e11, if the switch is
> accessed over MDIO?
It's "Ethernet GMAC", handled by mtk_eth_soc.
Join adjacent questions to a single question line. This fixes the
formatting of questions that were not part of the heading.
Also, drop Q: and A: prefixes. We don't need them now that questions and
answers are visually separated.
Signed-off-by: Baruch Siach
---
v2: Address comments from Jakub Ki
On Sun, Dec 20, 2020 at 04:36:27PM +0800, DENG Qingfang wrote:
> On Sun, Dec 20, 2020 at 3:49 PM Vladimir Oltean wrote:
> > But still, what is at memory address 0x1e11, if the switch is
> > accessed over MDIO?
>
> It's "Ethernet GMAC", handled by mtk_eth_soc.
I see. You have some work to do w
On Sun, Dec 20, 2020 at 12:21:53AM +0800, DENG Qingfang wrote:
> MT7621 is a SoC, so using "mediatek,mt7621" as its compatible is ambiguous.
> Rename it to "mediatek,mt7621-gsw".
>
> Signed-off-by: DENG Qingfang
> ---
I would say that you need to resolve the situation with the docs at
Documentat
syzbot suspects this issue was fixed by commit:
commit cc00bcaa589914096edef7fb87ca5cee4a166b5c
Author: Subash Abhinov Kasiviswanathan
Date: Wed Nov 25 18:27:22 2020 +
netfilter: x_tables: Switch synchronization to RCU
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1445c
>
>
> Lorenzo Bianconi writes:
>
> > Introduce xdp_init_buff and xdp_prepare_buff utility routines to
> > initialize
> > xdp_buff data structure and remove duplicated code in all XDP
> > capable
> > drivers.
> >
> > Changes since v3:
> > - use __always_inline instead of inline for
> > xdp_init_buf
> External Email
>
> --
> On Thu, 17 Dec 2020 14:37:28 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > During GoP port 2 Networking Complex Control mode of operation
> > configurations, also GoP port 3 mode of o
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 configurations.
Fixes: f84bf386f395 ("net: mvpp2: initialize the GoP")
Acked-by: Marcin Wojtas
Signed-off-by: Stefan Chulski
>
> --
> On Thu, 17 Dec 2020 18:07:58 +0200 stef...@marvell.com wrote:
> > From: Stefan Chulski
> >
> > Patch didn't fix any issue, just improve parse flow and align ipv4
> > parse flow with ipv6 parse flow.
> >
> > Currently ipv
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 this
That fix is commit b02709587ea3 ("bpf: Fix propagation of
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 to packet_type to fix it.
Fixes: 138635cc27c9 ("net/ncsi
Hello,
syzbot found the following issue on:
HEAD commit:3db1a3fa Merge tag 'staging-5.11-rc1' of git://git.kernel...
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=121dc93750
kernel config: https://syzkaller.appspot.com/x/.config?x=2764fc28a92339f9
dashboar
Hello Oleksij,
I assume there is some ndev->ml_priv value set - but not from a CAN
netdevice.
What was the reason to fiddle with the 'priv' stuff in
j1939_netdev_notify() before checking if it was a CAN device?
Would this patch fix the issue then?
diff --git a/net/can/j1939/main.c b/net/ca
syzbot suspects this issue was fixed by commit:
commit 3b3fd068c56e3fbea30090859216a368398e39bf
Author: Anmol Karn
Date: Thu Nov 19 19:10:43 2020 +
rose: Fix Null pointer dereference in rose_send_frame()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=139e2b9b50
start
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 from a CAN
> netdevice.
it is kind of CAN device :)
> What was the reason to fiddle with the 'priv' stuff in j1939_netdev_notify()
> befor
On Sun, Dec 20, 2020 at 3:00 AM Baruch Siach wrote:
>
> Hi Willem,
>
> On Thu, Dec 17 2020, Willem de Bruijn wrote:
> > On Thu, Dec 17, 2020 at 2:48 PM Jakub Kicinski wrote:
> >>
> >> On Tue, 15 Dec 2020 18:51:17 +0200 Baruch Siach wrote:
> >> > Before commit 889b8f964f2f ("packet: Kill CONFIG_PA
On Fri, Dec 18, 2020 at 05:48:29PM -0800, Daniel West wrote:
> This patch fixes the checkpatch warning:
>
> WARNING: Possible repeated word: 'and'
>
> Signed-off-by: Daniel West
> ---
> drivers/staging/qlge/qlge_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dr
Hello,
syzbot found the following issue on:
HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12b12c1350
kernel config: https://syzkaller.appspot.com/x/.config?x=267a60b188ded8ed
das
Hi Jakub,
czw., 10 gru 2020 o 15:35 Marcin Wojtas napisał(a):
>
> Hi Greg,
>
> śr., 9 gru 2020 o 11:59 Greg Kroah-Hartman
> napisał(a):
> >
> > On Tue, Dec 08, 2020 at 04:02:50PM +0100, Marcin Wojtas wrote:
> > > Hi Sasha,
> > >
> > > wt., 8 gru 2020 o 14:35 Sasha Levin napisał(a):
> > > >
> >
>
>
> 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 of the frags i
>
>
> Lorenzo Bianconi writes:
>
> > Introduce __xdp_build_skb_from_frame and
> > xdp_build_skb_from_frame
> > utility routines to build the skb from xdp_frame.
> > Add xdp multi-buff support to cpumap
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > include/net/xdp.h | 5
> > kernel/
On Sat, Dec 19, 2020 at 4:56 PM Shay Agroskin wrote:
>
>
> Lorenzo Bianconi writes:
>
> > Introduce the capability to map non-linear xdp buffer running
> > mvneta_xdp_submit_frame() for XDP_TX and XDP_REDIRECT
> >
> > Signed-off-by: Lorenzo Bianconi
> > ---
> > drivers/net/ethernet/marvell/mvne
Hello,
syzbot found the following issue on:
HEAD commit:5e60366d Merge tag 'fallthrough-fixes-clang-5.11-rc1' of g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=179a228750
kernel config: https://syzkaller.appspot.com/x/.config?x=db720fe37a6a41d8
das
Hmm, on first glance, I'm not sure I'm seeing the bug:
On Sun, Dec 20, 2020 at 5:54 PM syzbot
wrote:
> UBSAN: object-size-mismatch in ./include/linux/skbuff.h:2021:28
> member access within address 85889cc2 with insufficient space
> for an object of type 'struct sk_buff'
> __skb_queue_be
Hello!
Please CC me in future for mwifiex discussion :-)
On Wednesday 28 October 2020 23:24:30 Tsuchiya Yuto wrote:
> Hello all,
>
> On Microsoft Surface devices (PCIe-88W8897), we are observing stability
> issues when ps_mode (IEEE power_save) is enabled, then eventually causes
> firmware crash
> + /* Aneg complete provides more information */
> + if (DEV2G5_PCS1G_ANEG_STATUS_ANEG_COMPLETE_GET(value)) {
> + if (port->conf.portmode == PHY_INTERFACE_MODE_SGMII) {
> + /* SGMII cisco aneg */
> + u32 spdvalue = ((lp_abil >> 10) & 3);
> +++ b/drivers/net/ethernet/microchip/sparx5/sparx5_mactable.c
> +
> +static inline int sparx5_mact_get_status(struct sparx5 *sparx5)
> +{
> + return spx5_rd(sparx5, LRN_COMMON_ACCESS_CTRL);
> +}
> +
> +static inline int sparx5_mact_wait_for_completion(struct sparx5 *sparx5)
> +{
> + u32 v
Hi all,
On Mon, 14 Dec 2020 20:10:25 +1100 Stephen Rothwell
wrote:
>
> After merging the net-next tree, today's linux-next build (htmldocs)
> produced these warnings:
>
> include/net/cfg80211.h:1759: warning: Cannot understand * @struct
> cfg80211_sar_chan_ranges - sar frequency ranges
> on
On Fri, Dec 18, 2020 at 05:11:28PM +0100, Antoine Tenart wrote:
> That build issue seems unrelated to the patch. The series as a whole
> builds fine according to the same report, and this code is not modified
> by later patches.
Hi Antoine, this is a false positive report, kindly ignore this.
Sorry
On 12/16/2020 11:51 PM, Steen Hegelund wrote:
> Document the Sparx5 switch device driver bindings
>
> Signed-off-by: Steen Hegelund
> Signed-off-by: Lars Povlsen
> ---
[snip]
> + max-speed:
> +maxItems: 1
> +description: Bandwidth allocated to this port
> +
Begin forwarded message:
Date: Fri, 18 Dec 2020 23:24:31 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 210781] New: Tun.c fails with tc mirror when using bridges
https://bugzilla.kernel.org/show_bug.cgi?id=210781
Bug ID: 210781
Just in time for the holidays, new iproute2!
This update is smaller than usual, not a lot of new features.
It does NOT include libbpf, that will be merged in 5.11 (iproute2-next).
Download:
https://www.kernel.org/pub/linux/utils/net/iproute2/iproute2-5.10.0.tar.gz
Repository for upcoming rel
On 12/19/2020 4:12 AM, Vladimir Oltean wrote:
> On Fri, Dec 18, 2020 at 08:08:56PM -0800, Florian Fainelli wrote:
>> On 12/18/2020 2:38 PM, Vladimir Oltean wrote:
>>> The SYSTEMPORT driver maps each port of the embedded Broadcom DSA switch
>>> port to a certain queue of the master Ethernet contr
On 12/16/2020 11:51 PM, Steen Hegelund wrote:
> This series provides the Microchip Sparx5 Switch Driver
>
> The Sparx5 Carrier Ethernet and Industrial switch family delivers 64
> Ethernet ports and up to 200 Gbps of switching bandwidth.
>
> It provides a rich set of Ethernet switching features
The declaration of request_irq() in is marked as
__must_check.
Without the return value check, I see the following warnings:
drivers/net/ethernet/lantiq_etop.c: In function 'ltq_etop_hw_init':
drivers/net/ethernet/lantiq_etop.c:273:4: warning: ignoring return value of
'request_irq', declared wi
> I see lots of magic numbers in the driver like 2, 0x33 and 0x34 here.
> Please convert the magic numbers to proper defines explaining the meaning.
> And for vendor commands you could even use enum to group them better in .h
> file somewhere.
Hi Kalle,
Thanks for reviewing the driver, We wil
Srinivasan Raju writes:
>> I see lots of magic numbers in the driver like 2, 0x33 and 0x34 here.
>> Please convert the magic numbers to proper defines explaining the
>> meaning. And for vendor commands you could even use enum to group
>> them better in .h file somewhere.
>
> Hi Kalle,
>
> Thanks
On Mon, Dec 14, 2020 at 12:27 AM Miguel Ojeda
wrote:
>
> On Sun, Dec 13, 2020 at 4:16 PM Greg KH wrote:
> >
> > Because if you get a report of something breaking for your change, you
> > need to work to resolve it, not argue about it. Otherwise it needs to
> > be dropped/reverted.
>
> Nobody has
Am 21.12.20 um 00:19 schrieb Rainer Suhm:
Since kernel 5.9 I do have very poor wlan performance with one of my machines.
The transmission rate is only about a tenth of normal speed (~60MB/s -> 6 MB/s).
iperf3 -c shows hundreds of retries per second
--- snip ---
[ ID] Interval Transfer
Hi!
On Sun, Dec 20, 2020 at 1:10 AM Florian Fainelli wrote:
>
>
>
> On 12/19/2020 8:26 AM, Andrew Lunn wrote:
> >> --- a/drivers/net/dsa/mt7530.c
> >> +++ b/drivers/net/dsa/mt7530.c
> >> @@ -2688,7 +2688,7 @@ static const struct mt753x_info mt753x_table[] = {
> >> };
> >>
> >> static const stru
45 matches
Mail list logo
