I have a custom board based on Freescale (NXP) LS1012ARDB reference design, but mine has a Broadcom BCM53128 connected to the CPU via the RGMII bus.
First question: Should I be using the driver in ../drivers/net/phy/b53
or the DSA driver in ../drivers/net/dsa/b53?
I'm currently using the DSA driver, and that leads to my second question: Is my device tree correct (partly shown below)? I'm very confused on how I should set this up. I'm currently only using one mac port, and I commented out the two SGMII and RGMII sections that are used by the reference design board.
I can see that the switch is found. "b53_common: found switch: BCM53128, rev 4" is displayed during boot up. But right now I'm also seeing "bcm53xx ls1012a-0:1e: failed to register switch: -517".
That error is EPROBE_DEFER. I won't get into the specifics of my attempts to debug the code generating that error. I just want to start by getting my device tree correct.
Any help would be extremely appreciated. Thanks,
I only quickly glanced at it and whatever you assign to reg properties needs to equal the part after it's node's @ sign which is not the case, at least not everywhere.
Anyway, you may find good examples of a DSA switch configurations in @Ansuel 's DSA pull request for the IPQ806x here.
the switch configuration is for dsa driver (AFAIK)
Anyway probe defer is not really an error... (it should not be reported with a good driver)
With probe defer, the kernel just retry to probe the driver after some time...
Anyway to transition from a swconfig to a dsa config you should first check how it's init in the swconfig driver and check if the dsa driver does the same thing.
(I would also advice to check if there are some example in the kernel documentation about this dsa driver... And i would also advice to try (if not impossible) to make the dsa driver work since this is the future (1?!?!?) and dsa driver are present upstream and are better maintainable than swconfg driver that can't be proposed upstream)
I think the problem is that the EPROBE_DEFER is happening more than once and it eventually gives up.
I have traced back to the code that is failing.
Function dsa_port_parse_of calls of_find_net_device_by_node(ethernet), where "ethernet" is a device_node* returned from of_parse_phandle.
Then of_find_net_device_by_node calls class_find_device to locate the device associated with "ethernet" (I think).
Step 3: class_find_device iterates a couple of times and finds a device, then it calls the callback function of_dev_node_match.
Finally: of_dev_node_match takes the device found in step 3 (dev) and compares dev->parent->of_node to "data", where data is the "ethernet" device_node pointer from step 1 cast as a "const void *". These two things do not match.
My question is, what are the two things that are being compared? I think it parses the device tree and finds the "ethernet" phandle, correct? In my device tree I have ethernet=<&pfe_eth1>.
I printed out dev->parent->of_node->name and it is "pfe".
I don't understand what these two things are, and why don't they match? The fact that they do not match is what causes EPROBE_DEFER.
I hope that made sense. I didn't want to copy and paste many pages of code. Any help would be very much appreciated.
It's from step 1 of my description above.
dsa_port_parse_of is shown below. It is returning EPROBE_DEFER. So my long description lists all the functions that get called before two things are compared and determined not to match. That causes
of_find_net_device_by_node to return NULL. Thus the EPROBE_DEFER.
But I don't understand what is being compared and why.
I got past the probe defer error. It now appears to be loading the driver and there are no error messages. ifconfig -a now shows all the lan ports that were not listed before. I see "bcm53xx ls1012a-0:1e lan1: Link is Up" when I plug in a cable. But I still can't ping. There is no response. The other end of the cable is connected to a laptop running Wireshark and I see nothing there. I'm pretty sure this is just a configuration problem, but I have no experience in this area, so I'm looking for any clues
And that is the problem with this driver. Interfaces have nodes pfe_mac0 and pfe_mac1. But when I use it, driver return -517. When I put &pfe node which is whole controller, driver start, but with wrong interface. It's impossible to bind do eth1.
That is just a probe deferral and should not really be an issue. You are saying it really does not work then? Maybe some probe deferral bug. I used to fix countless such a few years back but would expect this to work quite nicely nowadays.