[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5414570.Sb9uPGUboI@5cd116mnfx>
Date: Wed, 01 Nov 2023 22:42:52 +0100
From: Marco von Rosenberg <marcovr@...fnet.de>
To: Andrew Lunn <andrew@...n.ch>
Cc: Florian Fainelli <florian.fainelli@...adcom.com>,
Broadcom internal kernel review list <bcm-kernel-feedback-list@...adcom.com>,
Heiner Kallweit <hkallweit1@...il.com>, Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: phy: broadcom: Wire suspend/resume for BCM54612E
On Tuesday, October 31, 2023 1:31:11 AM CET Andrew Lunn wrote:
> Are we talking about a device which as been suspended? The PHY has
> been left running because there is no suspend callback? Something then
> triggers a resume. The bootloader then suspends the active PHY? Linux
> then boots, detects its a resume, so does not touch the hardware
> because there is no resume callback? The suspended PHY is then
> useless.
Hi Andrew,
thanks for your feedback. I guess a bit of context is missing here. The issue
has nothing to do with an ordinary suspension of the OS. The main point is
that on initial power-up, the bootloader suspends the PHY before booting
Linux. With a resume callback defined, Linux would call it on boot and make the
PHY usable. However, since there is no resume callback defined for this PHY,
Linux doesn't touch the hardware and thus the PHY is not usable.
So this specific issue is primarily solved by adding the resume callback. The
suspend callback is just added for completeness.
Does this clarify the issue? If so, I'll adjust the commit message and submit
an updated patch.
Marco
Powered by blists - more mailing lists