Message ID | 20240103025334.541682-1-yajun.deng@linux.dev |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-15097-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:6f82:b0:100:9c79:88ff with SMTP id tb2csp4801458dyb; Tue, 2 Jan 2024 18:54:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IFmKuiye987tER7l3trbyuj5Gy7ISSduClCG2bP5Opci0zRE+6Hx0MfuG0GATaRIAVzDK4y X-Received: by 2002:a17:903:1252:b0:1d4:8727:76c7 with SMTP id u18-20020a170903125200b001d4872776c7mr5666293plh.85.1704250470335; Tue, 02 Jan 2024 18:54:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704250470; cv=none; d=google.com; s=arc-20160816; b=n4yJddcq2FvwtxBRJbWlsauNWTTC5UkNY/74j3myDZn+pyMtculTtS61CgMlgMXa3a EIKIrIdjn+Pax/cUXpxp8qG14weZnok3SVk9UqhftaUNobt23p7ca4BIoQXJKB2N+CpH tEIybxc3kh1dUpPyJwmseBqWbH33/jjyy9aA2IXd23z4EWa3P1lIUJUvAwd30PAMXqho 2lpGkXQIyrpXQLnJRwAK+2ymUQ2hzEozHe2Z9FRMMTHOJM1lseMdLRsYoQR7MPMa5NE7 vUZlnjS55AO1jwOlYVE3NxKioMIerASFmlLXFKYZ9wo+W4t10ZG9C7u9sCu+yxCygRql KNuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=jKg88EOc19Ldtm/CDT5Vvu/qnifyLXpVN7rl8hsod6M=; fh=ofXRanw8b8V3fyRJsU3Dni1vkxaQb8bG8RTS/EfAsMo=; b=w0FaKJ8v1PPuuWPHoOOoKbygoA9kmZEcL/9Wgpae2nuL98tkp5x12HikqYQSFndhD+ rXYMu977F0u5LcsRJkBvJT6t+vVZyj7ugXMJhSQFzHrCIIitLmGqaitSIbQmBu0FtNnZ pIMqw27zN2KH/y9bWydOKFBseHsRWiPoii064NGDbnH2ThBgXMtOt2Im97x8ngptsBf8 3vKGjmcaJo+seyeNPJ91FwyM4cwlSpQx70WBjBjv6U+GP+D7Mrlhea7BpusgqfDED4Hc yNqXxL0U2MnT4t4qNr4Ly8iOF6kvUemkg+r5Y03zgYkIbZbmjdyRDb7/DJEPkyo+VL1p 1LUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=IBcYPolr; spf=pass (google.com: domain of linux-kernel+bounces-15097-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15097-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id p14-20020a1709028a8e00b001d45f92c442si14131848plo.462.2024.01.02.18.54.30 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jan 2024 18:54:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-15097-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=IBcYPolr; spf=pass (google.com: domain of linux-kernel+bounces-15097-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15097-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 1F5FC284B8D for <ouuuleilei@gmail.com>; Wed, 3 Jan 2024 02:54:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7BA0311723; Wed, 3 Jan 2024 02:54:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="IBcYPolr" X-Original-To: linux-kernel@vger.kernel.org Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AB0F94A13 for <linux-kernel@vger.kernel.org>; Wed, 3 Jan 2024 02:54:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1704250440; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=jKg88EOc19Ldtm/CDT5Vvu/qnifyLXpVN7rl8hsod6M=; b=IBcYPolrqPHkbUIAacMiHDSykXqfpBH/JtWC+mGENXrqYgL+J+GAviTeW33XVK+uKQ1aUS ej/JQPXJgzMZ1yzFAgvVC05anwGGffEMZwtKkv0a2HHKQVnbVTS0baW3X1EC0h9bgW5f+f OMbJajn+6efsgCyejh9OuK9uc6Zqufo= From: Yajun Deng <yajun.deng@linux.dev> To: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com Cc: andrew@lunn.ch, olteanv@gmail.com, hkallweit1@gmail.com, linux@armlinux.org.uk, przemyslaw.kitszel@intel.com, rmk+kernel@armlinux.org.uk, kabel@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org, Yajun Deng <yajun.deng@linux.dev> Subject: [PATCH net-next v2 0/2] net: phy: Use is_phy_driver() and is_phy_device() Date: Wed, 3 Jan 2024 10:53:32 +0800 Message-Id: <20240103025334.541682-1-yajun.deng@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1787036141104319410 X-GMAIL-MSGID: 1787036141104319410 |
Series |
net: phy: Use is_phy_driver() and is_phy_device()
|
|
Message
Yajun Deng
Jan. 3, 2024, 2:53 a.m. UTC
There is only one flag that can be set in struct mdio_driver_common and mdio_device. We can compare the probe of the driver or the type of the device to implement it. Hence, these flags in struct mdio_driver_common and mdio_device can be removed. Introduce is_phy_driver() and is_phy_device(). Use them test the driver or device. v1 -> v2: remove redundant parens and the exported. Yajun Deng (2): net: phy: Cleanup struct mdio_driver_common and introduce is_phy_driver() net: phy: Introduce is_phy_device() drivers/net/dsa/b53/b53_mdio.c | 2 +- drivers/net/dsa/dsa_loop.c | 2 +- drivers/net/dsa/lan9303_mdio.c | 2 +- drivers/net/dsa/microchip/ksz8863_smi.c | 2 +- drivers/net/dsa/mt7530-mdio.c | 2 +- drivers/net/dsa/mv88e6060.c | 2 +- drivers/net/dsa/mv88e6xxx/chip.c | 2 +- drivers/net/dsa/qca/ar9331.c | 2 +- drivers/net/dsa/qca/qca8k-8xxx.c | 2 +- drivers/net/dsa/realtek/realtek-mdio.c | 2 +- drivers/net/dsa/xrs700x/xrs700x_mdio.c | 2 +- drivers/net/phy/mdio_bus.c | 7 ++-- drivers/net/phy/mdio_device.c | 21 +++++------- drivers/net/phy/phy_device.c | 44 ++++++++++++++----------- drivers/net/phy/xilinx_gmii2rgmii.c | 2 +- drivers/phy/broadcom/phy-bcm-ns-usb3.c | 8 ++--- drivers/phy/broadcom/phy-bcm-ns2-pcie.c | 8 ++--- include/linux/mdio.h | 19 ++--------- include/linux/phy.h | 10 +++--- 19 files changed, 62 insertions(+), 79 deletions(-)
Comments
On Wed, Jan 03, 2024 at 10:53:32AM +0800, Yajun Deng wrote: > There is only one flag that can be set in struct mdio_driver_common and > mdio_device. We can compare the probe of the driver or the type of the > device to implement it. Hence, these flags in struct mdio_driver_common > and mdio_device can be removed. > > Introduce is_phy_driver() and is_phy_device(). Use them test the driver > or device. I'm still not convinced this is useful. Please expand your commit message. One things which might convince me this is useful is if the PHY drivers can make there struct phy_driver structures const. Also, please break this patch series up. You should be able to add the helper is_phy_driver() and make use of it, without changing common. You should be able to add is_phy_device() without changing common. So do these little steps first. The current code is hard to review because these changes are all mixed in with everything else. Once you have done the preparation steps, you can then do the mass change. Andrew --- pw-bot: cr
On Wed, Jan 03, 2024 at 10:53:32AM +0800, Yajun Deng wrote: > There is only one flag that can be set in struct mdio_driver_common and > mdio_device. We can compare the probe of the driver or the type of the > device to implement it. Hence, these flags in struct mdio_driver_common > and mdio_device can be removed. > > Introduce is_phy_driver() and is_phy_device(). Use them test the driver > or device. It is not a good idea to post a new series while discussion of the first is still on-going, even if it has been 24 hours since you last posted a patch. If discussion is still going on, then we don't need the distraction of yet another series to duplicate the comments to. I remain completely unconvinced of the merit of these changes. IMHO, it is pure churn for churn's sake - there is no _real_ benefit. It doesn't fix a bug. It doesn't make the code easier to read. It only satisfies some ideological idea that all drivers should look the same. Unless a very good justification can be found, I am not in favour of changing these drivers. There _may_ be good merit in is_phy_driver() and is_phy_device(), and as Andrew says, that should be done _first_.
On 2024/1/3 22:00, Russell King (Oracle) wrote: > On Wed, Jan 03, 2024 at 10:53:32AM +0800, Yajun Deng wrote: >> There is only one flag that can be set in struct mdio_driver_common and >> mdio_device. We can compare the probe of the driver or the type of the >> device to implement it. Hence, these flags in struct mdio_driver_common >> and mdio_device can be removed. >> >> Introduce is_phy_driver() and is_phy_device(). Use them test the driver >> or device. > It is not a good idea to post a new series while discussion of the first > is still on-going, even if it has been 24 hours since you last posted a > patch. If discussion is still going on, then we don't need the > distraction of yet another series to duplicate the comments to. > > I remain completely unconvinced of the merit of these changes. IMHO, > it is pure churn for churn's sake - there is no _real_ benefit. It > doesn't fix a bug. It doesn't make the code easier to read. It only > satisfies some ideological idea that all drivers should look the same. > > Unless a very good justification can be found, I am not in favour of > changing these drivers. > > There _may_ be good merit in is_phy_driver() and is_phy_device(), and > as Andrew says, that should be done _first_. > Ok, I got it, thanks!