Received: by 2002:a05:7412:b995:b0:f9:9502:5bb8 with SMTP id it21csp7123076rdb; Wed, 3 Jan 2024 05:32:14 -0800 (PST) X-Google-Smtp-Source: AGHT+IHmpe8FVAqwiCW+VTvS2DHtNz0rSjT1HrBECSyGadc877zpUAc9XWWnQgT90ffyP4V4WWAL X-Received: by 2002:a05:620a:2448:b0:77f:2f1b:ad3b with SMTP id h8-20020a05620a244800b0077f2f1bad3bmr26789381qkn.146.1704288734332; Wed, 03 Jan 2024 05:32:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1704288734; cv=none; d=google.com; s=arc-20160816; b=DmQSHYzJRhrhGII1TXBHRJNHQ2hhda5JaJcXX/TG2dsXyqSJDIe18i5GTlx3qJOQ7N raTx/Hv1mbTUe4uosVOpiIeJT9qvdH15P/k4i1rP7qT9tbriMvvdK+aoNqYqyNyN6sJg 0pNzwRcwj5hRgJCHwaEhZSkOM1i1zvw6PuU1GNpAjG4708bGHHDBpxtIf4wLblb+sG4s sEmsL2ByO7ppuAkNpnjsHU43bu8wQ+neRMP6Yx+3RCv6vAu19ywWE9vWlRPJ3Rm0FvHq sugQVJej3YUNMPP3OZmKmTLDuViz6AW4n6/xnMxNmC2AovCMWd8QC7z3YbpNHRNMyuaP xDDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:list-unsubscribe:list-subscribe:list-id:precedence :references:message-id:subject:cc:to:from:date:dkim-signature; bh=1H++AJiescRoXR5SWrVB1eNQUoip3aAkOmJ/HiZ4zFc=; fh=SbvIy0NUZhfOnfGosHy3KC1ph0/NN0pbtZtZfTyEh2o=; b=zZXhxlnWyn7DG9GDVCU452D9FAIPn+SNcs1XpA/zwFs+uCBk+bsjU3NGPr3gmwWEmM EY0HOrv83VCTkmAVf52Mr4eUP759bXgIxShkBsvJu6MZ5DRJYOwhNOt2b6cBFHn6EB8g coSy2UA2FprxSXKGdR7qu5je3jtJ+33gnO7zV8m4uvI+QJ8mx7HnE7WRHfrJbJEGKs+L 3EX7HLFEL7nZEbthKGXG5PfgS4NZTKr4NNB5MgwzeHhtJQ/5ig6BadMNige6Ieod2RSd MBTOv36bHrlcZWDW3qniu4oIPXfFPQI0U1YqizvCftO0oAOnUd72qRmXOnaq8sZ0A1OO G4dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=1zHnQX+c; spf=pass (google.com: domain of linux-kernel+bounces-15579-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15579-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id bp7-20020a05620a458700b007811c528f8esi30055795qkb.287.2024.01.03.05.32.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 03 Jan 2024 05:32:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-15579-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@lunn.ch header.s=20171124 header.b=1zHnQX+c; spf=pass (google.com: domain of linux-kernel+bounces-15579-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-15579-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=lunn.ch 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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 18F751C23754 for ; Wed, 3 Jan 2024 13:32:14 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id EAEA01A594; Wed, 3 Jan 2024 13:30:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="1zHnQX+c" X-Original-To: linux-kernel@vger.kernel.org Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) (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 C7B671A27E; Wed, 3 Jan 2024 13:30:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=lunn.ch Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lunn.ch DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Transfer-Encoding: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=1H++AJiescRoXR5SWrVB1eNQUoip3aAkOmJ/HiZ4zFc=; b=1z HnQX+cm/ClYDZS+R5jDLXvXTqeToFIScTgJmaxWCtETaENqsdsnHh5KxQzovCNiLb/Fx8sJa0kTcD rMA3pPqTrNa7ZY9R64Wl9LYSxiS80L7yrD82n7/1d5vul9xWJ6tb0SzQemRdx4eK34bqzblhXXsq7 5dtK8NxHj7Vk330=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1rL1K8-004Fxw-12; Wed, 03 Jan 2024 14:30:20 +0100 Date: Wed, 3 Jan 2024 14:30:20 +0100 From: Andrew Lunn To: Yajun Deng Cc: "Russell King (Oracle)" , davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, olteanv@gmail.com, hkallweit1@gmail.com, kabel@kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-phy@lists.infradead.org Subject: Re: [PATCH net-next] net: phy: Cleanup struct mdio_driver_common Message-ID: <7367681a-3ef5-42ad-9c2f-173f77cc1b56@lunn.ch> References: <20231228072350.1294425-1-yajun.deng@linux.dev> <52ea5dbf-2d60-7a23-e525-9dcae2809554@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <52ea5dbf-2d60-7a23-e525-9dcae2809554@linux.dev> On Wed, Jan 03, 2024 at 07:38:04PM +0800, Yajun Deng wrote: > > On 2024/1/3 18:51, Russell King (Oracle) wrote: > > On Wed, Jan 03, 2024 at 10:03:14AM +0800, Yajun Deng wrote: > > > On 2024/1/3 01:34, Russell King (Oracle) wrote: > > > > I'm not sure why this consistency is even desired, the commit message > > > > doesn't properly say _why_ this change is being proposed. > > > Most drivers use device_driver directly. This should be added to the commit. > > > > > > Like this: > > > > > > struct sdio_driver { > > > > > > ... ... > > > > > > ??????? struct device_driver drv; > > > }; > > > > > > > > > struct pcie_port_service_driver { > > > > > > ... ... > > > > > > ??????? struct device_driver driver; > > > }; > > > > > > and so on ... > > ... which is fine for those other drivers because they don't share the > > same bus. That is not the case here - we have two different classes > > of drivers on the same bus. > > > Yes, that's true. But we can implement it with is_phy_driver(). I don't > think we need a flag for that. > > > > > I don't like a justification that just because other subsystems do > > something in one particular way, that is the only way things should be > > done. I think there is good reason to have the structure we have, and > > thus there needs to be a good reason to change it. > > Its purpose is to clean up struct mdio_driver_common, and make the code > cleaner. I have to agree with Russell here. The commit message should explain the 'Why?'. Why is this better? Why is it cleaner? Why does making it the same as all other drivers make it better, when in fact we have two classes of devices stacked on top of it, and making it different to every other driver actually helps developers realise that? Andrew