<div dir="ltr">Hi,<div><br></div><div>I have been looking deeper into my wireshark packet captures and found something that could be helpfull.</div><div><br></div><div>I can see that the Ethernet NICS at least do something. ARP BROADCAST traffic is seen.</div><div>But i also found some packets...which have LG BITs set to 1 .. when i think 0 should be the correct value..</div><div><br></div><div>This has something to do with the MAC adresses being non Authorative.. and since whe can use Uboot and choose any Mac addr we want, this could make sense.. More info about this <a href="https://osqa-ask.wireshark.org/questions/59761/oui-lookup-tool-does-not-recognize-local-addresses">https://osqa-ask.wireshark.org/questions/59761/oui-lookup-tool-does-not-recognize-local-addresses</a></div><div><br></div><div>Logs like these appear: not the original.</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:16px;background-color:rgb(247,247,247)">Destination: Broadcast (ff:ff:ff:ff:ff:ff)</span><br style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:16px;background-color:rgb(247,247,247)"><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:16px;background-color:rgb(247,247,247)">Address: Broadcast (ff:ff:ff:ff:ff:ff)</span><br style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:16px;background-color:rgb(247,247,247)"><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:16px;background-color:rgb(247,247,247)">.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)</span><br style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:16px;background-color:rgb(247,247,247)"><span style="color:rgb(51,51,51);font-family:Helvetica,Arial,sans-serif;font-size:16px;background-color:rgb(247,247,247)">.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)</span><br></div><div><br></div><div><br></div><div>Will try to get the picture more clear... but think about this..</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 16, 2018 at 6:57 PM, Joakim Tjernlund <span dir="ltr"><<a href="mailto:Joakim.Tjernlund@infinera.com" target="_blank">Joakim.Tjernlund@infinera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, 1970-01-01 at 00:00 +0000, Andrew Lunn wrote:<br>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.<br>
><br>
><br>
> > Hi, just saw this and thought of a small patch I just wrote for mdio bus, o idea<br>
> > if it is relevant but here goes:<br>
> ><br>
> > From fe0b98d54a79779482700676331b4d<wbr>10a0f3cada Mon Sep 17 00:00:00 2001<br>
> > From: Joakim Tjernlund <<a href="mailto:joakim.tjernlund@infinera.com">joakim.tjernlund@infinera.com</a><wbr>><br>
> > Date: Sun, 14 Jan 2018 21:27:20 +0100<br>
> > Subject: [PATCH] of_mdiobus_register: Continue after error<br>
> ><br>
> > of_mdiobus_register unregister itself if one phy fails to register<br>
> > which is bad for system having all its PHYs on the same MDIO bus.<br>
> > Just log the error and continue with the remaining PHYs instead.<br>
> ><br>
> > Signed-off-by: Joakim Tjernlund <<a href="mailto:joakim.tjernlund@infinera.com">joakim.tjernlund@infinera.com</a><wbr>><br>
><br>
> Hi Joakim<br>
><br>
> You appear to be using an old kernel. Take a look at:<br>
<br>
Not really, I am using 4.14.x and I don't think that is old. Seems like this<br>
patch hasn't been sent to 4.14.x.<br>
<br>
I wonder if I might be missing something else, we just moved to 4.14 and notic that all<br>
our fixed PHYs are non functioning:<br>
fsl_mac ffe4e2000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e2000.ethernet: FMan MAC address: 00:06:9c:0b:06:20<br>
fsl_mac dpaa-ethernet.0: __devm_request_mem_region(mac) failed<br>
fsl_mac: probe of dpaa-ethernet.0 failed with error -16<br>
fsl_mac ffe4e4000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e4000.ethernet: FMan MAC address: 00:06:9c:0b:06:21<br>
fsl_mac dpaa-ethernet.1: __devm_request_mem_region(mac) failed<br>
fsl_mac: probe of dpaa-ethernet.1 failed with error -16<br>
fsl_mac ffe4e6000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e6000.ethernet: FMan MAC address: 00:06:9c:0b:06:22<br>
fsl_mac dpaa-ethernet.2: __devm_request_mem_region(mac) failed<br>
fsl_mac: probe of dpaa-ethernet.2 failed with error -16<br>
fsl_mac ffe4e8000.ethernet: FMan MEMAC<br>
fsl_mac ffe4e8000.ethernet: FMan MAC address: 00:06:9c:0b:06:23<br>
fsl_mac dpaa-ethernet.3: __devm_request_mem_region(mac) failed<br>
fsl_mac: probe of dpaa-ethernet.3 failed with error -16<br>
<br>
Feels like FMAN still think there are real PHYs there ?<br>
><br>
> commit 95f566de0269a0c59fd6a737a14773<wbr>1302136429<br>
> Author: Madalin Bucur <<a href="mailto:madalin.bucur@nxp.com">madalin.bucur@nxp.com</a>><br>
> Date:   Tue Jan 9 14:43:34 2018 +0200<br>
><br>
>     of_mdio: avoid MDIO bus removal when a PHY is missing<br>
><br>
>     If one of the child devices is missing the of_mdiobus_register_phy()<br>
>     call will return -ENODEV. When a missing device is encountered the<br>
>     registration of the remaining PHYs is stopped and the MDIO bus will<br>
>     fail to register. Propagate all errors except ENODEV to avoid it.<br>
><br>
>     Signed-off-by: Madalin Bucur <<a href="mailto:madalin.bucur@nxp.com">madalin.bucur@nxp.com</a>><br>
>     Reviewed-by: Andrew Lunn <<a href="mailto:andrew@lunn.ch">andrew@lunn.ch</a>><br>
>     Signed-off-by: David S. Miller <<a href="mailto:davem@davemloft.net">davem@davemloft.net</a>><br>
><br>
><br>
>     Andrew<br>
</blockquote></div><br></div>