[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AM0PR04MB70413A15B7BBE8D17FEA363C86D90@AM0PR04MB7041.eurprd04.prod.outlook.com>
Date: Fri, 17 Apr 2020 06:48:46 +0000
From: Christian Herber <christian.herber@....com>
To: Oleksij Rempel <o.rempel@...gutronix.de>,
Andrew Lunn <andrew@...n.ch>
CC: "David S. Miller" <davem@...emloft.net>,
Florian Fainelli <f.fainelli@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>,
Jakub Kicinski <kuba@...nel.org>,
Jonathan Corbet <corbet@....net>,
Michal Kubecek <mkubecek@...e.cz>,
David Jander <david@...tonic.nl>,
"kernel@...gutronix.de" <kernel@...gutronix.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Russell King <linux@...linux.org.uk>,
"mkl@...gutronix.de" <mkl@...gutronix.de>
Subject: RE: [EXT] Re: [PATCH v1] ethtool: provide UAPI for PHY master/slave
configuration.
Hi Oleksij,
>If we will follow strictly to the IEEE 802.3 spec, it should be named:
>
>#define PORT_MODE_UNKNOWN 0x00
>/* this two options will not force some specific mode, only influence
> * the chance to get it */
>#define PORT_TYPE_MULTI_PORT 0x01
>#define PORT_TYPE_SINGLE_PORT 0x02
>/* this two options will force master or slave mode */
>#define PORT_MODE_MASTER 0x03
>#define PORT_MODE_SLAVE 0x04
>
>Please tell, if you have better ideas.
This would be quite in the spirit of 802.3. My assumption is multiport devices preferably operate as master to reduce the amount of clock domain crossing on the multiport device. Of course, it is a bit use case driven and you could configure a preference for master mode also on a single port device. For such use cases the name is confusing. Here,
>#define PORT_MODE_MASTER_PREFERRED 0x01
>#define PORT_MODE_SLAVE_PREFERRED 0x02
might be better.
Christian
Powered by blists - more mailing lists