From: Andrew Lunn <andrew@lunn.ch> To: Jakub Kicinski <kuba@kernel.org> Cc: "Machnikowski, Maciej" <maciej.machnikowski@intel.com>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, "intel-wired-lan@lists.osuosl.org" <intel-wired-lan@lists.osuosl.org>, "richardcochran@gmail.com" <richardcochran@gmail.com>, "abyagowi@fb.com" <abyagowi@fb.com>, "Nguyen, Anthony L" <anthony.l.nguyen@intel.com>, "davem@davemloft.net" <davem@davemloft.net>, "linux-kselftest@vger.kernel.org" <linux-kselftest@vger.kernel.org>, Michal Kubecek <mkubecek@suse.cz>, Saeed Mahameed <saeed@kernel.org>, Michael Chan <michael.chan@broadcom.com> Subject: Re: [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status Date: Thu, 9 Sep 2021 01:14:36 +0200 [thread overview] Message-ID: <YTlD3Gok7w/MF+g2@lunn.ch> (raw) In-Reply-To: <20210908151852.7ad8a0f1@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> > As you said, pin -> ref mapping is board specific, so the API should > not assume knowledge of routing between Port and ECC. That information will probably end up in device tree. And X different implementations of ACPI, unless somebody puts there foot down and stops the snow flakes. > Imagine a system with two cascaded switch ASICs and a bunch of PHYs. > How do you express that by pure extensions to the proposed API? Device tree is good at that. ACPI might eventually catch up. How complex a setup do we actually expect? Can there be multiple disjoint SyncE trees within an Ethernet switch cluster? Or would it be reasonable to say all you need to configure is the clock source, and all other ports of the switches are slaves if SyncE is enabled for the port? I've never see any SOHO switch hardware which allows you to have disjoint PTP trees, so it does not sound too unreasonable to only allow a single SyncE tree per switch cluster. Also, if you are cascading switches, you generally don't put PHYs in the middle, you just connect the SERDES lanes together. Andrew
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Lunn <andrew@lunn.ch> To: intel-wired-lan@osuosl.org Subject: [Intel-wired-lan] [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status Date: Thu, 9 Sep 2021 01:14:36 +0200 [thread overview] Message-ID: <YTlD3Gok7w/MF+g2@lunn.ch> (raw) In-Reply-To: <20210908151852.7ad8a0f1@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com> > As you said, pin -> ref mapping is board specific, so the API should > not assume knowledge of routing between Port and ECC. That information will probably end up in device tree. And X different implementations of ACPI, unless somebody puts there foot down and stops the snow flakes. > Imagine a system with two cascaded switch ASICs and a bunch of PHYs. > How do you express that by pure extensions to the proposed API? Device tree is good at that. ACPI might eventually catch up. How complex a setup do we actually expect? Can there be multiple disjoint SyncE trees within an Ethernet switch cluster? Or would it be reasonable to say all you need to configure is the clock source, and all other ports of the switches are slaves if SyncE is enabled for the port? I've never see any SOHO switch hardware which allows you to have disjoint PTP trees, so it does not sound too unreasonable to only allow a single SyncE tree per switch cluster. Also, if you are cascading switches, you generally don't put PHYs in the middle, you just connect the SERDES lanes together. Andrew
next prev parent reply other threads:[~2021-09-08 23:14 UTC|newest] Thread overview: 82+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-03 15:14 [RFC v4 net-next 0/2] Add RTNL interface for SyncE Maciej Machnikowski 2021-09-03 15:14 ` [Intel-wired-lan] " Maciej Machnikowski 2021-09-03 15:14 ` [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status Maciej Machnikowski 2021-09-03 15:14 ` [Intel-wired-lan] " Maciej Machnikowski 2021-09-03 16:18 ` Stephen Hemminger 2021-09-03 16:18 ` [Intel-wired-lan] " Stephen Hemminger 2021-09-03 22:20 ` Machnikowski, Maciej 2021-09-03 22:20 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-03 22:14 ` Jakub Kicinski 2021-09-03 22:14 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-06 18:30 ` Machnikowski, Maciej 2021-09-06 18:30 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-06 18:39 ` Jakub Kicinski 2021-09-06 18:39 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-06 19:01 ` Machnikowski, Maciej 2021-09-06 19:01 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-07 1:01 ` Jakub Kicinski 2021-09-07 1:01 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-07 8:50 ` Machnikowski, Maciej 2021-09-07 8:50 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-07 14:55 ` Jakub Kicinski 2021-09-07 14:55 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-07 15:47 ` Machnikowski, Maciej 2021-09-07 15:47 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-07 19:47 ` Jakub Kicinski 2021-09-07 19:47 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-08 8:03 ` Machnikowski, Maciej 2021-09-08 8:03 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-08 16:21 ` Jakub Kicinski 2021-09-08 16:21 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-08 17:30 ` Machnikowski, Maciej 2021-09-08 17:30 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-08 19:34 ` Andrew Lunn 2021-09-08 19:34 ` [Intel-wired-lan] " Andrew Lunn 2021-09-08 20:27 ` Machnikowski, Maciej 2021-09-08 20:27 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-08 22:20 ` Jakub Kicinski 2021-09-08 22:20 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-08 22:59 ` Andrew Lunn 2021-09-08 22:59 ` [Intel-wired-lan] " Andrew Lunn 2021-09-09 2:09 ` Richard Cochran 2021-09-09 2:09 ` [Intel-wired-lan] " Richard Cochran 2021-09-09 8:18 ` Machnikowski, Maciej 2021-09-09 8:18 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-10 14:14 ` Richard Cochran 2021-09-10 14:14 ` [Intel-wired-lan] " Richard Cochran 2021-09-08 22:18 ` Jakub Kicinski 2021-09-08 22:18 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-08 23:14 ` Andrew Lunn [this message] 2021-09-08 23:14 ` Andrew Lunn 2021-09-08 23:58 ` Jakub Kicinski 2021-09-08 23:58 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-09 8:26 ` Machnikowski, Maciej 2021-09-09 8:26 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-09 9:24 ` Machnikowski, Maciej 2021-09-09 9:24 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-09 10:15 ` David Miller 2021-09-09 10:15 ` [Intel-wired-lan] " David Miller 2021-09-09 8:11 ` Machnikowski, Maciej 2021-09-09 8:11 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-13 8:50 ` Ido Schimmel 2021-09-13 8:50 ` [Intel-wired-lan] " Ido Schimmel 2021-09-21 13:36 ` Ido Schimmel 2021-09-21 13:36 ` [Intel-wired-lan] " Ido Schimmel 2021-09-21 13:15 ` Ido Schimmel 2021-09-21 13:15 ` [Intel-wired-lan] " Ido Schimmel 2021-09-21 13:37 ` Machnikowski, Maciej 2021-09-21 13:37 ` [Intel-wired-lan] " Machnikowski, Maciej 2021-09-21 14:58 ` Ido Schimmel 2021-09-21 14:58 ` [Intel-wired-lan] " Ido Schimmel 2021-09-21 21:14 ` Jakub Kicinski 2021-09-21 21:14 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-22 6:22 ` Ido Schimmel 2021-09-22 6:22 ` [Intel-wired-lan] " Ido Schimmel 2021-09-03 15:14 ` [PATCH net-next 2/2] ice: add support for reading SyncE DPLL state Maciej Machnikowski 2021-09-03 15:14 ` [Intel-wired-lan] " Maciej Machnikowski 2021-09-03 22:06 ` Jakub Kicinski 2021-09-03 22:06 ` [Intel-wired-lan] " Jakub Kicinski 2021-09-21 13:25 ` Ido Schimmel 2021-09-21 13:25 ` [Intel-wired-lan] " Ido Schimmel -- strict thread matches above, loose matches on Subject: below -- 2021-08-31 11:52 [PATCH net-next 0/2] Add RTNL interface for SyncE EEC state Maciej Machnikowski 2021-08-31 11:52 ` [PATCH net-next 1/2] rtnetlink: Add new RTM_GETEECSTATE message to get SyncE status Maciej Machnikowski 2021-08-31 13:44 ` Jakub Kicinski
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=YTlD3Gok7w/MF+g2@lunn.ch \ --to=andrew@lunn.ch \ --cc=abyagowi@fb.com \ --cc=anthony.l.nguyen@intel.com \ --cc=davem@davemloft.net \ --cc=intel-wired-lan@lists.osuosl.org \ --cc=kuba@kernel.org \ --cc=linux-kselftest@vger.kernel.org \ --cc=maciej.machnikowski@intel.com \ --cc=michael.chan@broadcom.com \ --cc=mkubecek@suse.cz \ --cc=netdev@vger.kernel.org \ --cc=richardcochran@gmail.com \ --cc=saeed@kernel.org \ /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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.