[LEDE-DEV] [PATCH v2] ipq806x: Add support for ipq40xx AP-DK01.1-C1 and AP-DK04.1-C1

[Christian Lamparter]

On Tuesday, May 23, 2017 12:41:41 PM CEST Ram Chandra Jangir wrote:
> On Freitag, Monday, May 22, 2017 7:22 PM Sven Eckelmann wrote:
> >On Freitag, 21. April 2017 00:25:37 CEST Ram Chandra Jangir wrote:
> > +@@ -419,18 +424,19 @@
> > +                       status = "disabled";
> > +
> > +                       gmac0: gmac0 {
> > +                               local-mac-address = [00 00 00 00 00 00];
> > +-                              vlan_tag = <1 0x1f>;
> > +-                      };
> > +-
> > +-                      gmac1: gmac1 {
> > +-                              local-mac-address = [00 00 00 00 00 00];
> > +                               qcom,phy_mdio_addr = <4>;
> > +                               qcom,poll_required = <1>;
> > +                               qcom,forced_speed = <1000>;
> > +                               qcom,forced_duplex = <1>;
> > +                               vlan_tag = <2 0x20>;
> > +                       };
> > ++
> > ++                      gmac1: gmac1 {
> > ++                              local-mac-address = [00 00 00 00 00 00];
> > ++                              qcom,poll_required_dynamic = <1>;
> > ++                              vlan_tag = <1 0x1e>;
> > ++                      };
> 
> >Why did you swap the gmac0 and gmac1 interface? I would guess that you have
> to fix the network setup for the other devices (qcom-ipq4019-rt-ac58u.dts,
> qcom- ipq4019-nbg6617.dts, qcom-ipq4019-fritz4040.dts) when you do that.
> 
> >Kind regards,
> >	Sven
> 
> Thanks Sven,
> 
> Normally we configure gmac0 for  WAN group and gmac1 for  LAN group,
> existing ipq806x boards are also following the same, and we would like to
> continue with the  same convention. I do not see any reason to deviate this
> in ipq40xx based boards.
>
> I agree that ac58u nbg6617 and fritz4040 needs some changes, and Christian
> can help us to make the same.
No. I commented on this issue in v1 of this patch:

<https://www.mail-archive.com/lede-dev@lists.infradead.org/msg07018.html>
| For the record: eth1 IS NOT a separate MAC. From what I can tell, the
| essedma driver just maps different VLANs to multiple ethX instances. 
| So both eth0 and eth1 share the same PSGMII link to the QCA8075. 
| Therefore I suggest to let the kernel handle the VLAN and switch to:
|
|        ucidef_add_switch "switch0" \
|                "0 at eth0" "1:lan" "2:lan" "3:lan" "4:lan" "5:wan"
|
|                (the ucidef_set_interfaces_lan_wan gets removed)
|
|This will create eth0.1 and eth0.2 instead of eth0 and eth1.
|I've already tested this and made a patch:
|<https://github.com/chunkeey/LEDE-IPQ40XX/commit/608803737f1c072d3be141f5d8561bc8dd9a4c2d>
| [@John, I think this should fix the weird VLAN issues you had with your box]
|(I'm waiting for AP devices with a AR8036 to see how they behave here)

There's no GMAC1/eth1. it's just a virtual construct in the
essedma driver that is not upstreamable. I think any time
spent on reassigning, renaming or rearranging these custom
properties: vlan_tags, phy-mdio-addr, ... is better spend elsewhere...
Like:
 - adding qca8075 support to the existing qca8k driver.
   From what I know John is looking into this.
 - writing a proper DSA driver for the internal ess-switch (1).
 - remove cruft from essedma and get everything upstream.

(1): Chris Blake picked up an Meraki MR33. The MR33 only has a
single PHY chip: QCA8033. It's PHY ID matches the ar8035 and it
is supported by the at803x driver.

However, he ran into a big issue with the current ar40xx.c code.
The internal ess-switch does not have a working autoneg for connected
single PHYs. Meraki solved this by polling the QCA8033's MII status
register and forcing the ess-switch's port to match its speed and 
duplex setting. This will need to be addressed as well!

Thanks,
Christian