netdev - Re: RFC: Advice on adding support for Qualcomm IPQ9574 SoC Ethernet

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: <febe6776-53dc-454d-83b0-601540e45f78@lunn.ch>
Date: Thu, 3 Oct 2024 20:42:25 +0200
From: Andrew Lunn <andrew@...n.ch>
To: "Kiran Kumar C.S.K" <quic_kkumarcs@...cinc.com>
Cc: netdev@...r.kernel.org, Andy Gross <agross@...nel.org>,
	Bjorn Andersson <andersson@...nel.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Russell King <linux@...linux.org.uk>,
	Jacob Keller <jacob.e.keller@...el.com>,
	Bhupesh Sharma <bhupesh.sharma@...aro.org>,
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, vsmuthu@....qualcomm.com,
	arastogi@....qualcomm.com, linchen@....qualcomm.com,
	john@...ozen.org, Luo Jie <quic_luoj@...cinc.com>,
	Pavithra R <quic_pavir@...cinc.com>,
	"Suruchi Agarwal (QUIC)" <quic_suruchia@...cinc.com>,
	"Lei Wei (QUIC)" <quic_leiwei@...cinc.com>
Subject: Re: RFC: Advice on adding support for Qualcomm IPQ9574 SoC Ethernet

> Agree that switchdev is the right model for this device. We were
> planning to enable base Ethernet functionality using regular
> (non-switchdev) netdevice representation for the ports initially,
> without offload support. As the next step, L2/VLAN offload support using
> switchdev will be enabled on top. Hope this phased approach is fine.

Since it is not a DSA switch, yes, a phased approach should be O.K.

> >> 3) PCS driver patch series:
> >>         Driver for the PCS block in IPQ9574. New IPQ PCS driver will
> >>         be enabled in drivers/net/pcs/
> >> 	Dependent on NSS CC patch series (2).
> > 
> > I assume this dependency is pure at runtime? So the code will build
> > without the NSS CC patch series?
> 
> The MII Rx/Tx clocks are supplied from the NSS clock controller to the
> PCS's MII channels. To represent this in the DTS, the PCS node in the
> DTS is configured with the MII Rx/Tx clock that it consumes, using
> macros for clocks which are exported from the NSS CC driver in a header
> file. So, there will be a compile-time dependency for the dtbindings/DTS
> on the NSS CC patch series. We will clearly call out this dependency in
> the cover letter of the PCS driver. Hope that this approach is ok.

Since there is a compile time dependency, you might want to ask for
the clock patches to be put into a stable branch which can be merged
into netdev.

Or you need to wait a kernel cycle.

   Andrew