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: <9e744cc1-9c27-4172-aacc-8599079f5570@linaro.org>
Date: Fri, 4 Oct 2024 16:02:54 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Andrew Lunn <andrew@...n.ch>,
 "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

On 03/10/2024 20:42, 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.
> 
>>>> 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

Huh? How is this anyhow related to the point discussed here? That's DTS.
You *CANNOT* send DTS to net-next/net.

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

Sorry guys, but this is not accurate. There is no such dependency, but
what's more: there cannot be such dependency.

If there is such dependency and above cross-tree merging is needed, then
it is a clear NAK from me, because patchset is utterly broken.

Upstreaming SoCs have clear rules, already documented in the kernel, in
various emails and in Qualcomm internal guideline (I think, if it is not
in your internal guideline, then please update because we keep repeating
it once per month to you guys).

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ