netdev - RE: [EXT] Re: [PATCH v2 net 2/2] net: stmmac: dwmac-imx: pause the TXC clock in fixed-link

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:
 <PAXPR04MB918542A7030A3193562C4A948906A@PAXPR04MB9185.eurprd04.prod.outlook.com>
Date: Fri, 28 Jul 2023 16:09:29 +0000
From: Shenwei Wang <shenwei.wang@....com>
To: Will Deacon <will@...nel.org>, "Russell King (Oracle)"
	<linux@...linux.org.uk>
CC: Andrew Halaney <ahalaney@...hat.com>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Maxime Coquelin
	<mcoquelin.stm32@...il.com>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
	<s.hauer@...gutronix.de>, Neil Armstrong <neil.armstrong@...aro.org>, Kevin
 Hilman <khilman@...libre.com>, Vinod Koul <vkoul@...nel.org>, Chen-Yu Tsai
	<wens@...e.org>, Jernej Skrabec <jernej.skrabec@...il.com>, Samuel Holland
	<samuel@...lland.org>, Giuseppe Cavallaro <peppe.cavallaro@...com>, Alexandre
 Torgue <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>,
	Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam
	<festevam@...il.com>, dl-linux-imx <linux-imx@....com>, Jerome Brunet
	<jbrunet@...libre.com>, Martin Blumenstingl
	<martin.blumenstingl@...glemail.com>, Bhupesh Sharma
	<bhupesh.sharma@...aro.org>, Nobuhiro Iwamatsu
	<nobuhiro1.iwamatsu@...hiba.co.jp>, Simon Horman <simon.horman@...igine.com>,
	Bartosz Golaszewski <bartosz.golaszewski@...aro.org>, Wong Vee Khee
	<veekhee@...le.com>, Revanth Kumar Uppala <ruppala@...dia.com>, Jochen
 Henneberg <jh@...neberg-systemdesign.com>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "linux-stm32@...md-mailman.stormreply.com"
	<linux-stm32@...md-mailman.stormreply.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-amlogic@...ts.infradead.org"
	<linux-amlogic@...ts.infradead.org>, "imx@...ts.linux.dev"
	<imx@...ts.linux.dev>, Frank Li <frank.li@....com>
Subject: RE: [EXT] Re: [PATCH v2 net 2/2] net: stmmac: dwmac-imx: pause the
 TXC clock in fixed-link



> -----Original Message-----
> From: Will Deacon <will@...nel.org>
> Sent: Friday, July 28, 2023 10:36 AM
> To: Russell King (Oracle) <linux@...linux.org.uk>
> Cc: Andrew Halaney <ahalaney@...hat.com>; Shenwei Wang
> <shenwei.wang@....com>; David S. Miller <davem@...emloft.net>; Eric
> Dumazet <edumazet@...gle.com>; Jakub Kicinski <kuba@...nel.org>; Paolo
> Abeni <pabeni@...hat.com>; Maxime Coquelin
> <mcoquelin.stm32@...il.com>; Shawn Guo <shawnguo@...nel.org>; Sascha
> Hauer <s.hauer@...gutronix.de>; Neil Armstrong <neil.armstrong@...aro.org>;
> Kevin Hilman <khilman@...libre.com>; Vinod Koul <vkoul@...nel.org>; Chen-
> Yu Tsai <wens@...e.org>; Jernej Skrabec <jernej.skrabec@...il.com>; Samuel
> Holland <samuel@...lland.org>; Giuseppe Cavallaro
> <peppe.cavallaro@...com>; Alexandre Torgue <alexandre.torgue@...s.st.com>;
> Jose Abreu <joabreu@...opsys.com>; Pengutronix Kernel Team
> <kernel@...gutronix.de>; Fabio Estevam <festevam@...il.com>; dl-linux-imx
> <linux-imx@....com>; Jerome Brunet <jbrunet@...libre.com>; Martin
> Blumenstingl <martin.blumenstingl@...glemail.com>; Bhupesh Sharma
> <bhupesh.sharma@...aro.org>; Nobuhiro Iwamatsu
> <nobuhiro1.iwamatsu@...hiba.co.jp>; Simon Horman
> <simon.horman@...igine.com>; Bartosz Golaszewski
> <bartosz.golaszewski@...aro.org>; Wong Vee Khee <veekhee@...le.com>;
> Revanth Kumar Uppala <ruppala@...dia.com>; Jochen Henneberg
> <jh@...neberg-systemdesign.com>; netdev@...r.kernel.org; linux-stm32@st-
> md-mailman.stormreply.com; linux-arm-kernel@...ts.infradead.org; linux-
> kernel@...r.kernel.org; linux-amlogic@...ts.infradead.org; imx@...ts.linux.dev;
> Frank Li <frank.li@....com>
> Subject: [EXT] Re: [PATCH v2 net 2/2] net: stmmac: dwmac-imx: pause the TXC
> clock in fixed-link
>
> Caution: This is an external email. Please take care when clicking links or
> opening attachments. When in doubt, report the message using the 'Report this
> email' button
>
>
> On Fri, Jul 28, 2023 at 04:22:19PM +0100, Russell King (Oracle) wrote:
> > On Thu, Jul 27, 2023 at 01:36:45PM -0500, Andrew Halaney wrote:
> > > I don't have any documentation for the registers here, and as you
> > > can see I'm an amateur with respect to memory ordering based on my
> > > prior comment.
> > >
> > > But you:
> > >
> > >     1. Read intf_reg_off into variable iface
> > >     2. Write the RESET_SPEED for the appropriate mode to MAC_CTRL_REG
> > >     3. wmb() to ensure that write goes through
> >
> > I wonder about whether that wmb() is required. If the mapping is
> > device-like rather than memory-like, the write should be committed
> > before the read that regmap_update_bits() does according to the ARM
> > memory model. Maybe a bit of information about where this barrier has
> > come from would be good, and maybe getting it reviewed by the
> > arm64 barrier specialist, Will Deacon. :)
> >
> > wmb() is normally required to be paired with a rmb(), but we're not
> > talking about system memory here, so I also wonder whether wmb() is
> > the correct barrier to use.
>
> Yes, I don't think wmb() is the right thing here. If you need to ensure that the
> write to MAC_CTRL_REG has taken effect, then you'll need to go through some
> device-specific sequence which probably involves reading something back. If you
> just need things to arrive in order eventually, the memory type already gives you
> that.
>
> It's also worth pointing out that udelay() isn't necessarily ordered wrt MMIO
> writes, so that usleep_range() might need some help as well.
> Non-relaxed MMIO reads, however, _are_ ordered against a subsequent
> udelay(), so if you add the readback then this might all work out.
>

    1. Write RESET_SPEED
    2. Write 0 to MX93_GPR_ENET_QOS_INTF_MODE_MASK
    3. usleep_range()
    4. Restore MX93_GPR_ENET_QOS_CLK_GEN_EN | iface

In the above example, if a readback after step #2 could ensure sufficient time has passed
before step #4, the wmb() here should be abandoned.

Thanks,
Shenwei

> I gave a (slightly dated) talk about some of this at ELC a while back:
>
> https://www.yo/
> utube.com%2Fwatch%3Fv%3Di6DayghhA8Q&data=05%7C01%7Cshenwei.wang
> %40nxp.com%7C32396fd0396e4e46975f08db8f806680%7C686ea1d3bc2b4c6fa
> 92cd99c5c301635%7C0%7C0%7C638261553857503588%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&sdata=X5CQrQEVmUjYafYJ%2BzcnGXI9mhDT%
> 2BMzDazGHOcoomas%3D&reserved=0
>
> which might help.
>
> Will