netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Timur Tabi <timur@codeaurora.org>
To: Andrew Lunn <andrew@lunn.ch>, zefir.kurtisi@neratec.com
Cc: netdev@vger.kernel.org
Subject: Re: Need help with mdiobus_register and phy
Date: Fri, 14 Oct 2016 13:30:15 -0500	[thread overview]
Message-ID: <58012437.6010706@codeaurora.org> (raw)
In-Reply-To: <20161014172514.GA23455@lunn.ch>

Andrew Lunn wrote:

> It is normal to get the phy-mode from device tree. I've no idea what
> ACPI is supposed to do. Setting it to PHY_INTERFACE_MODE_NA means you
> assume the boot loader has correctly setup the hardware. You ACPI
> firmware might of done this, but there is no guarantee a device tree
> base bootloader has. So i would prefer not changing this.

Fair enough.  I don't think it's specified anywhere what firmware is 
supposed to do.

What about specifying PHY_INTERFACE_MODE_NA on ACPI systems, but using 
the phy-mode property on device tree systems?  That doesn't sound like a 
great idea.

>> >I don't see any other driver issue BMCR_PDOWN in their functions.  I
>> >added some printks for the PHYSID1 and PHYSID2 registers before and
>> >after BMCR_PDOWN:
>> >
>> >at803x_suspend:235 MII_PHYSID1=004d MII_PHYSID2=d074
>> >at803x_suspend:242 MII_PHYSID1=ffff MII_PHYSID2=ffff
>> >
>> >So after calling BMCR_PDOWN, the PHYSID1 and PHYSID2 registers are
>> >no longer readable.  Is that expected?
> You are making two changes here. Is it the SGMII power down which is
> causing the id registers to return 0xffff, or the BMCR_PDOWN.
>
> The generic suspend code sets the PDOWN bit, so it is assuming the PHY
> will respond afterwards.

Ok, it took me a while to figure this out.  The driver does three writes:

phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr & ~AT803X_BT_BX_REG_SEL);
phy_write(phydev, MII_BMCR, phy_read(phydev, MII_BMCR) | BMCR_PDOWN);
phy_write(phydev, AT803X_REG_CHIP_CONFIG, ccr | AT803X_BT_BX_REG_SEL);

The first clears the AT803X_BT_BX_REG_SEL bit.  According to the 
datasheet, that changes the register set from copper to fiber mode. 
BMCR_PDOWN in fiber mode shuts off the SerDes bus.  That's not true in 
copper mode.

Then after shutting down SerDes, it switches back to copper mode.

I also noticed the at803x_suspend already sends BMCR_PDOWN in copper 
mode earlier in the function.

So the question remains: should drivers shut down the SerDes bus when 
they suspend?  In a sense, I'm wondering if we should revert

	at803x: fix suspend/resume for SGMII link

However, the changelog for that patch makes it sound like it's a 
necessary fix.

So I'm torn.  With the SerDes connection disabled, the driver no longer 
responds to ID register reads.  That seems like something that would be 
broken on device tree as well, but I don't understand why no one noticed 
it before.

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

  reply	other threads:[~2016-10-14 18:46 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-13 23:15 Need help with mdiobus_register and phy Timur Tabi
2016-10-14  4:06 ` Andrew Lunn
2016-10-14 11:38   ` Timur Tabi
2016-10-14 12:06     ` Andrew Lunn
2016-10-14 12:39       ` Timur Tabi
2016-10-14 12:49         ` Andrew Lunn
2016-10-14 12:49           ` Timur Tabi
2016-10-14 12:57             ` Andrew Lunn
2016-10-14 13:03               ` Timur Tabi
2016-10-14 13:18                 ` Andrew Lunn
2016-10-14 13:28                   ` Timur Tabi
2016-10-14 16:57                   ` Timur Tabi
2016-10-14 17:25                     ` Andrew Lunn
2016-10-14 18:30                       ` Timur Tabi [this message]
2016-10-15 10:19                       ` Florian Fainelli
2016-10-15 14:39                         ` Timur Tabi
2016-10-15 18:02                           ` Andrew Lunn
2016-10-15 18:28                             ` Timur Tabi
2016-10-17  9:05                               ` Zefir Kurtisi
2016-10-17 20:53                                 ` Timur Tabi
2016-10-18 10:31                                   ` Zefir Kurtisi
2016-10-18 12:40                                     ` Timur Tabi
2016-10-19  8:55                                       ` Zefir Kurtisi
2016-10-19 12:16                                         ` Timur Tabi
2016-10-20 12:55                                           ` Zefir Kurtisi
2016-10-21  7:44                                             ` Zefir Kurtisi
2016-10-21 11:19                                               ` Timur Tabi

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=58012437.6010706@codeaurora.org \
    --to=timur@codeaurora.org \
    --cc=andrew@lunn.ch \
    --cc=netdev@vger.kernel.org \
    --cc=zefir.kurtisi@neratec.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;
as well as URLs for NNTP newsgroup(s).