From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7B24CC4167B for ; Tue, 5 Dec 2023 11:53:42 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=UIf5u+xV; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4SkzT117GNz3cTF for ; Tue, 5 Dec 2023 22:53:41 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20230601 header.b=UIf5u+xV; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2a00:1450:4864:20::62e; helo=mail-ej1-x62e.google.com; envelope-from=olteanv@gmail.com; receiver=lists.ozlabs.org) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 lists.ozlabs.org (Postfix) with ESMTPS id 4SkzRx14frz3cNt for ; Tue, 5 Dec 2023 22:52:44 +1100 (AEDT) Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-a1975fe7befso601336166b.2 for ; Tue, 05 Dec 2023 03:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701777157; x=1702381957; darn=lists.ozlabs.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yQnio+BjHch7uekOs0EbRaR6+xPg48w0mlLLI/zKaaU=; b=UIf5u+xV/MZTGxK3hQG0PmHuNhHxtSZ7w7EAUEQ3RilfG7rx9BHC6kMER2ljI5II8U YWUQhJ4ysxA0xYorIgxZDNJtI+LyPDchZAGYBSCq9KV4L9jLXTuXTiBiaJsECXLzyWkf XQ+ULm9HYQhIu1zC/CIo57nuZ/UBqRTP8sDmUZ7ozYLrTEae0zmgA0eLNUgKzta+j8SZ DnmV+JfDSmAD7JeX8AuoV+px8bUHJ8rGaiaawyEMRdyCHXXHueiNfuS3QmlmumD7uhXI ipD0ioe7Y0NxP+GZo6bC8JiJaoCG7t/EFF0jUTjWPjah+h9AaJHsbTglPYztTcCtdFIg mSRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701777157; x=1702381957; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yQnio+BjHch7uekOs0EbRaR6+xPg48w0mlLLI/zKaaU=; b=e150WPKoTlIaHOVfDBB+JLTQbWXYlGUxRlGXNuRQJsb6rZ+0HbrUVWnWuo9GOq/VRG 5lE1J0LQQ4CiOt3MeVOkdInqixo+6qDJX2zeEGOv1kI+Osvk3H+nD0bTkGbDP2U5szjM tpIs7paGp4RsV1o3tm6vSAm/bg9WOJMSsGNXWtSAjSiNSLMqho/EHN/pqeF1zaIXoNu+ wp78Kyt9HfgAaCXfkOk19Kfqg6Lh7icgHoGwOCRxFt/1EzyMGNlVrC3+FG6IPTLrQpxS cdIqwlbYOEwp897JSq8+D59g5GkU1+rz6YB5OzLd9i7mjx2heuV3mVLUg+rTvN3XabDY opJA== X-Gm-Message-State: AOJu0YzNqb0Q5WXoxpYI7z2jqIdu6iqJ+R7jZuawDLxup6QGOZEOMwsL MtWxK6h3auHCWm5ZVq+kErE= X-Google-Smtp-Source: AGHT+IFbcUHHGMa0y7mPKTyHnJVqbuoOrcBU5Fgp7HSueg3Asjnj4OKHJ4FateR0JcHkUAKp1ewXJQ== X-Received: by 2002:a17:907:8c8:b0:a0e:d93a:3202 with SMTP id zu8-20020a17090708c800b00a0ed93a3202mr323045ejb.4.1701777157222; Tue, 05 Dec 2023 03:52:37 -0800 (PST) Received: from skbuf ([188.27.185.68]) by smtp.gmail.com with ESMTPSA id x12-20020a170906298c00b00a1cbb055575sm451602eje.180.2023.12.05.03.52.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 03:52:37 -0800 (PST) Date: Tue, 5 Dec 2023 13:52:34 +0200 From: Vladimir Oltean To: Serge Semin Subject: Re: [PATCH net-next 06/16] net: pcs: xpcs: Avoid creating dummy XPCS MDIO device Message-ID: <20231205115234.7ntjvymurot5nnak@skbuf> References: <20231205103559.9605-1-fancer.lancer@gmail.com> <20231205103559.9605-1-fancer.lancer@gmail.com> <20231205103559.9605-7-fancer.lancer@gmail.com> <20231205103559.9605-7-fancer.lancer@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231205103559.9605-7-fancer.lancer@gmail.com> <20231205103559.9605-7-fancer.lancer@gmail.com> X-BeenThere: openbmc@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Development list for OpenBMC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jose Abreu , Andrew Lunn , Conor Dooley , Paolo Abeni , Tomer Maimon , devicetree@vger.kernel.org, netdev@vger.kernel.org, openbmc@lists.ozlabs.org, Alexandre Torgue , Rob Herring , Russell King , Eric Dumazet , Jose Abreu , Krzysztof Kozlowski , Jakub Kicinski , Maxime Chevallier , "David S. Miller" , linux-kernel@vger.kernel.org, Heiner Kallweit Errors-To: openbmc-bounces+openbmc=archiver.kernel.org@lists.ozlabs.org Sender: "openbmc" On Tue, Dec 05, 2023 at 01:35:27PM +0300, Serge Semin wrote: > If the DW XPCS MDIO devices are either left unmasked for being auto-probed > or explicitly registered in the MDIO subsystem by means of the > mdiobus_register_board_info() method mdiobus_register_board_info() has exactly one caller, and that is dsa_loop. I don't understand the relevance of it w.r.t. Synopsys XPCS. I'm reading the patches in order from the beginning. > there is no point in creating the dummy MDIO device instance in order Why dummy? There's nothing dummy about the mdio_device. It's how the PCS code accesses the hardware. > to get the DW XPCS handler since the MDIO core subsystem will create > the device during the MDIO bus registration procedure. It won't, though? Unless someone is using mdiobus_register_board_info() possibly, but who does that? > All what needs to be done is to just reuse the MDIO-device instance > available in the mii_bus.mdio_map array (using some getter for it > would look better though). It shall prevent the XPCS devices been > accessed over several MDIO-device instances. > > Note since the MDIO-device instance might be retrieved from the MDIO-bus > map array its reference counter shall be increased. If the MDIO-device > instance is created in the xpcs_create_mdiodev() method its reference > counter will be already increased. So there is no point in toggling the > reference counter in the xpcs_create() function. Just drop it from there. > > Signed-off-by: Serge Semin > --- Sorry, because the commit log lost me at the "context presentation" stage, I failed to understand the "what"s and the "why"s. Are you basically trying to add xpcs support on top of an mdio_device where the mdio_device_create() call was made externally to the xpcs code, through mdiobus_register_board_info() and mdiobus_setup_mdiodev_from_board_info()? From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fGyFDt+2" Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DB68AC3; Tue, 5 Dec 2023 03:52:38 -0800 (PST) Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-a1975fe7befso601336066b.2; Tue, 05 Dec 2023 03:52:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701777157; x=1702381957; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=yQnio+BjHch7uekOs0EbRaR6+xPg48w0mlLLI/zKaaU=; b=fGyFDt+2zfMoMGFkNb+wIqez0LxE+nJA6J0daN/LW4CpjKTBTpG5Gt9AUaEY4VWKFc Y/b4lLuuer2jiUCNf/A+rZ4+Ay+AWp7mxKScBDRdynDcFafxfvQLu0WouwBaD3pxB0+q aawAAXulKODe7QHWNAA/b2QfBM9BeKtbDNqK9fJkvRC//82r8X+0hWlt9OBbo++1dUMB a/d6//g4g2DGrP4PZ68TOhkGBbGkDv2L7mFDK7JcGg7PKggjMf4ZQCJeBhcOdVgSXhL/ mSclAgN9uAVIMcf+V6YxYS/j4R9AQFoCyrip7JxinLKBrybeAi+6YcUKWTncNmGpC4Hu 6hUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701777157; x=1702381957; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=yQnio+BjHch7uekOs0EbRaR6+xPg48w0mlLLI/zKaaU=; b=izdRUqlLbiT921wq7u3sJQ35clLmjmc1cRkjllg7ySibdmDDd9hCavXZ2VRIYORofi 1aIa1FBMbTEfCtIxhhGb6PZzjHBH8eKBagiCuNp0CuKj1wFaBxm1Q7nNKgnUausGBDf2 QMcVpe9EcCRj4VIlYM66EWIZdsd/Z0C1vFH2fU5XWQY13zUEW9GV4W66gVizdl+4Op+0 x8uCiZB98bihz/181/UT81WhZZ3H5/cS2RDhsQigJ4BUThNmz227f42/FBSU/SQ+diNf jnEFLxhSbTYEUteEcbmqFOz2SZUCzkHjPQOSNJrfjM1U2bZyauTDj2NMTvS80vzKW5VL Kqgg== X-Gm-Message-State: AOJu0YzLp3ohxMJI9ZuniHxCxOiKmVRCLym9g9QLcOEBbnkJAnDeSgTc DNwZC6C0FbUm7hAtXnjt9CA= X-Google-Smtp-Source: AGHT+IFbcUHHGMa0y7mPKTyHnJVqbuoOrcBU5Fgp7HSueg3Asjnj4OKHJ4FateR0JcHkUAKp1ewXJQ== X-Received: by 2002:a17:907:8c8:b0:a0e:d93a:3202 with SMTP id zu8-20020a17090708c800b00a0ed93a3202mr323045ejb.4.1701777157222; Tue, 05 Dec 2023 03:52:37 -0800 (PST) Received: from skbuf ([188.27.185.68]) by smtp.gmail.com with ESMTPSA id x12-20020a170906298c00b00a1cbb055575sm451602eje.180.2023.12.05.03.52.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 05 Dec 2023 03:52:37 -0800 (PST) Date: Tue, 5 Dec 2023 13:52:34 +0200 From: Vladimir Oltean To: Serge Semin Cc: Andrew Lunn , Heiner Kallweit , Russell King , Alexandre Torgue , Jose Abreu , Jose Abreu , Maxime Chevallier , Tomer Maimon , Rob Herring , Krzysztof Kozlowski , Conor Dooley , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , openbmc@lists.ozlabs.org, netdev@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH net-next 06/16] net: pcs: xpcs: Avoid creating dummy XPCS MDIO device Message-ID: <20231205115234.7ntjvymurot5nnak@skbuf> References: <20231205103559.9605-1-fancer.lancer@gmail.com> <20231205103559.9605-1-fancer.lancer@gmail.com> <20231205103559.9605-7-fancer.lancer@gmail.com> <20231205103559.9605-7-fancer.lancer@gmail.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231205103559.9605-7-fancer.lancer@gmail.com> <20231205103559.9605-7-fancer.lancer@gmail.com> On Tue, Dec 05, 2023 at 01:35:27PM +0300, Serge Semin wrote: > If the DW XPCS MDIO devices are either left unmasked for being auto-probed > or explicitly registered in the MDIO subsystem by means of the > mdiobus_register_board_info() method mdiobus_register_board_info() has exactly one caller, and that is dsa_loop. I don't understand the relevance of it w.r.t. Synopsys XPCS. I'm reading the patches in order from the beginning. > there is no point in creating the dummy MDIO device instance in order Why dummy? There's nothing dummy about the mdio_device. It's how the PCS code accesses the hardware. > to get the DW XPCS handler since the MDIO core subsystem will create > the device during the MDIO bus registration procedure. It won't, though? Unless someone is using mdiobus_register_board_info() possibly, but who does that? > All what needs to be done is to just reuse the MDIO-device instance > available in the mii_bus.mdio_map array (using some getter for it > would look better though). It shall prevent the XPCS devices been > accessed over several MDIO-device instances. > > Note since the MDIO-device instance might be retrieved from the MDIO-bus > map array its reference counter shall be increased. If the MDIO-device > instance is created in the xpcs_create_mdiodev() method its reference > counter will be already increased. So there is no point in toggling the > reference counter in the xpcs_create() function. Just drop it from there. > > Signed-off-by: Serge Semin > --- Sorry, because the commit log lost me at the "context presentation" stage, I failed to understand the "what"s and the "why"s. Are you basically trying to add xpcs support on top of an mdio_device where the mdio_device_create() call was made externally to the xpcs code, through mdiobus_register_board_info() and mdiobus_setup_mdiodev_from_board_info()?