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) 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. 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. -- 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
