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  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]
Date:	Thu, 18 Sep 2008 17:47:03 -0500
From:	"Andy Fleming" <>
To:	"Lennert Buytenhek" <>
Cc:	"Andy Fleming" <>,
Subject: Re: [PATCH 3/3] mv643xx_eth: convert to phylib

> I'll make this function:
>        static void phy_init(struct mv643xx_eth_private *mp, int speed, int duplex)
>        {
>                struct phy_device *phy = mp->phy;
>                phy_reset(mp);
>                phy_attach(mp->dev, phy->dev.bus_id, 0, PHY_INTERFACE_MODE_GMII);
>                phy->state = PHY_HALTED;
>                if (speed == 0) {
>                        phy->autoneg = AUTONEG_ENABLE;
>                        phy->speed = 0;
>                        phy->duplex = 0;
>                        phy->advertising = phy->supported | ADVERTISED_Autoneg;
>                } else {
>                        phy->autoneg = AUTONEG_DISABLE;
>                        phy->advertising = 0;
>                        phy->speed = speed;
>                        phy->duplex = duplex;
>                }
>                phy_start_aneg(phy);
>        }
> OK?  (PHY_HALTED because that seems to be the way to stop the state
> machine from running at all.  Or should I call phy_stop() once?)

You don't need to disable the state machine.  With phy_attach, it
won't start unless you call phy_start_machine().  So the state changes
won't cause the state machine to run.  If the state information is
interfering with things, let me know.  We might have to create a state
for "state machine is not actually running".

>> You will, however, need to
>> figure out how best to read out the status for the PHY, and how to
>> know when autonegotiation is done.  I'm assuming that your controller
>> tracks that information, and that you can manually pull that
>> information from local register space (rather than the SMI bus).
> I don't really need to access it all during normal operation -- the
> controller just reads the link up/down and speed and duplex bits from
> the PHY automatically and then configures itself accordingly.  The
> only time I need to access this information is when someone asks for
> it via ethtool (or if I want to print a link status message).  I.e. I
> don't need any state machine, be it phylib's or my own.

Right, but doesn't your driver react to the link going up and down by
changing the carrier state?  If so, then it costs nothing to cache
that state in the phydev->link, and then a request for link status can
just return phydev->link.  Those are decisions you can make, though,
as I'm not familiar with your device and your driver.

If you could check those things, you can submit the patch with:

Acked-by: Andy Fleming <>
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists