[<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
 
