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] [day] [month] [year] [list]

Message-ID: <zz7m5v5bqx76fk5pfjppnkl6toui6cz6vxavctqztcyyjb645l@67joksb6rfcz>
Date: Sat, 5 Oct 2024 13:30:21 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: "Kiran Kumar C.S.K" <quic_kkumarcs@...cinc.com>
Cc: Bjorn Andersson <quic_bjorande@...cinc.com>, 
	Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org, Andy Gross <agross@...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 Fri, Oct 04, 2024 at 07:47:15PM GMT, Kiran Kumar C.S.K wrote:
> 
> 
> On 10/4/2024 12:50 AM, Bjorn Andersson wrote:
> > On Thu, Oct 03, 2024 at 11:20:03PM +0530, Kiran Kumar C.S.K wrote:
> >> On 10/3/2024 2:58 AM, Andrew Lunn wrote:
> >>> On Thu, Oct 03, 2024 at 02:07:10AM +0530, Kiran Kumar C.S.K wrote:
[..]
> > The only remaining dependency I was expecting is the qcom tree depending
> > on the clock and netdev trees to have picked up the bindings, and for
> > new bindings I do accept dts changes in the same cycle (I validate dts
> > against bindings in linux-next).
> > 
> 
> The only compile-time dependency from PCS driver to NSS CC driver is
> with the example section in PCS driver's dtbindings file. The PCS DTS
> node example definitions include a header file exported by the NSS CC
> driver, to access certain macros for referring to the MII Rx/Tx clocks.
> So, although there is no dependency in the driver code, a successful
> dtbindings check will require the NSS CC driver to be available. Could
> you suggest how such dependencies can be worked around? Would it be
> acceptable to defer enabling the example node for dtbindings compilation
> using its 'status' property, until the NSS CC driver is merged?
> 

You can avoid this dependency by making the example...an example.

By using just descriptive phandles you can present an example of the
client device without creating a dependency on the specific provider.

Regards,
Bjorn