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: <20231023072700.17060-1-ante.knezic@helmholz.de>
Date: Mon, 23 Oct 2023 09:27:00 +0200
From: Ante Knezic <ante.knezic@...mholz.de>
To: <olteanv@...il.com>
CC: <UNGLinuxDriver@...rochip.com>, <andrew@...n.ch>,
	<ante.knezic@...mholz.de>, <conor+dt@...nel.org>, <davem@...emloft.net>,
	<devicetree@...r.kernel.org>, <edumazet@...gle.com>, <f.fainelli@...il.com>,
	<krzysztof.kozlowski+dt@...aro.org>, <kuba@...nel.org>,
	<linux-kernel@...r.kernel.org>, <marex@...x.de>, <netdev@...r.kernel.org>,
	<o.rempel@...gutronix.de>, <pabeni@...hat.com>, <robh+dt@...nel.org>,
	<woojung.huh@...rochip.com>
Subject: Re: [PATCH net-next v4 2/2] net:dsa:microchip: add property to select

On Fri, 20 Oct 2023 17:37:59 +0300, Vladimir Oltean wrote:

> Sorry, I didn't realize on v3 that you didn't completely apply my
> feedback on v2. Can "microchip,rmii-clk-internal" be a port device tree
> property? You have indeed moved its parsing to port code, but it is
> still located directly under the switch node in the device tree.
> 
> I'm thinking that if this property was also applicable to other switches
> with multiple RMII ports, the setting would be per port rather than global.

As far as I am aware only the KSZ8863 and KSZ8873 have this property available,
but the biggger issue might be in scaling this to port property as the register
"Forward Invalid VID Frame and Host Mode" where the setting is applied is
located under "Advanced Control Registers" section which is actually global at
least looking from the switch point of view. Usually port properties are more
applicable when registers in question are located under "Port Registers" section.
This is somewhat similar to for example enabling the tail tag mode which is 
again used only by the port 3 interface and is control from "Global Control 1"
register.
With this in mind - if you still believe we should move this to port dt 
property, then should we forbid setting the property for any other port other 
than port 3, and can/should this be enforced by the dt schema?




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ