From: Andrew Lunn <andrew@lunn.ch>
To: Jamie Lentin <jm@lentin.co.uk>
Cc: Jason Cooper <jason@lakedaemon.net>,
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
Gregory Clement <gregory.clement@free-electrons.com>,
Imre Kaloz <kaloz@openwrt.org>,
Florian Fainelli <f.fainelli@gmail.com>,
linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Subject: Re: [PATCH v0 00/10] Convert Netgear WNR854T to devicetree
Date: Sun, 17 Jul 2016 17:33:38 +0200 [thread overview]
Message-ID: <20160717153338.GA13611@lunn.ch> (raw)
In-Reply-To: <alpine.DEB.2.11.1607171043100.19980@marmot.wormnet.eu>
> Firstly I've tried to to rebase against net-next[0], but after
> adding 6131 to mv88e6xxx_of_match, &chip->ppu_work seems to be
> causing a NULL pointer ooops. I'll assume it's not done yet and
> ignore net-next for now.
You don't need to modify mv88e6xxx_of_match, the 6131 is compatible
with the mv88e6085. Just use the compatible string of
"marvell,mv88e6085". So far, ever Marvell chip we support is
compatible with the mv88e6085, in terms of probing. Once the driver
has probed, and read the device ID from a register, it knows enough to
decide for itself what features the chip has.
In order to get the LEDs working as you want, you are going to have to
use the new binding. So i would suggest sticking with that.
> >I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
> >configuration. Try swapping to EDSA. I even removed support for
> >TAG_DSA in one of the recent patches.
>
> Okay, back to my original wnr854t-support-v0a branch based on 4.6,
> switched to .tag_protocol = DSA_TAG_PROTO_EDSA and reconfig'ed to
> add support, but there's no traffic in/out of any port. tcpdump on
> the underlying ethernet port shows encapsulated broadcast traffic,
> e.g. this ARP request from enp0:10.100.4.41:
>
> 00:15:31.173399 1a:ff:0f:fe:10:22 (oui Unknown) > Broadcast,
> ethertype Unknown (0xc008), length 64:
> 0x0000: 0000 0806 0001 0800 0604 0001 1aff 0ffe ................
> 0x0010: 1022 0a64 0429 0000 0000 0000 0a64 0437 .".d.).......d.7
> 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0030: 0000 ..
>
> ...but no unicast traffic.
Uh, that does not look like EDSA tagging. Expect an ethertype of
0xdada. Also, if you get the latest tcpdump sources, it knows how to
decode the additional EDSA header which is added.
>
> >Please also can you get https://github.com/vivien/linux.git commit
> >323321875671dfe95b6b91ce051a74d415c7158c which will give you some
> >extra debug files /sys/kernel/debug/mv88e6xxx.
> >
> >The reg, stats, and atu would be interesting.
>
> Okay, I rebased 4.7-rc7, ignoring my ropey attempts to configure the
> LEDs, cherry-picked the above commit. Pushed the result if it's
> useful[1]. The debugfs code wouldn't patch cleanly onto 4.6 or
> net-next.
Yes, the debug code is a real pain. Something i'm working on in the
background, get something generic which is acceptable for mainline.
> On boot up I get:
>
> mdio_bus f1072004.mdio-bu: switch 0x106 probed: Marvell 88E6131, revision 6
> mv643xx_eth_port mv643xx_eth_port.0 eth0: [0]: detected a Marvell 88E6131 switch
> libphy: dsa slave smi: probed
> Marvell 88E1121R dsa-0:00:00: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:00, irq=-1)
> Marvell 88E1121R dsa-0:00:01: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:01, irq=-1)
> Marvell 88E1121R dsa-0:00:02: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:02, irq=-1)
> Marvell 88E1112 dsa-0:00:05: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:05, irq=-1)
> Marvell 88E1112 dsa-0:00:07: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:07, irq=-1)
That looks good, it found the PHYs etc.
> Like above (since 4.7 seems to use DSA_TAG_PROTO_EDSA), there's no
> traffic visible with tcpdump on lan1/4 (broadcast or unicast), only
> broadcast traffic on the backing port, eth0.
>
> # cat /sys/kernel/debug/mv88e6xxx.0/regs
> GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6 7
> 0: c800 0 0 7080 7d80 7080 6e88 6086 7e86 6086 7086
> 1: 1b 0 0 3 3 3 3e 403 403 403 403
> 2: 2fd5 0 0 0 0 0 0 0 0 0 0
> 3: 9df4 ffff 0 1066 1066 1066 1066 1066 1066 1066 1066
> 4: 4000 191 0 433 433 433 3533 433 433 433 433
> 5: 1000 ff 0 0 0 0 0 0 0 0 0
> 6: c000 1f0f 0 708 708 708 7f7 708 708 708 708
> 7: 0 70ff 0 0 0 0 0 0 0 0 0
> 8: 0 7800 0 83 83 83 c3 83 83 83 83
> 9: 0 0 0 1 1 1 1 1 1 1 1
> a: f148 0 0 0 0 0 0 0 0 0 0
> b: 400f 0 0 1 2 4 0 10 20 40 80
> c: 0 0 0 0 0 0 0 0 0 0 0
> d: ffff 0 0 0 0 0 0 0 0 0 0
> e: ffff 0 0 0 0 0 0 0 0 0 0
> f: ffff 77 0 0 0 0 0 0 0 0 0
> 10: 0 0 0 0 0 0 0 0 0 0 0
> 11: 0 0 0 0 0 0 0 0 0 0 0
> 12: 5555 0 0 0 0 0 12 0 0 0 0
> 13: 5555 0 0 0 0 0 0 0 0 0 0
> 14: aaaa 0 0 403 403 403 8403 403 403 403 403
> 15: aaaa 0 0 0 0 0 0 0 0 0 0
> 16: ffff 0 0 700 70d 700 700 f41 f0e f41 f02
> 17: ffff 0 0 0 0 0 0 0 0 0 0
> 18: fa41 0 0 3210 3210 3210 3210 3210 3210 3210 3210
> 19: 8100 0 0 7654 7654 7654 7654 7654 7654 7654 7654
> 1a: 3330 0 0 - - - - - - - -
> 1b: f4 0 0 - - - - - - - -
> 1c: f000 0 0 - - - - - - - -
> 1d: 5c07 0 0 - - - - - - - -
> 1e: 0 f0 0 - - - - - - - -
> 1f: 0 0 0 - - - - - - - -
>
> # cat /sys/kernel/debug/mv88e6xxx.0/stats
> (lan4) (cpu) (lan1)
> Statistic Port 0 Port 1 Port 2 Port 3 Port 4 Port 5 Port 6 Port 7
> in_good_octets: 0 1064 0 1152 0 112155 0 0
> in_bad_octets: 0 0 0 0 0 0 0 0
> in_unicast: 0 0 0 0 0 0 0 0
> in_broadcasts: 0 6 0 18 0 335 0 0
> in_multicasts: 0 8 0 0 0 490 0 0
> in_pause: 0 0 0 0 0 0 0 0
> in_undersize: 0 0 0 0 0 0 0 0
> in_fragments: 0 0 0 0 0 0 0 0
> in_oversize: 0 0 0 0 0 0 0 0
> in_jabber: 0 0 0 0 0 0 0 0
> in_rx_error: 0 0 0 0 0 0 0 0
> in_fcs_error: 0 0 0 0 0 0 0 0
> out_octets: 0 0 0 131331 0 0 0 0
> out_unicast: 0 0 0 0 0 0 0 0
> out_broadcasts: 0 0 0 558 0 0 0 0
> out_multicasts: 0 0 0 498 0 0 0 0
> out_pause: 0 0 0 0 0 0 0 0
> excessive: 0 0 0 0 0 0 0 0
> collisions: 0 0 0 0 0 0 0 0
> deferred: 0 0 0 0 0 0 0 0
> single: 0 0 0 0 0 0 0 0
> multiple: 0 0 0 0 0 0 0 0
> out_fcs_error: 0 0 0 0 0 0 0 0
> late: 0 0 0 0 0 0 0 0
> hist_64bytes: 0 6 0 18 0 188 0 0
> hist_65_127bytes: 0 8 0 440 0 69 0 0
> hist_128_255bytes: 0 0 0 376 0 376 0 0
> hist_256_511bytes: 0 0 0 0 0 0 0 0
> hist_512_1023bytes: 0 0 0 0 0 0 0 0
> hist_1024_max_bytes: 0 0 0 0 0 0 0 0
> sw_in_discards: 0 0 0 0 0 0 0 0
> sw_in_filtered: 0 0 0 18 0 0 0 0
> sw_out_filtered: 0 0 0 0 0 0 0 0
So as you say, no unicast traffic to/from the CPU port. The 18
sw_in_filtered also look suspicious.
> [0] https://github.com/lentinj/linux/tree/wnr854t-support-v0b-net-next-experiment
+ port@3 {
+ reg = <3>;
+ label = "cpu";
+ ethernet = <ð>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
You don't need a fixed-link here. The cpu port is automatically
configured fixed at the highest speed the port will do.
However,
ð {
status = "okay";
- ethernet-port@0 {
- speed = <1000>;
- duplex = <1>;
- };
};
here you do need the fixed link, otherwise it thinks there is a PHY
connected and tried to do auto-negotiation. That will never work.
Andrew
WARNING: multiple messages have this Message-ID (diff)
From: andrew@lunn.ch (Andrew Lunn)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v0 00/10] Convert Netgear WNR854T to devicetree
Date: Sun, 17 Jul 2016 17:33:38 +0200 [thread overview]
Message-ID: <20160717153338.GA13611@lunn.ch> (raw)
In-Reply-To: <alpine.DEB.2.11.1607171043100.19980@marmot.wormnet.eu>
> Firstly I've tried to to rebase against net-next[0], but after
> adding 6131 to mv88e6xxx_of_match, &chip->ppu_work seems to be
> causing a NULL pointer ooops. I'll assume it's not done yet and
> ignore net-next for now.
You don't need to modify mv88e6xxx_of_match, the 6131 is compatible
with the mv88e6085. Just use the compatible string of
"marvell,mv88e6085". So far, ever Marvell chip we support is
compatible with the mv88e6085, in terms of probing. Once the driver
has probed, and read the device ID from a register, it knows enough to
decide for itself what features the chip has.
In order to get the LEDs working as you want, you are going to have to
use the new binding. So i would suggest sticking with that.
> >I see you have NET_TAG_DSA, but not NET_TAG_EDSA in your
> >configuration. Try swapping to EDSA. I even removed support for
> >TAG_DSA in one of the recent patches.
>
> Okay, back to my original wnr854t-support-v0a branch based on 4.6,
> switched to .tag_protocol = DSA_TAG_PROTO_EDSA and reconfig'ed to
> add support, but there's no traffic in/out of any port. tcpdump on
> the underlying ethernet port shows encapsulated broadcast traffic,
> e.g. this ARP request from enp0:10.100.4.41:
>
> 00:15:31.173399 1a:ff:0f:fe:10:22 (oui Unknown) > Broadcast,
> ethertype Unknown (0xc008), length 64:
> 0x0000: 0000 0806 0001 0800 0604 0001 1aff 0ffe ................
> 0x0010: 1022 0a64 0429 0000 0000 0000 0a64 0437 .".d.).......d.7
> 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
> 0x0030: 0000 ..
>
> ...but no unicast traffic.
Uh, that does not look like EDSA tagging. Expect an ethertype of
0xdada. Also, if you get the latest tcpdump sources, it knows how to
decode the additional EDSA header which is added.
>
> >Please also can you get https://github.com/vivien/linux.git commit
> >323321875671dfe95b6b91ce051a74d415c7158c which will give you some
> >extra debug files /sys/kernel/debug/mv88e6xxx.
> >
> >The reg, stats, and atu would be interesting.
>
> Okay, I rebased 4.7-rc7, ignoring my ropey attempts to configure the
> LEDs, cherry-picked the above commit. Pushed the result if it's
> useful[1]. The debugfs code wouldn't patch cleanly onto 4.6 or
> net-next.
Yes, the debug code is a real pain. Something i'm working on in the
background, get something generic which is acceptable for mainline.
> On boot up I get:
>
> mdio_bus f1072004.mdio-bu: switch 0x106 probed: Marvell 88E6131, revision 6
> mv643xx_eth_port mv643xx_eth_port.0 eth0: [0]: detected a Marvell 88E6131 switch
> libphy: dsa slave smi: probed
> Marvell 88E1121R dsa-0:00:00: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:00, irq=-1)
> Marvell 88E1121R dsa-0:00:01: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:01, irq=-1)
> Marvell 88E1121R dsa-0:00:02: attached PHY driver [Marvell 88E1121R] (mii_bus:phy_addr=dsa-0:00:02, irq=-1)
> Marvell 88E1112 dsa-0:00:05: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:05, irq=-1)
> Marvell 88E1112 dsa-0:00:07: attached PHY driver [Marvell 88E1112] (mii_bus:phy_addr=dsa-0:00:07, irq=-1)
That looks good, it found the PHYs etc.
> Like above (since 4.7 seems to use DSA_TAG_PROTO_EDSA), there's no
> traffic visible with tcpdump on lan1/4 (broadcast or unicast), only
> broadcast traffic on the backing port, eth0.
>
> # cat /sys/kernel/debug/mv88e6xxx.0/regs
> GLOBAL GLOBAL2 SERDES 0 1 2 3 4 5 6 7
> 0: c800 0 0 7080 7d80 7080 6e88 6086 7e86 6086 7086
> 1: 1b 0 0 3 3 3 3e 403 403 403 403
> 2: 2fd5 0 0 0 0 0 0 0 0 0 0
> 3: 9df4 ffff 0 1066 1066 1066 1066 1066 1066 1066 1066
> 4: 4000 191 0 433 433 433 3533 433 433 433 433
> 5: 1000 ff 0 0 0 0 0 0 0 0 0
> 6: c000 1f0f 0 708 708 708 7f7 708 708 708 708
> 7: 0 70ff 0 0 0 0 0 0 0 0 0
> 8: 0 7800 0 83 83 83 c3 83 83 83 83
> 9: 0 0 0 1 1 1 1 1 1 1 1
> a: f148 0 0 0 0 0 0 0 0 0 0
> b: 400f 0 0 1 2 4 0 10 20 40 80
> c: 0 0 0 0 0 0 0 0 0 0 0
> d: ffff 0 0 0 0 0 0 0 0 0 0
> e: ffff 0 0 0 0 0 0 0 0 0 0
> f: ffff 77 0 0 0 0 0 0 0 0 0
> 10: 0 0 0 0 0 0 0 0 0 0 0
> 11: 0 0 0 0 0 0 0 0 0 0 0
> 12: 5555 0 0 0 0 0 12 0 0 0 0
> 13: 5555 0 0 0 0 0 0 0 0 0 0
> 14: aaaa 0 0 403 403 403 8403 403 403 403 403
> 15: aaaa 0 0 0 0 0 0 0 0 0 0
> 16: ffff 0 0 700 70d 700 700 f41 f0e f41 f02
> 17: ffff 0 0 0 0 0 0 0 0 0 0
> 18: fa41 0 0 3210 3210 3210 3210 3210 3210 3210 3210
> 19: 8100 0 0 7654 7654 7654 7654 7654 7654 7654 7654
> 1a: 3330 0 0 - - - - - - - -
> 1b: f4 0 0 - - - - - - - -
> 1c: f000 0 0 - - - - - - - -
> 1d: 5c07 0 0 - - - - - - - -
> 1e: 0 f0 0 - - - - - - - -
> 1f: 0 0 0 - - - - - - - -
>
> # cat /sys/kernel/debug/mv88e6xxx.0/stats
> (lan4) (cpu) (lan1)
> Statistic Port 0 Port 1 Port 2 Port 3 Port 4 Port 5 Port 6 Port 7
> in_good_octets: 0 1064 0 1152 0 112155 0 0
> in_bad_octets: 0 0 0 0 0 0 0 0
> in_unicast: 0 0 0 0 0 0 0 0
> in_broadcasts: 0 6 0 18 0 335 0 0
> in_multicasts: 0 8 0 0 0 490 0 0
> in_pause: 0 0 0 0 0 0 0 0
> in_undersize: 0 0 0 0 0 0 0 0
> in_fragments: 0 0 0 0 0 0 0 0
> in_oversize: 0 0 0 0 0 0 0 0
> in_jabber: 0 0 0 0 0 0 0 0
> in_rx_error: 0 0 0 0 0 0 0 0
> in_fcs_error: 0 0 0 0 0 0 0 0
> out_octets: 0 0 0 131331 0 0 0 0
> out_unicast: 0 0 0 0 0 0 0 0
> out_broadcasts: 0 0 0 558 0 0 0 0
> out_multicasts: 0 0 0 498 0 0 0 0
> out_pause: 0 0 0 0 0 0 0 0
> excessive: 0 0 0 0 0 0 0 0
> collisions: 0 0 0 0 0 0 0 0
> deferred: 0 0 0 0 0 0 0 0
> single: 0 0 0 0 0 0 0 0
> multiple: 0 0 0 0 0 0 0 0
> out_fcs_error: 0 0 0 0 0 0 0 0
> late: 0 0 0 0 0 0 0 0
> hist_64bytes: 0 6 0 18 0 188 0 0
> hist_65_127bytes: 0 8 0 440 0 69 0 0
> hist_128_255bytes: 0 0 0 376 0 376 0 0
> hist_256_511bytes: 0 0 0 0 0 0 0 0
> hist_512_1023bytes: 0 0 0 0 0 0 0 0
> hist_1024_max_bytes: 0 0 0 0 0 0 0 0
> sw_in_discards: 0 0 0 0 0 0 0 0
> sw_in_filtered: 0 0 0 18 0 0 0 0
> sw_out_filtered: 0 0 0 0 0 0 0 0
So as you say, no unicast traffic to/from the CPU port. The 18
sw_in_filtered also look suspicious.
> [0] https://github.com/lentinj/linux/tree/wnr854t-support-v0b-net-next-experiment
+ port at 3 {
+ reg = <3>;
+ label = "cpu";
+ ethernet = <ð>;
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
You don't need a fixed-link here. The cpu port is automatically
configured fixed at the highest speed the port will do.
However,
ð {
status = "okay";
- ethernet-port at 0 {
- speed = <1000>;
- duplex = <1>;
- };
};
here you do need the fixed link, otherwise it thinks there is a PHY
connected and tried to do auto-negotiation. That will never work.
Andrew
next prev parent reply other threads:[~2016-07-17 15:34 UTC|newest]
Thread overview: 179+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-16 14:28 [PATCH v0 00/10] Convert Netgear WNR854T to devicetree Jamie Lentin
2016-07-16 14:28 ` Jamie Lentin
2016-07-16 14:28 ` Jamie Lentin
2016-07-16 14:28 ` [PATCH v0 01/10] arm: orion5x: Add required properties for orion-wdt to DT node Jamie Lentin
2016-07-16 14:28 ` Jamie Lentin
2016-07-16 14:28 ` Jamie Lentin
2016-07-16 16:03 ` Andrew Lunn
2016-07-16 16:03 ` Andrew Lunn
2016-07-16 14:29 ` [PATCH v0 02/10] arm: orion5x: Add documentation for SoC and board bindings Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:05 ` Andrew Lunn
2016-07-16 16:05 ` Andrew Lunn
2016-07-16 16:05 ` Andrew Lunn
2016-07-17 20:35 ` Rob Herring
2016-07-17 20:35 ` Rob Herring
2016-07-17 20:35 ` Rob Herring
2016-07-16 14:29 ` [PATCH v0 03/10] arm: orion5x: Add clk support for mv88f5181 Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:10 ` Andrew Lunn
2016-07-16 16:10 ` Andrew Lunn
2016-07-16 16:10 ` Andrew Lunn
2016-07-16 17:34 ` Sergei Shtylyov
2016-07-16 17:34 ` Sergei Shtylyov
2016-07-16 17:34 ` Sergei Shtylyov
2016-07-17 20:36 ` Rob Herring
2016-07-17 20:36 ` Rob Herring
2016-07-17 20:36 ` Rob Herring
2016-07-16 14:29 ` [PATCH v0 04/10] arm: orion5x: Generalise mv88f5181l pinctrl support for 88f5181 Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:15 ` Andrew Lunn
2016-07-16 16:15 ` Andrew Lunn
2016-07-17 20:40 ` Rob Herring
2016-07-17 20:40 ` Rob Herring
2016-07-17 20:40 ` Rob Herring
2016-07-16 14:29 ` [PATCH v0 05/10] arm: orion5x: Add DT include for mv88f5181 Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:17 ` Andrew Lunn
2016-07-16 16:17 ` Andrew Lunn
2016-07-16 16:17 ` Andrew Lunn
2016-07-17 20:41 ` Rob Herring
2016-07-17 20:41 ` Rob Herring
2016-07-16 14:29 ` [PATCH v0 06/10] arm: orion5x: Add DT-based support for Netgear WNR854T Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:34 ` Andrew Lunn
2016-07-16 16:34 ` Andrew Lunn
2016-07-16 16:34 ` Andrew Lunn
2016-07-16 16:39 ` Andrew Lunn
2016-07-16 16:39 ` Andrew Lunn
2016-07-16 19:10 ` Arnd Bergmann
2016-07-16 19:10 ` Arnd Bergmann
2016-07-17 9:39 ` Jamie Lentin
2016-07-17 9:39 ` Jamie Lentin
2016-07-17 9:39 ` Jamie Lentin
2016-07-17 20:41 ` Arnd Bergmann
2016-07-17 20:41 ` Arnd Bergmann
2016-07-18 9:44 ` Thomas Petazzoni
2016-07-18 9:44 ` Thomas Petazzoni
2016-07-18 10:06 ` Arnd Bergmann
2016-07-18 10:06 ` Arnd Bergmann
2016-07-18 10:06 ` Arnd Bergmann
2016-07-19 9:40 ` Jamie Lentin
2016-07-19 9:40 ` Jamie Lentin
2016-07-19 9:46 ` Arnd Bergmann
2016-07-19 9:46 ` Arnd Bergmann
2016-07-17 20:51 ` Rob Herring
2016-07-17 20:51 ` Rob Herring
2016-07-19 9:46 ` Jamie Lentin
2016-07-19 9:46 ` Jamie Lentin
2016-07-19 9:46 ` Jamie Lentin
2016-07-16 14:29 ` [PATCH v0 07/10] arm: orion5x: Remove old non-DT-based WNR854T support Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:36 ` Andrew Lunn
2016-07-16 16:36 ` Andrew Lunn
2016-07-16 14:29 ` [PATCH v0 08/10] net: phy: Try looking for a phy-handle property to find the OF node Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:44 ` Andrew Lunn
2016-07-16 16:44 ` Andrew Lunn
2016-07-16 14:29 ` [PATCH v0 09/10] net: phy: Re-attempt custom DT configuration after configuration Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 16:44 ` Andrew Lunn
2016-07-16 16:44 ` Andrew Lunn
2016-07-16 16:44 ` Andrew Lunn
2016-07-16 14:29 ` [PATCH v0 10/10] arm: orion5x: Configure Netgear WNR854T network port LEDs Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 14:29 ` Jamie Lentin
2016-07-16 20:53 ` [PATCH v0 00/10] Convert Netgear WNR854T to devicetree Andrew Lunn
2016-07-16 20:53 ` Andrew Lunn
2016-07-17 12:52 ` Jamie Lentin
2016-07-17 12:52 ` Jamie Lentin
2016-07-17 15:33 ` Andrew Lunn [this message]
2016-07-17 15:33 ` Andrew Lunn
2016-07-19 9:33 ` Jamie Lentin
2016-07-19 9:33 ` Jamie Lentin
2016-07-19 14:01 ` Andrew Lunn
2016-07-19 14:01 ` Andrew Lunn
2016-07-19 14:16 ` Andrew Lunn
2016-07-19 15:04 ` Vivien Didelot
[not found] ` <1468679348-10522-1-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-26 9:20 ` [PATCH 0/8] " Jamie Lentin
2016-08-26 9:20 ` Jamie Lentin
[not found] ` <1472203264-21089-1-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-26 9:20 ` [PATCH 1/8] arm: orion5x: Add documentation for SoC and board bindings Jamie Lentin
2016-08-26 9:20 ` Jamie Lentin
2016-08-26 9:20 ` [PATCH 2/8] arm: orion5x: Add clk support for mv88f5181 Jamie Lentin
2016-08-26 9:20 ` Jamie Lentin
[not found] ` <1472203264-21089-3-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-26 11:34 ` LABBE Corentin
2016-08-26 11:34 ` LABBE Corentin
2016-08-26 12:24 ` Jamie Lentin
2016-08-26 12:24 ` Jamie Lentin
2016-08-26 14:24 ` Andrew Lunn
2016-08-26 14:24 ` Andrew Lunn
2016-08-26 9:20 ` [PATCH 3/8] arm: orion5x: Generalise mv88f5181l pinctrl support for 88f5181 Jamie Lentin
2016-08-26 9:20 ` Jamie Lentin
2016-08-26 9:21 ` [PATCH 4/8] arm: orion5x: Alias uart0 to serial0 for all orion5x Jamie Lentin
2016-08-26 9:21 ` Jamie Lentin
[not found] ` <1472203264-21089-5-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-26 14:54 ` Andrew Lunn
2016-08-26 14:54 ` Andrew Lunn
2016-09-12 21:12 ` Arnd Bergmann
2016-09-12 21:12 ` Arnd Bergmann
2016-08-26 9:21 ` [PATCH 5/8] arm: orion5x: Add DT include for mv88f5181 Jamie Lentin
2016-08-26 9:21 ` Jamie Lentin
[not found] ` <1472203264-21089-6-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-26 14:55 ` Andrew Lunn
2016-08-26 14:55 ` Andrew Lunn
2016-08-31 15:15 ` Rob Herring
2016-08-31 15:15 ` Rob Herring
2016-08-26 9:21 ` [PATCH 6/8] arm: orion5x: Add DT-based support for Netgear WNR854T Jamie Lentin
2016-08-26 9:21 ` Jamie Lentin
[not found] ` <1472203264-21089-7-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-31 15:26 ` Rob Herring
2016-08-31 15:26 ` Rob Herring
2016-09-05 21:07 ` [PATCH 6/8 v2] " Jamie Lentin
2016-09-05 21:07 ` Jamie Lentin
[not found] ` <1473109646-23366-1-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-09-08 12:41 ` Gregory CLEMENT
2016-09-08 12:41 ` Gregory CLEMENT
[not found] ` <87d1kebm2o.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2016-09-08 16:47 ` Jamie Lentin
2016-09-08 16:47 ` Jamie Lentin
2016-09-12 17:06 ` Rob Herring
2016-09-12 17:06 ` Rob Herring
2016-09-12 21:13 ` Arnd Bergmann
2016-09-12 21:13 ` Arnd Bergmann
2016-09-12 21:19 ` Arnd Bergmann
2016-09-12 21:19 ` Arnd Bergmann
2016-09-12 22:03 ` Andrew Lunn
2016-09-12 22:03 ` Andrew Lunn
[not found] ` <20160912220344.GM11400-g2DYL2Zd6BY@public.gmane.org>
2016-09-13 9:10 ` Jamie Lentin
2016-09-13 9:10 ` Jamie Lentin
[not found] ` <88e40f0c6cafec244dc16af5a03cfb44-SBYVURHw+sBNwP/n92qj9LVCufUGDwFn@public.gmane.org>
2016-09-13 12:36 ` Andrew Lunn
2016-09-13 12:36 ` Andrew Lunn
[not found] ` <20160913123639.GB15332-g2DYL2Zd6BY@public.gmane.org>
2016-09-13 14:15 ` Jamie Lentin
2016-09-13 14:15 ` Jamie Lentin
[not found] ` <b7d442f9d26249976d7698b6a32db2a3-SBYVURHw+sBNwP/n92qj9LVCufUGDwFn@public.gmane.org>
2016-09-13 19:16 ` Gregory CLEMENT
2016-09-13 19:16 ` Gregory CLEMENT
[not found] ` <87r38nehkj.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
2016-09-13 20:39 ` Arnd Bergmann
2016-09-13 20:39 ` Arnd Bergmann
2016-08-26 9:21 ` [PATCH 7/8] arm: orion5x: Remove old non-DT-based WNR854T support Jamie Lentin
2016-08-26 9:21 ` Jamie Lentin
[not found] ` <1472203264-21089-8-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-26 14:59 ` Andrew Lunn
2016-08-26 14:59 ` Andrew Lunn
2016-08-26 9:21 ` [PATCH 8/8] arm: orion5x: Configure WNR854T ethernet PHY LEDs Jamie Lentin
2016-08-26 9:21 ` Jamie Lentin
[not found] ` <1472203264-21089-9-git-send-email-jm-Pj/HzkgeCk7QXOPxS62xeg@public.gmane.org>
2016-08-26 15:05 ` Andrew Lunn
2016-08-26 15:05 ` Andrew Lunn
2016-08-26 15:05 ` Andrew Lunn
2016-08-26 15:05 ` Andrew Lunn
2016-08-26 12:09 ` [PATCH 0/8] Convert Netgear WNR854T to devicetree Imre Kaloz
2016-08-26 12:09 ` Imre Kaloz
2016-08-26 12:56 ` Jamie Lentin
2016-08-26 12:56 ` Jamie Lentin
[not found] ` <alpine.DEB.2.11.1608261325310.19980-5X291BYdrx55rAo4AelP/Ydd74u8MsAO@public.gmane.org>
2016-08-26 14:33 ` Andrew Lunn
2016-08-26 14:33 ` Andrew Lunn
2016-08-26 16:50 ` Jamie Lentin
2016-08-26 16:50 ` Jamie Lentin
[not found] ` <alpine.DEB.2.11.1608261703460.19980-5X291BYdrx55rAo4AelP/Ydd74u8MsAO@public.gmane.org>
2016-08-26 20:30 ` Imre Kaloz
2016-08-26 20:30 ` Imre Kaloz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160717153338.GA13611@lunn.ch \
--to=andrew@lunn.ch \
--cc=f.fainelli@gmail.com \
--cc=gregory.clement@free-electrons.com \
--cc=jason@lakedaemon.net \
--cc=jm@lentin.co.uk \
--cc=kaloz@openwrt.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=netdev@vger.kernel.org \
--cc=sebastian.hesselbarth@gmail.com \
--cc=vivien.didelot@savoirfairelinux.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.