On 17.07.20 22:39, Florian Fainelli wrote:
On 7/17/2020 1:29 PM, Matthew Hagan wrote:
On 16/07/2020 23:09, Jakub Kicinski wrote:
On Mon, 13 Jul 2020 21:50:26 +0100 Matthew Hagan wrote:
Add names and decriptions of additional PORT0_PAD_CTRL properties.
Signed-off-by: Matthew Hagan <mnhagan88@xxxxxxxxx>
---
Documentation/devicetree/bindings/net/dsa/qca8k.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
index ccbc6d89325d..3d34c4f2e891 100644
--- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt
+++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt
@@ -13,6 +13,14 @@ Optional properties:
- reset-gpios: GPIO to be used to reset the whole device
+Optional MAC configuration properties:
+
+- qca,exchange-mac0-mac6: If present, internally swaps MAC0 and MAC6.
Perhaps we can say a little more here?
From John's patch:
"The switch allows us to swap the internal wirering of the two cpu ports.
For the HW offloading to work the ethernet MAC conencting to the LAN
ports must be wired to cpu port 0. There is HW in the wild that does not
fulfill this requirement. On these boards we need to swap the cpu ports."
This option is somewhat linked to instances where both MAC0 and MAC6 are
used as CPU ports. I may omit this for now since support for this hasn't
been added and MAC0 is hard-coded as the CPU port. The initial intention
here was to cover options commonly set by OpenWrt devices, based upon
their ar8327-initvals, to allow migration to qca8k.
If you update the description of the property, I do not see a reason why
this should not be supported as of today, sooner or later you will need
it to convert more devices to qca8k as you say.
correct, there will be patches soonish to make qcom dakota and
hawkeye/cypress use qca8k as their switch fabric is 95% identical. we
already started working on it. it is mmio based rather than mdio based,
so the patch is quite a large rework right now.
John
