Zefir Kurtisi wrote:
>Now the interesting (and new for me) part is: if I remove the at803x driver
from
>the system and use the generic phy instead, the problem does not happen (or at
>least not while running for one full day). [...]
>
Update: the failure also happened with genphy after running
On 10/20/2016 02:55 PM, Zefir Kurtisi wrote:
> [...]
>
> Now the interesting (and new for me) part is: if I remove the at803x driver
> from
> the system and use the generic phy instead, the problem does not happen (or at
> least not while running for one full day). [...]
>
Update: the failure al
On 10/19/2016 02:16 PM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> Ok then, if you can wait some days, I'll prepare and provide you a more
>> detailed
>> failure report to allow you testing if the issue happens with other NICs.
>
> That sounds great.
>
I am now able again to reproduce the issu
Zefir Kurtisi wrote:
Ok then, if you can wait some days, I'll prepare and provide you a more detailed
failure report to allow you testing if the issue happens with other NICs.
That sounds great.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc.
On 10/18/2016 02:40 PM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>
>>> I have never seen the original problem that you noticed. When I use the
>>> generic
>>> phy driver instead of the at803x driver, everything works great for me.
>>> Perhaps
>>> the problem that you noticed only occurs with t
Zefir Kurtisi wrote:
I have never seen the original problem that you noticed. When I use the generic
phy driver instead of the at803x driver, everything works great for me. Perhaps
the problem that you noticed only occurs with the Gianfar NIC?
You mean it works for you in SGMII mode without
On 10/17/2016 10:53 PM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> Anyway, since the SGMII reset is required, instead of reverting the patch in
>> full
>> I suggest to move the SGMII power down from at803x_suspend() and do a SerDes
>> power
>> cycle in at803x_resume(). Could you please test if t
Zefir Kurtisi wrote:
Anyway, since the SGMII reset is required, instead of reverting the patch in
full
I suggest to move the SGMII power down from at803x_suspend() and do a SerDes
power
cycle in at803x_resume(). Could you please test if the patch below fixes the
problem?
I have never seen th
On 10/15/2016 08:28 PM, Timur Tabi wrote:
> Andrew Lunn wrote:
>> 1) Take the SerDes power down out of the suspend code for the at803x.
>>
>> 2) Assume MII_PHYID1/2 registers are not guaranteed to be available
>> when the PHY is powered down. So get_phy_id should first read
>> MII_BMCR. If it gets
Andrew Lunn wrote:
1) Take the SerDes power down out of the suspend code for the at803x.
2) Assume MII_PHYID1/2 registers are not guaranteed to be available
when the PHY is powered down. So get_phy_id should first read
MII_BMCR. If it gets 0x, assume there is no PHY there. If the
PDOWN bit i
On Sat, Oct 15, 2016 at 09:39:12AM -0500, Timur Tabi wrote:
> Florian Fainelli wrote:
> >After reading the spec again, it does not appear to me that a PHY
> >with PDOWN set is guaranteed or even required to respond to other
> >register reads such as MII_PHYID1/2, in which case we may have to
> >imp
Florian Fainelli wrote:
After reading the spec again, it does not appear to me that a PHY
with PDOWN set is guaranteed or even required to respond to other
register reads such as MII_PHYID1/2, in which case we may have to
implement a MDIO bus reset routine which clears PDOWN for all PHYs
that we
On October 14, 2016 7:25:14 PM CEST, Andrew Lunn wrote:
>> 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 0x, or the BMCR_P
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
bas
On Fri, Oct 14, 2016 at 11:57:29AM -0500, Timur Tabi wrote:
> Andrew Lunn wrote:
> >That is a basic assumption of the code. If you cannot read the IDs how
> >are you supposed to know what device it is, and what quirks you need
> >to work around its broken features...
> >
> >Does the datasheet say a
Andrew Lunn wrote:
That is a basic assumption of the code. If you cannot read the IDs how
are you supposed to know what device it is, and what quirks you need
to work around its broken features...
Does the datasheet say anything about this?
I would say for this device, suspend() is too aggressi
Andrew Lunn wrote:
Does the datasheet say anything about this?
I would say for this device, suspend() is too aggressive.
I'll have to find the datasheet. Let me do some research and get back
to you. Thanks for your help so far.
--
Sent by an employee of the Qualcomm Innovation Center, Inc
On Fri, Oct 14, 2016 at 08:03:18AM -0500, Timur Tabi wrote:
> Andrew Lunn wrote:
> >Have you tried using the ethernet-phy-id device tree property? It
> >looks like that will allow you to skip get_phy_device and just create
> >the phy device. You can then bring the phy out of sleep in the probe
> >f
Andrew Lunn wrote:
Have you tried using the ethernet-phy-id device tree property? It
looks like that will allow you to skip get_phy_device and just create
the phy device. You can then bring the phy out of sleep in the probe
function?
The problem I'm experiencing is with ACPI, so I can't use any
On Fri, Oct 14, 2016 at 07:49:56AM -0500, Timur Tabi wrote:
> Andrew Lunn wrote:
> >So are you seeing that the reads to MII_PHYSID1 and MII_PHYSID2 return
> >0x, when called from get_phy_id()?
Have you tried using the ethernet-phy-id device tree property? It
looks like that will allow you to s
> It's the at803x driver.
The at803x_resume() just does normal MDIO transactions. Which suggests
the MDIO bus side of the device is still away. Or at least, the
MII_BMCR register is.
So are you seeing that the reads to MII_PHYSID1 and MII_PHYSID2 return
0x, when called from get_phy_id()?
Andrew Lunn wrote:
So are you seeing that the reads to MII_PHYSID1 and MII_PHYSID2 return
0x, when called from get_phy_id()?
Yes.
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Fo
Andrew Lunn wrote:
Please can you tell us what PHY which is, and how it is put to sleep
and woken up.
It's the at803x driver.
http://lxr.free-electrons.com/source/drivers/net/phy/at803x.c
It goes to sleep in its at803x_suspend() function, which is called by
phy_suspend().
There is a corres
On Fri, Oct 14, 2016 at 06:38:47AM -0500, Timur Tabi wrote:
> Andrew Lunn wrote:
> >Normally, a sleeping PHY does respond to MDIO. Otherwise, how do you
> >wake it?
> >
> >So i assume this phy has some other means to wake it. What is this
> >means?
>
> I'm guessing that someone has to call phy_res
Andrew Lunn wrote:
Normally, a sleeping PHY does respond to MDIO. Otherwise, how do you
wake it?
So i assume this phy has some other means to wake it. What is this
means?
I'm guessing that someone has to call phy_resume() before/during the
call to mdiobus_register, but I don't see how that's
On Thu, Oct 13, 2016 at 06:15:39PM -0500, Timur Tabi wrote:
> I need help with a program I've discovered with my driver
> (ethernet/qualcomm/emac/) that occurs in the following process:
>
> 1. Load the driver
> 1a. Driver calls mdiobus_register (see emac_phy_config), which calls
> mdiobus_scan(),
I need help with a program I've discovered with my driver
(ethernet/qualcomm/emac/) that occurs in the following process:
1. Load the driver
1a. Driver calls mdiobus_register (see emac_phy_config), which calls
mdiobus_scan(), which calls get_phy_device()
1b. get_phy_device() performs MDIO bus o
27 matches
Mail list logo
