>
> [...]
Here is the summary with links:
- [v3,net-next,1/5] net: dsa: mv88e6xxx: Mark chips with undocumented EDSA
tag support
https://git.kernel.org/netdev/net-next/c/670bb80f8196
- [v3,net-next,2/5] net: dsa: mv88e6xxx: Allow dynamic reconfiguration of tag
protocol
https://gi
queues transition.
> 1: Guard band is implemented for any queue to schedule queue
> transition.
>
> [...]
Here is the summary with links:
- [net-next] net: dsa: felix: disable always guard band bit for TAS config
https://git.kernel.org/netdev/net-next/c/316bcffe4479
On Tue, Apr 20, 2021 at 08:53:10PM +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
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
port to receive FORWARDs with a DSA tag.
3. Undocumented
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 Waldekranz
---
Documentation/devicetree/bindings/net/dsa/ds
.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 5 +++
net/dsa/dsa2.c| 103 ++
2 files changed, 91 insertions(+), 17 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 1259b0f40684..2b25fe1ad5b7 100644
--- a/include/net
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
changed on devices with undocumented support for EDSA. But
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 Waldekranz
Reviewed-by: Vladimir Oltean
Reviewed-by: Florian
happened on hardware port 8. Looking at the DSA master interface
(dpaa-ethernet) we could see that an Rx error counter was bumped at
the same rate. The logs indicated a parser error.
It just so happens that a TO_CPU coming in on device 0, port 8, will
result in the first two bytes of the DSA tag being
On Tue, Apr 20, 2021 at 01:30:51PM +0300, Vladimir Oltean wrote:
> On Tue, Apr 20, 2021 at 10:28:45AM +, Xiaoliang Yang wrote:
> > Hi Vladimir,
> >
> > On Tue, Apr 20, 2021 at 16:27:10AM +0800, Vladimir Oltean wrote:
> > >
> > > On Tue, Apr 20, 2021 at 03:06:40AM +, Xiaoliang Yang wrote:
>
On Mon, Apr 19, 2021 at 06:25:30PM +0800, Xiaoliang Yang wrote:
> ALWAYS_GUARD_BAND_SCH_Q bit in TAS config register is descripted as
> this:
> 0: Guard band is implemented for nonschedule queues to schedule
> queues transition.
> 1: Guard band is implemented for any queue to s
On Tue, Apr 20, 2021 at 10:28:45AM +, Xiaoliang Yang wrote:
> Hi Vladimir,
>
> On Tue, Apr 20, 2021 at 16:27:10AM +0800, Vladimir Oltean wrote:
> >
> > On Tue, Apr 20, 2021 at 03:06:40AM +, Xiaoliang Yang wrote:
> >> Hi Vladimir.
> >>
> >> On Mon, Apr 19, 2021 at 20:38PM +0800, Vladimir Ol
Hi Vladimir,
On Tue, Apr 20, 2021 at 16:27:10AM +0800, Vladimir Oltean wrote:
>
> On Tue, Apr 20, 2021 at 03:06:40AM +, Xiaoliang Yang wrote:
>> Hi Vladimir.
>>
>> On Mon, Apr 19, 2021 at 20:38PM +0800, Vladimir Oltean wrote:
>> >
>> >What is a scheduled queue? When time-aware scheduling is en
On Tue, Apr 20, 2021 at 03:06:40AM +, Xiaoliang Yang wrote:
> Hi Vladimir.
>
> On Mon, Apr 19, 2021 at 20:38PM +0800, Vladimir Oltean wrote:
> >
> >What is a scheduled queue? When time-aware scheduling is enabled on
> >the port, why are some queues scheduled and some not?
>
> The felix vsc995
Amethyst internal PHYs also report empty model number in MII_PHYSID2.
Fill in switch product number, as is done for Topaz and Peridot.
Signed-off-by: Marek Behún
Reviewed-by: Andrew Lunn
---
drivers/net/dsa/mv88e6xxx/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa
idelot ; Florian
> Fainelli ; Claudiu Manoil ;
> Alexandre Belloni ;
> unglinuxdri...@microchip.com; linux-...@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Subject: Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling
>
> On Fri, Apr 16, 2021 at 08:36:53PM +0800, Ya
n Fainelli ; Claudiu Manoil
> ; Alexandre Belloni
> ; unglinuxdri...@microchip.com;
> linux-...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling
>
> On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> >
Didelot ; Florian Fainelli ;
> Claudiu Manoil ; Alexandre Belloni
> ; unglinuxdri...@microchip.com;
> linux-...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [net-next 1/3] net: dsa: optimize tx timestamp request handling
>
> On Sun, Apr 18, 2021 at 12:18:42PM +0300, Vladimi
Hi Vladimir.
On Mon, Apr 19, 2021 at 20:38PM +0800, Vladimir Oltean wrote:
>
>What is a scheduled queue? When time-aware scheduling is enabled on the port,
>why are some queues scheduled and some not?
The felix vsc9959 device can set SCH_TRAFFIC_QUEUES field bits to define which
queue is schedu
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
>
Most of generic selftest should be able to work with probably all ethernet
controllers. The DSA switches are not exception, so enable it by default at
least for DSA.
This patch was tested with SJA1105 and AR9331.
Signed-off-by: Oleksij Rempel
---
include/net/dsa.h | 2 ++
net/dsa/Kconfig
Hi Xiaoliang,
On Mon, Apr 19, 2021 at 06:25:30PM +0800, Xiaoliang Yang wrote:
> ALWAYS_GUARD_BAND_SCH_Q bit in TAS config register is descripted as
> this:
> 0: Guard band is implemented for nonschedule queues to schedule
> queues transition.
> 1: Guard band is implemented for
.
Signed-off-by: Xiaoliang Yang
---
drivers/net/dsa/ocelot/felix_vsc9959.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/dsa/ocelot/felix_vsc9959.c
b/drivers/net/dsa/ocelot/felix_vsc9959.c
index 789fe08cae50..2473bebe48e6 100644
--- a/drivers/net/dsa/ocelot
On Fri Apr 16 2021, Yangbo Lu wrote:
> Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
> drivers should adapt to it.
>
> - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
> port_txtstamp, so that most skbs not requiring tx timest
On Sun, Apr 18, 2021 at 12:18:42PM +0300, Vladimir Oltean wrote:
>
> How about not passing "clone" back to DSA as an argument by reference,
> but instead require the driver to populate DSA_SKB_CB(skb)->clone if it
> needs to do so?
>
> Also, how about changing the
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> @@ -628,9 +620,7 @@ static netdev_tx_t dsa_slave_xmit(struct sk_buff *skb,
> struct net_device *dev)
>
> DSA_SKB_CB(skb)->clone = NULL;
>
> - /* Identify PTP protocol packets, clone them, and pass them to the
> - * swi
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
> drivers should adapt to it.
>
> - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
> port_txtstamp, so that most skbs n
On Fri, Apr 16, 2021 at 08:36:53PM +0800, Yangbo Lu wrote:
> Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
> drivers should adapt to it.
>
> - Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
> port_txtstamp, so that most skbs n
Optimization could be done on dsa_skb_tx_timestamp(), and dsa device
drivers should adapt to it.
- Check SKBTX_HW_TSTAMP request flag at the very beginning, instead of in
port_txtstamp, so that most skbs not requiring tx timestamp just return.
- No longer to identify PTP packets, and limit tx
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.
>
&
All errors (new ones prefixed by >>, old ones prefixed by <<):
>> ERROR: modpost: "net_selftest_get_count" [net/dsa/dsa_core.ko] undefined!
>> ERROR: modpost: "net_selftest" [net/dsa/dsa_core.ko] undefined!
>> ERROR: modpost: "net_selftest_g
; to inform the driver of this fact by selecting an alternate protocol
> that is known to work.
>
> Signed-off-by: Tobias Waldekranz
> ---
> include/net/dsa.h | 5 +++
> net/dsa/dsa2.c| 95 ++-
> 2 files changed, 83 insertions(+
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.
>
>
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
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 c
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
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,
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 e
Most of generic selftest should be able to work with probably all ethernet
controllers. The DSA switches are not exception, so enable it by default at
least for DSA.
This patch was tested with SJA1105 and AR9331.
Signed-off-by: Oleksij Rempel
---
include/net/dsa.h | 2 ++
net/dsa/Kconfig
.
Signed-off-by: Tobias Waldekranz
---
include/net/dsa.h | 5 +++
net/dsa/dsa2.c| 95 ++-
2 files changed, 83 insertions(+), 17 deletions(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 1259b0f40684..2b25fe1ad5b7 100644
--- a/include/net
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
changed on devices with undocumented support for EDSA. But
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 Waldekranz
---
Documentation/devicetree/bindings/net/dsa/ds
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 Waldekranz
---
net/dsa/switch.c | 25
happened on hardware port 8. Looking at the DSA master interface
(dpaa-ethernet) we could see that an Rx error counter was bumped at
the same rate. The logs indicated a parser error.
It just so happens that a TO_CPU coming in on device 0, port 8, will
result in the first two bytes of the DSA tag being
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
port to receive FORWARDs with a DSA tag.
3. Undocumented
FORWARD tag,
which contains the _source_ information. So that might work for
mv88e6xxx as well!
Marek, what do you think? If this works, it would be great if we could
also allow the hash based approach since that would work better in cases
where you have many flows coming in on a single port that y
s port VLANs, AFAIU) enforce the bounding box
for every packet such that it goes to one CPU port or to another.
This, however, has implications upon the DSA API. In my current attempts
for the 'RX filtering in DSA' series, host addresses are reference-counted
by DSA, and passed on
On Wed, Apr 14, 2021 at 17:14, Marek Behun wrote:
> On Tue, 13 Apr 2021 20:16:24 +0200
> Tobias Waldekranz wrote:
>
>> You could imagine a different mode in which the DSA driver would receive
>> the bucket allocation from the bond/team driver (which in turn could
>
On Tue, 13 Apr 2021 20:16:24 +0200
Tobias Waldekranz wrote:
> You could imagine a different mode in which the DSA driver would receive
> the bucket allocation from the bond/team driver (which in turn could
> come all the way from userspace). Userspace could then implement
> whatever
.
Although this is O.K, there has been a trend towards using devlink
regions for this, and other register sets in the switch. Take a look
at drivers/net/dsa/mv88e6xxx/devlink.c.
There is a userspace tool for the mv88e6xxx devlink regions here:
https://github.com/lunn/mv88e6xxx_dump
and a few
eports is the EEE is active, this function also checks
> the PHY, duplex and broken DTS modes.
> When active set the MAC EEE bit based on the speed.
> - Add {GET,SET)_LPI_THRESH(x) macro
> - PMCR_FORCE_EEE1G | PMCR_FORCE_EEE100 are now placed in the right MASK
> variable
>
>
On 4/13/2021 12:25 PM, Martin Blumenstingl wrote:
> On Tue, Apr 13, 2021 at 1:45 AM Andrew Lunn wrote:
> [...]
>>>> and a few people have forked it and modified it for other DSA
>>>> switches. At some point we might want to try to merge the forks back
>>>
On Tue, Apr 13, 2021 at 1:45 AM Andrew Lunn wrote:
[...]
> > > and a few people have forked it and modified it for other DSA
> > > switches. At some point we might want to try to merge the forks back
> > > together so we have one tool to dump any switch.
> > act
t; What do you think?
>>
>> As you concluded in your followup, not being able to have a fixed MAC
>> for the CPU seems weird.
>>
>> Maybe you could do the inverse? Allow userspace to set the masks for an
>> individual bond/team port in a hash-based LAG, then you c
On Tue, Apr 13, 2021 at 02:52:59PM +0200, Andrew Lunn wrote:
> > I guess this is depends whether the most usual case is to have all
> > these interrupts being actively in use or not. Most interrupts only
> > use a limited portion of their interrupt space at any given time.
> > Allocating all interr
ct frames into the switch and try different
> > MAC addresses for the CPU ports until desired load-balancing is reached.
> >
> > What do you think?
>
> As you concluded in your followup, not being able to have a fixed MAC
> for the CPU seems weird.
>
> Maybe you c
our followup, not being able to have a fixed MAC
for the CPU seems weird.
Maybe you could do the inverse? Allow userspace to set the masks for an
individual bond/team port in a hash-based LAG, then you can offload that
to DSA. Here there be dragons though, you need to ensure that there is
no inte
On Tue, Apr 13, 2021 at 01:54, Marek Behun wrote:
> On Tue, 13 Apr 2021 01:13:53 +0200
> Tobias Waldekranz wrote:
>
>> > ...you could get the isolation in place. But you will still lookup the
>> > DA in the ATU, and there you will find a destination of either cpu0 or
>> > cpu1. So for one of the
On Tue, Apr 13, 2021 at 09:55:37AM +0200, Marek Behún wrote:
> Amethyst internal PHYs also report empty model number in MII_PHYSID2.
>
> Fill in switch product number, as is done for Topaz and Peridot.
>
> Signed-off-by: Marek Behún
Reviewed-by: Andrew Lunn
Andrew
> I guess this is depends whether the most usual case is to have all
> these interrupts being actively in use or not. Most interrupts only
> use a limited portion of their interrupt space at any given time.
> Allocating all interrupts and creating mappings upfront is a waste of
> memory.
>
> If th
On Tue, 13 Apr 2021 01:07:23 +0100,
Andrew Lunn wrote:
>
> > > > +static void
> > > > +mt7530_setup_mdio_irq(struct mt7530_priv *priv)
> > > > +{
> > > > + struct dsa_switch *ds = priv->ds;
> > > > + int p;
> > > > +
> > > > + for (p = 0; p < MT7530_NUM_PHYS; p++) {
> > > > +
Amethyst internal PHYs also report empty model number in MII_PHYSID2.
Fill in switch product number, as is done for Topaz and Peridot.
Signed-off-by: Marek Behún
---
drivers/net/dsa/mv88e6xxx/chip.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers
On Tue, 13 Apr 2021 02:27:30 +0200
Marek Behun wrote:
> On Tue, 13 Apr 2021 01:54:50 +0200
> Marek Behun wrote:
>
> > I will look into this, maybe ask some follow-up questions.
>
> Tobias,
>
> it seems that currently the LAGs in mv88e6xxx driver do not use the
> HashTrunk feature (which can b
On Tue, 13 Apr 2021 01:54:50 +0200
Marek Behun wrote:
> I will look into this, maybe ask some follow-up questions.
Tobias,
it seems that currently the LAGs in mv88e6xxx driver do not use the
HashTrunk feature (which can be enabled via bit 11 of the
MV88E6XXX_G2_TRUNK_MAPPING register).
If we u
save a lot of device tree boilerplate
by doing it in code. And when you have 4 of these switches, it gets
very boring adding all the DT to just wire up the interrupts 28
interrupts.
> Andrew, perhaps this can be done in DSA core?
Not easily. It is not always a simple mapping like this. Two of the
switches supported by mv88exxx offset the PHYs by 0x10. You really
need the switch driver involved, with its detailed knowledge of the
hardware.
Andrew
On Tue, 13 Apr 2021 01:13:53 +0200
Tobias Waldekranz wrote:
> > ...you could get the isolation in place. But you will still lookup the
> > DA in the ATU, and there you will find a destination of either cpu0 or
> > cpu1. So for one of the ports, the destination will be outside of its
> > port base
e result of the auto polling mechanism). Other global and per-port
> > > registers which are also considered useful are included as well.
> >
> > Although this is O.K, there has been a trend towards using devlink
> > regions for this, and other register sets in the switch. Take
port). So we have only 5 pairs of src + dst MAC addresses. If we simply
>>> >> > fill the LAG table as it is done now, then there is 2 * 0.5^5 = 1/16
>>> >> > chance that all packets would go through one CPU port.
>>> >> >
>>> >> &g
ance that all packets would go through one CPU port.
>> >> >
>> >> > In order to have real load balancing in this scenario, we would either
>> >> > have to recompute the LAG mask table depending on the MAC addresses, or
>> >> > rewrite
>> > CPU ports and 5 user ports, is that into these 5 user ports the user
> > >> >> > plugs 5 simple devices (no switches, so only one peer MAC address
> > >> >> > for
> > >> >> > port). So we have only 5 pairs of src + dst
simply
> >> > fill the LAG table as it is done now, then there is 2 * 0.5^5 = 1/16
> >> > chance that all packets would go through one CPU port.
> >> >
> >> > In order to have real load balancing in this scenario, we would either
> >> > have to r
s 5 simple devices (no switches, so only one peer MAC address for
> >> >> > port). So we have only 5 pairs of src + dst MAC addresses. If we
> >> >> > simply
> >> >> > fill the LAG table as it is done now, then there is 2 * 0.5^5 = 1/16
> >> >&
; > which make it not ideal in router application (Router WAN <--> ISP BRAS
> > > > traffic will always have the same DA/SA and thus use only one port).
> > >
> > > Is this supposed to make a difference? Choose a better switch vendor!
> >
> >
included as well.
>
> Although this is O.K, there has been a trend towards using devlink
> regions for this, and other register sets in the switch. Take a look
> at drivers/net/dsa/mv88e6xxx/devlink.c.
>
> There is a userspace tool for the mv88e6xxx devlink regions here:
>
>
through one CPU port.
>> >> >
>> >> > In order to have real load balancing in this scenario, we would either
>> >> > have to recompute the LAG mask table depending on the MAC addresses, or
>> >> > rewrite the LAG mask table somewhat randomly
t; > > Many switches such as mv88e6xxx only support MAC DA/SA load balancing,
> > > which make it not ideal in router application (Router WAN <--> ISP BRAS
> > > traffic will always have the same DA/SA and thus use only one port).
> >
> > Is this supposed t
> fill the LAG table as it is done now, then there is 2 * 0.5^5 = 1/16
> >> > chance that all packets would go through one CPU port.
> >> >
> >> > In order to have real load balancing in this scenario, we would either
> >> > have to recompute the
cing in this scenario, we would either
>> > have to recompute the LAG mask table depending on the MAC addresses, or
>> > rewrite the LAG mask table somewhat randomly periodically. (This could
>> > be in theory offloaded onto the Z80 internal CPU for some of the
>> &g
WAN <--> ISP BRAS
> > traffic will always have the same DA/SA and thus use only one port).
>
> Is this supposed to make a difference? Choose a better switch vendor!
:-) Are you saying that we shall abandon trying to make the DSA
subsystem work with better performace for our routers, in order to
punish ourselves for our bad decision to use Marvell switches?
> fill the LAG table as it is done now, then there is 2 * 0.5^5 = 1/16
> >> > chance that all packets would go through one CPU port.
> >> >
> >> > In order to have real load balancing in this scenario, we would either
> >> > have to recompute the L
n this scenario, we would either
>> > have to recompute the LAG mask table depending on the MAC addresses, or
>> > rewrite the LAG mask table somewhat randomly periodically. (This could
>> > be in theory offloaded onto the Z80 internal CPU for some of the
>> > sw
cally. (This could
> > be in theory offloaded onto the Z80 internal CPU for some of the
> > switches of the mv88e6xxx family, but not for Omnia.)
>
> I thought that the option to associate each port netdev with a DSA
> master would only be used on transmit. Are you saying th
dically. (This could
> > be in theory offloaded onto the Z80 internal CPU for some of the
> > switches of the mv88e6xxx family, but not for Omnia.)
>
> I thought that the option to associate each port netdev with a DSA
> master would only be used on transmit. Are you saying tha
on the MAC addresses, or
> rewrite the LAG mask table somewhat randomly periodically. (This could
> be in theory offloaded onto the Z80 internal CPU for some of the
> switches of the mv88e6xxx family, but not for Omnia.)
I thought that the option to associate each port netdev with a DSA
mas
at, 10 Apr 2021 15:34:46 +0200
>> >> Ansuel Smith wrote:
>> >>
>> >> > Hi,
>> >> > this is a respin of the Marek series in hope that this time we can
>> >> > finally make some progress with dsa supporting multi-cpu port.
>> >>
On Mon, 12 Apr 2021 14:46:11 +0200
Tobias Waldekranz wrote:
> I agree. Unless you only have a few really wideband flows, a LAG will
> typically do a great job with balancing. This will happen without the
> user having to do any configuration at all. It would also perform well
> in "router-on-a-st
On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
> On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
> >
> > So I'd be tempted to say 'tough luck' if all your ports are not up, and
> > the ones that are are assigned statically to the same CPU port. It's a
> > compromise
Am 12. April 2021 17:30:58 MESZ schrieb DENG Qingfang :
>So we somehow configured default CPU port in dts (by port name). In
>my opinion we can just add a default CPU property in dts to specify
>it (like Frank Wunderlich did earlier), and fall back to round-robin
>if the property is not present, w
On Mon, Apr 12, 2021 at 06:41:58AM +0200, Ansuel Smith wrote:
> > So, drivers will read the name of every port and decide which CPU port
> > does it use?
> >
>
> Yes, this seems to be an acceptable path to follow. The driver can
> provide a preferred CPU port or just
DIO bus
> > is also done in this driver.
> >
> > Signed-off-by: DENG Qingfang
> > ---
> > RFC v3 -> RFC v4:
> > - No changes.
> >
> > drivers/net/dsa/Kconfig | 1 +
> > drivers/net/dsa/mt7530.c | 266 +++
On Sun, Apr 11, 2021 at 09:50:17PM +0300, Vladimir Oltean wrote:
>
> So I'd be tempted to say 'tough luck' if all your ports are not up, and
> the ones that are are assigned statically to the same CPU port. It's a
> compromise between flexibility and simplicity, and I would go for
> simplicity her
gt; >> > Hi,
> >> > this is a respin of the Marek series in hope that this time we can
> >> > finally make some progress with dsa supporting multi-cpu port.
> >> >
> >> > This implementation is similar to the Marek series but with some tweaks
we can
>> > finally make some progress with dsa supporting multi-cpu port.
>> >
>> > This implementation is similar to the Marek series but with some tweaks.
>> > This adds support for multiple-cpu port but leave the driver the
>> > decision of the type
hat this time we can
> > > finally make some progress with dsa supporting multi-cpu port.
> > >
> > > This implementation is similar to the Marek series but with some tweaks.
> > > This adds support for multiple-cpu port but leave the driver the
> > >
On Mon Apr 12 2021, DENG Qingfang wrote:
> Add device tree binding to support MT7530 interrupt controller.
>
> Signed-off-by: DENG Qingfang
> Reviewed-by: Andrew Lunn
> ---
> RFC v3 -> RFC v4:
> - Add #interrupt-cells property.
>
> Documentation/devicetree/b
hat this time we can
> > > finally make some progress with dsa supporting multi-cpu port.
> > >
> > > This implementation is similar to the Marek series but with some tweaks.
> > > This adds support for multiple-cpu port but leave the driver the
> > > decis
On Mon, Apr 12, 2021 at 11:35:25AM +0800, DENG Qingfang wrote:
> On Sat, Apr 10, 2021 at 03:34:47PM +0200, Ansuel Smith wrote:
> > Allow for multiple CPU ports in a DSA switch tree. By default the first
> > CPU port is assigned mimic the original assignement logic. A DSA driver
&
; ---
> RFC v3 -> RFC v4:
> - No changes.
>
> drivers/net/dsa/Kconfig | 1 +
> drivers/net/dsa/mt7530.c | 266 +++
> drivers/net/dsa/mt7530.h | 20 ++-
> 3 files changed, 258 insertions(+), 29 deletions(-)
>
> diff --git a/driver
Quoting DENG Qingfang :
Hi Qingfang,
Thanks for the review.
Hi René,
On Sat, Apr 10, 2021 at 6:54 AM René van Dorst wrote:
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -2568,6 +2568,11 @@ static void
mt753x_phylink_mac_link_up(struct dsa_switch *ds, int port
- PMCR_FORCE_EEE1G | PMCR_FORCE_EEE100 are now placed in the right MASK variable
drivers/net/dsa/mt7530.c | 43 ++++
drivers/net/dsa/mt7530.h | 14 -
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/
1 - 100 of 13455 matches
Mail list logo
