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

Message-ID: <20241101103427.b2a7ir57tigwghcu@skbuf>
Date: Fri, 1 Nov 2024 12:34:27 +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 Fri, Nov 01, 2024 at 04:18:55AM +0200, Wei Fang wrote:
> > 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 think the related info should be provided by DTS, but currently, we do not
> have such requirement that needs Linux to change the ECAM space, this may
> be supported in the future if we have the requirement.
> 
> > 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?
> 
> Yes, we indeed have this use case on i.MX95, only the VFs of 10G ENETC
> are owned by Cortex-A, the entire ECAM space and other NETC devices
> are all owned by Cortex-M. In this case, the system-controller is no needed
> in DTS, because Linux have no permission to access these resources.
> 
> > 
> > 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?
> 
> Currently, I have not idea in what use case we need a different ECAM driver
> to handle internally the entire system-controller.
> 
> For the use case I mentioned above, we use a different ECAM driver, which
> is implemented by RPMSG, because the entire ECAM space is owned by
> Cortex-M. So we use the ECAM driver to notify the Cortex-M to enable/disable
> VFs or do FLR for VFs and so on. But this ECAM driver does not need to
> configure the system-controller.

Ok, I was actually wondering if it makes sense for the the parent bus of
the NETC PCIe functions to be described through a unified binding that
covers all of the above use cases, so that major device tree modifications
aren't necessary to adapt between the 'Linux as host' and 'Linux as guest'
use cases. But you're saying it doesn't make much sense, because the
device tree in the guest case would contain descriptions of inaccessible
resources (the NETCMIX block). Oh well, this is just another case where
"device tree should describe hardware" actually means "device tree describes
what software wants to know about the hardware".

Anyway, I am now convinced by your design choices at least to the extent
that they appear self-consistent to me (I still don't really have an
independent opinion). If somebody has a different idea on how the PCIe
bus should be described, feel free to chime in.