lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <02eaa2ca-d788-c98f-e23f-8ab71a161104@gmail.com>
Date:   Sat, 18 Feb 2023 12:17:41 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Arınç ÜNAL <arinc.unal@...nc9.com>,
        Vladimir Oltean <olteanv@...il.com>,
        Frank Wunderlich <frank-w@...lic-files.de>
Cc:     netdev <netdev@...r.kernel.org>, erkin.bozoglu@...ont.com
Subject: Re: Choose a default DSA CPU port



On 2/18/2023 9:07 AM, Arınç ÜNAL wrote:
> Hey there folks,
> 
> The problem is this. Frank and I have got a Bananapi BPI-R2 with MT7623 
> SoC. The port5 of MT7530 switch is wired to gmac1 of the SoC. Port6 is 
> wired to gmac0. Since DSA sets the first CPU port it finds on the 
> devicetree, port5 becomes the CPU port for all DSA slaves.
> 
> But we'd prefer port6 since it uses trgmii while port5 uses rgmii. There 
> are also some performance issues with the port5 - gmac1 link.
> 
> Now we could change it manually on userspace if the DSA subdriver 
> supported changing the DSA master.
> 
> I'd like to find a solution which would work for the cases of; the 
> driver not supporting changing the DSA master, or saving the effort of 
> manually changing it on userspace.

Changing the assignment is a policy, and policies reside in user-space, 
most of the time. What is inconvenient with doing this in user-space? 
Assuming you are going to do this in an OpenWrt context, this seems 
fairly easy to have /etc/config/network result into the right set of 
calls to configure the switch, would not it?

> 
> The solution that came to my mind:
> 
> Introduce a DT property to designate a CPU port as the default CPU port.
> If this property exists on a CPU port, that port becomes the CPU port 
> for all DSA slaves.
> If it doesn't exist, fallback to the first-found-cpu-port method.
> 
> Frank doesn't like this idea:
> 
>  > maybe define the default cpu in driver which gets picked up by core 
> (define port6 as default if available).
>  > Imho additional dts-propperty is wrong approch...it should be handled 
> by driver. But cpu-port-selection is currently done in dsa-core which 
> makes it a bit difficult.
> 
> What are your thoughts?

I agree with Frank for the reasons that this is akin to encoding a 
policy in the Device Tree which is not what Device Tree is for. There is 
already Richard working on adding support for changing the DSA master:

https://lore.kernel.org/all/20230211184101.651462-1-richard@routerhints.com/
-- 
Florian

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ