Date: Sat, 21 Jan 2012 00:58:08 +0100 From: Stefan Bethke <stb@lassitu.de> To: Marius Strobl <marius@alchemy.franken.de> Cc: YongHyeon PYUN <pyunyh@gmail.com>, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: "ifconfig media off"? Message-ID: <AD7424DB-01E7-4988-BE12-835286112960@lassitu.de> In-Reply-To: <20111214011657.GH36635@alchemy.franken.de> References: <600A8C6C-DAB4-4E22-A034-38224017166B@lassitu.de> <20111213025041.GF3705@michelle.cdnetworks.com> <45B0B859-207C-4F02-A28F-7E34B775A273@lassitu.de> <20111213185348.GA7546@michelle.cdnetworks.com> <20111214011657.GH36635@alchemy.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 14.12.2011 um 02:16 schrieb Marius Strobl:
> On Tue, Dec 13, 2011 at 10:53:48AM -0800, YongHyeon PYUN wrote:
>> On Tue, Dec 13, 2011 at 11:04:51AM +0100, Stefan Bethke wrote:
>>> Am 13.12.2011 um 03:50 schrieb YongHyeon PYUN:
>>>=20
>>>> On Tue, Dec 13, 2011 at 12:56:22AM +0100, Stefan Bethke wrote:
>>>>> I'm currently writing a driver to configure an ethernet switch =
chip (see TL-WR1043ND on -embedded).
>>>>>=20
>>>>> I noticed that there doesn't seem to be a way to power down a phy =
right now through the ifconfig media command.
>>>>>=20
>>>>> Would there be objections to extend the media subtype definitions =
to include an "off", "poweroff" or "down" media subtype, and add code to =
the relevant phy drivers to power down the phy for this media subtype?
>>>>>=20
>>>>> The difference between media subtype "none" and this new one would =
be that there will be no link, even if there is a physical connection. =
With media subtype "none", a 10 MBit/s half-duplex connection is =
established, potentially confusing the remote end about the availability =
of this link. On the local side, the link is down, so no packets are =
exchanged.
>>>>>=20
>>>>=20
>>>> I think "none" means "isolated" so should have no established link
>>>> and probably you can also power down the PHY.
>>>> I vaguely guess the PHY of switch chip does not correctly support
>>>> isolated mode so you may have wanted to power down.
>>>=20
>>>=20
>>> After looking at the code a bit more, I think the common code just =
doesn't set the BMCR_PDOWN (but clears it when bringing up the PHY).
>>>=20
>>=20
>> Yes, and most PHYs could be powered down when BMCR_ISO is chosen.
>> I'm not sure whether this could be applied to hardwares that
>> support multiple PHYs(i.e. internal and external transceivers)
>> though. Marius may have some opinions on this(CCed).
>> However powering down PHY with BMCR_ISO looks natural to me.
>>=20
>>> Index: sys/dev/mii/mii_physubr.c
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> --- sys/dev/mii/mii_physubr.c (revision 228402)
>>> +++ sys/dev/mii/mii_physubr.c (working copy)
>>> @@ -58,7 +58,7 @@
>>> */
>>> static const struct mii_media mii_media_table[MII_NMEDIA] =3D {
>>> /* None */
>>> - { BMCR_ISO, ANAR_CSMA,
>>> + { BMCR_ISO | BMCR_PDOWN, ANAR_CSMA,
>>> 0, },
>>>=20
>>> /* 10baseT */
>>>=20
>>> I've opened kern/163240.
>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163240
I'd like to revisit this. Just to reiterate my motivation for the =
change: I want to be able to indicate to the remote end that my station =
is not active. With the PHY just isolated from the MII, the link stays =
up and functional (and even autoneg continues to work), so the remote =
has no indication that it's just shouting into a void.
> I don't think powering down the PHY along with IFM_NONE especially
> in that way is a good idea for several reasons:
> - It's incomplete as not all PHY drivers use mii_phy_add_media()/
> mii_phy_setmedia().
> - Even for those that do IFM_NONE isn't added when the PHY driver
> sets MIIF_NOISOLATE (for some PHYs BMCR_ISO either just doesn't
> work as especially the built-in ones probably have been designed
> with only single-PHY configurations in mind or even wedges the
> chip up to the point that even a reset doesn't get it working
> again). In general though, BMCR_ISO and BMCR_PDOWN are orthogonal
> (even in IEEE 802.3-2008 as far as I can see), i.e. while BMCR_ISO
> might be broken, BMCR_PDOWN could work (actually I'd expect
> BMCR_PDOWN to be less fragile than BMCR_ISO).
I didn't expect my suggestion to be the be-all end-all, only a quick and =
easy way to allow compliant PHYs to be powered down, and I'm not sure =
why a "complete" solution is required. I'd assume that PHYs setting =
MIIF_NOISOLATE have specific requirements, so it's OK to not have the =
power-down option available there. (Plus I don't have hardware I could =
test that case on).
> - There should be a way to let a PHY driver do something different
> than setting BMCR_PDOWN when it's told to power down as f.e. at
> least some Broadcom PHYs support a "super isolation" mode.
Cool, but how does my suggestion stop anyone from implementing that?
> - As you already mentioned in general there can be multiple PHYs
> on one MII bus and I'd expect "power down that interface" to
> mean to power all of them down (granted, MACs with multiple
> PHYs are rather uncommon in reality but they do exist, f.e.
> Allied Telesis has several card models that use two PHYs per
> MAC).
Since there can be only one active PHY at a time, it could make sense to =
also set PDOWN in mii_mediachg(). How about a new flag MIIF_PDOWN that =
the phy driver can set to indicate that it would rather be shut off than =
just isolated? Right now I only care about ukphy anyway.
> In generall I agree that there should be a way to power down PHYs
> though. While there might be some merit in additionally adding that
> as a media option I think that the most intuitive way would be for
> `ifconfig foo0 down` to also power down the PHYs on that interface.
> In order implement that the basic way seems to be to make the
> various foo_stop() methods of MAC drivers to call mii_down() (as
> in NetBSD) and to make mii_phy_down() (or a replacement) actually
> do something, with PHY drivers being allowed to opt-out with
> something like a MIIF_NOPOWERDOWN. What I'm not sure about is how
> to implement power down in the individual drivers while keeping
> code duplication for the common case low, i.e. I'm not sure whether
> the NetBSD way of having a MII_DOWN case in the service routines
> is the way to go.
I'm hesitant to tie IFF_UP to link state. Is there precedent for that? =
My gut feeling is that IFF_UP has always meant that the interface has =
been brought up administratively; bringing an interface down "only" =
means that the system should not transmit on it and discard received =
frames.
> Is there something in the rc.d scripts that downs network
> interfaces on shutdown that could interfere with WOL when we
> power down the PHYs?
I don't think so, but I've never looked in detail. I believe that =
interfaces are brought down on shutdown by the kernel, though.
Stefan
--=20
Stefan Bethke <stb@lassitu.de> Fon +49 151 14070811
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AD7424DB-01E7-4988-BE12-835286112960>