All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dinh Nguyen <dinguyen@opensource.altera.com>
To: David Daney <ddaney@caviumnetworks.com>,
	Florian Fainelli <f.fainelli@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>, <david.daney@cavium.com>,
	<netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: SoCFPGA ethernet broken
Date: Thu, 15 Oct 2015 15:49:28 -0500	[thread overview]
Message-ID: <56201158.8040806@opensource.altera.com> (raw)
In-Reply-To: <56200E15.9080603@caviumnetworks.com>

On 10/15/2015 03:35 PM, David Daney wrote:
> On 10/15/2015 01:25 PM, Florian Fainelli wrote:
>> On 15/10/15 12:59, Dinh Nguyen wrote:
>>> On 10/15/2015 03:03 PM, Florian Fainelli wrote:
>>>> On 15/10/15 12:09, Dinh Nguyen wrote:
>>>>> Hi,
>>>>>
>>>>> commit "8b63ec1837fa phylib: Make PHYs children of their MDIO bus, not
>>>>> the bus' parent." seems to have broken ethernet support for the
>>>>> SoCFPGA
>>>>> platform which is using the stmmac ethernet driver.
>>>>
>>>> It is not clear to me how this relates to what you are seeing yet.
>>>>
>>>>>
>>>>> It appears that during DHCP, it cannot get an IP address. This only
>>>>> happens if ethernet was not used by the bootloader to tftp an kernel
>>>>> image. If I use the bootloader to tftp an image then ethernet is
>>>>> working
>>>>> fine. So I think the PHY is not getting enabled properly.
>>>>>
>>>>> If I revert this patch, then ethernet is back to working on the
>>>>> platform.
>>>>
>>>> Is the Device Tree source for this platform available somewhere to
>>>> look at?
>>>>
>>>
>>> Yes, I'm using the DTS that is in the mainline:
>>>
>>> arch/arm/boot/dts/socfpga.dtsi
>>> arch/arm/boot/dts/socfpga_cyclone5.dtsi
>>> arch/arm/boot/dts/socfpga_cyclone5_socdk.dts
>>
>> There are no PHY devices in any of these DTS files, instead there is the
>> non-standard "phy-addr" property which is set to 0xffffffff supposedly
>> to indicate that the MDIO bus should be scanned. This is likely part of
>> your problem. The stmmac driver seems to be looking for "snps,phy-addr"
>> and not "phy-addr", so I am not even clear how this is supposed to work,
>> and the driver mentions this custom property is deprecated anyway.
>>
> 
> I think it is OK not to expose the PHYs in the device tree if they can
> be accurately probed without knowing information from the device tree.
> 
>> The core problem is in
>> drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c::stmmac_mdio_register
>> which manually detects the PHY, that is mostly fine, except that it does
>> not really seem to work here for a reason that is still unclear to me.
>>
> 
> I agree with this analysis.  I have also been looking at the code and
> cannot see anything that depends on what the parent device of the PHY
> is.  So it is a bit mystifying.
> 
> 
> I noticed in your original message you had in the boot log this:
> 
> .
> .
> .
> [    0.804992] libphy: stmmac: probed
> [    0.808410] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active
> .
> .
> .
> 
> Does this text change with and without the 8b63ec1837fa patch?

No, this text does not change with/without the 8b63ec1837fa patch.

Dinh


  reply	other threads:[~2015-10-15 20:56 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-15 19:09 SoCFPGA ethernet broken Dinh Nguyen
2015-10-15 20:03 ` Florian Fainelli
2015-10-15 19:59   ` Dinh Nguyen
2015-10-15 20:25     ` Florian Fainelli
2015-10-15 20:35       ` David Daney
2015-10-15 20:49         ` Dinh Nguyen [this message]
2015-10-15 21:30           ` Florian Fainelli
2015-10-16  2:32             ` Dinh Nguyen
2015-10-16  3:31               ` Andrew Lunn
2015-10-16 14:38                 ` Dinh Nguyen
2015-10-16 15:03                   ` Andrew Lunn
2015-10-16 15:31                     ` Dinh Nguyen
2015-10-16 15:56                       ` Andrew Lunn
2015-10-16 16:47                         ` David Daney
2015-10-16 19:10                           ` Dinh Nguyen
2015-10-16 19:38                             ` Andrew Lunn
2015-10-16 20:24                               ` David Daney
2015-10-16 20:29                                 ` Andrew Lunn
2015-10-19 15:14                               ` Dinh Nguyen
2015-10-19 10:50                                 ` Dinh Nguyen
2015-10-16 18:17                         ` Florian Fainelli
2015-10-16  3:04             ` Dinh Nguyen
2015-12-03 20:48       ` Pavel Machek
2015-12-03 21:23         ` David Daney
2015-12-03 23:17           ` Dinh Nguyen
2015-12-04  1:10             ` Andrew Lunn
2015-12-04  1:50               ` Andrew Lunn
2015-12-04 11:27                 ` Dinh Nguyen
2015-12-04 14:31                   ` Andrew Lunn
2015-12-04  9:38           ` Pavel Machek

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=56201158.8040806@opensource.altera.com \
    --to=dinguyen@opensource.altera.com \
    --cc=davem@davemloft.net \
    --cc=david.daney@cavium.com \
    --cc=ddaney@caviumnetworks.com \
    --cc=f.fainelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.