Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Message-ID: <10f8e599-940b-4b7c-8c82-8d505007f19b@theobroma-systems.com>
Date:   Mon, 4 Dec 2023 11:14:12 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] net: mdio: enable optional clock when registering a phy
 from devicetree
Content-Language: en-US
To:     Florian Fainelli <f.fainelli@gmail.com>,
        Heiko Stuebner <heiko@sntech.de>, andrew@lunn.ch,
        hkallweit1@gmail.com
Cc:     linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
        kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Heiko Stuebner <heiko.stuebner@cherry.de>
References: <20231201142453.324697-1-heiko@sntech.de>
 <ecbdcfb7-32ab-45cc-991a-982c52bf4b14@gmail.com>
From:   Quentin Schulz <quentin.schulz@theobroma-systems.com>
In-Reply-To: <ecbdcfb7-32ab-45cc-991a-982c52bf4b14@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?N3RuSFE0YVlRQVErWEtjMmlGbVc5aldmQ08yNFdLNUJrWVA3NTFOcVR5RDNz?=
 =?utf-8?B?UlJPQWxJeUpEdVg1Slo0QlNNSEpOKysrWUJmSGNxVnRlbnV5TU9WTDM2T29J?=
 =?utf-8?B?VzlVL2pKQnMvczZiS3dlUzFGRDJuU3kwTXg4TlZmWHBxNDJxN1NKdXF6T2Nq?=
 =?utf-8?B?WSsyaXBDMm5ZQ1krM0FReGlTeWtTVFFpNVMrNzBvdmdOdUlVNitQSUs2Y0VV?=
 =?utf-8?B?L2ZIdS9hOUJzSnNuK2hoNEtSUjFrNzJFaE1IVGRvMXFnK2EvSURSUFhKQzRs?=
 =?utf-8?B?QWRWTk91VFRYTmk2WWVLTVI3bTloNW5CWm5WSmMyYml0cndjTHkrcjY1U3px?=
 =?utf-8?B?RGZGVWsxUG9SV25sYy94amV5YUZwSFMxc1lpYjVpcCtCYkpsNFpCUFFBdU5y?=
 =?utf-8?B?aktjV0V2SnErbkxrVVZZNHllZ3FMMzd0dWNUK2dRaFVOVlVYSVpqMHhDSE85?=
 =?utf-8?B?akMrS042MUdzU29yK2Y4ZHhYSVZsMzdkYWFydnhWT1QzTW9rUTVxblEzdzY5?=
 =?utf-8?B?UG1zN01iK0FhSEl5c29Mb28zajk5U1pQUHdXdFEvdGRMeStaQ0pVNFJiR0t5?=
 =?utf-8?B?MkRYZ1l0S1YxSDVJdWk0UnNsbThaT2o4MDJhYjZrbk12QTk3d2Fhdng1UUky?=
 =?utf-8?B?emJOK1FqOCtLOXF4Y093bUhvdUZtbGdoSnlvUmNQTDZRTkZuZEp6aElRelA4?=
 =?utf-8?B?dCtDb2k3cUZDd3lJNnV3MGRvbzZOS2hXSHpIK3UxYlIzbEd5Zk84MVZpZFll?=
 =?utf-8?B?THdra2xkOGIrdVIyMmRub0JzdnNPSlFlNGdUNllIMGZqbjZFS05QNUFQQXZq?=
 =?utf-8?B?cEFkSy9lQnQ1OCs2OE5BYzlBM3Yvc1NJRk5LUGFkUmRTc3NiTXBySVBHRmx5?=
 =?utf-8?B?SGM1Ly9LZytiYitrWW95K3F4d25wNGpISnp3a1Vqb0FOUWlzMGF0NU05aStX?=
 =?utf-8?B?RVZHZm5KQUpqQU5ScHdHVjNxYS9sU1owK3NOWlg3bTBXZGk0WUFaeml3a0tV?=
 =?utf-8?B?TldFRlNKVFJFRGE5cW8vT2Y4T3ZLWGcrNFdwNW16MERidWVodmoydnZmdkw2?=
 =?utf-8?B?N1p5aWJKNkpvcTJDUGZ4Wi91Mm5ia2NQZ3RIRnBCbDlsRTVBQjFtU3hMZitQ?=
 =?utf-8?B?N1IrSDd4c1dNZ2VyV2hGRjFLdWdxQTVBcXNpQ2pzVVpRWVEzNFZkVlRQejJZ?=
 =?utf-8?B?d1RJOWdvTFJjRzBnSkJYUmxiT3lKVlZtTWo2dytiOWtJbExIa3hkRDYwaXky?=
 =?utf-8?B?ZDAvekcwN1oyU3ozN1JjQUo3NDl0R29qd3FrdnUweHh1UHZHOFJPRGtXc0xH?=
 =?utf-8?B?TmUyaUpqNTJqQS84RmZtdVBKWW5xdk9GeHByaVR5RTgrSnpxNkhPS2FLZitO?=
 =?utf-8?B?b3FkQUNnSTFOZCtCSWt5L0JyV3RlMEFZdVJMdzVEMkpsZFUvS053Q0x4cWN2?=
 =?utf-8?B?cUdwUHFtUDVXaVJVN2kraU5QUFl6ZzZJa2ovUzRFbkhodFdreU1MbmhTQTFR?=
 =?utf-8?B?b3RMdGcrNC9qQzUvZFRpOUtMb1p4cVlCTnFtOXgybUNJNmE3QUFCYWNzbnNL?=
 =?utf-8?B?cDhKa0hLalh3UHVZZVAwaTQ0UFkybkdxTVRQZm0wbi84TEgyd3BBaG45ZFZo?=
 =?utf-8?B?NldnZFhYeGZMb3R1UjRDa21Td0d3R2xaS2xUYjNtWVVQRmJpSHEwR0VsQUMx?=
 =?utf-8?B?bjgyb2l5L3pIMGRDYUtHUktDaW10LzlUamo2UmxPWWJKUkdWckF4RGtBamk0?=
 =?utf-8?B?Um9pY2dLTG5Jc043QWtsVjUxTzd0SWE3MGsxWkhWaytBVWZvUzBJY2JpN3BM?=
 =?utf-8?B?aUxYMXFwKzM3ZGY5a0lPMUhzSlZkSzNpMVRQaTJSMk9kaXc4Qy91WTVwRWV4?=
 =?utf-8?B?Wjg2ejJOSnFLQVI2ZHFobUw4bVc5cVpSNnFEVG1PVGN0N2ZxUUg2UjdnVUw3?=
 =?utf-8?B?TGhmYW1jcVhHZ1lCMHlnWUVjaER0VWljTWlMUUV6ZXIzWndlOHBKRGdxSXNj?=
 =?utf-8?B?eTlMV1hBbURBMjRkRFpKejBtWWNOd2YrR1lDVHB2TnQrdWdRcll2dDhMK1pQ?=
 =?utf-8?B?NTZPTFFSeEsrTEs3QjdtUVJjZ3pzZlFCdUx4TkFsNzJLUFFWT2VyczhOS1Yv?=
 =?utf-8?B?OUVwUmNWQ1JNZ3YwSzlucjRNWk5mRlprTGZCazlwWFhaMWhvNVpHWllnU2s0?=
 =?utf-8?Q?/ledJB8EMF87ihbRRgv5rAs=3D?=
X-OriginatorOrg: theobroma-systems.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 583cfd83-2c37-413c-f752-08dbf4b1c4c3
X-MS-Exchange-CrossTenant-AuthSource: DU2PR04MB8536.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Dec 2023 10:14:15.1956
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5e0e1b52-21b5-4e7b-83bb-514ec460677e
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: IoQ/uNof/tSYM4dw8zrkZMEeGZwZigVpoyc7fY9JQni7vj0lBwvM6oM3y1rZqzVcm8RtDd4wsc4EGxgu2G3dC5i8jVrAEyGe/2wuelrZri6yiTFVHKBTnFERhMvLJWAe
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DUZPR04MB9781
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,
	SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable
	autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Mon, 04 Dec 2023 02:14:29 -0800 (PST)

Hi Florian, Heiko,

On 12/1/23 23:41, Florian Fainelli wrote:
> On 12/1/23 06:24, Heiko Stuebner wrote:
>> From: Heiko Stuebner <heiko.stuebner@cherry.de>
>>
>> The ethernet-phy binding (now) specifys that phys can declare a clock
>> supply. Phy driver itself will handle this when probing the phy-driver.
>>
>> But there is a gap when trying to detect phys, because the mdio-bus needs
>> to talk to the phy to get its phy-id. Using actual phy-ids in the dt like
>>         compatible = "ethernet-phy-id0022.1640",
>>                      "ethernet-phy-ieee802.3-c22";
>> of course circumvents this, but in turn hard-codes the phy.
> 
> But it is the established practice for situations like those where you 
> need specific resources to be available in order to identify the device 
> you are trying to probe/register.
> 
> You can get away here with the clock API because it can operate on 
> device_node, and you might be able with a bunch of other "resources" 
> subsystems, but for instance with regulators, that won't work, we need a 
> "struct device" which won't be created because that is exactly what we 
> are trying to do.
> 
> Also this only works for OF, not for ACPI or other yet to come firmware 
> interface.
> 
> Sorry but NACK.
> 
> I am sympathetic to the idea that if you have multiple boards and you 
> may have multiple PHY vendors this may not really scale, but in 2023 you 
> have boot loaders aware of the Device Tree which can do all sorts of 
> live DTB patching to provide the kernel with a "perfect" view of the world.

There's a strong push towards unifying the device tree across all pieces 
of SW involved, sometimes going as far as only having one binary passed 
between SW stages (e.g. U-Boot passes its own DT to TF-A, and then to 
the Linux kernel without actually loading anything aside from the Linux 
kernel Image binary) if I remember correctly (haven't really followed 
tbh). So, this is kinda a step backward for this effort. I don't like 
relying on bootloader to make the kernel work, this is usually not a 
great thing. I understand the reasons but am still a bit sad to not see 
this done in the kernel.

Heiko, I would personally put the ID of the PHY to be the most likely 
encountered in the Linux kernel Device Tree so that if we somehow have a 
broken bootloader, there's a chance some devices still work properly. HW 
department said ksz9131 so we can go forward with this. In U-Boot DT, we 
would need a -u-boot.dtsi we change to the auto-detection compatible and 
we do the magic the Linux kernel doesn't want to do and hope it's fine 
for U-Boot maintainers. Once properly detected, we fixup the DT before 
booting the kernel.

Cheers,
Quentin