Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sat, 17 Apr 2021 15:29:04 +0800 you wrote:
> Issue was traffic problems after a while with increased ping times if
> flow offload is active. It turns out that key_offset with cookie is
> needed in rhashtable_params but w
On Thu, Apr 15, 2021 at 04:27:58PM -0500, Rob Herring wrote:
> On Thu, Apr 15, 2021 at 11:26:10AM +0200, Tobias Waldekranz wrote:
> > The 'dsa,tag-protocol' is used to force a switch tree to use a
> > particular tag protocol, typically because the Ethernet controller
> > that it is connected to is
Tested on Bananapi-r2 (please see my mt7623 patch for supporting offloading)
with ~300 iperf3 iterations and uptime >6h
Tested-by: Frank Wunderlich
regards Frank
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Fri, 16 Apr 2021 11:15:17 +0300 you wrote:
> From: Stefan Chulski
>
> Add parser entries for different IPv4 IHL values.
> Each entry will set the L4 header offset according to the IPv4 IHL field.
> L3 header offset wil
On Thu, Apr 15, 2021 at 11:26:10AM +0200, Tobias Waldekranz wrote:
> The 'dsa,tag-protocol' is used to force a switch tree to use a
> particular tag protocol, typically because the Ethernet controller
> that it is connected to is not compatible with the default one.
>
> Signed-off-by: Tobias Walde
On Thu, Apr 15, 2021 at 11:26:09AM +0200, Tobias Waldekranz wrote:
> Some combinations of tag protocols and Ethernet controllers are
> incompatible, and it is hard for the driver to keep track of these.
>
> Therefore, allow the device tree author (typically the board vendor)
> to inform the driver
On 4/15/2021 2:26 AM, Tobias Waldekranz wrote:
> Previously DSA ports were also included, on the assumption that the
> protocol used by the CPU port had to the matched throughout the entire
> tree.
>
> As there is not yet any consumer in need of this, drop the call.
>
> Signed-off-by: Tobias W
On 4/15/2021 2:26 AM, Tobias Waldekranz wrote:
> For devices that supports both regular and Ethertyped DSA tags, allow
> the user to change the protocol.
>
> Additionally, because there are ethernet controllers that do not
> handle regular DSA tags in all cases, also allow the protocol to be
>
On 4/15/2021 2:26 AM, Tobias Waldekranz wrote:
> All devices are capable of using regular DSA tags. Support for
> Ethertyped DSA tags sort into three categories:
>
> 1. No support. Older chips fall into this category.
>
> 2. Full support. Datasheet explicitly supports configuring the CPU
>
On Thu, Apr 15, 2021 at 11:26:08AM +0200, Tobias Waldekranz wrote:
> Previously DSA ports were also included, on the assumption that the
> protocol used by the CPU port had to the matched throughout the entire
> tree.
>
> As there is not yet any consumer in need of this, drop the call.
>
> Signed
On Thu, Apr 15, 2021 at 11:26:07AM +0200, Tobias Waldekranz wrote:
> For devices that supports both regular and Ethertyped DSA tags, allow
> the user to change the protocol.
>
> Additionally, because there are ethernet controllers that do not
> handle regular DSA tags in all cases, also allow the
On Thu, Apr 15, 2021 at 11:26:06AM +0200, Tobias Waldekranz wrote:
> All devices are capable of using regular DSA tags. Support for
> Ethertyped DSA tags sort into three categories:
>
> 1. No support. Older chips fall into this category.
>
> 2. Full support. Datasheet explicitly supports configur
Hi Thomas,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Thomas-Bogendoerfer/net-Korina-improvements/20210414-233326
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
5871d0c6b8e
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Wed, 14 Apr 2021 22:22:57 +0300 you wrote:
> From: Florian Fainelli
>
> Some Ethernet switches might only be able to support disabling multicast
> snooping globally, which is an issue for example when several bridges
>
From: Thomas Bogendoerfer
Date: Wed, 14 Apr 2021 17:29:36 +0200
> While converting Mikrotik RB532 support to use device tree I stumbled
> over the korina ethernet driver, which used way too many MIPS specific
> hacks. This series cleans this all up and adds support for device tree.
>
> Changes i
On 4/14/2021 8:29 AM, Thomas Bogendoerfer wrote:
> If there is no mac address passed via platform data try to get it via
> device tree and fall back to a random mac address, if all fail.
>
> Signed-off-by: Thomas Bogendoerfer
> ---
> drivers/net/ethernet/korina.c | 29
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 13 Apr 2021 10:22:16 -0700 you wrote:
> All the uses of HWTSTAMP_FILTER_* values need to be
> bit shifters, not straight values.
>
> v2: fixed subject and added Cc Dan and SoB Allen
>
> Fixes: f8ba81da73fc ("ionic
> From: Stephen Hemminger
> Sent: Thursday, April 8, 2021 9:52 AM
Thanks all for your input! We'll make the below changes as suggested:
Microsoft Azure Network Device ==> Microsoft Network Devices
Drop the default m
validated ==> supported
We'll also fix some warnings reported by "kernel test r
; netdev@vger.kernel.org; l...@kernel.org;
> and...@lunn.ch; be...@petrovitsch.priv.at; linux-ker...@vger.kernel.org;
> linux-hyp...@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure
> Network Adapter (MANA)
>
> On Thu, 8 Apr 2021 09:22:57 -0
On Thu, 8 Apr 2021 09:22:57 -0700
Randy Dunlap wrote:
> On 4/8/21 2:15 AM, Dexuan Cui wrote:
> > diff --git a/drivers/net/ethernet/microsoft/Kconfig
> > b/drivers/net/ethernet/microsoft/Kconfig
> > new file mode 100644
> > index ..12ef6b581566
> > --- /dev/null
> > +++ b/drivers/net/
; netdev@vger.kernel.org; l...@kernel.org;
> be...@petrovitsch.priv.at; linux-ker...@vger.kernel.org; linux-
> hyp...@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure
> Network Adapter (MANA)
>
> > > > diff --git a/drivers/net/ethernet/mi
> > > diff --git a/drivers/net/ethernet/microsoft/Kconfig
> > b/drivers/net/ethernet/microsoft/Kconfig
> > > new file mode 100644
> > > index ..12ef6b581566
> > > --- /dev/null
> > > +++ b/drivers/net/ethernet/microsoft/Kconfig
> > > @@ -0,0 +1,30 @@
> > > +#
> > > +# Microsoft Azure ne
el.org;
> and...@lunn.ch; be...@petrovitsch.priv.at
> Cc: linux-ker...@vger.kernel.org; linux-hyp...@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure
> Network Adapter (MANA)
>
> On 4/8/21 2:15 AM, Dexuan Cui wrote:
> > diff --
On 4/8/21 2:15 AM, Dexuan Cui wrote:
> diff --git a/drivers/net/ethernet/microsoft/Kconfig
> b/drivers/net/ethernet/microsoft/Kconfig
> new file mode 100644
> index ..12ef6b581566
> --- /dev/null
> +++ b/drivers/net/ethernet/microsoft/Kconfig
> @@ -0,0 +1,30 @@
> +#
> +# Microsoft Azur
Hi Dexuan,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Dexuan-Cui/net-mana-Add-a-driver-for-Microsoft-Azure-Network-Adapter-MANA/20210408-171836
base: https://git.kernel.org/pub/scm/linux/kernel/git/d
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Tue, 6 Apr 2021 09:32:50 +0800 you wrote:
> EHL PSE SGMII mode requires to ungate the SERDES PHY rx clk for power up
> sequence and vice versa.
>
> Signed-off-by: Voon Weifeng
> ---
> Changes:
> v1 -> v2
> -change s
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Sun, 4 Apr 2021 13:38:23 + you wrote:
> struct ip6_sf_socklist and ipv6_mc_socklist are per-socket MLD data.
> These data are protected by rtnl lock, socket lock, and RCU.
> So, when these are used, it verifies whet
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Fri, 26 Mar 2021 01:39:11 +0800 you wrote:
> This patchset adds support for multi MSI interrupts in addition to
> current single common interrupt implementation. Each MSI interrupt is tied
> to a newly introduce interru
>+static int stmmac_config_multi_msi(struct pci_dev *pdev,
>+ struct plat_stmmacenet_data *plat,
>+ struct stmmac_resources *res)
>+{
For optimum RX & TX queue processing on the same IRQ, we should use
irq_set_affinity_hint() to set th
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 22 Mar 2021 11:51:55 +0800 you wrote:
> This patchset refactor some functions and add some new features for
> flow director.
>
> patch 1~3: refactor large functions
> patch 4, 7: add traffic class and user-def fie
On 3/21/21 6:43 AM, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> Currently, MSG_CMSG_COMPAT is defined as '1 << 31'. However, 'msg_flags'
> is defined with type of 'int' somewhere, such as 'packet_recvmsg' and
> other recvmsg functions:
>
> static int packet_recvmsg(struct socket *s
On 3/21/21 6:43 AM, menglong8.d...@gmail.com wrote:
> From: Menglong Dong
>
> The bit mask for MSG_* seems a little confused here. Replace it
> with BIT() to make it clear to understand.
>
> Signed-off-by: Menglong Dong
With this patch sent as patch 1/2, any code trying to bisect
a compat rela
Hello:
This patch was applied to netdev/net-next.git (refs/heads/master):
On Thu, 18 Mar 2021 20:44:31 +0100 you wrote:
> Here is what Vladimir says about it:
>
> at803x_aneg_done() keeps the aneg reporting as "not done" even when
> the copper-side link was reported as up, but the in-band au
On 18.03.2021 20:44, Michael Walle wrote:
> Here is what Vladimir says about it:
>
> at803x_aneg_done() keeps the aneg reporting as "not done" even when
> the copper-side link was reported as up, but the in-band autoneg has
> not finished.
>
> That was the _intended_ behavior when that co
Am 2021-03-18 20:44, schrieb Michael Walle:
Here is what Vladimir says about it:
at803x_aneg_done() keeps the aneg reporting as "not done" even when
the copper-side link was reported as up, but the in-band autoneg has
not finished.
That was the _intended_ behavior when that code was int
On 3/18/2021 7:35 AM, Vladimir Oltean wrote:
> On Thu, Mar 18, 2021 at 03:15:50PM +0100, Tobias Waldekranz wrote:
>> These switches have two modes of classifying broadcast:
>>
>> 1. Broadcast is multicast.
>> 2. Broadcast is its own unique thing that is always flooded
>>everywhere.
>>
>> Thi
On 3/18/2021 7:15 AM, Tobias Waldekranz wrote:
> Allow a user to control automatic learning per port.
>
> Many chips have an explicit "LearningDisable"-bit that can be used for
> this, but we opt for setting/clearing the PAV instead, as it works on
> all devices at least as far back as 6083.
>
On 3/18/2021 7:15 AM, Tobias Waldekranz wrote:
> Use the conventional declaration style of a MAC address in the
> kernel (u8 addr[ETH_ALEN]) for the broadcast address, then set it
> using the existing helper.
>
> Signed-off-by: Tobias Waldekranz
Reviewed-by: Florian Fainelli
--
Florian
On 3/18/2021 7:15 AM, Tobias Waldekranz wrote:
> The hardware has a somewhat quirky protocol for reading out the VTU
> entry for a particular VID. But there is no reason why we cannot
> create a better API for ourselves in the driver.
>
> Signed-off-by: Tobias Waldekranz
Reviewed-by: Florian
On 3/18/2021 7:15 AM, Tobias Waldekranz wrote:
> Move the intricacies of correctly iterating over the VTU to a common
> implementation.
>
> Signed-off-by: Tobias Waldekranz
> Reviewed-by: Andrew Lunn
Reviewed-by: Florian Fainelli
--
Florian
On 3/18/2021 7:15 AM, Tobias Waldekranz wrote:
> When a port is a part of a LAG, the ATU will create dynamic entries
> belonging to the LAG ID when learning is enabled. So trying to
> fast-age those out using the constituent port will have no
> effect. Unfortunately the hardware does not support
On 3/18/2021 7:15 AM, Tobias Waldekranz wrote:
> In order for a driver to be able to query a bridge for information
> about itself, e.g. reading out port flags, it has to use a netdev that
> is known to the bridge. In the simple case, that is just the netdev
> representing the port, e.g. swp0 or
On Thu, Mar 18, 2021 at 03:15:43PM +0100, Tobias Waldekranz wrote:
> In order for a driver to be able to query a bridge for information
> about itself, e.g. reading out port flags, it has to use a netdev that
> is known to the bridge. In the simple case, that is just the netdev
> representing the p
On Thu, Mar 18, 2021 at 03:15:44PM +0100, Tobias Waldekranz wrote:
> When a port is a part of a LAG, the ATU will create dynamic entries
> belonging to the LAG ID when learning is enabled. So trying to
> fast-age those out using the constituent port will have no
> effect. Unfortunately the hardware
On Thu, Mar 18, 2021 at 03:15:50PM +0100, Tobias Waldekranz wrote:
> These switches have two modes of classifying broadcast:
>
> 1. Broadcast is multicast.
> 2. Broadcast is its own unique thing that is always flooded
>everywhere.
>
> This driver uses the first option, making sure to load the
On Thu, Mar 18, 2021 at 03:15:49PM +0100, Tobias Waldekranz wrote:
> Allow a user to control automatic learning per port.
>
> Many chips have an explicit "LearningDisable"-bit that can be used for
> this, but we opt for setting/clearing the PAV instead, as it works on
> all devices at least as far
On Thu, Mar 18, 2021 at 03:15:47PM +0100, Tobias Waldekranz wrote:
> Use the conventional declaration style of a MAC address in the
> kernel (u8 addr[ETH_ALEN]) for the broadcast address, then set it
> using the existing helper.
>
> Signed-off-by: Tobias Waldekranz
> ---
Reviewed-by: Vladimir Ol
On Thu, Mar 18, 2021 at 03:15:46PM +0100, Tobias Waldekranz wrote:
> The hardware has a somewhat quirky protocol for reading out the VTU
> entry for a particular VID. But there is no reason why we cannot
> create a better API for ourselves in the driver.
>
> Signed-off-by: Tobias Waldekranz
> ---
On Thu, Mar 18, 2021 at 03:15:45PM +0100, Tobias Waldekranz wrote:
> Move the intricacies of correctly iterating over the VTU to a common
> implementation.
>
> Signed-off-by: Tobias Waldekranz
> Reviewed-by: Andrew Lunn
> ---
Reviewed-by: Vladimir Oltean
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Wed, 17 Mar 2021 11:29:25 +0100 you wrote:
> Legacy Broadcom tags are needed for older switches.
>
> Álvaro Fernández Rojas (2):
> net: dsa: tag_brcm: add support for legacy tags
> net: dsa: b53: support legacy tag
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Tue, 16 Mar 2021 13:24:07 +0200 you wrote:
> From: Vladimir Oltean
>
> Many changes were made to the code but of course the documentation was
> not kept up to date. This is an attempt to update some of the verbiage.
>
The 03/16/2021 13:24, Vladimir Oltean wrote:
>
> From: Vladimir Oltean
>
> Add a short summary of the methods that a driver writer must implement
> for getting an MRP instance to work on top of a DSA switch.
>
> Cc: Horatiu Vultur
> Signed-off-by: Vladimir Oltean
> ---
> Documentation/networ
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Mon, 15 Mar 2021 16:45:26 +0100 you wrote:
> This controller is present on BCM6318, BCM6328, BCM6362, BCM6368 and BCM63268
> SoCs.
>
> v2: add changes suggested by Andrew Lunn and Jakub Kicinski.
>
> Álvaro Fernández
On Tue, Mar 16, 2021 at 13:24, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> Add a short summary of the methods that a driver writer must implement
> for offloading a link aggregation group, and what is still missing.
>
> Cc: Tobias Waldekranz
> Signed-off-by: Vladimir Oltean
> Reviewed-by
On Tue, Mar 16, 2021 at 04:04:31PM +0200, Vladimir Oltean wrote:
> On Tue, Mar 16, 2021 at 04:01:13PM +0200, Ido Schimmel wrote:
> > On Tue, Mar 16, 2021 at 01:24:18PM +0200, Vladimir Oltean wrote:
> > > +When the bridge has VLAN filtering enabled and a PVID is not configured
> > > on the
> > > +i
On Tue, Mar 16, 2021 at 04:01:13PM +0200, Ido Schimmel wrote:
> On Tue, Mar 16, 2021 at 01:24:18PM +0200, Vladimir Oltean wrote:
> > +When the bridge has VLAN filtering enabled and a PVID is not configured on
> > the
> > +ingress port, untagged 802.1p tagged packets must be dropped. When the
> >
On Tue, Mar 16, 2021 at 01:24:19PM +0200, Vladimir Oltean wrote:
> From: Vladimir Oltean
>
> The "bridge fdb add" command provided in the switchdev documentation is
> junk now, not only because it is syntactically incorrect and rejected by
> the iproute2 bridge program, but also because it was no
On Tue, Mar 16, 2021 at 01:24:18PM +0200, Vladimir Oltean wrote:
> +When the bridge has VLAN filtering enabled and a PVID is not configured on
> the
> +ingress port, untagged 802.1p tagged packets must be dropped. When the bridge
I think you meant "untagged and 802.1p tagged packets" ?
Looks goo
On Mon, 15 Mar 2021 16:11:40 +0100 Álvaro Fernández Rojas wrote:
> Add device tree support to b53_mmap.c while keeping platform devices support.
>
> Signed-off-by: Álvaro Fernández Rojas
> ---
> v2: add change suggested by Florian Fainelli (less "OF-centric") and replace
> brcm,ports property
On 3/15/2021 8:11 AM, Álvaro Fernández Rojas wrote:
> Add device tree support to b53_mmap.c while keeping platform devices support.
>
> Signed-off-by: Álvaro Fernández Rojas
Acked-by: Florian Fainelli
--
Florian
From: David Miller
Date: Sat, 13 Mar 2021 18:10:00 -0800 (PST)
> None of these apply to net-next as per the patchwork automated checks. Any
> idea why?
No unfortunately. That'why I sent a follow-up mail. All of them
successfully apply to pure net-next on my machine.
Can it be a Git version con
None of these apply to net-next as per the patchwork automated checks. Any
idea why?
Thanks.
From: Alexander Lobakin
Date: Sat, 13 Mar 2021 11:37:03 +
> This little number makes all of the flow dissection functions take
> raw input data pointer as const (1-5) and shuffles the branches in
> __skb_header_pointer() according to their hit probability.
>
> The result is +20 Mbps per flow/
On 3/12/21 2:41 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> On some SoCs (e.g. BCM4908, BCM631[345]8) SF2 has an integrated
> crossbar. It allows connecting its selected external ports to internal
> ports. It's used by vendors to handle custom Ethernet setups.
>
> BCM4908 has following 3x
On 3/12/21 2:41 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> It's needed later for proper switch / crossbar setup.
>
> Signed-off-by: Rafał Miłecki
Acked-by: Florian Fainelli
--
Florian
On Thu, 25 Feb 2021 16:22:29 +0800
Xuan Zhuo wrote:
> The number of queues implemented by many virtio backends is limited,
> especially some machines have a large number of CPUs. In this case, it
> is often impossible to allocate a separate queue for XDP_TX.
>
> This patch allows XDP_TX to run b
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 19 Feb 2021 13:10:44 +0300 you wrote:
> The comments to phy_select_page() say that "phy_restore_page() must
> always be called after this, irrespective of success or failure of this
> call." If we don't call phy_restore
On Fri, Feb 19, 2021 at 01:10:44PM +0300, Dan Carpenter wrote:
> The comments to phy_select_page() say that "phy_restore_page() must
> always be called after this, irrespective of success or failure of this
> call." If we don't call phy_restore_page() then we are still holding
> the phy_lock_mdio_
On Fri, Feb 19, 2021 at 11:46:23AM +0100, Michael Walle wrote:
> Am 2021-02-19 11:10, schrieb Dan Carpenter:
> > The comments to phy_select_page() say that "phy_restore_page() must
> > always be called after this, irrespective of success or failure of this
> > call." If we don't call phy_restore_p
Am 2021-02-19 11:10, schrieb Dan Carpenter:
The comments to phy_select_page() say that "phy_restore_page() must
always be called after this, irrespective of success or failure of this
call." If we don't call phy_restore_page() then we are still holding
the phy_lock_mdio_bus() so it eventually le
On Tue, 16 Feb 2021 13:12:29 -0500 Vincent Cheng wrote:
> >> +}
> >> +
> >> +static int wait_for_sys_apll_dpll_lock(struct idtcm *idtcm)
> >> +{
> >> + const char *fmt = "%d ms SYS lock timeout: APLL Loss Lock %d DPLL
> >> state %d";
> >> + u8 i = LOCK_TIMEOUT_MS / LOCK_POLL_INTERVAL_MS;
> >
On Mon, Feb 15, 2021 at 02:48:22PM EST, Jakub Kicinski wrote:
>On Sat, 13 Feb 2021 00:06:04 -0500 vincent.cheng...@renesas.com wrote:
>> +static int read_sys_apll_status(struct idtcm *idtcm, u8 *status)
>> +{
>> +int err;
>> +
>> +err = idtcm_read(idtcm, STATUS, DPLL_SYS_APLL_STATUS, statu
On Sat, 13 Feb 2021 00:06:04 -0500 vincent.cheng...@renesas.com wrote:
> From: Vincent Cheng
>
> Part of the device initialization aligns the rising edge of the output
> clock to the internal 1 PPS clock. If the system APLL and DPLL is not
> locked, then the alignment will fail and there will be
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Sun, 14 Feb 2021 00:37:49 +0200 you wrote:
> From: Vladimir Oltean
>
> Changes in v2:
> Add stub definition for ocelot_port_inject_frame when switch driver is
> not compiled in.
>
> This is part two of the errata wor
On 2/13/2021 14:38, Vladimir Oltean wrote:
From: Vladimir Oltean
For TX timestamping, we use the felix_txtstamp method which is common
with the regular (non-8021q) ocelot tagger. This method says that skb
deferral is needed, prepares a timestamp request ID, and puts a clone of
the skb in a q
On 2/13/2021 14:38, Vladimir Oltean wrote:
From: Vladimir Oltean
Since the tag_8021q tagger is software-defined, it has no means by
itself for retrieving hardware timestamps of PTP event messages.
Because we do want to support PTP on ocelot even with tag_8021q, we need
to use the CPU port m
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
Since the felix DSA driver will need to poll the CPU port module for
extracted frames as well, let's create some common functions that read
an Extraction Frame Header, and then an skb, from a CPU extraction
group.
We abuse the
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
The ocelot tagger is a hot mess currently, it relies on memory
initialized by the attached driver for basic frame transmission.
This is against all that DSA tagging protocols stand for, which is that
the transmission and recept
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
There is one place where we cannot avoid accessing driver data, and that
is 2-step PTP TX timestamping, since the switch wants us to provide a
timestamp request ID through the injection header, which naturally must
come from a
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
The Injection Frame Header and Extraction Frame Header that the switch
prepends to frames over the NPI port is also prepended to frames
delivered over the CPU port module's queues.
Let's unify the handling of the frame headers
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
Taggers should be written to do something valid irrespective of the
switch driver that they are attached to. This is even more true now,
because since the introduction of the .change_tag_protocol method, a
certain tagger is not
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
The felix DSA driver will inject some frames through register MMIO, same
as ocelot switchdev currently does. So we need to be able to reuse the
common code.
Also create some shim definitions, since the DSA tagger can be compil
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
This looks a bit nicer than the open-coded "(x + 3) % 4" idiom.
Signed-off-by: Vladimir Oltean
Reviewed-by: Florian Fainelli
--
Florian
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
It appears that the intention of this snippet of code is to not exit
ocelot_xtr_irq_handler() while in the middle of extracting a frame.
The problem in extracting it word by word is that future extraction
attempts are really ea
On 2/13/2021 14:37, Vladimir Oltean wrote:
From: Vladimir Oltean
The ocelot_rx_frame_word() function can return a negative error code,
however this isn't being checked for consistently. Errors being ignored
have not been seen in practice though.
Also, some constructs can be simplified by us
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Fri, 12 Feb 2021 11:21:00 +0800 you wrote:
> To improve code readability and maintainability, the series
> refactor out some bloated functions in the HNS3 ethernet driver.
>
> change log:
> V2: remove an unused variabl
On Thu, 11 Feb 2021 17:39:35 +
Igor Russkikh wrote:
> >> +echo " -w : (\$DELAY) Tx Delay value (us)"
> >This is not in "us" it is in "ns" (nanosec). (Like I pointed out last
> >time...)
>
> Ah, sorry lost that. Will fix.
Also remember that you made similar mistake in next patc
On Thu, Feb 11, 2021 at 11:35:27AM +0200, Vladimir Oltean wrote:
> On Thu, Feb 11, 2021 at 09:44:43AM +0200, Ido Schimmel wrote:
> > On Thu, Feb 11, 2021 at 01:23:52AM +0200, Vladimir Oltean wrote:
> > > On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel wrote:
> > > > > > The reverse, during u
On 2/11/21 4:11 PM, Heiner Kallweit wrote:
On 11.02.2021 22:19, Alex Elder wrote:
When initializing the IPA core clock and interconnects, it's
possible we'll get an EPROBE_DEFER error. This isn't really an
error, it's just means we need to be re-probed later.
Check the return code when initial
On 11.02.2021 22:19, Alex Elder wrote:
> When initializing the IPA core clock and interconnects, it's
> possible we'll get an EPROBE_DEFER error. This isn't really an
> error, it's just means we need to be re-probed later.
>
> Check the return code when initializing these, and if it's
> EPROBE_DE
>> +echo " -w : (\$DELAY) Tx Delay value (us)"
>This is not in "us" it is in "ns" (nanosec). (Like I pointed out last time...)
Ah, sorry lost that. Will fix.
One extra thing I wanted to raise is "set -o errexit" in functions.sh.
It basically contradicts with the usecase I'm using (doing
On Thu, 11 Feb 2021 16:56:25 +0100
Igor Russkikh wrote:
> diff --git a/samples/pktgen/parameters.sh b/samples/pktgen/parameters.sh
> index ff0ed474fee9..70cc2878d479 100644
> --- a/samples/pktgen/parameters.sh
> +++ b/samples/pktgen/parameters.sh
> @@ -19,12 +19,13 @@ function usage() {
> ec
On Thu, Feb 11, 2021 at 09:44:43AM +0200, Ido Schimmel wrote:
> On Thu, Feb 11, 2021 at 01:23:52AM +0200, Vladimir Oltean wrote:
> > On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel wrote:
> > > > > The reverse, during unlinking, would be to refuse unlinking if the
> > > > > upper
> > > > >
On Thu, Feb 11, 2021 at 01:23:52AM +0200, Vladimir Oltean wrote:
> On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel wrote:
> > > > The reverse, during unlinking, would be to refuse unlinking if the upper
> > > > has uppers of its own. netdev_upper_dev_unlink() needs to learn to
> > > > return
On Wed, Feb 10, 2021 at 01:55:20PM +0100, Robert Marko wrote:
> Add DT bindings for Qualcomm QCA807x PHY series.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> ---
> Changes in v2:
> * Drop PSGMII/QSGMII TX driver defines
>
> include/dt-bindings/net/qcom-qca807x.h | 30 +++
> +static int qca807x_psgmii_config(struct phy_device *phydev)
> +{
> + struct device_node *node = phydev->mdio.dev.of_node;
> + int psgmii_az, tx_amp, ret = 0;
> + u32 tx_driver_strength_dt;
> +
> + /* Workaround to enable AZ transmitting ability */
> + if (of_property_read_boo
On Wed, Feb 10, 2021 at 01:55:22PM +0100, Robert Marko wrote:
Hi Robert
Could you move the GPIO driver into a patch of its own, and Cc: the
GPIO maintainer and list for that patch please.
Andrew
On Wed, Feb 10, 2021 at 12:59:49PM +0200, Ido Schimmel wrote:
> > > The reverse, during unlinking, would be to refuse unlinking if the upper
> > > has uppers of its own. netdev_upper_dev_unlink() needs to learn to
> > > return an error and callers such as team/bond need to learn to handle
> > > it,
Hi Robert,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url:
https://github.com/0day-ci/linux/commits/Robert-Marko/Add-support-for-Qualcomm-QCA807x-PHYs/20210210-210217
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
de1d
On Wed, Feb 10, 2021 at 01:55:21PM +0100, Robert Marko wrote:
> Add DT bindings for Qualcomm QCA807x PHYs.
>
> Signed-off-by: Robert Marko
> Cc: Luka Perkov
> ---
> Changes in v2:
> * Drop LED properties
> * Directly define PSGMII/QSGMII SerDes driver values
>
> .../devicetree/bindings/net/qco
1 - 100 of 2857 matches
Mail list logo
