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 ---Hi, On Fri, Aug 17, 2018 at 12:05 PM Jonas Gorski <[email protected]> wrote: > > Hi, > > On 16 August 2018 at 05:05, Chuanhong Guo <[email protected]> wrote: > > Signed-off-by: Chuanhong Guo <[email protected]> > > --- > > RFC: > > Previous discussion about this patch can be found on GitHub PR#1271. > > This patch applies correct interface mode to MII0/1_CNTL register at > > 0x18070000/ > > 0x18070004. But there is a small difference in values for these two > > registers: > > | GMAC0 | GMAC1 | > > |----------|---------| > > | 0 GMII | 0 RGMII | > > | 1 MII | 1 RMII | > > | 2 RGMII | | > > | 3 RMII | | > > I currently have 4 ways of dealing with this: > > 1. Use a bool value in dts indicating whether this is the second GMAC. This > > one > > is pretty dirty and I dropped it. > > 2. Split MII_CNTL into separated dt node and use different compatible for > > them > > like we did for ETH_CFG (gmac node) on ar933x and later SoCs. After some > > discussion > > on GitHub it turns out to be unreasonable to treat those in separated > > nodes. > > 3. Use ar7100-eth0/ar7100-eth1 as compatible string. This is what I've done > > in > > this patch I sent here. But I think my way of using compatible string > > here is ugly :( > > A possible cleaner implementation would be introducing > > ar7100-eth0/ar7100-eth1/ > > ar9130-eth0/ar9130-eth1 to replace ar7100-eth/ar9130-eth. But I doubt > > whether > > introducing 4 new compatible strings for such a slight difference is > > worthy. as already stated on the github PR I prefer option #3 > > 4. Somehow write all the possible values for each interface mode in device > > tree. > > e.g. qca,if-modes = "gmii","mii","rgmii","rmii"; for eth0 and > > qca,if-modes = "rgmii","rmii"; for eth1. this would encode register values in a devicetree property (index of each string is the register value) I believe that upstream devicetree maintainers don't want this anymore the rule of thumb is: devicetree should describe the hardware (not register contents or driver settings) because it should be "universal" (some bootloaders use it, Linux uses it, ...) if two devices are compatible they can use the same compatible string however, if they are different (even just slightly) they should get their own compatible string (see the stmmac bindings upstream for an example: Documentation/devicetree/bindings/net/stmmac.txt contains the original stmmac bindings while Documentation/devicetree/bindings/net/meson-dwmac.txt / Documentation/devicetree/bindings/net/stm32-dwmac.txt define new compatible strings because each vendor has defined it's own extensions to the original stmmac IP block) > > Which one is better? Is there any other possible solutions for this problem? > > I'd prefer 4, or a modified 3: > > do something like > > aliases { > .... > ethernet0 = ð0; > ethernet1 = ð1; > }; > > > and then you can find out if you are eth0 or eth1 by calling > > id = of_alias_get_id(node, "ethernet"); > > and maybe warn (and don't configure mii mode) if it returns neither 0 or 1. this is an interesting idea do you have any upstream example where this behavior was reviewed (and ACK'ed) by the upstream devicetree maintainers? (I found some examples relying on that exact behavior, but I'm not sure if the devicetree maintainers know about this code/want this solution to be used in the future) Regards Martin
--- End Message ---
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
