linux-kernel - Re: [PATCH v4 net-next 03/13] dt-bindings: net: add bindings for NETC blocks control

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: <20241031124500.vxj7ppuhygh6lkpm@skbuf>
Date: Thu, 31 Oct 2024 14:45:00 +0200
From: Vladimir Oltean <vladimir.oltean@....com>
To: Wei Fang <wei.fang@....com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"edumazet@...gle.com" <edumazet@...gle.com>,
	"kuba@...nel.org" <kuba@...nel.org>,
	"pabeni@...hat.com" <pabeni@...hat.com>,
	"robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>,
	Claudiu Manoil <claudiu.manoil@....com>,
	Clark Wang <xiaoning.wang@....com>, Frank Li <frank.li@....com>,
	"christophe.leroy@...roup.eu" <christophe.leroy@...roup.eu>,
	"linux@...linux.org.uk" <linux@...linux.org.uk>,
	"bhelgaas@...gle.com" <bhelgaas@...gle.com>,
	"horms@...nel.org" <horms@...nel.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"alexander.stein@...tq-group.com" <alexander.stein@...tq-group.com>
Subject: Re: [PATCH v4 net-next 03/13] dt-bindings: net: add bindings for
 NETC blocks control

On Sat, Oct 26, 2024 at 06:01:37AM +0300, Wei Fang wrote:
> system-controller not only configure the endpoints of the NETC, but also
> can configure the ECAM space, such as the vendor ID, device ID, the RID
> of endpoint, VF stride and so on. For this perspective, I don't think the
> ECAM space should placed at the same hierarchical level with system-controller.
> 
> If they are placed at the same level, then before pci_host_common_probe() is
> called, we need to ensure that IERB completes probe(), which means we need
> to modify the PCI host common driver, component API or add a callback function
> or something else, which I don't think is a good idea.

Ok, that does sound important. If the NETCMIX block were to actually
modify the ECAM space, what would be the primary source of information
for how the ECAM device descriptions should look like?

I remember a use case being discussed internally a while ago was that
where the Cortex-A cores are only guests which only have ownership of
some Ethernet ports discovered through the ECAM, but not of the entire
NETCMIX block and not of physical Ethernet ports. How would that be
described in the device tree? The ECAM node would no longer be placed
under system-controller?

At what point does it simply just make more sense to have a different
PCIe ECAM driver than pcie-host-ecam-generic, which just handles
internally the entire NETCMIX?