Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Christian Herber <christian.herber@nxp.com>
To:     Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>
CC:     "davem@davemloft.net" <davem@davemloft.net>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Re: [PATCH net-next 0/1] Add BASE-T1 PHY support
Thread-Topic: Re: [PATCH net-next 0/1] Add BASE-T1 PHY support
Thread-Index: AQHVWLnFOZqG4EcHiU275uWw+5j6mA==
Date:   Thu, 22 Aug 2019 07:18:18 +0000
Message-ID: <AM6PR0402MB3798C702793071E34A5659ED86A50@AM6PR0402MB3798.eurprd04.prod.outlook.com>
References: <20190815153209.21529-1-christian.herber@nxp.com>
 <8c15b855-6947-9930-c3df-71a64fbff33b@gmail.com>
 <AM6PR0402MB379864B810F08D3698618B5F86A80@AM6PR0402MB3798.eurprd04.prod.outlook.com>
 <13e65051-fe4f-5964-30b3-75285e6d2eee@gmail.com>
 <AM6PR0402MB3798FCBF1EE592687B13A3C386AB0@AM6PR0402MB3798.eurprd04.prod.outlook.com>
 <5c920846-b8f5-d087-cea4-a8ca3f816127@gmail.com>
 <20190821185715.GA16401@lunn.ch>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: nxp.com does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f8960d3b-22c3-4385-d5b9-08d726d0e867
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2019 07:18:18.9557
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 686ea1d3-bc2b-4c6f-a92c-d99c5c301635
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ns8h476ulbU5m6JCNtQwAo38lJoe3aeIl4v8NMN68EEs9RuS7bcQV2WLtlaWSFuqGszBbMaiMY7uboVqk4CHVbcfwh3AEGmc5baltDeCuzI=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0402MB3877
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 21.08.2019 20:57, Andrew Lunn wrote:=0A=
> =0A=
>> The current patch set IMO is a little bit hacky. I'm not 100% happy=0A=
>> with the implicit assumption that there can't be devices supporting=0A=
>> T1 and classic BaseT modes or fiber modes.=0A=
>=0A=
>> Andrew: Do you have an opinion on that?=0A=
> =0A=
> Hi Heiner=0A=
> =0A=
> I would also like cleaner integration. I doubt here is anything in the=0A=
> standard which says you cannot combine these modes. It is more a=0A=
> marketing question if anybody would build such a device. Maybe not=0A=
> directly into a vehicle, but you could imaging a mobile test device=0A=
> which uses T1 to talk to the car and T4 to connect to the garage=0A=
> network?=0A=
> =0A=
> So i don't think we should limit ourselves. phylib should provide a=0A=
> clean, simple set of helpers to perform standard operations for=0A=
> various modes. Drivers can make use of those helpers. That much should=0A=
> be clear. If we try to make genphy support them all simultaneously, is=0A=
> less clear.=0A=
> =0A=
>       Andrew=0A=
> =0A=
=0A=
If you want to go down this path, then i think we have to ask some more =0A=
questions. Clause 45 is a very scalable register scheme, it is not a =0A=
specific class of devices and will be extended and extended.=0A=
=0A=
Currently, the phy-c45.c supports 10/100/1000/2500/5000/10000 Mbps =0A=
consumer/enterprise PHYs. This is also an implicit assumption. The =0A=
register set (e.g. on auto-neg) used for this will also only support =0A=
these modes and nothing more, as it is done scaling.=0A=
=0A=
Currently not supported, but already present in IEEE 802.3:=0A=
- MultiGBASE-T (25/40 Gbps) (see e.g. MultiGBASE-T AN control 1 register)=
=0A=
- BASE-T1=0A=
- 10BASE-T1=0A=
- NGBASE-T1=0A=
=0A=
And surely there are some on the way or already there that I am not =0A=
aware of.=0A=
=0A=
To me, one architectural decision point is if you want to have generic =0A=
support for all C45 PHYs in one file, or if you want to split it by =0A=
device class. I went down the first path with my patch, as this is the =0A=
road gone also with the existing code.=0A=
=0A=
If you want to split BASE-T1, i think you will need one basic C45 =0A=
library (genphy_c45_pma_read_abilities() is a good example of a function =
=0A=
that is not specific to a device class). On the other hand, =0A=
genphy_c45_pma_setup_forced() is not a generic function at this point as =
=0A=
it supports only a subset of devices managed in C45.=0A=
=0A=
I tend to agree with you that splitting is the best way to go in the =0A=
long run, but that also requires a split of the existing phy-c45.c into =0A=
two IMHO.=0A=