* secondary CPU port facing switch does not come up/online
@ 2020-06-21 20:24 ѽ҉ᶬḳ℠
2020-06-21 21:08 ` Florian Fainelli
0 siblings, 1 reply; 7+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-06-21 20:24 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1.1: Type: text/plain, Size: 1673 bytes --]
{"kernel":"5.4.46","hostname":"OpenWrt","system":"ARMv7 Processor rev 1
(v7l)","model":"Turris
Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13600-9a477b833a","target":"mvebu/cortexa9","description":"OpenWrt
SNAPSHOT r13600-9a477b833a"}}
_____
With the below cited DT both CPU ports facing the node's build-in switch
are brought online at boot time with kernel 4.14 but since having
switched to kernel 5.4 only one CPU port gets online. It is as if the
kernel discards the presence of the secondary CPU port. Kernel log only
prints for the offline port just a single entry:
mvneta f1070000.ethernet eth0: Using hardware mac address
Swapping eth1 to port6 and eth0 to port6 then eth0 is brought online but
eth1 is not. Removing port5 then the port6 listed port is brought up/online.
Once the node is booted the offline port can brought up with ip l set
up. This seems like a regression bug in between the kernel versions.
____
DT
cpu_port5: ports@5 {
reg = <5>;
label = "cpu";
ethernet = <ð1>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
cpu_port6: ports@6 {
reg = <6>;
label = "cpu";
ethernet = <ð0>;
fixed-link {
speed = <1000>;
full-duplex;
};
};
------------
kconf
CONFIG_MTD_NAND_MARVELL=y
# CONFIG_PATA_MARVELL is not set
CONFIG_NET_VENDOR_MARVELL=y
CONFIG_MARVELL_PHY=y
# CONFIG_MARVELL_10G_PHY is not set
# CONFIG_WLAN_VENDOR_MARVELL is not set
CONFIG_CRYPTO_DEV_MARVELL_CESA=y
[-- Attachment #1.1.2: OpenPGP_0xF4F735931F05C5CE.asc --]
[-- Type: application/pgp-keys, Size: 3155 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: secondary CPU port facing switch does not come up/online
2020-06-21 20:24 secondary CPU port facing switch does not come up/online ѽ҉ᶬḳ℠
@ 2020-06-21 21:08 ` Florian Fainelli
2020-06-22 7:39 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 7+ messages in thread
From: Florian Fainelli @ 2020-06-21 21:08 UTC (permalink / raw)
To: vtol, netdev, Andrew Lunn, Vivien Didelot, marek.behun
Le 2020-06-21 à 13:24, ѽ҉ᶬḳ℠ a écrit :
> {"kernel":"5.4.46","hostname":"OpenWrt","system":"ARMv7 Processor rev 1
> (v7l)","model":"Turris
> Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13600-9a477b833a","target":"mvebu/cortexa9","description":"OpenWrt
> SNAPSHOT r13600-9a477b833a"}}
> _____
>
> With the below cited DT both CPU ports facing the node's build-in switch
> are brought online at boot time with kernel 4.14 but since having
> switched to kernel 5.4 only one CPU port gets online. It is as if the
> kernel discards the presence of the secondary CPU port. Kernel log only
> prints for the offline port just a single entry:
>
> mvneta f1070000.ethernet eth0: Using hardware mac address
>
> Swapping eth1 to port6 and eth0 to port6 then eth0 is brought online but
> eth1 is not. Removing port5 then the port6 listed port is brought
> up/online.
>
> Once the node is booted the offline port can brought up with ip l set
> up. This seems like a regression bug in between the kernel versions.
There can only be one CPU port at a time active right now, so I am not
sure why it even worked with kernel 4.14. Could you please share kernel
logs and the output of ip link show in both working/non-working cases?
>
> ____
> DT
>
> cpu_port5: ports@5 {
> reg = <5>;
> label = "cpu";
> ethernet = <ð1>;
>
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
>
> cpu_port6: ports@6 {
> reg = <6>;
> label = "cpu";
> ethernet = <ð0>;
>
> fixed-link {
> speed = <1000>;
> full-duplex;
> };
> };
> ------------
> kconf
>
> CONFIG_MTD_NAND_MARVELL=y
> # CONFIG_PATA_MARVELL is not set
> CONFIG_NET_VENDOR_MARVELL=y
> CONFIG_MARVELL_PHY=y
> # CONFIG_MARVELL_10G_PHY is not set
> # CONFIG_WLAN_VENDOR_MARVELL is not set
> CONFIG_CRYPTO_DEV_MARVELL_CESA=y
--
Florian
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: secondary CPU port facing switch does not come up/online
2020-06-21 21:08 ` Florian Fainelli
@ 2020-06-22 7:39 ` ѽ҉ᶬḳ℠
2020-06-22 12:31 ` Marek Behun
0 siblings, 1 reply; 7+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-06-22 7:39 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, marek.behun
[-- Attachment #1.1.1: Type: text/plain, Size: 4599 bytes --]
On 21/06/2020 21:08, Florian Fainelli wrote:
> Le 2020-06-21 à 13:24, ѽ҉ᶬḳ℠ a écrit :
>> {"kernel":"5.4.46","hostname":"OpenWrt","system":"ARMv7 Processor rev 1
>> (v7l)","model":"Turris
>> Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13600-9a477b833a","target":"mvebu/cortexa9","description":"OpenWrt
>> SNAPSHOT r13600-9a477b833a"}}
>> _____
>>
>> With the below cited DT both CPU ports facing the node's build-in switch
>> are brought online at boot time with kernel 4.14 but since having
>> switched to kernel 5.4 only one CPU port gets online. It is as if the
>> kernel discards the presence of the secondary CPU port. Kernel log only
>> prints for the offline port just a single entry:
>>
>> mvneta f1070000.ethernet eth0: Using hardware mac address
>>
>> Swapping eth1 to port6 and eth0 to port6 then eth0 is brought online but
>> eth1 is not. Removing port5 then the port6 listed port is brought
>> up/online.
>>
>> Once the node is booted the offline port can brought up with ip l set
>> up. This seems like a regression bug in between the kernel versions.
> There can only be one CPU port at a time active right now, so I am not
> sure why it even worked with kernel 4.14.
What is the reasoning, because DSA is not coded to handle multi-ports?
DSA can be patched downstream (proposed patches to mainline kernel were
not accepted) and is so is for the 4.14 instance but there is DSA patch
available for the 5.4 instance yet. That aside I would assume that DSA
is not in charge of handling the state of the CPU ports but rather PHY
or PHYLINK?
I understand that dual CPU port chipset design is somewhat unusual but
it is something unique and therefore a fringe case that is not supported
by the kernel?
> Could you please share kernel
> logs and the output of ip link show in both working/non-working cases?
Sure, does the ML accept attachments, if so which format, or you want
two full kernel logs in the message body? Meantime, the short version:
4.14
dmesg -t | grep mvneta
mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
mvneta f1070000.ethernet eth0: configuring for fixed/rgmii link mode
mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than
1600B
mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
5.4
dmesg -t | grep mvneta
mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than
1600B
mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
mvneta f1034000.ethernet eth2: Link is Down
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
[-- Attachment #1.1.2: OpenPGP_0xF4F735931F05C5CE.asc --]
[-- Type: application/pgp-keys, Size: 3155 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: secondary CPU port facing switch does not come up/online
2020-06-22 7:39 ` ѽ҉ᶬḳ℠
@ 2020-06-22 12:31 ` Marek Behun
2020-06-22 12:58 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 7+ messages in thread
From: Marek Behun @ 2020-06-22 12:31 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠
Cc: netdev, Florian Fainelli, Andrew Lunn, Vivien Didelot
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/hbd/patches/openwrt/wip/0009-mvebu-turris-omnia-multi-cpu-dsa.patch
(this creates
target/linux/mvebu/patches-4.14/90500-net-dsa-multi-cpu.patch
target/linux/mvebu/patches-4.14/90501-omnia-dts-dsa-multi-cpu.patch
)
For 5.4 kernel:
https://gitlab.labs.nic.cz/turris/turris-build/-/blob/fix/hbd-omnia-5.4-kernel/patches/openwrt/wip/0005-mvebu-initial-support-for-Omnia-on-5.4-kernel.patch
(this creates
target/linux/mvebu/patches-5.4/9950-net-dsa-allow-for-multiple-CPU-ports.patch
target/linux/mvebu/patches-5.4/9951-net-add-ndo-for-setting-the-iflink-property.patch
target/linux/mvebu/patches-5.4/9952-net-dsa-implement-ndo_set_netlink-for-chaning-port-s.patch
target/linux/mvebu/patches-5.4/9953-net-dsa-mv88e6xxx-support-multi-CPU-DSA.patch
)
On Mon, 22 Jun 2020 07:39:00 +0000
ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> On 21/06/2020 21:08, Florian Fainelli wrote:
> > Le 2020-06-21 à 13:24, ѽ҉ᶬḳ℠ a écrit :
> >> {"kernel":"5.4.46","hostname":"OpenWrt","system":"ARMv7 Processor rev 1
> >> (v7l)","model":"Turris
> >> Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13600-9a477b833a","target":"mvebu/cortexa9","description":"OpenWrt
> >> SNAPSHOT r13600-9a477b833a"}}
> >> _____
> >>
> >> With the below cited DT both CPU ports facing the node's build-in switch
> >> are brought online at boot time with kernel 4.14 but since having
> >> switched to kernel 5.4 only one CPU port gets online. It is as if the
> >> kernel discards the presence of the secondary CPU port. Kernel log only
> >> prints for the offline port just a single entry:
> >>
> >> mvneta f1070000.ethernet eth0: Using hardware mac address
> >>
> >> Swapping eth1 to port6 and eth0 to port6 then eth0 is brought online but
> >> eth1 is not. Removing port5 then the port6 listed port is brought
> >> up/online.
> >>
> >> Once the node is booted the offline port can brought up with ip l set
> >> up. This seems like a regression bug in between the kernel versions.
> > There can only be one CPU port at a time active right now, so I am not
> > sure why it even worked with kernel 4.14.
>
> What is the reasoning, because DSA is not coded to handle multi-ports?
> DSA can be patched downstream (proposed patches to mainline kernel were
> not accepted) and is so is for the 4.14 instance but there is DSA patch
> available for the 5.4 instance yet. That aside I would assume that DSA
> is not in charge of handling the state of the CPU ports but rather PHY
> or PHYLINK?
>
> I understand that dual CPU port chipset design is somewhat unusual but
> it is something unique and therefore a fringe case that is not supported
> by the kernel?
>
> > Could you please share kernel
> > logs and the output of ip link show in both working/non-working cases?
>
> Sure, does the ML accept attachments, if so which format, or you want
> two full kernel logs in the message body? Meantime, the short version:
>
> 4.14
> dmesg -t | grep mvneta
> mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
> mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
> mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
> mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
> mvneta f1070000.ethernet eth0: configuring for fixed/rgmii link mode
> mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
> mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than
> 1600B
> mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
> mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
> mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
> mvneta f1034000.ethernet eth2: Link is Down
> mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
> mvneta f1034000.ethernet eth2: Link is Down
> mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>
> 5.4
> dmesg -t | grep mvneta
> mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
> mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
> mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
> mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
> mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than
> 1600B
> mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
> mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
> mvneta f1034000.ethernet eth2: Link is Down
> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
> mvneta f1034000.ethernet eth2: Link is Down
> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: secondary CPU port facing switch does not come up/online
2020-06-22 12:31 ` Marek Behun
@ 2020-06-22 12:58 ` ѽ҉ᶬḳ℠
2020-06-22 13:06 ` Marek Behun
0 siblings, 1 reply; 7+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-06-22 12:58 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, Marek Behun
[-- Attachment #1.1.1: Type: text/plain, Size: 6694 bytes --]
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 available in mainline or OpenWrt
whilst the Marvell SoC chipset is not unique to the CZ.NIC manufactured
devices but leveraged by other vendors as well.
It seems a bit strange to be nudged to the deployment of a particular
repo, unless self-compiling kernel with those patch sets, instead of the
same functionality being provided straight from mainline. Are those
patch sets being introduced to mainline?
On 22/06/2020 12:31, Marek Behun wrote:
> 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/hbd/patches/openwrt/wip/0009-mvebu-turris-omnia-multi-cpu-dsa.patch
>
> (this creates
> target/linux/mvebu/patches-4.14/90500-net-dsa-multi-cpu.patch
> target/linux/mvebu/patches-4.14/90501-omnia-dts-dsa-multi-cpu.patch
> )
>
> For 5.4 kernel:
> https://gitlab.labs.nic.cz/turris/turris-build/-/blob/fix/hbd-omnia-5.4-kernel/patches/openwrt/wip/0005-mvebu-initial-support-for-Omnia-on-5.4-kernel.patch
>
> (this creates
> target/linux/mvebu/patches-5.4/9950-net-dsa-allow-for-multiple-CPU-ports.patch
> target/linux/mvebu/patches-5.4/9951-net-add-ndo-for-setting-the-iflink-property.patch
> target/linux/mvebu/patches-5.4/9952-net-dsa-implement-ndo_set_netlink-for-chaning-port-s.patch
> target/linux/mvebu/patches-5.4/9953-net-dsa-mv88e6xxx-support-multi-CPU-DSA.patch
> )
>
> On Mon, 22 Jun 2020 07:39:00 +0000
> ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
>
>> On 21/06/2020 21:08, Florian Fainelli wrote:
>>> Le 2020-06-21 à 13:24, ѽ҉ᶬḳ℠ a écrit :
>>>> {"kernel":"5.4.46","hostname":"OpenWrt","system":"ARMv7 Processor rev 1
>>>> (v7l)","model":"Turris
>>>> Omnia","board_name":"cznic,turris-omnia","release":{"distribution":"OpenWrt","version":"SNAPSHOT","revision":"r13600-9a477b833a","target":"mvebu/cortexa9","description":"OpenWrt
>>>> SNAPSHOT r13600-9a477b833a"}}
>>>> _____
>>>>
>>>> With the below cited DT both CPU ports facing the node's build-in switch
>>>> are brought online at boot time with kernel 4.14 but since having
>>>> switched to kernel 5.4 only one CPU port gets online. It is as if the
>>>> kernel discards the presence of the secondary CPU port. Kernel log only
>>>> prints for the offline port just a single entry:
>>>>
>>>> mvneta f1070000.ethernet eth0: Using hardware mac address
>>>>
>>>> Swapping eth1 to port6 and eth0 to port6 then eth0 is brought online but
>>>> eth1 is not. Removing port5 then the port6 listed port is brought
>>>> up/online.
>>>>
>>>> Once the node is booted the offline port can brought up with ip l set
>>>> up. This seems like a regression bug in between the kernel versions.
>>> There can only be one CPU port at a time active right now, so I am not
>>> sure why it even worked with kernel 4.14.
>> What is the reasoning, because DSA is not coded to handle multi-ports?
>> DSA can be patched downstream (proposed patches to mainline kernel were
>> not accepted) and is so is for the 4.14 instance but there is DSA patch
>> available for the 5.4 instance yet. That aside I would assume that DSA
>> is not in charge of handling the state of the CPU ports but rather PHY
>> or PHYLINK?
>>
>> I understand that dual CPU port chipset design is somewhat unusual but
>> it is something unique and therefore a fringe case that is not supported
>> by the kernel?
>>
>>> Could you please share kernel
>>> logs and the output of ip link show in both working/non-working cases?
>> Sure, does the ML accept attachments, if so which format, or you want
>> two full kernel logs in the message body? Meantime, the short version:
>>
>> 4.14
>> dmesg -t | grep mvneta
>> mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
>> mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
>> mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
>> mvneta f1034000.ethernet eth2: switched to 802.3z/1000base-x link mode
>> mvneta f1070000.ethernet eth0: configuring for fixed/rgmii link mode
>> mvneta f1070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
>> mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than
>> 1600B
>> mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
>> mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
>> mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
>> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>> mvneta f1034000.ethernet eth2: Link is Down
>> mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
>> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>> mvneta f1034000.ethernet eth2: Link is Down
>> mvneta f1034000.ethernet eth2: configuring for 802.3z/1000base-x link mode
>> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>>
>> 5.4
>> dmesg -t | grep mvneta
>> mvneta f1070000.ethernet eth0: Using hardware mac address d8:58:d7:00:79:7c
>> mvneta f1030000.ethernet eth1: Using hardware mac address d8:58:d7:00:79:7a
>> mvneta f1034000.ethernet eth2: Using hardware mac address d8:58:d7:00:79:7b
>> mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
>> mvneta f1030000.ethernet eth1: Disable IP checksum for MTU greater than
>> 1600B
>> mvneta f1030000.ethernet eth1: configuring for fixed/rgmii link mode
>> mvneta f1030000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
>> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
>> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>> mvneta f1034000.ethernet eth2: Link is Down
>> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
>> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
>> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>> mvneta f1034000.ethernet eth2: Link is Down
>> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
>> mvneta f1034000.ethernet eth2: configuring for inband/1000base-x link mode
>> mvneta f1034000.ethernet eth2: Link is Up - 1Gbps/Full - flow control off
>>
>>
[-- Attachment #1.1.2: OpenPGP_0xF4F735931F05C5CE.asc --]
[-- Type: application/pgp-keys, Size: 3155 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: secondary CPU port facing switch does not come up/online
2020-06-22 12:58 ` ѽ҉ᶬḳ℠
@ 2020-06-22 13:06 ` Marek Behun
2020-06-22 13:23 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 7+ messages in thread
From: Marek Behun @ 2020-06-22 13:06 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠
Cc: netdev, Florian Fainelli, Andrew Lunn, Vivien Didelot
On Mon, 22 Jun 2020 12:58:00 +0000
ѽ҉ᶬḳ℠ <vtol@gmx.net> 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 available in mainline or OpenWrt
> whilst the Marvell SoC chipset is not unique to the CZ.NIC manufactured
> devices but leveraged by other vendors as well.
>
> It seems a bit strange to be nudged to the deployment of a particular
> repo, unless self-compiling kernel with those patch sets, instead of the
> same functionality being provided straight from mainline. Are those
> patch sets being introduced to mainline?
Hi,
I sent a RFC patch series last year adding multiCPU DSA to upstream
kernel, but the problem is a rather complicated. I plan to try again,
but do not know when.
As for OpenWRT - yes, we will try to add full support for Omnia into
upstream OpenWRT sometime soon. We were waiting for some other
patches to be accepted in upstream kernel.
Marek
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: secondary CPU port facing switch does not come up/online
2020-06-22 13:06 ` Marek Behun
@ 2020-06-22 13:23 ` ѽ҉ᶬḳ℠
0 siblings, 0 replies; 7+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-06-22 13:23 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, Andrew Lunn, Vivien Didelot, Marek Behun
[-- Attachment #1.1.1: Type: text/plain, Size: 1828 bytes --]
On 22/06/2020 13:06, Marek Behun wrote:
> On Mon, 22 Jun 2020 12:58:00 +0000
> ѽ҉ᶬḳ℠ <vtol@gmx.net> 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 available in mainline or OpenWrt
>> whilst the Marvell SoC chipset is not unique to the CZ.NIC manufactured
>> devices but leveraged by other vendors as well.
>>
>> It seems a bit strange to be nudged to the deployment of a particular
>> repo, unless self-compiling kernel with those patch sets, instead of the
>> same functionality being provided straight from mainline. Are those
>> patch sets being introduced to mainline?
> Hi,
>
> I sent a RFC patch series last year adding multiCPU DSA to upstream
> kernel, but the problem is a rather complicated.
Tracked those on the ML but did not understand why they fizzled into
nothing, least it did not look like that patches been outright rejected.
But that is perhaps where "complicated" comes in...
> I plan to try again,
> but do not know when.
If time is an issue I suppose it would not just do if I picked up those
patches and submit those on your behalf to mainline since it likely
would require follow up on a code discussion which is beyond realm.
>
> As for OpenWRT - yes, we will try to add full support for Omnia into
> upstream OpenWRT sometime soon. We were waiting for some other
> patches to be accepted in upstream kernel.
>
> Marek
Will have to wait then and see how that goes. Though it would certainly
benefit all device owners with such chip design if mainline would cater
for it instead of the various downstream having to patch their end.
[-- Attachment #1.1.2: OpenPGP_0xF4F735931F05C5CE.asc --]
[-- Type: application/pgp-keys, Size: 3155 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-06-22 13:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-21 20:24 secondary CPU port facing switch does not come up/online ѽ҉ᶬḳ℠
2020-06-21 21:08 ` Florian Fainelli
2020-06-22 7:39 ` ѽ҉ᶬḳ℠
2020-06-22 12:31 ` Marek Behun
2020-06-22 12:58 ` ѽ҉ᶬḳ℠
2020-06-22 13:06 ` Marek Behun
2020-06-22 13:23 ` ѽ҉ᶬḳ℠
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).