Hi Andrii,
I love your patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Andrii-Nakryiko/Support-kernel-module-ksym-variables/20210106-144531
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Ping...
Any comments? Thanks!
> -Original Message-
> From: Jianyong Wu
> Sent: Wednesday, December 9, 2020 2:09 PM
> To: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; [email protected];
> [email protected]; richar
Hi Andrii,
I love your patch! Perhaps something to improve:
[auto build test WARNING on bpf-next/master]
url:
https://github.com/0day-ci/linux/commits/Andrii-Nakryiko/Support-kernel-module-ksym-variables/20210106-144531
base: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf
Hi Thomas,
CC Nemoto-san (de-facto TX49XX maintainer)
On Tue, Jan 5, 2021 at 3:03 PM Thomas Bogendoerfer
wrote:
> I couldn't find any buyable product other than reference boards using
> TX49xx CPUs. And since nobody showed interest in keeping support for
> it, it's time to remove it.
I have an
On 2021-01-04 6:07 PM, Petr Machata wrote:
Roi Dayan writes:
Since moving get_rate() and get_size() from tc to lib, on some
systems we fail to link because of missing the math lib.
Move the link flag from tc makefile to the main makefile.
Hmm, yeah, it gets optimized out on x86-64. The i
Hello,
syzbot found the following issue on:
HEAD commit:3db1a3fa Merge tag 'staging-5.11-rc1' of git://git.kernel...
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1286be6750
kernel config: https://syzkaller.appspot.com/x/.config?x=a6e6725884106332
das
Hi Andrew,
On Wed, Dec 30, 2020 at 11:23 PM Andrew Lunn wrote:
>
> On Wed, Dec 30, 2020 at 09:42:09AM +, Marc Zyngier wrote:
> > > +static irqreturn_t
> > > +mt7530_irq(int irq, void *data)
> > > +{
> > > + struct mt7530_priv *priv = data;
> > > + bool handled = false;
> > > + int phy;
map_direct_mr() assumed that the number of scatter/gather entries
returned by dma_map_sg_attrs() was equal to the number of segments in
the sgl list. This led to wrong population of the mkey object. Fix this
by properly referring to the returned value.
In addition, get rid of fill_sg() whjich effe
From: Rafał Miłecki
Looking for an -EINVAL all over the dsa code could take hours for
inexperienced DSA users.
Signed-off-by: Rafał Miłecki
---
net/dsa/dsa2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
index 183003e45762..01f21b0b379a 100644
--- a/net
在 2021/1/6 16:09, Markus Elfring 写道:
A null-ptr-deref bug is reported by Hulk Robot like this:
Can it be clearer to use the term “null pointer dereference” for the final
commit message?
This advice is too detailed for 'null-ptr-deref' is known as a general phrase
This key word was provid
From: Vladimir Oltean
This series tries to make DSA behave a bit more sanely when bridged with
"foreign" (non-DSA) interfaces and source address learning is not
supported on the hardware CPU port (which would make things work more
seamlessly without software intervention). When a station A connec
From: Vladimir Oltean
Currently the bridge emits atomic switchdev notifications for
dynamically learnt FDB entries. Monitoring these notifications works
wonders for switchdev drivers that want to keep their hardware FDB in
sync with the bridge's FDB.
For example station A wants to talk to statio
From: Vladimir Oltean
Right now, the following would happen for a switch driver that does not
implement .port_fdb_add or .port_fdb_del.
dsa_slave_switchdev_event returns NOTIFY_OK and schedules:
-> dsa_slave_switchdev_event_work
-> dsa_port_fdb_add
-> dsa_port_notify(DSA_NOTIFIER_FDB_AD
From: Vladimir Oltean
We'll need to start listening to SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE
events even for interfaces where dsa_slave_dev_check returns false, so
we need that check inside the switch-case statement for SWITCHDEV_FDB_*.
This movement also avoids a useless allocation / free of switch
From: Vladimir Oltean
Currently DSA doesn't add FDB entries on the CPU port, because it only
does so through switchdev, which is associated with a net_device, and
there are none of those for the CPU port.
But actually FDB addresses on the CPU port have some use cases of their
own, if the switchd
From: Vladimir Oltean
Given the following setup:
ip link add br0 type bridge
ip link set eno0 master br0
ip link set swp0 master br0
ip link set swp1 master br0
ip link set swp2 master br0
ip link set swp3 master br0
Currently, packets received on a DSA slave interface (such as swp0)
which shou
From: Vladimir Oltean
Some DSA switches (and not only) cannot learn source MAC addresses from
packets injected from the CPU. They only perform hardware address
learning from inbound traffic.
This can be problematic when we have a bridge spanning some DSA switch
ports and some non-DSA ports (whic
From: Vladimir Oltean
The dev_close() call was added in commit c9eb3e0f8701 ("net: dsa: Add
support for learning FDB through notification") "to indicate inconsistent
situation" when we could not delete an FDB entry from the port.
bridge fdb del d8:58:d7:00:ca:6d dev swp0 self master
It is a bit
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote:
>
> This is a deinitialization function that always returned zero, and that
> return value was always ignored. Have it return void instead.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Chen-Yu Tsai
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote:
>
> sun8i_dwmac_unpower_internal_phy already checks if the PHY is powered,
> so there is no need to do it again here.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Chen-Yu Tsai
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote:
>
> Adjust the spacing and use an explicit "return 0" in the success path
> to make the function easier to parse.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Chen-Yu Tsai
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote:
>
> Use the appropriate function instead of reimplementing it,
> and update the error message to match the code.
>
> Signed-off-by: Samuel Holland
Reviewed-by: Chen-Yu Tsai
On Sun, Jan 3, 2021 at 7:25 PM Samuel Holland wrote:
>
> The Ethernet MAC and PHY are usually major consumers of power on boards
> which may not be able to fully power off (that have no PMIC). Powering
> down the MAC and internal PHY saves power while these boards are "off".
>
> Signed-off-by: Sam
On Wed, Jan 6, 2021 at 8:09 AM Alexei Starovoitov
wrote:
>
> On Tue, Jan 05, 2021 at 01:03:47PM -0800, Andrii Nakryiko wrote:
> > > >
> > > > - handling 32-bit vs 64-bit UAPI structs uniformly;
> > >
> > > what do you mean?
> > > 32-bit user space running on 64-bit kernel works through 'compat'
From: Yingjie Wang
In rvu_mbox_handler_cgx_mac_addr_get()
and rvu_mbox_handler_cgx_mac_addr_set(),
the msg is expected only from PFs that are mapped to CGX LMACs.
It should be checked before mapping,
so we add the is_cgx_config_permitted() in the functions.
Signed-off-by: Yingjie Wang
---
driv
It should be a typing error ('-' instead of '_'), as no mdio-bus.c but
just mdio_bus.c exists.
Just find it when inspecting these code. Tried to compile to test, but
failed to construct an applicable .config file for that. Maybe someone
can do that more skillfully, glad to know how.
Signed-off-by
At the moment it is quite hard to identify the network interface
provided by IPA in userspace components: The network interface is
created as virtual device, without any link to the IPA device.
The interface name ("rmnet_ipa%d") is the only indication that the
network interface belongs to IPA, but
On Tue, 5 Jan 2021 18:43:08 +0100
Marek Behún wrote:
> On Tue, 5 Jan 2021 18:24:37 +0100
> Sven Auhagen wrote:
>
> > On Tue, Jan 05, 2021 at 06:19:21PM +0100, Marek Behún wrote:
> > > Currently mvpp2_xdp_setup won't allow attaching XDP program if
> > > mtu > ETH_DATA_LEN (1500).
> > >
> >
According to Realtek the ERI register 0x1a8 quirk is needed to work
around a hw issue with the PHY on RTL8168g. The register needs to be
changed before powering down the PHY. Currently we don't meet this
requirement, however I'm not aware of any problems caused by this.
Therefore I see the change a
No functional change here. We just move a code block to avoid a
function forward declaration in a subsequent change.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 128 +++---
1 file changed, 64 insertions(+), 64 deletions(-)
diff --git a/drivers/
According to Realtek the ERI register 0x1a8 quirk is needed to work
around a hw issue with the PHY on RTL8168g. The register needs to be
changed before powering down the PHY. Currently we don't meet this
requirement, however I'm not aware of any problems caused by this.
Therefore I see the change a
From: Yingjie Wang
In rvu_mbox_handler_cgx_mac_addr_get()
and rvu_mbox_handler_cgx_mac_addr_set(),
the msg is expected only from PFs that are mapped to CGX LMACs.
It should be checked before mapping,
so we add the is_cgx_config_permitted() in the functions.
Fixes: 85482bb ("af/rvu_cgx: Fix missi
> On Mon, 28 Dec 2020 16:14:17 -0500 Konstantin Ryabitsev wrote:
> > On Mon, Dec 28, 2020 at 01:05:26PM -0800, Florian Fainelli wrote:
> > > On 12/28/2020 12:23 PM, Konstantin Ryabitsev wrote:
> > > > On Thu, Dec 24, 2020 at 01:57:40PM -0800, Florian Fainelli wrote:
> > > Konstantin, would
On Mon, 28 Dec 2020 15:05:08 +0800, Tian Tao wrote:
> asm/exception.h is included more than once. Remove the one that isn't
> necessary.
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: traps: remove duplicate include statement
https://git.kernel.org/arm64/c/3fb6819f411b
--
Catalin
If we know that a device has broken parity checking, then disable it.
This avoids quirks like in r8169 where on the first parity error
interrupt parity checking will be disabled if broken_parity_status
is set. Make pci_quirk_broken_parity() public so that it can be used
by platform code, e.g. for T
If we know that a device has broken parity checking, then disable it.
This avoids quirks like in r8169 where on the first parity error
interrupt parity checking will be disabled if broken_parity_status
is set. Make pci_quirk_broken_parity() public so that it can be used
by platform code, e.g. for T
Meanwhile the PCI core disables parity checking for a device that has
broken_parity_status set. Therefore we don't need the quirk any longer
to disable parity checking on the first parity error interrupt.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 14 -
Use new PCI core function pci_quirk_broken_parity(), in addition to
setting broken_parity_status is disables parity checking.
This allows us to remove a quirk in r8169 driver.
Signed-off-by: Heiner Kallweit
---
v2:
- remove additional changes from this patch
---
arch/arm/mach-iop32x/n2100.c | 2
On Wed, Jan 06, 2021 at 05:46:22PM +0800, Qinglang Miao wrote:
>
>
> 在 2021/1/6 16:09, Markus Elfring 写道:
> > > > > A null-ptr-deref bug is reported by Hulk Robot like this:
> > > >
> > > > Can it be clearer to use the term “null pointer dereference” for the
> > > > final commit message?
> > >
On Tue, 5 Jan 2021 21:21:10 +0100
Andrew Lunn wrote:
> On Tue, Jan 05, 2021 at 06:43:08PM +0100, Marek Behún wrote:
> > On Tue, 5 Jan 2021 18:24:37 +0100
> > Sven Auhagen wrote:
> >
> > > On Tue, Jan 05, 2021 at 06:19:21PM +0100, Marek Behún wrote:
> > > > Currently mvpp2_xdp_setup won't al
From: Rafał Miłecki
BCM4908 family SoCs come with integrated Starfighter 2 switch. Its
registers layout it a mix of BCM7278 and BCM7445. It has 5 integrated
PHYs and 8 ports. It also supports RGMII and SerDes.
Signed-off-by: Rafał Miłecki
---
drivers/net/dsa/b53/b53_common.c | 14 +
From: Rafał Miłecki
BCM4908 family SoCs have integrated Starfighter 2 switch.
Signed-off-by: Rafał Miłecki
---
Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml
b/Documentation/de
From: Rafał Miłecki
This helps validating DTS files. Only the current (not deprecated one)
binding was converted.
Minor changes:
1. Dropped dsa/dsa.txt references
2. Updated node name to match dsa.yaml requirement
3. Fixed 2 typos in examples
The new binding was validated using the dt_binding_c
On Tue, 5 Jan 2021 21:23:12 +0100
Andrew Lunn wrote:
> > @@ -4913,8 +4914,8 @@ static int mvpp2_xdp_setup(struct mvpp2_port *port,
> > struct netdev_bpf *bpf)
> > bool running = netif_running(port->dev);
> > bool reset = !prog != !port->xdp_prog;
> >
> > - if (port->dev->mtu > ETH_DA
On Wed, 6 Jan 2021 10:45:30 +1000
Pavana Sharma wrote:
> Thanks Marek for catching this.
>
> I will have a closer look and update the patchset.
I also sent a reply patch with subject
"patch fixing mv88e6393x SERDES IRQ for Pavana's series"
it contains the changes necessary to your series. P
When measuring the throughput (iperf3 + TCP) while routing on a
not-so-powerful device (Mediatek MT7621, 880MHz CPU), I noticed that I
achieved significantly lower speeds with QMI-based modems than for
example a USB LAN dongle. The CPU was saturated in all of my tests.
With the dongle I got ~300 M
On Wed, 6 Jan 2021 12:56:08 +0100
Marek Behún wrote:
> I also to write a simple NAT masquerading program. I think XDP can
> increase NAT throughput to 2.5gbps as well.
BTW currently if XDP modifies the packet, it has to modify the
checksums accordingly. There is a helper for that even, bpf_csum_
On Wed, 6 Jan 2021 13:32:05 +0100
Marek Behún wrote:
> On Wed, 6 Jan 2021 12:56:08 +0100
> Marek Behún wrote:
>
> > I also to write a simple NAT masquerading program. I think XDP can
> > increase NAT throughput to 2.5gbps as well.
>
> BTW currently if XDP modifies the packet, it has to modify
On 2021-01-06 10:42 AM, Roi Dayan wrote:
On 2021-01-04 6:07 PM, Petr Machata wrote:
Roi Dayan writes:
Since moving get_rate() and get_size() from tc to lib, on some
systems we fail to link because of missing the math lib.
Move the link flag from tc makefile to the main makefile.
Hmm,
Switch to lockdep_assert_held(_once), similar to what is being done
in other subsystems. One advantage is that there's zero runtime
overhead if lockdep support isn't enabled.
Signed-off-by: Heiner Kallweit
---
drivers/net/phy/mdio_bus.c | 4 ++--
drivers/net/phy/phy.c| 2 +-
drivers/ne
From: Danielle Ratson
Currently, when auto negotiation is set to off, the user can force a
specific speed or both speed and duplex. The user cannot influence the
number of lanes that will be forced.
Add support for setting speed along with lanes so one would be able
to choose how many lanes will
From: Danielle Ratson
Test that setting lanes parameter is working.
Set max speed and max lanes in the list of advertised link modes,
and then try to set max speed with the lanes below max lanes if exists
in the list.
And then, test that setting number of lanes larger than max lanes fails.
Do
From: Danielle Ratson
Currently, when user space queries the link's parameters, as speed and
duplex, each parameter is passed from the driver to ethtool.
Instead, get the link mode bit in use, and derive each of the parameters
from it in ethtool.
Signed-off-by: Danielle Ratson
---
Documentati
From: Danielle Ratson
Currently, when user space queries the link's parameters, as speed and
duplex, each parameter is passed from the driver to ethtool.
Instead, pass the link mode bit in use.
In Spectrum-1, simply pass the bit that is set to '1' from PTYS register.
In Spectrum-2, pass the firs
From: Danielle Ratson
Currently, ethtool does not expose how many lanes are used when the
link is up.
After adding a possibility to advertise or force a specific number of
lanes, the lanes in use value can be either the maximum width of the port
or below.
Extend ethtool to expose the number of
From: Danielle Ratson
Currently, when auto negotiation is on, the user can advertise all the
linkmodes which correspond to a specific speed, but does not have a
similar selector for the number of lanes. This is significant when a
specific speed can be achieved using different number of lanes. Fo
From: Danielle Ratson
Some speeds can be achieved with different number of lanes. For example,
100Gbps can be achieved using two lanes of 50Gbps or four lanes of
25Gbps. This patch set adds a new selector that allows ethtool to
advertise link modes according to their number of lanes and also forc
From: Danielle Ratson
Currently, when a speed can be supported by different number of lanes,
the supported link modes bitmask contains only link modes with a single
number of lanes.
This was done in order to prevent auto negotiation on number of
lanes after 50G-1-lane and 100G-2-lanes link modes
From: Vladimir Oltean
Since the introduction of the switchdev API, port objects were
transmitted to drivers for offloading using a two-step transactional
model, with a prepare phase that was supposed to catch all errors, and a
commit phase that was supposed to never fail.
Some classes of failure
From: Vladimir Oltean
This series comes after the late realization that the prepare/commit
separation imposed by switchdev does not help literally anybody:
https://patchwork.kernel.org/project/netdevbpf/patch/[email protected]/
We should kill it before it inflicts e
From: Danielle Ratson
Currently, there is no way of knowing how many lanes will be use to
achieve a wanted speed.
For example, 100G speed can be achieved using: 2X50 or 4X25.
In order to solve that, extend ethtool uAPI with lanes as a new link
mode setting so the command below, for example, will
From: Danielle Ratson
Lanes parameter was added for setting using ethtool.
Update the man page to include the new parameter.
Signed-off-by: Danielle Ratson
---
ethtool.8.in | 4
1 file changed, 4 insertions(+)
diff --git a/ethtool.8.in b/ethtool.8.in
index ba4e245..fe49b66 100644
--- a/
From: Vladimir Oltean
Since the introduction of the switchdev API, port attributes were
transmitted to drivers for offloading using a two-step transactional
model, with a prepare phase that was supposed to catch all errors, and a
commit phase that was supposed to never fail.
Some classes of fail
From: Vladimir Oltean
For many drivers, the .port_mdb_prepare callback was not a good opportunity
to avoid any error condition, and they would suppress errors found during
the actual commit phase.
Where a logical separation between the prepare and the commit phase
existed, the function that used
From: Vladimir Oltean
After the removal of the transactional model inside
switchdev_port_obj_add_now, it has no added value and we can just call
switchdev_port_obj_notify directly, bypassing this function. Let's
delete it.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Acked-by:
Add support for "ethtool -s lanes N ..." for setting a specific
number of lanes.
Signed-off-by: Danielle Ratson
Reviewed-by: Jiri Pirko
---
ethtool.c | 1 +
netlink/settings.c | 8
2 files changed, 9 insertions(+)
diff --git a/ethtool.c b/ethtool.c
index 585aafa..fcb09f7 100
From: Vladimir Oltean
It should be the driver's business to logically separate its VLAN
offloading into a preparation and a commit phase, and some drivers don't
need / can't do this.
So remove the transactional shim from DSA and let drivers propagate
errors directly from the .port_vlan_add callb
From: Vladimir Oltean
Remove the shim introduced in DSA for offloading the bridge ageing time
from switchdev, by first checking whether the ageing time is within the
range limits requested by the driver.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Acked-by: Linus Walleij
Acke
From: Vladimir Oltean
As of commit 457e20d65924 ("mlxsw: spectrum_switchdev: Avoid returning
errors in commit phase"), the mlxsw driver performs the VLAN object
offloading during the prepare phase. So conversion just seems to be a
matter of removing the code that was running in the commit phase.
From: Vladimir Oltean
Now that all users of struct switchdev_trans have been modified to do
without it, we can remove this structure and the two helpers to determine
the phase.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Acked-by: Linus Walleij
Acked-by: Jiri Pirko
---
Chang
From: Danielle Ratson
Currently, the user does not have the information regarding how many lanes
are used when the link is up.
After adding a possibility to advertise or force a specific number of
lanes this information becomes helpful.
Expose the number of lanes in use if the information is pa
Add ETHTOOL_A_LINKMODES_LANES, expand ethtool_link_settings with
lanes attribute and define valid lanes in order to support a new
lanes-selector.
Signed-off-by: Danielle Ratson
Reviewed-by: Jiri Pirko
---
netlink/desc-ethtool.c | 1 +
uapi/linux/ethtool.h | 8
uapi/linux/
From: Vladimir Oltean
Now that all port object notifiers were converted to be non-transactional,
we can remove the comments that say otherwise.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
Acked-by: Linus Walleij
Acked-by: Jiri Pirko
---
Changes in v2:
None.
net/dsa/slave.c
Lanes was added as a new link mode setting in ethtool.
Support completion for lanes when setting parameters.
Signed-off-by: Danielle Ratson
Reviewed-by: Jiri Pirko
---
shell-completion/bash/ethtool | 4
1 file changed, 4 insertions(+)
diff --git a/shell-completion/bash/ethtool b/shell-co
From: Vladimir Oltean
The call path of a switchdev VLAN addition to the bridge looks something
like this today:
nbp_vlan_init
| __br_vlan_set_default_pvid
| | |
| |br_afspec |
| || |
| |
On Wed, Jan 06, 2021 at 12:56:08PM +0100, Marek Behún wrote:
> I found out that on Turris MOX I am able to route 2.5gbps (at MTU 1500)
> with XDP. But when not using XDP, when the packets go via kernel's
> stack, MOX is able to route less than 1gbps (cca 800mbps, at MTU
> 1500, and the CPU is at 10
Roi Dayan writes:
> On 2021-01-06 10:42 AM, Roi Dayan wrote:
>>
>> On 2021-01-04 6:07 PM, Petr Machata wrote:
>>>
>>> I think that just adding an unnecessary -lm is more of a tidiness issue
>>> than anything else. One way to avoid it is to split the -lm deps out
>>> from util.c / json_print.c
On 09:02 Tue 05 Jan 2021, Randy Dunlap wrote:
On 1/5/21 2:17 AM, Bhaskar Chowdhury wrote:
s/defautly/de-faulty/p
Signed-off-by: Bhaskar Chowdhury
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/
This series includes a number of smaller improvements.
Heiner Kallweit (3):
r8169: replace BUG_ON with WARN in _rtl_eri_write
r8169: improve rtl_ocp_reg_failure
r8169: don't wakeup-enable device on shutdown if WOL is disabled
drivers/net/ethernet/realtek/r8169_main.c | 21 -
Use WARN here to avoid stopping the system. In addition print the addr
and mask values that triggered the warning.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_m
Use WARN_ONCE here to get a call trace in case of a problem.
This facilitates finding the offending code part.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/
If WOL isn't enabled, then there's no need to enable wakeup from D3.
Signed-off-by: Heiner Kallweit
---
drivers/net/ethernet/realtek/r8169_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169_main.c
b/drivers/net/ethernet/realtek/r8169_ma
Currently, the MHI controller driver defines which channels should
have their inbound buffers allocated and queued. But ideally, this is
something that should be decided by the MHI device driver instead,
which actually deals with that buffers.
Add a flag parameter to mhi_prepare_for_transfer allow
Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX
delay register which allows picoseconds precision. Parse the new
"rx-internal-delay-ps" property or fall back to the value from the old
"amlogic,rx-delay-ns" property.
No upstream DTB uses the old "amlogic,rx-delay-ns" property (y
Newer SoCs starting with the Amlogic Meson G12A have more a precise
RGMII RX delay configuration register. This means more complexity in the
code. Extract the existing RGMII delay configuration code into a
separate function to make it easier to read/understand even when adding
more logic in the fut
Amlogic Meson G12A (and newer: G12B, SM1) SoCs have a more advanced RX
delay logic. Instead of fine-tuning the delay in the nanoseconds range
it now allows tuning in 200 picosecond steps. This support comes with
new bits in the PRG_ETH1[19:16] register.
Add support for validating the RGMII RX dela
Hello,
with the help of Jianxin Pan (many thanks!) the meaning of the "new"
PRG_ETH1[19:16] register bits on Amlogic Meson G12A, G12B and SM1 SoCs
are finally known. These SoCs allow fine-tuning the RGMII RX delay in
200ps steps (contrary to what I have thought in the past [0] these are
not some "
The timing-adjustment clock only has to be enabled when a) there is a
2ns RX delay configured using device-tree and b) the phy-mode indicates
that the RX delay should be enabled.
Only enable the RX delay if both are true, instead of (by accident) also
enabling it when there's the 2ns RX delay conf
Amlogic Meson G12A, G12B and SM1 SoCs have a more advanced RGMII RX
delay register which allows picoseconds precision. Deprecate the old
"amlogic,rx-delay-ns" in favour of the generic "rx-internal-delay-ps"
property.
For older SoCs the only known supported values were 0ns and 2ns. The new
SoCs hav
On Tue, Jan 05, 2021 at 08:58:50PM +0200, Vladimir Oltean wrote:
> This is marked as Request For Comments for a reason.
If nobody has any objections, I will remove the memory leaks I
introduced to check if anybody is paying attention, and I will resubmit
this as a non-RFC series.
Arnd Bergmann [2021-01-03 14:57:55]:
Hi,
just a small nitpick,
> From: Arnd Bergmann
>
> The lone '|' at the end of a line causes a build failure:
>
> drivers/net/wireless/mediatek/mt76/mt7915/init.c:47:2: error: expected
> expression before '}' token
>
> Replace the #ifdef with an equival
Hi Vladimir,
I love your patch! Perhaps something to improve:
[auto build test WARNING on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Get-rid-of-the-switchdev-transactional-model/20210106-211752
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem
On 2021-01-06 3:16 PM, Petr Machata wrote:
Roi Dayan writes:
On 2021-01-06 10:42 AM, Roi Dayan wrote:
On 2021-01-04 6:07 PM, Petr Machata wrote:
I think that just adding an unnecessary -lm is more of a tidiness issue
than anything else. One way to avoid it is to split the -lm deps out
Roi Dayan writes:
> On 2021-01-06 3:16 PM, Petr Machata wrote:
>> Regarding the publishing, the _jw reference can be changed to a call to
>> is_json_context(), which does the same thing. Then _jw can stay private
>> in json_print.c.
>> Exposing an _IS_JSON_CONTEXT / _IS_FP_CONTEXT might be odd
Kristian Evensen writes:
> When measuring the throughput (iperf3 + TCP) while routing on a
> not-so-powerful device (Mediatek MT7621, 880MHz CPU), I noticed that I
> achieved significantly lower speeds with QMI-based modems than for
> example a USB LAN dongle. The CPU was saturated in all of my t
This patch series aim to improve the bcm63xx_enet driver by integrating the
latest networking features, i.e. batched rx processing, BQL, build_skb,
etc.
The newer enetsw SoCs are found to be able to do unaligned rx DMA by adding
NET_IP_ALIGN padding which, combined with these patches, improved pac
Use netif_receive_skb_list to batch process rx skb.
Tested on BCM6328 320 MHz using iperf3 -M 512, increasing performance
by 12.5%.
Before:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-30.00 sec 120 MBytes 33.7 Mbits/sec 277 sender
[ 4] 0.00-30.00 sec
Add Byte Queue Limits support to reduce/remove bufferbloat in
bcm63xx_enet.
Signed-off-by: Sieng Piaw Liew
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/broadcom/bcm63xx_enet.c
b/drivers/net/ethernet/broadcom/b
The rx SKB ring use the same code for cleanup at various points.
Combine them into a function to reduce lines of code.
Signed-off-by: Sieng Piaw Liew
---
drivers/net/ethernet/broadcom/bcm63xx_enet.c | 72 ++--
1 file changed, 22 insertions(+), 50 deletions(-)
diff --git a/driver
We can increase the efficiency of rx path by using buffers to receive
packets then build SKBs around them just before passing into the network
stack. In contrast, preallocating SKBs too early reduces CPU cache
efficiency.
Check if we're in NAPI context when refilling RX. Normally we're almost
alwa
1 - 100 of 320 matches
Mail list logo
