From: Andrew Lunn <andrew@lunn.ch>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
kernel@pengutronix.de, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, netdev@vger.kernel.org,
paskripkin@gmail.com
Subject: Re: net: asix: best way to handle orphan PHYs
Date: Wed, 9 Mar 2022 14:31:18 +0100 [thread overview]
Message-ID: <YiisJogt/WO5gLId@lunn.ch> (raw)
In-Reply-To: <20220309121835.GA15680@pengutronix.de>
On Wed, Mar 09, 2022 at 01:18:35PM +0100, Oleksij Rempel wrote:
> Hello all,
>
> I have ASIX based USB Ethernet adapter with two PHYs: internal and
> external. The internal PHY is enabled by default and there seems to be
> no way to disable internal PHY on the MAC level without affecting the
> external PHY.
>
> What is the preferred method to suspend internal PHY?
> Currently I have following options:
> - suspend PHY in the probe function of the PHY driver
> - get the phydev in the MAC driver and call phy_suspend()
> - whisper magic numbers from the MAC driver directly this the MDIO bus.
>
> Are there other options?
Hi Oleksij
Can you unique identity this device? Does it have a custom VID:PID?
It seems like suspending it in the PHY driver would be messy. How do
you identify the PHY is part of your devices and should be suspended?
Doing it from the MAC driver seems better, your identification
information is close to hand.
I would avoid the magic numbers, since phy_suspend() makes it clear
what you are doing.
Is there one MDIO bus with two devices, or two MDIO busses? If there
are two busses, you could maybe add an extra flag to the bus structure
you pass to mdiobus_register() which indicates it should suspend all
PHY it finds on the bus during enumeration of the bus. Generally we
don't want this, if the PHY has link already we want to keep it, to
avoid the 1.5s delay causes by autoneg. But if we know the PHYs on the
bus are not going to be used, it would be a good point to suspend
them.
Andrew
next prev parent reply other threads:[~2022-03-09 13:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 12:18 net: asix: best way to handle orphan PHYs Oleksij Rempel
2022-03-09 13:31 ` Andrew Lunn [this message]
2022-03-09 14:45 ` Oleksij Rempel
2022-03-09 15:57 ` Andrew Lunn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YiisJogt/WO5gLId@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=hkallweit1@gmail.com \
--cc=kernel@pengutronix.de \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
--cc=paskripkin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox