Message-ID: <50a02fb5-cb6c-5f37-150f-8ecfccdd473b@gmx.net>
Date:   Mon, 22 Jun 2020 12:58:00 +0000
From:   ѽ҉ᶬḳ℠ <vtol@....net>
To:     netdev@...r.kernel.org
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Marek Behun <marek.behun@....cz>
Subject: Re: secondary CPU port facing switch does not come up/online

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@....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
>>
>>


Download attachment "OpenPGP_0xF4F735931F05C5CE.asc" of type "application/pgp-keys" (3112 bytes)

Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)

Powered by blists - more mailing lists