netdev - Re: [BUG] SIOCSIFFLAGS returns -EIO on SMSC LAN911x

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] [day] [month] [year] [list]

Message-ID: <CAAwP0s36dvw7d5LLs4LGZ8_ANiCHpCSWLSrUObF6thziY9JpsQ@mail.gmail.com>
Date:	Tue, 3 Jan 2012 08:44:25 +0100
From:	Javier Martinez Canillas <martinez.javier@...il.com>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	netdev@...r.kernel.org,
	Enric Balletbo i Serra <eballetbo@...ebcn.com>
Subject: Re: [BUG] SIOCSIFFLAGS returns -EIO on SMSC LAN911x

On Mon, Jan 2, 2012 at 8:45 PM, Ben Hutchings <ben@...adent.org.uk> wrote:
> On Mon, 2012-01-02 at 19:37 +0100, Javier Martinez Canillas wrote:
> [...]
>> Thanks for your help.
>>
>> Finally, what I did was to bring to operational mode the integrated
>> PHY chip by disabling the energy detect power-down mode before doing a
>> software reset and re-enabling after it.
>>
>> Does that solution make sense to you? I've sent the patch-set to the
>> list for review. The patch-set is composed of the following patches:
> [...]
>
> I think that if the data sheet says the power-down bit is reserved on
> the 9221i then it is better not to set it at all.  However, given that
> you actually have hardware to test on, you are in a better position to
> say what actually works.
>
> Ben.
>

Hello Ben,

I didn't find on the LAN9221/LAN9221i data-sheet where it says that
this bit 0x17.13 is reserved.

In fact if you look at Section 5.5 "PHY Registers" (page 117) you will
see that the PHY register 0x17 "Mode Control/Status Register" (page
122) is a valid PHY register address and can be used to enable and
disable the Energy Detect Power-Down mode by writing to the bit-field
13 (EDPWRDOWN). Also a functional description of this behavior is
explanied in Section "3.10.3.2 Energy Detect Power-Down" (page 47).

Since in drivers/net/phy/smsc.c the phy is initialized with:

#define MII_LAN83C185_CTRL_STATUS 17 /* Mode/Status Register */
#define MII_LAN83C185_EDPWRDOWN (1 << 13) /* EDPWRDOWN */

static int smsc_phy_config_init(struct phy_device *phydev)
{
        int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
        if (rc < 0)
                return rc;

        /* Enable energy detect mode for this SMSC Transceivers */
        rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
                       rc | MII_LAN83C185_EDPWRDOWN);
        if (rc < 0)
                return rc;

        return smsc_phy_ack_interrupt (phydev);
}

I think that the enabling of the Energy Detect Power-Down mode is correct.

On section 5.3.9 "HW_CFG—Hardware Configuration Register" it says that:

"Soft Reset Timeout (SRST_TO). If a software reset is attempted when
the PHY is not in the operational state (RX_CLK and TX_CLK running),
the reset will not
complete and the soft reset operation will timeout and this bit will
be set to a ‘1’."

Is exactly the behavior we have when the PHY is in low power mode
because the energy detect power-down mode is enabled and no energy is
detected.

That's why I thought to use the bit-field EDPWRDOWN to disable the
energy detect power-down mode before making the software reset. This
brings the PHY to operational mode so the software reset never fails.
After the software reset was successful we can re-enable the energy
detect power-down mode to take advantage of the automatic energy
detection supported by the device.

I have tested on the hardware and seems to work properly, but I don't
know if is the best approach.

Best regards,

-- 
Javier Martínez Canillas
(+34) 682 39 81 69
Barcelona, Spain
--
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