Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp906281rwl; Wed, 5 Apr 2023 09:11:15 -0700 (PDT) X-Google-Smtp-Source: AKy350b10rsm7i+zQ9DCxK3T5BL7QDpw7JlJ6y+ie9ItiMJcwTZ9/4NzBQefvRxUlMk2U2gH7x+P X-Received: by 2002:a17:903:110d:b0:1a1:b36d:7803 with SMTP id n13-20020a170903110d00b001a1b36d7803mr8860451plh.36.1680711074876; Wed, 05 Apr 2023 09:11:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680711074; cv=none; d=google.com; s=arc-20160816; b=Qd4FJ3w/Kj9iSYGdphKNq1jagdyD+CIF0TnSHqd4HkEYrzr63uQyXaUTuDT8HQuqzS OrA0A2jAOnp0QVIO3vymsWwdtjsSTHpBfvG79KnYJXwmirx7P/mkiEywkYS32oquor+B mlYEb7zU/yJyDWU1MFYEjSIWZ/rNRismoTf8wynOeOPI4W/+uO3XNUCXvcTiIhOCo+lW NteIZC1y9TptGKjBzJ7gOs2KHog0RunFhy+CfWr2a9wa4MnpKiEmcdQKOGYSl/ViOZuf IUlGcDQo4W6DVjuGRcHSfZ+5vgYcUGCowfyie7jndzXMEbeUK7UyNkxMG8uZWq7nTCTK 17MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=sazrJU4w8BvwcUrOpjX/vjDRrO2IbyUUqQvpLwhaH7k=; b=j8QFXub/ji06h2fAcmiFGmIDfwyT1Dr6RnIcmRGZSpKeLsBp3R/1NZfbOyb1namOU6 JS5/dZm39ZhdHQnV7SLjVtHSaCCQTq/U4RB7hyQSDyinWZ84IgotrSgxKFAxK3+40Jgj NYqdMbx0vk7E0m7GaSr6c7YfWmflvWYk+bIAkmibMpe0/swlZvgOznPw+XzNbfpS46pp 5N60WybJFFceY8G+l+YWrBhHXLXWfiIk4APdDSjy4Xw4DH6dhKU4aJIuUOVO2kpF8oMG l6NTkahyl9FZnegmdlQ3EbsJHOqKK1Hb3Keqc5JwOnq/lQCAqTbxbh11itlVnIOw14Z8 zj+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="1A/fF0lX"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c10-20020a170902f30a00b001a1be5ca65asi11983905ple.528.2023.04.05.09.11.02; Wed, 05 Apr 2023 09:11:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b="1A/fF0lX"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235669AbjDEQGo (ORCPT + 99 others); Wed, 5 Apr 2023 12:06:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57548 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231269AbjDEQGl (ORCPT ); Wed, 5 Apr 2023 12:06:41 -0400 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0151659CD; Wed, 5 Apr 2023 09:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=sazrJU4w8BvwcUrOpjX/vjDRrO2IbyUUqQvpLwhaH7k=; b=1A/fF0lXMxmJYKpvJL/EEpXji3 7MnzCQeJXXZyH4TdJYoaLcfPHniiMY6hAej8r5IcFsnddrNlnuI1k7KbuXsOzhdejLx/5O4H2cJsP k+4WKpKM6UPPg9a2A2LU9Ajt+q+H3LUSKpajZ5GOU6fvtpqKcrSZ+PvSlp9Hwj45wB58=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1pk5eI-009XMT-0P; Wed, 05 Apr 2023 18:06:14 +0200 Date: Wed, 5 Apr 2023 18:06:13 +0200 From: Andrew Lunn To: Marco Felsch Cc: Heiner Kallweit , Russell King , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Florian Fainelli , Broadcom internal kernel review list , Richard Cochran , Radu Pirea , Shyam Sundar S K , Yisen Zhuang , Salil Mehta , Jassi Brar , Ilias Apalodimas , Iyappan Subramanian , Keyur Chudgar , Quan Nguyen , "Rafael J. Wysocki" , Len Brown , Rob Herring , Frank Rowand , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, devicetree@vger.kernel.org, kernel@pengutronix.de Subject: Re: [PATCH 06/12] net: phy: add phy_device_atomic_register helper Message-ID: References: <20230405-net-next-topic-net-phy-reset-v1-0-7e5329f08002@pengutronix.de> <20230405-net-next-topic-net-phy-reset-v1-6-7e5329f08002@pengutronix.de> <20230405152225.tu3wmbcvchuugs5u@pengutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230405152225.tu3wmbcvchuugs5u@pengutronix.de> X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > The current fwnode_mdio.c don't provide the proper helper functions yet. > Instead the parsing is spread between fwnode_mdiobus_register_phy() and > fwnode_mdiobus_phy_device_register(). Of course these can be extracted > and exported but I don't see the benefit. IMHO it just cause jumping > around files and since fwnode is a proper firmware abstraction we could > use is directly wihin core/lib files. No, assuming fwnode is the proper firmware abstraction is wrong. You need to be very careful any time you convert of_ to fwnode_ and look at the history of every property. Look at the number of deprecated OF properties in Documentation/devicetree/bindings. They should never be moved to fwnode_ because then you are moving deprecated properties to ACPI, which never had them in the first place! You cannot assume DT and ACPI are the same thing, have the same binding. And the same is true, in theory, in the opposite direction. We don't want the DT properties polluted with ACPI only properties. Not that anybody takes ACPI seriously in networking. > I know and I thought about adding the firmware parsing helpers first but > than I went this way. I can split this of course to make the patch > smaller. Please do. Also, i read your commit message thinking it was a straight copy of the code, and hence i did not need to review the code. But in fact it is new code. So i need to take a close look at it. But what i think is most important for this patchset is the justification for not fixing the current API. Why is it broken beyond repair? Andrew