netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ѽ҉ᶬḳ℠ <vtol@gmx.net>
To: netdev@vger.kernel.org
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Marek Behun <marek.behun@nic.cz>
Subject: Re: secondary CPU port facing switch does not come up/online
Date: Mon, 22 Jun 2020 12:58:00 +0000	[thread overview]
Message-ID: <50a02fb5-cb6c-5f37-150f-8ecfccdd473b@gmx.net> (raw)
In-Reply-To: <20200622143155.2d57d7f7@nic.cz>


[-- 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 --]

  reply	other threads:[~2020-06-22 12:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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       ` ѽ҉ᶬḳ℠ [this message]
2020-06-22 13:06         ` Marek Behun
2020-06-22 13:23           ` ѽ҉ᶬḳ℠

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50a02fb5-cb6c-5f37-150f-8ecfccdd473b@gmx.net \
    --to=vtol@gmx.net \
    --cc=andrew@lunn.ch \
    --cc=f.fainelli@gmail.com \
    --cc=marek.behun@nic.cz \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).