Message ID | 20221227-v6-2-rc1-c45-seperation-v2-3-ddb37710e5a7@walle.cc |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp1621981wrt; Tue, 27 Dec 2022 15:08:49 -0800 (PST) X-Google-Smtp-Source: AMrXdXtkBgIzTtzriNztLFQ4kFZPV+wyFAymGym4YBboA+EqS7ziqYDGwOT30kfntZStdXALaZjm X-Received: by 2002:a17:903:3255:b0:191:f83:636b with SMTP id ji21-20020a170903325500b001910f83636bmr26938835plb.25.1672182528916; Tue, 27 Dec 2022 15:08:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1672182528; cv=none; d=google.com; s=arc-20160816; b=HoDriRjp/Ys7RFizBPL1eRul2XlbzidPHFyaErBFfh46avmcJl4q8au/SY5XuU88fN EEqQGVo58mdyvm+/f9tiayW7cx1oUex0aFExrhlq/zET/kRwoFe5QQ4b4rG/Cd1NuHbA g+5o1V2+KDHRRsD2BcTS0A3xBM029tgn/69R3BuKNh0CqMX9eRqSljWJ6hyTvG38AHeZ S/igydX43YjrHGXZ9Uu/9G9dhtKbV0yktGukLcXlSK1XdyDuO6Dt6DyWoBM4aWNLHc9D oJoz3udG1ZnzVtvu/bUXqBQF+C3FvKi36tG6Nir3ZKTWroiifFLVXIdvO2k+wTHSNX32 yYRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:in-reply-to:references:message-id :content-transfer-encoding:mime-version:subject:date:from :dkim-signature; bh=PEAs1cY2KUGfDWF8DZJhmKi3UDdwVzcJA87E/SYrVOE=; b=VbAS4mMvtsT+F26rAqNcozmAoInNga8CSgD653mOaPtzdKxLNPn/UUtQC0Dj5z0CbK NxSNu0fpvHkmefazdt449WWnURoeKW2yJKhHbd7Y/DyvMKKFUgggr5yGymkkS+OS+72/ 69Wm6fCuSjpWYnvH08CdzH74KsAJ5Rkby67LwElQ0OJi9Uxo2TvyKn411D6OpEWp4afB lzx6n2HeLMnc79QCgHavks0ptXKt3cjodSUGJVieL4KQlEDJKiMqJmB4DV9Odmz0JLXG G60/7scQF1O6zX05ugwfHC/tthNtEGYkkOIpUlWICN8XbpNe/6LtYq32Qkebd5ZmbLwy KfkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@walle.cc header.s=mail2022082101 header.b=mtu1oTBa; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=walle.cc Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id n7-20020a170902f60700b00179cf094dccsi1750088plg.526.2022.12.27.15.08.37; Tue, 27 Dec 2022 15:08:48 -0800 (PST) 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=@walle.cc header.s=mail2022082101 header.b=mtu1oTBa; 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=walle.cc Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232294AbiL0XIV (ORCPT <rfc822;eddaouddi.ayoub@gmail.com> + 99 others); Tue, 27 Dec 2022 18:08:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45146 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229608AbiL0XHo (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 27 Dec 2022 18:07:44 -0500 Received: from mail.3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7C1CD62E5; Tue, 27 Dec 2022 15:07:28 -0800 (PST) Received: from mwalle01.sab.local (unknown [213.135.10.150]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 696AF169D; Wed, 28 Dec 2022 00:07:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1672182446; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=PEAs1cY2KUGfDWF8DZJhmKi3UDdwVzcJA87E/SYrVOE=; b=mtu1oTBaxSngOLJAMfQndS7QsiKJFcYMtxVy/Vf3h9ET6EQmvAN9NTeV9uvL5debjMGv8c LcP9XcxB/6EcWrvVwEhOs9ijS22CCQyFKGLbEKSgik0owwnYgfVXqpgTUA4HZdtpVBb7H7 v5nMCDpoHXlCUPKZMpempFS4ykEFxhFYFjmWHHfx+B9dRgwXBFJ+P0LejAaVmG2heL4liv fr8HpYAfgXekauNSI26OaansaGepJ1NLKTntcG+CMYfhX/NO6+O1wJSB3YAStScb1omZul AroLnuQwESfFBDCwasVEMZ1ti4zIFGEkGXYR6zxfC5emKzgU47zvhRYYyJJ+mQ== From: Michael Walle <michael@walle.cc> Date: Wed, 28 Dec 2022 00:07:19 +0100 Subject: [PATCH RFC net-next v2 03/12] net: mdio: mdiobus_register: update validation test MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <20221227-v6-2-rc1-c45-seperation-v2-3-ddb37710e5a7@walle.cc> References: <20221227-v6-2-rc1-c45-seperation-v2-0-ddb37710e5a7@walle.cc> In-Reply-To: <20221227-v6-2-rc1-c45-seperation-v2-0-ddb37710e5a7@walle.cc> To: Heiner Kallweit <hkallweit1@gmail.com>, Russell King <linux@armlinux.org.uk>, "David S. Miller" <davem@davemloft.net>, Eric Dumazet <edumazet@google.com>, Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>, Jose Abreu <Jose.Abreu@synopsys.com>, Sergey Shtylyov <s.shtylyov@omp.ru>, Wei Fang <wei.fang@nxp.com>, Shenwei Wang <shenwei.wang@nxp.com>, Clark Wang <xiaoning.wang@nxp.com>, NXP Linux Team <linux-imx@nxp.com>, Sean Wang <sean.wang@mediatek.com>, Landen Chao <Landen.Chao@mediatek.com>, DENG Qingfang <dqfext@gmail.com>, Florian Fainelli <f.fainelli@gmail.com>, Vladimir Oltean <olteanv@gmail.com>, Matthias Brugger <matthias.bgg@gmail.com> Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Andrew Lunn <andrew@lunn.ch>, Geert Uytterhoeven <geert+renesas@glider.be>, Michael Walle <michael@walle.cc> X-Mailer: b4 0.11.1 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS autolearn=ham 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1753410467283159557?= X-GMAIL-MSGID: =?utf-8?q?1753410467283159557?= |
Series |
net: mdio: Start separating C22 and C45
|
|
Commit Message
Michael Walle
Dec. 27, 2022, 11:07 p.m. UTC
From: Andrew Lunn <andrew@lunn.ch> Now that C45 uses its own read/write methods, the validation performed when a bus is registers needs updating. All combinations of C22 and C45 are supported, but both read and write methods must be provided, read only busses are not supported etc. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Michael Walle <michael@walle.cc> --- v2: - [al] be consistent with other checks - [mw] make the test a bit easier to read --- drivers/net/phy/mdio_bus.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
Comments
Hi Michael, Thanks for picking this up! On Wed, Dec 28, 2022 at 12:07:19AM +0100, Michael Walle wrote: > + if (!bus || !bus->name) > + return -EINVAL; > + > + /* An access method always needs both read and write operations */ > + if ((bus->read && !bus->write) || > + (!bus->read && bus->write) || > + (bus->read_c45 && !bus->write_c45) || > + (!bus->read_c45 && bus->write_c45)) I wonder whether the following would be even more readable: if (!bus->read != !bus->write || !bus->read_c45 != !bus->write_c45) which essentially asserts that the boolean of !method for the read and write methods must match.
Hi Russell, Am 2023-01-03 11:13, schrieb Russell King (Oracle): > On Wed, Dec 28, 2022 at 12:07:19AM +0100, Michael Walle wrote: >> + if (!bus || !bus->name) >> + return -EINVAL; >> + >> + /* An access method always needs both read and write operations */ >> + if ((bus->read && !bus->write) || >> + (!bus->read && bus->write) || >> + (bus->read_c45 && !bus->write_c45) || >> + (!bus->read_c45 && bus->write_c45)) > > I wonder whether the following would be even more readable: > > if (!bus->read != !bus->write || !bus->read_c45 != !bus->write_c45) That's what Andrew had originally. But there was a comment from Sergey [1] which I agree with. I had a hard time wrapping my head around that, so I just listed all the possible bad cases. I don't have a strong opinion, though. > which essentially asserts that the boolean of !method for the read and > write methods must match. Maybe with that as a comment? -michael [1] https://lore.kernel.org/netdev/ae79823f-3697-feee-32e6-645c6f4b4e93@omp.ru/
Hi Michael, On Tue, Jan 03, 2023 at 11:21:08AM +0100, Michael Walle wrote: > Hi Russell, > > Am 2023-01-03 11:13, schrieb Russell King (Oracle): > > On Wed, Dec 28, 2022 at 12:07:19AM +0100, Michael Walle wrote: > > > + if (!bus || !bus->name) > > > + return -EINVAL; > > > + > > > + /* An access method always needs both read and write operations */ > > > + if ((bus->read && !bus->write) || > > > + (!bus->read && bus->write) || > > > + (bus->read_c45 && !bus->write_c45) || > > > + (!bus->read_c45 && bus->write_c45)) > > > > I wonder whether the following would be even more readable: > > > > if (!bus->read != !bus->write || !bus->read_c45 != !bus->write_c45) > > That's what Andrew had originally. But there was a comment from Sergey [1] > which I agree with. I had a hard time wrapping my head around that, so I > just listed all the possible bad cases. The only reason I suggested it was because when looked at your code, it also took several reads to work out what it was trying to do! Would using !!bus->read != !!bus->write would help or make it worse, !!ptr being the more normal way to convert something to a boolean?
Hi Russell, Am 2023-01-03 23:19, schrieb Russell King (Oracle): > On Tue, Jan 03, 2023 at 11:21:08AM +0100, Michael Walle wrote: >> Am 2023-01-03 11:13, schrieb Russell King (Oracle): >> > On Wed, Dec 28, 2022 at 12:07:19AM +0100, Michael Walle wrote: >> > > + if (!bus || !bus->name) >> > > + return -EINVAL; >> > > + >> > > + /* An access method always needs both read and write operations */ >> > > + if ((bus->read && !bus->write) || >> > > + (!bus->read && bus->write) || >> > > + (bus->read_c45 && !bus->write_c45) || >> > > + (!bus->read_c45 && bus->write_c45)) >> > >> > I wonder whether the following would be even more readable: >> > >> > if (!bus->read != !bus->write || !bus->read_c45 != !bus->write_c45) >> >> That's what Andrew had originally. But there was a comment from Sergey >> [1] >> which I agree with. I had a hard time wrapping my head around that, so >> I >> just listed all the possible bad cases. > > The only reason I suggested it was because when looked at your code, > it also took several reads to work out what it was trying to do! > > Would using !!bus->read != !!bus->write would help or make it worse, > !!ptr being the more normal way to convert something to a boolean? IMHO that makes it even harder. But I doubt we will find an expression that will work for everyone. I'll go with your suggestion/Andrew's first version in the next iteration. -michael
On Mon, Jan 09, 2023 at 01:35:29PM +0100, Michael Walle wrote: > Hi Russell, > > Am 2023-01-03 23:19, schrieb Russell King (Oracle): > > On Tue, Jan 03, 2023 at 11:21:08AM +0100, Michael Walle wrote: > > > Am 2023-01-03 11:13, schrieb Russell King (Oracle): > > > > On Wed, Dec 28, 2022 at 12:07:19AM +0100, Michael Walle wrote: > > > > > + if (!bus || !bus->name) > > > > > + return -EINVAL; > > > > > + > > > > > + /* An access method always needs both read and write operations */ > > > > > + if ((bus->read && !bus->write) || > > > > > + (!bus->read && bus->write) || > > > > > + (bus->read_c45 && !bus->write_c45) || > > > > > + (!bus->read_c45 && bus->write_c45)) > > > > > > > > I wonder whether the following would be even more readable: > > > > > > > > if (!bus->read != !bus->write || !bus->read_c45 != !bus->write_c45) > > > > > > That's what Andrew had originally. But there was a comment from > > > Sergey [1] > > > which I agree with. I had a hard time wrapping my head around that, > > > so I > > > just listed all the possible bad cases. > > > > The only reason I suggested it was because when looked at your code, > > it also took several reads to work out what it was trying to do! > > > > Would using !!bus->read != !!bus->write would help or make it worse, > > !!ptr being the more normal way to convert something to a boolean? > > IMHO that makes it even harder. But I doubt we will find an expression > that will work for everyone. I'll go with your suggestion/Andrew's first > version in the next iteration. I think the double negation conveys the intention better than the simple one, actually (maybe even xor instead of != ?). In terms of readability I think I prefer the way the patch is written right now, but if you keep the comment, the double negation should be pretty easy to swallow too.
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c index bde195864c17..d14d7704e895 100644 --- a/drivers/net/phy/mdio_bus.c +++ b/drivers/net/phy/mdio_bus.c @@ -526,8 +526,18 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner) int i, err; struct gpio_desc *gpiod; - if (NULL == bus || NULL == bus->name || - NULL == bus->read || NULL == bus->write) + if (!bus || !bus->name) + return -EINVAL; + + /* An access method always needs both read and write operations */ + if ((bus->read && !bus->write) || + (!bus->read && bus->write) || + (bus->read_c45 && !bus->write_c45) || + (!bus->read_c45 && bus->write_c45)) + return -EINVAL; + + /* At least one method is mandatory */ + if (!bus->read && !bus->read_c45) return -EINVAL; if (bus->parent && bus->parent->of_node)