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: <6c0118b9-f883-4fb5-9e69-a9095869d37f@quicinc.com>
Date: Fri, 4 Oct 2024 18:36:59 +0530
From: Kiran Kumar C.S.K <quic_kkumarcs@...cinc.com>
To: Andrew Lunn <andrew@...n.ch>
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



On 10/4/2024 12:12 AM, Andrew Lunn wrote:
>> 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.
> 

Ok.

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

Sure. We will request for such a stable branch merge once the NSS CC
patches are accepted by the reviewers. Could the 'net' tree be one such
stable branch option to merge the NSS CC driver?


> Or you need to wait a kernel cycle.>
Understand.

>    Andrew