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 strategy it w
On Tue, 13 Apr 2021 16:46:32 +0200
Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 02:27, 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.
> >
> &g
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
>
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
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
gt; On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean
> > >> wrote:
> > >> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> > >> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun
> > >> >>
On Tue, 13 Apr 2021 00:05:51 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 23:50, Marek Behun wrote:
> > On Mon, 12 Apr 2021 23:22:45 +0200
> > Tobias Waldekranz wrote:
> >
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >&g
On Tue, 13 Apr 2021 01:17:21 +0300
Vladimir Oltean wrote:
> On Tue, Apr 13, 2021 at 12:04:57AM +0200, Marek Behun wrote:
> > On Mon, 12 Apr 2021 19:32:11 +0300
> > Vladimir Oltean wrote:
> >
> > > On Mon, Apr 12, 2021 at 11:00:45PM +0800, DENG Qingfang wrote:
&
On Mon, 12 Apr 2021 19:32:11 +0300
Vladimir Oltean wrote:
> 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
On Mon, 12 Apr 2021 23:49:22 +0200
Tobias Waldekranz wrote:
> On Tue, Apr 13, 2021 at 00:34, Vladimir Oltean wrote:
> > On Mon, Apr 12, 2021 at 11:22:45PM +0200, Tobias Waldekranz wrote:
> >> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> >> > On M
On Mon, 12 Apr 2021 23:22:45 +0200
Tobias Waldekranz wrote:
> On Mon, Apr 12, 2021 at 21:30, Marek Behun wrote:
> > 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
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 Sat, 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.
>
> This implementation is similar to the Marek series but with some tweaks.
> This adds support for
On Mon, 15 Feb 2021 15:29:44 +
Russell King - ARM Linux admin wrote:
> On Mon, Feb 15, 2021 at 04:16:27PM +0100, Marek Behun wrote:
> > On Mon, 15 Feb 2021 14:57:57 +
> > Russell King - ARM Linux admin wrote:
> >
> > > On Mon, Feb 15, 2021 at 02:47
On Mon, 15 Feb 2021 14:57:57 +
Russell King - ARM Linux admin wrote:
> On Mon, Feb 15, 2021 at 02:47:56PM +0100, Marek Behun wrote:
> > On Mon, 15 Feb 2021 06:15:59 +
> > Nathan Rossi wrote:
> >
> > > diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
>
On Mon, 15 Feb 2021 06:15:59 +
Nathan Rossi wrote:
> diff --git a/drivers/net/dsa/mv88e6xxx/chip.c
> b/drivers/net/dsa/mv88e6xxx/chip.c
> index 54aa942eed..5c52906b29 100644
> --- a/drivers/net/dsa/mv88e6xxx/chip.c
> +++ b/drivers/net/dsa/mv88e6xxx/chip.c
> @@ -650,6 +650,13 @@ static void m
It seems this problem can manifest somehow with Peridot as well, at
least when in combination with 88X3310 PHY.
I will do some more experiments and try to come up with a solution.
Marek
On Thu, 7 Jan 2021 22:02:48 +0100
Wolfram Sang wrote:
> > My question is whether this is allowed, whether the msgs array passed
> > to the i2c_transfer() function can have multiple msgs pointing to the
> > same buffer (the one into which the original page is first stored
> > with first i2c_msg an
Hi Wolfram and Russell,
I have a question regarding whether the struct i2c_msg array passed to
the i2c_transfer() function can have multiple messages refer to the
same buffers.
Previously Russell raised a point on my patch series adding support
for RollBall SFPs regarding the I2C MDIO access, whi
Hi Andrew,
On Fri, 20 Nov 2020 02:29:06 +0100
Andrew Lunn wrote:
> > + if (speed >= 2500 && port > 0 && port < 9)
> > + return -EOPNOTSUPP;
>
> Maybe i'm missing something, but it looks like at this point you can
> call
>
> return mv88e6xxx_port_set_speed_duplex(chip, port,
On Sat, 14 Nov 2020 16:06:33 +
"Tj (Elloe Linux)" wrote:
> On 14/11/2020 15:56, Andrew Lunn wrote:
> >> 1) with isc-dhcp-server configured with very short lease times (180
> >> seconds). After mox reboot (or systemctl restart systemd-networkd)
> >> clients successfully obtain a lease and a co
On Thu, 29 Oct 2020 15:40:25 +1000
Pavana Sharma wrote:
> Updated patchset.
>
> Split the patch to separate mv88e6393 changes from refactoring
> serdes_get_lane.
> Update Documentation before adding new mode.
Pavana, the patch adding support for Amethyst has to be the last in the
series. The pa
On Thu, 29 Oct 2020 15:42:29 +1000
Pavana Sharma wrote:
> The Marvell 88E6393X device is a single-chip integration of a 11-port
> Ethernet switch with eight integrated Gigabit Ethernet (GbE) transceivers
> and three 10-Gigabit interfaces.
>
> This patch adds functionalities specific to mv88e6393
On Thu, 29 Oct 2020 15:42:00 +1000
Pavana Sharma wrote:
> Add new mode supported by MV88E6393 family.
>
This commit message isn't ideal. It infers that the Amethyst is first
such device to implement this mode, which is not true. The 5gbase-r mode
is supported by various other hardware, for exam
On Tue, 27 Oct 2020 19:25:16 +0100
Tobias Waldekranz wrote:
> .-. TO_CPU, FORWARD .-. TO_CPU, FORWARD .-.
> | +-+ +-+ |
> | CPU | | sw0 | | sw1 |
> | +-+ +-+ |
> '--
Pavana,
please add me to Cc for this.
Does USXGMII mode work? There are some erratas for for 10gb serdes mode.
Also you should split this patch. The code that refactores the
serdes_get_lane methods should be in a separate patch.
I have a device with this switch and also a SFP module which can
o
> In order for this to work on transmit, we need to add forward offloading
> to the bridge so that we can, for example, send one FORWARD from the CPU
> to send an ARP broadcast to swp1..4 instead of four FROM_CPUs.
Wouldn't this be solved if the CPU master interface was a bonding interface?
On Tue, 27 Oct 2020 11:51:14 +0100
Tobias Waldekranz wrote:
> The policy is to use ethertyped DSA for all devices that are capable
> of doing so, which the Peridot is.
What is the benefit here?
On Tue, 27 Oct 2020 15:52:13 +0100
Marek Behun wrote:
> On Tue, 27 Oct 2020 11:51:14 +0100
> Tobias Waldekranz wrote:
>
> > The policy is to use ethertyped DSA for all devices that are capable
> > of doing so, which the Peridot is.
>
> What is the benefit here?
On Tue, 27 Oct 2020 15:54:36 +0100
Marek Behun wrote:
> But again, what is the benefit here?
OK, you need this for the LAG support, somehow those emails went to
another folder, sorry :)
When I first read about port trunking in the Peridot documentation, I
immediately thought that this could be used to transparently offload
that which is called Bonding in Linux...
Is this what you want to eventually do?
BTW, I thought about using port trunking to solve the multi-CPU DSA
issue as
On Tue, 20 Oct 2020 15:15:25 +0100
Russell King - ARM Linux admin wrote:
> On Tue, Oct 20, 2020 at 04:05:35PM +0200, Andrew Lunn wrote:
> > On Tue, Oct 20, 2020 at 03:49:40PM +0200, Marek Behun wrote:
> > > On Tue, 20 Oct 2020 11:15:52 +0100
> > > Russell Ki
On Tue, 20 Oct 2020 11:15:52 +0100
Russell King - ARM Linux admin wrote:
> On Tue, Oct 20, 2020 at 04:45:56PM +1300, Chris Packham wrote:
> > When a port is configured with 'managed = "in-band-status"' don't force
> > the link up, the switch MAC will detect the link status correctly.
> >
> > Sig
On Mon, 28 Sep 2020 19:10:05 +0200
Alexander Dahl wrote:
> Hei hei,
>
> On Mon, Sep 28, 2020 at 05:52:09PM +0200, Marek Behun wrote:
> > On Mon, 28 Sep 2020 15:04:10 +0200
> > Alexander Dahl wrote:
> >
> > > Hei Marek,
> > >
> > > Am So
On Mon, 28 Sep 2020 15:04:10 +0200
Alexander Dahl wrote:
> Hei Marek,
>
> Am Sonntag, 27. September 2020, 02:52:58 CEST schrieb Marek Behun:
> > On Sun, 27 Sep 2020 00:40:25 +0200
> >
> > Marek Behun wrote:
> > > What I am wondering is how should
On Sun, 27 Sep 2020 00:40:25 +0200
Marek Behun wrote:
> What I am wondering is how should we select a name for the device part
> of the LED for network devices, when network namespaces are enabled.
>
> a) We could just use the interface name (eth0:yellow:activity). The
>
On Sun, 27 Sep 2020 02:29:35 +0200
Andrew Lunn wrote:
> On Sun, Sep 27, 2020 at 12:40:25AM +0200, Marek Behun wrote:
> > Hi,
> >
> > linux-leds is trying to create a consistent naming mechanism for LEDs
> > The schema is:
> > device:color:function
> &g
Hi,
linux-leds is trying to create a consistent naming mechanism for LEDs
The schema is:
device:color:function
for example
system:green:power
keyboard0:green:capslock
But we are not there yet.
LEDs are often dedicated to specific function by manufacturers, for
example there can be an icon
Andrew, can this be used to write the registers from userspace, or only
to read it?
Marek
Hello,
I have been thinking about another way to implement ABI for HW control
of ethernet PHY connected LEDs.
This proposal is inspired by the fact that for some time there is a
movement in the kernel to do transparent HW offloading of things (DSA
is an example of that).
So currently we have the
On Thu, 10 Sep 2020 22:23:45 +0200
Pavel Machek wrote:
> Hi!
>
> > Okay, so the netdev trigger offers modes `link`, `rx`, `tx`.
> > You can enable/disable either of these (via separate sysfs files). `rx`
> > and `tx` blink the LED, `link` turns the LED on if the interface is
> > linked.
>
> I
On Thu, 10 Sep 2020 19:34:35 +0100
Russell King - ARM Linux admin wrote:
> On Thu, Sep 10, 2020 at 08:31:54PM +0200, Andrew Lunn wrote:
> > Generally the driver will default to the hardware reset blink
> > pattern. There are a few PHY drivers which change this at probe, but
> > not many. The sili
On Wed, 9 Sep 2020 23:40:09 +0200
Pavel Machek wrote:
> > >
> > > 80 columns :-) (and please fix that globally, at least at places where
> > > it is easy, like comments).
> > >
> >
> > Linux is at 100 columns now since commit bdc48fa11e46, commited by
> > Linus. See
> > https://git.kernel.or
On Wed, 9 Sep 2020 23:42:59 +0200
Andrew Lunn wrote:
> On Wed, Sep 09, 2020 at 06:25:45PM +0200, Marek Behún wrote:
> > Hello Andrew and Pavel,
> >
> > please review these patches adding support for HW controlled LEDs.
> > The main difference from previous version is that the API is now generali
On Wed, 9 Sep 2020 15:15:52 -0600
Rob Herring wrote:
> On Wed, Sep 09, 2020 at 06:25:46PM +0200, Marek Behún wrote:
> > Document binding for LEDs connected to and controlled by various chips
> > (such as ethernet PHY chips).
>
> If they are h/w controlled, then why are they in DT?
The idea is
On Wed, 9 Sep 2020 15:31:22 -0600
Rob Herring wrote:
> On Wed, Sep 09, 2020 at 11:07:26PM +0200, Marek Behun wrote:
> > On Wed, 9 Sep 2020 14:59:23 -0600
> > Rob Herring wrote:
> >
> > > >
> > > > I don't know :) I copied this from other dr
On Wed, 9 Sep 2020 22:48:15 +0200
Pavel Machek wrote:
> Hi!
>
> > Many an ethernet PHY (and other chips) supports various HW control modes
> > for LEDs connected directly to them.
>
> I guess this should be
>
> "Many ethernet PHYs (and other chips) support various HW control modes
> for LEDs
On Wed, 9 Sep 2020 14:59:23 -0600
Rob Herring wrote:
> >
> > I don't know :) I copied this from other drivers, I once tried setting
> > up environment for doing checking of device trees with YAML schemas,
> > and it was a little painful :)
>
> pip3 install dtschema ?
>
> Can you elaborate on
Please ignore this series, still refactoring...
Please ignore this patch, still refactoring...
On Tue, 25 Aug 2020 10:13:59 +0200
Matthias Schiffer wrote:
> On Tue, 2020-07-28 at 17:05 +0200, Marek Behún wrote:
> > Hi,
> >
> > this is v4 of my RFC adding support for LEDs connected to Marvell
> > PHYs.
> >
> > Please note that if you want to test this, you still need to first
> > apply
>
On Tue, 28 Jul 2020 18:18:00 +0200
Andrew Lunn wrote:
> > +static int of_phy_register_led(struct phy_device *phydev, struct
> > device_node *np)
> > +{
> > + struct led_init_data init_data = {};
> > + struct phy_device_led *led;
> > + u32 reg;
> > + int ret;
> > +
> > + ret = of_proper
On Tue, 28 Jul 2020 18:28:16 +0200
Andrew Lunn wrote:
> > > @@ -736,6 +777,16 @@ struct phy_driver {
> > > int (*set_loopback)(struct phy_device *dev, bool enable);
> > > int (*get_sqi)(struct phy_device *dev);
> > > int (*get_sqi_max)(struct phy_device *dev);
> > > +
> > > + /* PHY LED sup
On Sat, 25 Jul 2020 20:48:46 +0200
Andrew Lunn wrote:
> > > > +#if 0
> > > > + /* LED_COLOR_ID_MULTI is not yet merged in Linus' tree */
> > > > + /* TODO: Support DUAL MODE */
> > > > + if (color == LED_COLOR_ID_MULTI) {
> > > > + phydev_warn(phydev, "node %pOF: T
On Sat, 25 Jul 2020 19:23:18 +0200
Andrew Lunn wrote:
> On Fri, Jul 24, 2020 at 06:46:03PM +0200, Marek Behún wrote:
> > This patch adds support for controlling the LEDs connected to several
> > families of Marvell PHYs via the PHY HW LED trigger API. These families
> > are: 88E1112, 88E1121R, 88
On Sat, 25 Jul 2020 17:03:42 +0200
Andrew Lunn wrote:
> Does hi-z mean off? In the implementation i did, i did not list off
> and on as triggers. I instead used them for untriggered
> brightness. That allowed the software triggers to work, so i had the
> PHY blinking the heartbeat etc. But i had
On Sat, 25 Jul 2020 11:21:24 +0200
Pavel Machek wrote:
> Hi!
>
> > Many PHYs support various HW control modes for LEDs connected directly
> > to them.
> >
> > This code adds a new private LED trigger called phydev-hw-mode. When
> > this trigger is enabled for a LED, the various HW control modes
On Sat, 25 Jul 2020 11:23:39 +0200
Pavel Machek wrote:
> Hi!
>
> > +static const struct marvell_led_mode_info marvell_led_mode_info[] = {
> > + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 },
> > + { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0 }
On Thu, 23 Jul 2020 23:35:31 +0200
Andrew Lunn wrote:
> Hi Marek
>
> I expect some of this should be moved into the phylib core. We don't
> want each PHY inventing its own way to do this. The core should
> provide a framework and the PHY driver fills in the gaps.
>
> Take a look at for example
On Thu, 23 Jul 2020 23:35:31 +0200
Andrew Lunn wrote:
> I thought the brightness file disappeared when a trigger takes
> over. So is this possible?
>
> Andrew
It does not disappear nor should it. When you have a LED with 10 levels
of brightness, you want to be able to configure with which
On Sun, 19 Jul 2020 14:43:49 -0700
Chris Healy wrote:
> > Hmm.
> >
> > What about the errata setup?
> > It says:
> > /* The 6390 copper ports have an errata which require poking magic
> > * values into undocumented hidden registers and then performing a
> > * software reset.
> > */
> > But the
On Sat, 18 Jul 2020 17:05:14 +0200
Andrew Lunn wrote:
> > If the traces were broken between the fiber module and the SERDES, I
> > should not see these counters incrementing.
>
> Plus it is reproducible on multiple boards, of different designs.
>
> This is somehow specific to the 6390X ports
Hmm, nothing sticks out in the register dump.
I encountered a similar problem 2 years ago on Topaz SERDES port when
the cmode was set to 2500BASE-X but the speed register was set to speed
incompatible with 2500BASE-X (I don't remember what, though). This
issue was solved by a patch I sent to netde
On Sat, 11 Jul 2020 22:32:05 +0200
Andrew Lunn wrote:
> The Marvell Switches support jumbo packages. So implement the
> callbacks needed for changing the MTU.
>
> Signed-off-by: Andrew Lunn
Hi Andrew,
maybe this could be sent to net, not only net-next. Or maybe even
better, with a Fixes tag t
On Mon, 22 Jun 2020 12:58:00 +
ѽ҉ᶬḳ℠ wrote:
> Thank you for the input and pointer to patches.
>
> The problem is that it would require TOS deployed on the device, which
> is not the case and the repo being twice removed from the kernel source
> -> OpenWrt -> TOS, patches are neither availa
TurrisOS has patches adding multi-CPU DSA support, look at those if you
want this functionality.
These patches apply on openwrt, after patching there should be kernel
patches created in target/linux/mvebu/patches-{4.14,5.4}
For 4.14 kernel:
https://gitlab.labs.nic.cz/turris/turris-build/-/blob/hb
On Fri, 5 Jun 2020 19:10:58 +0100
Jonathan McDowell wrote:
> The QCA8337(N) has an SGMII port which can operate in MAC, PHY or BASE-X
> mode depending on what it's connected to (e.g. CPU vs external PHY or
> SFP). At present the driver does no configuration of this port even if
> it is selected.
On Fri, 8 May 2020 16:28:44 +0100
Russell King - ARM Linux admin wrote:
> On Thu, May 07, 2020 at 03:21:35PM +0200, Marek Behún wrote:
> > FreeTel P.C30.2 and P.C30.3 may fail to report anything useful from
> > their EEPROM. They report correct nominal bitrate of 10300 MBd, but do
> > not report
On Sat, 7 Sep 2019 16:00:48 -0400
Vivien Didelot wrote:
> @@ -3132,6 +3132,7 @@ static const struct mv88e6xxx_ops mv88e6172_ops = {
> .port_set_rgmii_delay = mv88e6352_port_set_rgmii_delay,
> .port_set_speed = mv88e6352_port_set_speed,
> .port_tag_remap = mv88e6095_port_tag_rem
On Wed, 28 Aug 2019 14:55:11 -0400
Vivien Didelot wrote:
> Now mv88e6xxx does not enable its ports at setup itself and let
> the DSA core handle this, unused ports are disabled without being
> powered on first. While that is expected, the SERDES powering code
> was assuming that a port was alread
On Mon, 26 Aug 2019 14:28:09 -0400
Vivien Didelot wrote:
> Ask yourself what is the single task achieved by this function, and name this
> operation accordingly. It seems to change the CMODE to be writable, only
> supported by certain switch models right? So in addition to port_get_cmode
> and po
What about this?
It adds a new chip operation (I know Vivien said not to, but I was
doing it already) port_setup_extra, and implements it for Topaz.
Also it changes the mv88e6xxx_port_set_cmode so that it does not use
those 2 additional parameters.
Should I rewrite it so that only the second cha
On Mon, 26 Aug 2019 13:44:18 -0400
Vivien Didelot wrote:
> > It can be done once at probe. At first I thought about doing this in
> > setup_errata, but this is not an erratum. So shall I create a new
> > method for this in chip operations structure? Something like
> > port_additional_setup() ?
On Mon, 26 Aug 2019 17:38:30 +0200
Andrew Lunn wrote:
> > +static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
> > + phy_interface_t mode, bool allow_over_2500,
> > + bool make_cmode_writable)
>
> I don't like t
On Mon, 26 Aug 2019 17:38:30 +0200
Andrew Lunn wrote:
> > +static int mv88e6xxx_port_set_cmode(struct mv88e6xxx_chip *chip, int port,
> > + phy_interface_t mode, bool allow_over_2500,
> > + bool make_cmode_writable)
>
> I don't like t
On Sun, 25 Aug 2019 12:12:14 -0400
Vivien Didelot wrote:
> In fact you're also relying on -ENODEV, which is what you return here (and in
> other places) instead of 0. So I'm afraid you have to address my comment
> now...
Vivien, you are right. I returned -ENODEV for Peridot when no lane was
to
On Sun, 25 Aug 2019 12:02:32 -0400
Vivien Didelot wrote:
> Aren't you relying on -ENODEV as well?
Vivien, I am not relying o -ENODEV. I changed the serdes_get_lane
semantics:
- previously:
- if port has a lane for current cmode, return given lane number
- otherwise return -ENODEV
- if
On Sat, 24 Aug 2019 20:53:49 -0400
Vivien Didelot wrote:
> OK I think you meant info->ops->serdes_irq_free and
> info->ops->serdes_irq_setup, otherwise it's confusing.
>
> I think I know what's going on, I'll look into it soon.
Either dsa_port_setup is calling dsa_port_disable for
DSA_PORT_TYPE
On Sat, 24 Aug 2019 13:04:04 -0700
Florian Fainelli wrote:
> Now, the 4.9 kernel behavior actually works just fine because eth1 is
> not a special interface, so no tagging is expected, and "wifi", although
> it supports DSA tagging, represents another side of the CPU/host network
> stack, so you
On Sat, 24 Aug 2019 17:24:07 +0200
Andrew Lunn wrote:
> That is a new idea. Interesting.
>
> I would like to look around and see what else uses this "lan1@eth0"
> concept. We need to ensure it is not counter intuitive in general,
> when you consider all possible users.
There are not many users
On Sat, 24 Aug 2019 23:01:21 +0200
Marek Behun wrote:
> the documentation would became weird to users.
... would become weird ...
>
> We are *already* using the iflink property to report which CPU device
> is used as CPU destination port for a given switch slave interface. So
>
On Sat, 24 Aug 2019 13:04:04 -0700
Florian Fainelli wrote:
> 1) Your approach is kind of interesting here, not sure if it is the best
> but it is not outright wrong. In the past, we had been talking about
> different approaches, some of which seemed too simplistic or too narrow
> on the use case,
On Sat, 24 Aug 2019 15:32:54 -0400
Vivien Didelot wrote:
> You are already using these macros in the previous patch. I guess you meant
> to introduce this patch before. But since you are moving and renaming the
> same code without functional changes, you may squash them together.
Hm, you are rig
On Sat, 24 Aug 2019 16:13:28 -0400
Vivien Didelot wrote:
> Hi Marek,
>
> On Fri, 23 Aug 2019 23:26:02 +0200, Marek Behún wrote:
> > -int mv88e6xxx_port_hidden_write(struct mv88e6xxx_chip *chip, int port, int
> > reg,
> > - u16 val);
> > +int mv88e6xxx_port_hidden_writ
On Sat, 24 Aug 2019 17:56:36 +0200
Andrew Lunn wrote:
> I expect bad things will happen if frames are flooded to multiple CPU
> ports. For this to work, the whole switch design needs to support
> multiple CPU ports. I doubt this will work on any old switch.
>
> Having a host interface connected
On Sat, 24 Aug 2019 18:44:44 +0300
Vladimir Oltean wrote:
> Just to be clear. You can argue that such switches are weird, and
> that's ok. Just want to understand the general type of hardware for
> which such a patch is intended.
Vladimir,
the general part should solve for devices like Turris 1
On Sat, 24 Aug 2019 17:24:07 +0200
Andrew Lunn wrote:
> So this is all about transmit from the host out the switch. What about
> receive? How do you tell the switch which CPU interface it should use
> for a port?
Andrew, we use the same. The DSA slave implementation of ndo_set_iflink
will also t
On Sat, 24 Aug 2019 17:43:02 +0200
Andrew Lunn wrote:
> But i don't know if it is worth the effort. I've never seen a D in DSA
> setup with multiple CPUs ports. I've only ever seen an single switch
> with multiple CPU ports.
Yes, that exactly. I was thinking about the most optimal algorithm, but
On Sun, 18 Aug 2019 13:35:45 -0400
Vivien Didelot wrote:
> Call the .port_enable and .port_disable functions for all ports,
> not only the user ports, so that drivers may optimize the power
> consumption of all ports after a successful setup.
>
> Unused ports are now disabled on setup. CPU and D
On Sat, 17 Aug 2019 20:03:42 +0200
Marek Behun wrote:
> One way would be to rename the mv88e6xxx_setup_port function to
> mv88e6xxx_setup_port_regs, or mv88e6xxx_port_pre_setup, or something
> like that. Would the names mv88e6xxx_port_setup and
> mv88e6xxx_setup_port_regs still be ve
Hi Vivien,
On Fri, 16 Aug 2019 19:05:37 -0400
Vivien Didelot wrote:
> I think the DSA switch port_setup/port_teardown operations are fine, but the
> idea would be that the drivers must no longer setup their ports directly
> in their .setup function. So for mv88e6xxx precisely, we should rename
>
On Fri, 16 Aug 2019 12:25:52 -0400
Vivien Didelot wrote:
> So now we have mv88e6xxx_setup_port() and mv88e6xxx_port_setup(), which both
> setup a port, differently, at different time. This is definitely error prone.
Hmm. I don't know how much of mv88e6xxx_setup_port() could be moved to
this new
On Tue, 13 Aug 2019 22:32:34 +0200
Andrew Lunn wrote:
> On Tue, Aug 13, 2019 at 07:12:43PM +0200, Marek Behún wrote:
> > @@ -598,12 +599,49 @@ int mv88e6352_port_link_state(struct mv88e6xxx_chip
> > *chip, int port,
> > struct phylink_link_state *state)
> > {
> > i
On Sun, 11 Aug 2019 18:16:11 +0300
Vladimir Oltean wrote:
> The DSA fixed-link port functionality *has* been converted to phylink.
> See:
> -
> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=0e27921816ad9
> -
> https://git.kernel.org/pub/scm/linux/kernel/git/davem
On Sun, 11 Aug 2019 17:31:53 +0200
Andrew Lunn wrote:
> On Sun, Aug 11, 2019 at 05:08:11PM +0200, Marek Behún wrote:
> > The mv88e6xxx_port_setup_mac looks if one of the {link, speed, duplex}
> > parameters is being changed from the current setting, and if not, does
> > not do anything. This test
On Sun, 11 Aug 2019 17:40:01 +0200
Andrew Lunn wrote:
> On Sun, Aug 11, 2019 at 05:08:12PM +0200, Marek Behún wrote:
> > The fixed_phy driver does not set the phydev->is_gigabit_capable member
> > when the fixed_phy is gigabit capable.
>
> Neither does any other PHY driver. It should be possib
I have sent two new patches, each fixing one of the bugs that negated
each other.
Marek
OK guys, something is terribly wrong here.
I bisected to the commit mentioned (88d6272acaaa), looked around at the
genphy functions, tried adding the link=0 workaround and it did work,
so I though this was the issue.
What I realized now is that before the commit 88d6272acaaa things
worked because
On Sat, 10 Aug 2019 20:00:01 -0700 (PDT)
David Miller wrote:
> From: Marek Behun
> Date: Sun, 11 Aug 2019 04:02:47 +0200
>
> > Which means I should have added the Fixes tag /o\
>
> Which means you need to repost this patch with it added.
Sent as v2
Which means I should have added the Fixes tag /o\
On Sun, 11 Aug 2019 03:47:42 +0200
Marek Behun wrote:
> This should probably go into stable as well, after review.
>
> Marek
1 - 100 of 114 matches
Mail list logo
