The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.
--- Begin Message ---
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@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
--- End Message ---
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
