On Wed, 23 Dec 2015 20:18:16 -0500 "David Rivshin (Allworx)" <drivshin.allworx@xxxxxxxxx> wrote: > On Thu, 24 Dec 2015 00:34:49 +0100 > Nicolas Chauvet <kwizart@xxxxxxxxx> wrote: > > > 2015-12-23 22:54 GMT+01:00 David Rivshin (Allworx) < > > drivshin.allworx@xxxxxxxxx>: > > > > > On Wed, 23 Dec 2015 22:20:58 +0100 > > > Nicolas Chauvet <kwizart@xxxxxxxxx> wrote: > > > > > > > 2015-12-23 1:36 GMT+01:00 David Rivshin (Allworx) < > > > > drivshin.allworx@xxxxxxxxx>: > > > > > > > > > From: David Rivshin <drivshin@xxxxxxxxxxx> > > > > > > > > > > This series is based on the tip of the net tree. > > > > > > > > > > The first patch fixes a bug that makes dual_emac mode break if > > > > > either slave uses the phy-handle property in the devicetree. > > > > > > > > > > The second patch fixes some cosmetic problems with error > > > > > messages, and also makes the binding documentation more > > > > > explicit. > > > > > > > > > > The third patch cleans up the fixed-link case to work like > > > > > the now-fixed phy-handle case. > > > > > > > > > > I have tested on the following hardware configurations: > > > > > - (EVMSK) dual emac, phy_id property in both slaves > > > > > - (BeagleBoneBlack) single emac, phy_id property > > > > > - (custom) single emac, fixed-link subnode > > > > > Note that I don't have a board which would uses a phy-handle > > > > > property, though I have used hacked devicetrees to exercise > > > > > the code paths. Testing by anyone who has real hardware using > > > > > phy-handle or dual_emac with fixed-link would be appreciated. > > > > > > > > > > David Rivshin (3): > > > > > drivers: net: cpsw: fix parsing of phy-handle DT property in > > > > > dual_emac config > > > > > drivers: net: cpsw: fix error messages when using phy-handle > > > > > DT property > > > > > drivers: net: cpsw: use of_phy_connect() in fixed-link case > > > > > > > > > > Documentation/devicetree/bindings/net/cpsw.txt | 4 +-- > > > > > drivers/net/ethernet/ti/cpsw.c | 40 > > > > > +++++++++++++------------- > > > > > drivers/net/ethernet/ti/cpsw.h | 1 + > > > > > 3 files changed, 23 insertions(+), 22 deletions(-) > > > > > > > > > > > > > > This serie failed with me on dm8418 hp-t410 on top of linux-next > > > > from today whereas the same patch level and same methods without > > > > this serie is working fine. > > > > I wasn't able to ping anything on a minimal rootfs with static > > > > ip set from cmdline from kernel. > > > > > > > > Sorry for the lack of details, feel free to add me to any other > > > > revision of the patch if any. > > > > I will be able to do more testing next month. > > > > > > (Sorry for the duplicate, doing a reply-all this time. Not sure > > > why it looked like a non-list email the first time) > > > > > My bad, I've replied twice, but only last on-list. > > > > > > > Thanks for testing. I found the dm8148-t410.dts devicetree in the > > > kernel source, and it uses the phy_id for both slaves, just like > > > the EVMSK board I tested. So I can't think of an obvious reason > > > for the problem. > > > Would you be able to send the 'dmesg' log from right after bootup? > > > I'm hoping there is an error message in there with some clue. > > > > > here is the full dmesg output with this serie applied to linux-next: > > http://ur1.ca/ocvs6 > > > > [ 2.281524] davinci_mdio 4a100800.mdio: davinci mdio revision 1.6 > > [ 2.287909] davinci_mdio 4a100800.mdio: detected phy mask > > fffffffe [ 2.302663] Atheros 8031 ethernet 4a100800.mdio:00: > > GPIO lookup for consumer reset > > [ 2.302686] Atheros 8031 ethernet 4a100800.mdio:00: using lookup > > tables for GPIO lookup > > [ 2.302732] Atheros 8031 ethernet 4a100800.mdio:00: lookup for > > GPIO reset failed > > [ 2.302860] libphy: 4a100800.mdio: probed > > [ 2.307063] davinci_mdio 4a100800.mdio: phy[0]: device > > 4a100800.mdio:00, driver Atheros 8031 ethernet > > [ 2.317945] cpsw 4a100000.ethernet: Detected MACID = > > 00:18:32:60:8e:38 > > > > * 19:06 < nchauvet> btw with this dmesg, I've tried to apply this > > serie: http://marc.info/?l=linux-omap&m=145032865615589&w=2, but it > > doesn't seem to work for me (I cannot ping my gateway anymore) > > That particular email was about a v1 patch, which was then replaced > by a 3-patch series for v2: > http://marc.info/?l=linux-netdev&m=145032497014944&w=2 > That is already in linux-next, and below you show that you have it. > > > So I've remembered that I've double checked the Ethernet wire, but I > > agree it can also be another random issue. > > If it works without this series, but fails with it, that is strong > evidence that something in this series either is a bug or exposes > one. > > > > Just to verify, is your linux-next tree up-to-date? This series > > > needs to be applied is based on another recent series of 3 patches > > > to cpsw.c. Although I doubt it would apply cleanly at all without > > > those. > > > > From my linux-next base, related to cpsw, I have: > > git log --oneline cpsw* > > a6b257c Merge remote-tracking branch 'net-next/master' > > dfc0a6d drivers: net: cpsw: increment reference count on fixed-link > > PHY node > > f1eea5c drivers: net: cpsw: fix RMII/RGMII mode when used > > with fixed-link PHY > > 1873c58 ethernet:ti:cpsw: fix phy identification with multiple > > slaves on fixed-phy > > f188b95 Merge > > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 0db19b8 > > net: cpsw: Fix ethernet regression for dm814 > > > > Theses patches don't lead to any issue on the t410 device. > > Thanks for verifying. 1873c58, f1eea5, and cdfc0a6d are the previous > patches I referred to. > > > Comparing a dmesg output where the driver work: it doesn't show any > > difference from the quoted lines: > > http://paste.fedoraproject.org/304248/45086839/ > > Thanks for the additional info. I also don't see any red flags in the > dmesg output. > > When I looked closer at the dm8148-t410 devicetree, I see that it's > actually more like the BeagleBones than an EVMSK. It specifies two > slaves, but is not in dual_emac mode. Other than using RGMII mode > instead of MII, the emac configuration in the DT looks the same to > me. Further, your dmesg shows there is only one actual PHY, same as > a BeagleBone. I assume that's historical, as specifying slaves=<1> > used to crash (fixed by 1973db0df7c3b in v4.2). > > Despite the similarities, I have been unable to reproduce a failure > on a BeagleBone-Black running linux-next plus this series. Things > that I've checked in dmesg output look similar to yours, so I'm > currently out of ideas I can check myself. If I could ask you for > some more assistance in debugging: > > Are you using the devicetree from the linux-next source, or is it > modified? If it's modified, can you send it? > > Could you check the phy_interface mode used? I know that being wrong > would generate such symptoms. Quickest way to check that (and related > bits) is probably: > grep -H . /sys/bus/mdio_bus/devices/*/phy* > Based on the devicetree in the kernel source and your dmesg output, > I expect there to be a single PHY with phy_interface=rgmii and > phy_id=0x4dd074. If any of those aspects don't match what sysfs > reports, then that's likely to be the cause. > > Failing that, I would next try to apply the 3 patches in this series > one at a time (or bisect them) to identify the specific culprit. > > Thanks. Nicolas, Did you have a chance to try this series again? I've retested on a BeagleBone-Black against both current net and linux-next, and I still can't reproduce see the failure you reported. I'm hoping that was just the result of some unrelated and since- resolved problem. Note that the 3rd patch has a merge conflict now, but it is trivially resolved by taking the (deletion of) lines from this series. If you'd like me to send a post-merge version, just let me know. Also, I have just CCed you on a related patch that adds a dev_warn() which catches the case I mentioned at the end of my previous email. I would suggest applying that as well, just to remove some guesswork. Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
