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. -- Florian
