netdev - RE: [PATCH v5 net-next 04/13] net: enetc: add initial netc-blk-ctrl driver support

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:
 <PAXPR04MB8510D46820B360298AAE130E88482@PAXPR04MB8510.eurprd04.prod.outlook.com>
Date: Sat, 26 Oct 2024 02:47:38 +0000
From: Wei Fang <wei.fang@....com>
To: Vladimir Oltean <vladimir.oltean@....com>
CC: "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 v5 net-next 04/13] net: enetc: add initial netc-blk-ctrl
 driver support

> -----Original Message-----
> From: Vladimir Oltean <vladimir.oltean@....com>
> Sent: 2024年10月25日 20:43
> To: Wei Fang <wei.fang@....com>
> Cc: davem@...emloft.net; edumazet@...gle.com; kuba@...nel.org;
> pabeni@...hat.com; robh@...nel.org; krzk+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; linux@...linux.org.uk; bhelgaas@...gle.com;
> horms@...nel.org; imx@...ts.linux.dev; netdev@...r.kernel.org;
> devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
> linux-pci@...r.kernel.org; alexander.stein@...tq-group.com
> Subject: Re: [PATCH v5 net-next 04/13] net: enetc: add initial netc-blk-ctrl
> driver support
> 
> On Fri, Oct 25, 2024 at 04:44:50AM +0300, Wei Fang wrote:
> > > On Thu, Oct 24, 2024 at 02:53:19PM +0800, Wei Fang wrote:
> > > Can U-Boot deal with the IERB/PRB configuration?
> > >
> > > For LS1028A, the platform which initiated the IERB driver "trend", the
> situation
> > > was a bit more complicated, as we realized the reset-time defaults aren't
> what
> > > we need very late in the product life cycle, when customer boards already
> had
> > > bootloaders and we didn't want to complicate their process to have to
> redeploy
> > > in order to get access to such a basic feature as flow control. Though if we
> knew
> > > it from day one, we would have put the IERB fixups in U-Boot.
> >
> > The situation of i.MX95 is different from LS1028A, i.MX95 needs to support
> system
> > suspend/resume feature. If the i.MX95 enters suspend mode, the NETC may
> > power off (depends on user case), so IERB and PRB will be reset, in this case,
> we need
> > to reconfigure the IERB & PRB, including NETCMIX.
> >
> > > What is written in the IERB for MII/PCS protocols by default? I suppose
> there's
> > > some other mechanism to preinitialize it with good values?
> >
> > The MII/PCS protocols are set in NETCMIX not IERB, but the IERB will get
> these
> > info from NETCMIX, I mean the hardware, not the software. The default
> values
> > are all 0.
> 
> I am shocked that the NETCMIX/IERB blocks does not have a separate power
> domain from the ENETC, to avoid powering them off, which loses the settings.
> Please provide this explanation in the opening comments of this driver, it
> is its entire "raison d'être".

Hmm, it's a good idea, I can add this annotation at the beginning of the driver.
But this in not the entire "raison d'être", because we also hope to be able to
dynamically configure based on DTS, which is more flexible than under uboot.
For example, Timer binding for ENETC and switch if there are multiple Timer
instances, port selection if two ENETCs or one ENETC and one switch port share
the same physical port.