Re: [PATCH 2/2] dt-bindings: net: dsa: qca8k: Add PORT0_PAD_CTRL properties

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 17.07.20 22:29, 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.


correct, specifically quantenna designs do this, also saw ciscos swap mac0/6 for cpu port, that part of the patch is definitely safe to go. I stumbled across this while making qca8k work for g-fiber on a quantenna SoC.

in regards to the sgmii clk skew. I never understood the electrics fully I am afraid, but without the patch it simply does not work. my eletcric foo is unfortunately is not sufficient to understand the "whys" I am afraid.

    John




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux