Netdev Archive on lore.kernel.org help / color / mirror / Atom feed
From: Helmut Grohne <firstname.lastname@example.org> To: Andrew Lunn <email@example.com> Cc: Nicolas Ferre <firstname.lastname@example.org>, Alexandre Belloni <email@example.com>, Ludovic Desroches <firstname.lastname@example.org>, Woojung Huh <email@example.com>, Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>, Vivien Didelot <firstname.lastname@example.org>, Florian Fainelli <email@example.com>, "David S. Miller" <firstname.lastname@example.org>, Jakub Kicinski <email@example.com>, "Rob Herring" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [PATCH] net: dsa: microchip: look for phy-mode in port nodes Date: Wed, 15 Jul 2020 09:31:12 +0200 [thread overview] Message-ID: <20200715073112.GA25047@laureti-dev> (raw) In-Reply-To: <20200714222716.GP1078057@lunn.ch> Hi Andrew, Thank you for the quick reply. On Wed, Jul 15, 2020 at 12:27:16AM +0200, Andrew Lunn wrote: > I think this change is more complex than it needs to be. Only the CPU > port supports different interface modes. So i don't see the need to > handle both dev->interface and p->interface. Just first search > ksz_switch_register() first look in the cpu port node, and if not > found go back to the old location. The rest of the code can stay the > same. The driver supports (among others) the KSZ9897R, which comes with two MAC ports supporting[1, page 8] RGMII/RMII/MII (ports 6 and 7). Both of these can be connected to a CPU, so they can both operate as CPU ports in principle. However, one can only enable tail tagging for one of them at a time[1, page 39]. As the current driver expects tail tagging to be enabled on CPU ports, it doesn't work as is with the driver. It could still be used to form a ring of switches such that a single failing switch would leave two chains of switches attached to the CPU. This kind of failover seems to be part of the DSA vision (but I fail to find a reference at the moment). For these reasons, I think that there can be multiple CPU ports in future. Now there is a trade-off. Either we further encode the assumption of there being only a single CPU port more deeply into the driver (as it already does assume that) or we can take the opportunity to already lift it here with the vision for runtime reconfiguration of switch topologies. You seem to be in favour of more deeply encoding the "there can be only one CPU port" assumption. Based on that assumption, the rest of what you write makes very much sense to me. Is that the direction to go? Helmut  http://ww1.microchip.com/downloads/en/DeviceDoc/KSZ9897R-Data-Sheet-DS00002330D.pdf
next prev parent reply other threads:[~2020-07-15 7:31 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-06-17 8:22 net/dsa/microchip: correct placement of dt property phy-mode? Helmut Grohne 2020-06-17 21:18 ` Andrew Lunn 2020-07-14 12:08 ` [PATCH] net: dsa: microchip: look for phy-mode in port nodes Helmut Grohne 2020-07-14 22:27 ` Andrew Lunn 2020-07-15 7:31 ` Helmut Grohne [this message] 2020-07-15 13:00 ` Andrew Lunn 2020-07-16 7:00 ` Helmut Grohne 2020-07-16 10:07 ` Helmut Grohne 2020-08-20 6:03 ` [RESEND PATCH] " Helmut Grohne 2020-08-24 22:37 ` David Miller 2020-09-04 8:14 ` [PATCH v2] " Helmut Grohne 2020-09-04 12:59 ` Alexandre Belloni 2020-09-04 13:52 ` Andrew Lunn 2020-09-07 6:15 ` Helmut Grohne 2020-09-07 12:55 ` Andrew Lunn 2020-09-08 8:01 ` [PATCH v3] " Helmut Grohne 2020-09-10 19:32 ` David Miller 2020-09-24 8:37 ` [PATCH] net: dsa: microchip: really " Helmut Grohne 2020-09-25 3:10 ` David Miller
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20200715073112.GA25047@laureti-dev \ --email@example.com \ --cc=UNGLinuxDriver@microchip.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).