All of lore.kernel.org
 help / color / mirror / Atom feed
* Fwd: Davicom DM9162 PHY supported in the kernel?
       [not found] <CAOLz05qgn2-9Qxm1cR7mXa67GAwD2SGbMnbeeEBrYeSPsBexuw@mail.gmail.com>
@ 2016-04-20 15:25 ` Amr Bekhit
  2016-04-20 18:03 ` Florian Fainelli
  1 sibling, 0 replies; 13+ messages in thread
From: Amr Bekhit @ 2016-04-20 15:25 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev

(Sorry, repeat message due to the previous one being HTML)

Hello,

I'm using an embedded Linux board based on an AT91SAM9X25 that uses
the Davicom DM9162IEP PHY chip. I'm struggling to get packets out on
the wire and I'm suspecting that I might have an issue between the
AT91 MAC and the PHY chip. I've looked through the kernel config
options and the kernel already has compiled-in support for the Davicom
PHYs, however I noticed that according to the help text, only the
dm9161e and dm9131 chips are supported, which may indicate why my
ethernet isn't working. I was wondering whether the DM9162 is
backwards compatible with the existing driver? I'm currently using the
mainline kernel 4.3. (p.s. I know the hardware works fine since I have
no problem transferring files using tftp via u-boot).

Thanks,

Amr Bekhit

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
       [not found] <CAOLz05qgn2-9Qxm1cR7mXa67GAwD2SGbMnbeeEBrYeSPsBexuw@mail.gmail.com>
  2016-04-20 15:25 ` Fwd: Davicom DM9162 PHY supported in the kernel? Amr Bekhit
@ 2016-04-20 18:03 ` Florian Fainelli
  2016-05-03 14:38   ` Amr Bekhit
  1 sibling, 1 reply; 13+ messages in thread
From: Florian Fainelli @ 2016-04-20 18:03 UTC (permalink / raw)
  To: Amr Bekhit; +Cc: netdev, andrew

Hi,

On 20/04/16 08:21, Amr Bekhit wrote:
> Hello,
> 
> I'm using an embedded Linux board based on an AT91SAM9X25 that uses the
> Davicom DM9162IEP PHY chip. I'm struggling to get packets out on the
> wire and I'm suspecting that I might have an issue between the AT91 MAC
> and the PHY chip. I've looked through the kernel config options and the
> kernel already has compiled-in support for the Davicom PHYs, however I
> noticed that according to the help text, only the dm9161e and dm9131
> chips are supported, which may indicate why my ethernet isn't working. I
> was wondering whether the DM9162 is backwards compatible with the
> existing driver? I'm currently using the mainline kernel 4.3. (p.s. I
> know the hardware works fine since I have no problem transferring files
> using tftp via u-boot).

Well, u-boot is a very simplistic networking stack, there could be tons
of issues that get under the radar because it cannot report them
properly, but let's assume it works so you have something to compare
against.

The DM9162 should be very similar to the DM9161, so the first thing
might be trying to add the PHY ID (32-bits OUI) to the matching table in
drivers/net/phy/davicom.c, and make it configure the PHY through
dm9161_config_init() since that looks at the PHY interface (MII, RMII
etc.) and does a bit of configuration here.

Right now, chances are that you are running with the Generic PHY driver
which has no clue about Davicom specific programming (if any). There
could also be board-level fixups required (adjusting trace lengths, if
you are using a RGMII interface for instance), etc.
-- 
Florian

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-04-20 18:03 ` Florian Fainelli
@ 2016-05-03 14:38   ` Amr Bekhit
  2016-05-03 15:36     ` Andrew Lunn
  0 siblings, 1 reply; 13+ messages in thread
From: Amr Bekhit @ 2016-05-03 14:38 UTC (permalink / raw)
  To: Florian Fainelli; +Cc: netdev, andrew

Hi Florian,

Thanks for your response. I had look through the bootup messages on my
Linux board and saw the following:

[    5.398437] libphy: MACB_mii_bus: probed
[    5.484375] macb f802c000.ethernet eth0: Cadence MACB rev
0x0001010c at 0xf802c000 irq 39 (70:b3:d5:ba:b8:90)
[    5.492187] macb f802c000.ethernet eth0: attached PHY driver
[Davicom DM9161A] (mii_bus:phy_addr=f802c000.etherne:00, irq=-1)

So it appears that the DM9161A driver is already being loaded for the
DM9162. I checked through the datasheet for the DM9162 and I confirmed
that the OUI was indeed the same as the one for the DM9161A. I can
only imagine that the company would do that because they are
compatible with each other. They are pin to pin compatible as well. As
you said, it's likely the existing PHY driver is compatible.

The reason why I suspected the PHY is because I have an embedded
system where I cannot seem to get any ethernet packets out from (see:
http://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/no-response-to-dhcp-discover-packets-sent-on-eth0-4175577259/).
One thing that was suggested to me was whether there was a problem
with the link between the MAC and PHY, which is what lead me to look
at the PHY drivers in Linux and hence this question.

Any ideas as to why I can't get any packets out? Is there a way for me
to test whether there is an issue between the MAC and PHY?

Thanks,

Amr


On 20 April 2016 at 19:03, Florian Fainelli <f.fainelli@gmail.com> wrote:
> Hi,
>
> On 20/04/16 08:21, Amr Bekhit wrote:
>> Hello,
>>
>> I'm using an embedded Linux board based on an AT91SAM9X25 that uses the
>> Davicom DM9162IEP PHY chip. I'm struggling to get packets out on the
>> wire and I'm suspecting that I might have an issue between the AT91 MAC
>> and the PHY chip. I've looked through the kernel config options and the
>> kernel already has compiled-in support for the Davicom PHYs, however I
>> noticed that according to the help text, only the dm9161e and dm9131
>> chips are supported, which may indicate why my ethernet isn't working. I
>> was wondering whether the DM9162 is backwards compatible with the
>> existing driver? I'm currently using the mainline kernel 4.3. (p.s. I
>> know the hardware works fine since I have no problem transferring files
>> using tftp via u-boot).
>
> Well, u-boot is a very simplistic networking stack, there could be tons
> of issues that get under the radar because it cannot report them
> properly, but let's assume it works so you have something to compare
> against.
>
> The DM9162 should be very similar to the DM9161, so the first thing
> might be trying to add the PHY ID (32-bits OUI) to the matching table in
> drivers/net/phy/davicom.c, and make it configure the PHY through
> dm9161_config_init() since that looks at the PHY interface (MII, RMII
> etc.) and does a bit of configuration here.
>
> Right now, chances are that you are running with the Generic PHY driver
> which has no clue about Davicom specific programming (if any). There
> could also be board-level fixups required (adjusting trace lengths, if
> you are using a RGMII interface for instance), etc.
> --
> Florian

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-03 14:38   ` Amr Bekhit
@ 2016-05-03 15:36     ` Andrew Lunn
  2016-05-09 10:01       ` Amr Bekhit
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Lunn @ 2016-05-03 15:36 UTC (permalink / raw)
  To: Amr Bekhit; +Cc: Florian Fainelli, netdev

> Any ideas as to why I can't get any packets out? Is there a way for me
> to test whether there is an issue between the MAC and PHY?

Does it perform auto-negotiate? If it does, the PHY to the cable is
probably O.K.

Have you checked the status bits. Loopback, Power down, Isolate?

     Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-03 15:36     ` Andrew Lunn
@ 2016-05-09 10:01       ` Amr Bekhit
  2016-05-09 12:06         ` Andrew Lunn
  0 siblings, 1 reply; 13+ messages in thread
From: Amr Bekhit @ 2016-05-09 10:01 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Florian Fainelli, netdev

Hi Andrew,

Based on the information I pasted below, it appears that
autonegotiation is working - the device detects that there is a link
partner connected and ethtool reports back the various link modes that
can be used. I'm not sure about the status bits - I couldn't find out
how I would check them.

The test results are as follows - I've carried out the following test
on a freshly booted system with the ethernet cable initially
unplugged:

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 70:B3:D5:BA:B8:90
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:39 Base address:0xc000
# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: Unknown!
        Duplex: Unknown! (255)
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Link detected: no

--------------------------------------------------------------------
Now the ethernet cable is plugged in and the network interface brought up:

# ifconfig eth0 up
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
# macb f802c000.ethernet eth0: link up (100/Full)
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 70:B3:D5:BA:B8:90
          inet6 addr: fe80::72b3:d5ff:feba:b890%3068527384/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:39 Base address:0xc000

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
        Link partner advertised pause frame use: Symmetric Receive-only
        Link partner advertised auto-negotiation: Yes
        Speed: 100Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 0
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes

-------------------------------------------------
Setting a static IP

# ifconfig eth0 192.168.100.200
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 70:B3:D5:BA:B8:90
          inet addr:192.168.100.200  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::72b3:d5ff:feba:b890%3067806488/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:39 Base address:0xc000

------------------------------------------------
Trying to ping and arping (I ctrl+C out of it after a while, as I do
not get any output):

# ping 192.168.100.100
PING 192.168.100.100 (192.168.100.100): 56 data bytes
^C
--- 192.168.100.100 ping statistics ---
24 packets transmitted, 0 packets received, 100% packet loss

# arping 192.168.100.100
ARPING to 192.168.100.100 from 192.168.100.200 via eth0
^CSent 19 probe(s) (19 broadcast(s))
Received 0 reply (0 request(s), 0 broadcast(s))


On 3 May 2016 at 16:36, Andrew Lunn <andrew@lunn.ch> wrote:
>> Any ideas as to why I can't get any packets out? Is there a way for me
>> to test whether there is an issue between the MAC and PHY?
>
> Does it perform auto-negotiate? If it does, the PHY to the cable is
> probably O.K.
>
> Have you checked the status bits. Loopback, Power down, Isolate?
>
>      Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-09 10:01       ` Amr Bekhit
@ 2016-05-09 12:06         ` Andrew Lunn
  2016-05-24 16:09           ` Amr Bekhit
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Lunn @ 2016-05-09 12:06 UTC (permalink / raw)
  To: Amr Bekhit; +Cc: Florian Fainelli, netdev

Hi Amr

Please don't top post.

> Based on the information I pasted below, it appears that
> autonegotiation is working - the device detects that there is a link
> partner connected and ethtool reports back the various link modes that
> can be used.

This suggests the PHY to cable is O.K. and your problem is between the
MAC and the PHY.

> I'm not sure about the status bits - I couldn't find out how I would
> check them.

How about adding a printk() in genphy_read_status().

    Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-09 12:06         ` Andrew Lunn
@ 2016-05-24 16:09           ` Amr Bekhit
  2016-05-24 16:30             ` Andrew Lunn
  0 siblings, 1 reply; 13+ messages in thread
From: Amr Bekhit @ 2016-05-24 16:09 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Florian Fainelli, netdev

Hi Andrew,

> How about adding a printk() in genphy_read_status().

Would you be able to point me to some more information about these
status bits, please? I'm struggling to find information about what
they are, where I read them from, etc. I'm happy to write some debug
printk's in the code, I just don't know where to get information about
these status bits.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-24 16:09           ` Amr Bekhit
@ 2016-05-24 16:30             ` Andrew Lunn
  2016-05-25 10:28               ` Amr Bekhit
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Lunn @ 2016-05-24 16:30 UTC (permalink / raw)
  To: Amr Bekhit; +Cc: Florian Fainelli, netdev

On Tue, May 24, 2016 at 05:09:35PM +0100, Amr Bekhit wrote:
> Hi Andrew,
> 
> > How about adding a printk() in genphy_read_status().
> 
> Would you be able to point me to some more information about these
> status bits, please?

You can get the datasheet from here:

http://www.davicom.com.tw/userfile/24247/DM9162_DM9162I-12-MCO-DS-F01_08062014.pdf

I would start by looking at the BMCR register. The
genphy_read_status() function should get called about once per second,
so that is an O.K. place to add debug prints, and there is example
code for reading MII_BMCR.

     Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-24 16:30             ` Andrew Lunn
@ 2016-05-25 10:28               ` Amr Bekhit
  2016-05-25 12:39                 ` Andrew Lunn
  0 siblings, 1 reply; 13+ messages in thread
From: Amr Bekhit @ 2016-05-25 10:28 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Florian Fainelli, netdev

Hi Andrew,

I added the following line to genphy_read_status to print out the value of BMCR:

 phydev->lp_advertising = 0;

+printk(KERN_DEBUG "MII_BMCR: 0x%04X\n", phy_read(phydev, MII_BMCR));

 if (AUTONEG_ENABLE == phydev->autoneg) {

After booting up the kernel and running ifconfig eth0 up, I get the
following in kernel log:

[   83.890625] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   85.328125] MII_BMCR: 0x1000
[   86.328125] MII_BMCR: 0x1000
[   87.328125] MII_BMCR: 0x3100
[   87.328125] macb f802c000.ethernet eth0: link up (100/Full)
[   87.328125] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   88.328125] MII_BMCR: 0x3100
[   89.328125] MII_BMCR: 0x3100
[   90.328125] MII_BMCR: 0x3100

So it appears that after bringing the interface up, the PHY is
configured for 100Mbps, autoneg enabled and duplex mode. The PHY is
not isolated or powered down.

On 24 May 2016 at 17:30, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, May 24, 2016 at 05:09:35PM +0100, Amr Bekhit wrote:
>> Hi Andrew,
>>
>> > How about adding a printk() in genphy_read_status().
>>
>> Would you be able to point me to some more information about these
>> status bits, please?
>
> You can get the datasheet from here:
>
> http://www.davicom.com.tw/userfile/24247/DM9162_DM9162I-12-MCO-DS-F01_08062014.pdf
>
> I would start by looking at the BMCR register. The
> genphy_read_status() function should get called about once per second,
> so that is an O.K. place to add debug prints, and there is example
> code for reading MII_BMCR.
>
>      Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-25 10:28               ` Amr Bekhit
@ 2016-05-25 12:39                 ` Andrew Lunn
  2016-05-25 13:20                   ` Amr Bekhit
  0 siblings, 1 reply; 13+ messages in thread
From: Andrew Lunn @ 2016-05-25 12:39 UTC (permalink / raw)
  To: Amr Bekhit; +Cc: Florian Fainelli, netdev

On Wed, May 25, 2016 at 11:28:37AM +0100, Amr Bekhit wrote:
> Hi Andrew,
> 
> I added the following line to genphy_read_status to print out the value of BMCR:
> 
>  phydev->lp_advertising = 0;
> 
> +printk(KERN_DEBUG "MII_BMCR: 0x%04X\n", phy_read(phydev, MII_BMCR));
> 
>  if (AUTONEG_ENABLE == phydev->autoneg) {
> 
> After booting up the kernel and running ifconfig eth0 up, I get the
> following in kernel log:
> 
> [   83.890625] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   85.328125] MII_BMCR: 0x1000
> [   86.328125] MII_BMCR: 0x1000
> [   87.328125] MII_BMCR: 0x3100
> [   87.328125] macb f802c000.ethernet eth0: link up (100/Full)
> [   87.328125] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
> [   88.328125] MII_BMCR: 0x3100
> [   89.328125] MII_BMCR: 0x3100
> [   90.328125] MII_BMCR: 0x3100
> 
> So it appears that after bringing the interface up, the PHY is
> configured for 100Mbps, autoneg enabled and duplex mode. The PHY is
> not isolated or powered down.

So this all looks good. So it suggests your problem is between the MAC
and the PHY, since the PHY is able to talk to the PHY on the other end
of the cable.

What do you have in device tree?

     Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-25 12:39                 ` Andrew Lunn
@ 2016-05-25 13:20                   ` Amr Bekhit
  2016-05-25 14:00                     ` Amr Bekhit
  2016-05-25 14:03                     ` Andrew Lunn
  0 siblings, 2 replies; 13+ messages in thread
From: Amr Bekhit @ 2016-05-25 13:20 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Florian Fainelli, netdev

Hi Andrew,

I've uploaded the device tree to http://pastebin.com/tNp2PnW4.

On 25 May 2016 at 13:39, Andrew Lunn <andrew@lunn.ch> wrote:
> On Wed, May 25, 2016 at 11:28:37AM +0100, Amr Bekhit wrote:
>> Hi Andrew,
>>
>> I added the following line to genphy_read_status to print out the value of BMCR:
>>
>>  phydev->lp_advertising = 0;
>>
>> +printk(KERN_DEBUG "MII_BMCR: 0x%04X\n", phy_read(phydev, MII_BMCR));
>>
>>  if (AUTONEG_ENABLE == phydev->autoneg) {
>>
>> After booting up the kernel and running ifconfig eth0 up, I get the
>> following in kernel log:
>>
>> [   83.890625] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>> [   85.328125] MII_BMCR: 0x1000
>> [   86.328125] MII_BMCR: 0x1000
>> [   87.328125] MII_BMCR: 0x3100
>> [   87.328125] macb f802c000.ethernet eth0: link up (100/Full)
>> [   87.328125] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>> [   88.328125] MII_BMCR: 0x3100
>> [   89.328125] MII_BMCR: 0x3100
>> [   90.328125] MII_BMCR: 0x3100
>>
>> So it appears that after bringing the interface up, the PHY is
>> configured for 100Mbps, autoneg enabled and duplex mode. The PHY is
>> not isolated or powered down.
>
> So this all looks good. So it suggests your problem is between the MAC
> and the PHY, since the PHY is able to talk to the PHY on the other end
> of the cable.
>
> What do you have in device tree?
>
>      Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-25 13:20                   ` Amr Bekhit
@ 2016-05-25 14:00                     ` Amr Bekhit
  2016-05-25 14:03                     ` Andrew Lunn
  1 sibling, 0 replies; 13+ messages in thread
From: Amr Bekhit @ 2016-05-25 14:00 UTC (permalink / raw)
  To: Andrew Lunn; +Cc: Florian Fainelli, netdev

Hi Andrew,

I've had another play around with the DTS and appear to have solved
the problem. I've changed the ethernet defintions from:

compatible = "cdns,at32ap7000-macb", "cdns,macb";

to

compatible = "cdns,at91sam9260-macb";

and everything seems to work fine now - I can finally send pings.

The reason I never suspected the dts is because the dts file comes
from the manufacturer provided software package, and in their package
the ethernet works fine, so I never suspected it.

Anyway, thanks for all your help, I appreciate it.

On 25 May 2016 at 14:20, Amr Bekhit <amrbekhit@gmail.com> wrote:
> Hi Andrew,
>
> I've uploaded the device tree to http://pastebin.com/tNp2PnW4.
>
> On 25 May 2016 at 13:39, Andrew Lunn <andrew@lunn.ch> wrote:
>> On Wed, May 25, 2016 at 11:28:37AM +0100, Amr Bekhit wrote:
>>> Hi Andrew,
>>>
>>> I added the following line to genphy_read_status to print out the value of BMCR:
>>>
>>>  phydev->lp_advertising = 0;
>>>
>>> +printk(KERN_DEBUG "MII_BMCR: 0x%04X\n", phy_read(phydev, MII_BMCR));
>>>
>>>  if (AUTONEG_ENABLE == phydev->autoneg) {
>>>
>>> After booting up the kernel and running ifconfig eth0 up, I get the
>>> following in kernel log:
>>>
>>> [   83.890625] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>> [   85.328125] MII_BMCR: 0x1000
>>> [   86.328125] MII_BMCR: 0x1000
>>> [   87.328125] MII_BMCR: 0x3100
>>> [   87.328125] macb f802c000.ethernet eth0: link up (100/Full)
>>> [   87.328125] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>> [   88.328125] MII_BMCR: 0x3100
>>> [   89.328125] MII_BMCR: 0x3100
>>> [   90.328125] MII_BMCR: 0x3100
>>>
>>> So it appears that after bringing the interface up, the PHY is
>>> configured for 100Mbps, autoneg enabled and duplex mode. The PHY is
>>> not isolated or powered down.
>>
>> So this all looks good. So it suggests your problem is between the MAC
>> and the PHY, since the PHY is able to talk to the PHY on the other end
>> of the cable.
>>
>> What do you have in device tree?
>>
>>      Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: Davicom DM9162 PHY supported in the kernel?
  2016-05-25 13:20                   ` Amr Bekhit
  2016-05-25 14:00                     ` Amr Bekhit
@ 2016-05-25 14:03                     ` Andrew Lunn
  1 sibling, 0 replies; 13+ messages in thread
From: Andrew Lunn @ 2016-05-25 14:03 UTC (permalink / raw)
  To: Amr Bekhit; +Cc: Florian Fainelli, netdev

On Wed, May 25, 2016 at 02:20:58PM +0100, Amr Bekhit wrote:
> Hi Andrew,
> 
> I've uploaded the device tree to http://pastebin.com/tNp2PnW4.

This is the decompiled blob, making it hard to read.

I do however notice that you have two clocks, "hclk", "pclk". The
binding talks of a third optional clock. Is it required for your
hardware?

Also, have you seen:

https://lkml.org/lkml/2015/3/5/499

Are you sure you have the correct compatible string?

    Andrew

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2016-05-25 14:03 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CAOLz05qgn2-9Qxm1cR7mXa67GAwD2SGbMnbeeEBrYeSPsBexuw@mail.gmail.com>
2016-04-20 15:25 ` Fwd: Davicom DM9162 PHY supported in the kernel? Amr Bekhit
2016-04-20 18:03 ` Florian Fainelli
2016-05-03 14:38   ` Amr Bekhit
2016-05-03 15:36     ` Andrew Lunn
2016-05-09 10:01       ` Amr Bekhit
2016-05-09 12:06         ` Andrew Lunn
2016-05-24 16:09           ` Amr Bekhit
2016-05-24 16:30             ` Andrew Lunn
2016-05-25 10:28               ` Amr Bekhit
2016-05-25 12:39                 ` Andrew Lunn
2016-05-25 13:20                   ` Amr Bekhit
2016-05-25 14:00                     ` Amr Bekhit
2016-05-25 14:03                     ` Andrew Lunn

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.