netdev - Re: [PATCH 3/3] mv643xx_eth: convert to phylib

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]

Date:	Thu, 18 Sep 2008 17:47:03 -0500
From:	"Andy Fleming" <afleming@...il.com>
To:	"Lennert Buytenhek" <buytenh@...tstofly.org>
Cc:	"Andy Fleming" <afleming@...escale.com>, netdev@...r.kernel.org
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 <afleming@...escale.com>
Andy
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html