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:
 <AM5PR04MB313940F68C4817BEEC2377E78813A@AM5PR04MB3139.eurprd04.prod.outlook.com>
Date: Thu, 10 Aug 2023 03:38:16 +0000
From: Wei Fang <wei.fang@....com>
To: Andrew Lunn <andrew@...n.ch>
CC: Oleksij Rempel <o.rempel@...gutronix.de>, Marek Vasut <marex@...x.de>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>, "David S. Miller"
	<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Heiner Kallweit
	<hkallweit1@...il.com>, Jakub Kicinski <kuba@...nel.org>, Oleksij Rempel
	<linux@...pel-privat.de>, Paolo Abeni <pabeni@...hat.com>, Russell King
	<linux@...linux.org.uk>, Clark Wang <xiaoning.wang@....com>
Subject: RE: [PATCH] net: phy: at803x: Improve hibernation support on start up

> > > Hm.. how about officially defining this PHY as the clock provider
> > > and disable PHY automatic hibernation as long as clock is acquired?
> > >
> > Sorry, I don't know much about the clock provider/consumer, but I
> > think there will be more changes if we use clock provider/consume
> mechanism.
> 
> Less changes is not always best. What happens when a different PHY is used?
> By having a clock provider in the PHY, you are defining a clear API that any
> PHY needs to provide to work with this MAC.
> 
Yes, as Russell mentioned the issue of suspend/resume, that i.MX platform uses
the RTL8211 PHY. But now I don't have a clear idea to solve this issue on dwmac
IP, the design of this IP is so different.

Cc to Clark to aware of this issue on dwmac IP.

> As Russell has point out, this is not the first time we have run into this
> problem. So far, it seems everybody has tried to solve it for just their system.
> So maybe now we should look at the whole picture and put in place a
> generic solution which can be made to work for any PHY.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ