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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2403C4167B for ; Tue, 5 Dec 2023 13:52:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1442280AbjLENwe (ORCPT ); Tue, 5 Dec 2023 08:52:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345523AbjLENwd (ORCPT ); Tue, 5 Dec 2023 08:52:33 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [156.67.10.101]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 51DB012C; Tue, 5 Dec 2023 05:52:39 -0800 (PST) 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=fp/k+9cjXPMJD2AI1NBPq4sHcsTLnY0P6a5ilpBrwwI=; b=NktDqN5jNI5Ylg9ZHDCm/VXu55 z+DTg9FlA8wsQGtB2rP4e07ENtnZ+R782xG+VNf6Ve91GLktgfzGKWa6epkNfgsfR0hUo+dhFhhS3 1CrG3fFgCQUD8ABXHVmW2Siqq94y127Lrsf4p0pvesSlcVu9tV0o9cHVqHfYFhdammPM=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1rAVqa-0026FF-6u; Tue, 05 Dec 2023 14:52:24 +0100 Date: Tue, 5 Dec 2023 14:52:24 +0100 From: Andrew Lunn To: Serge Semin Cc: "Russell King (Oracle)" , Heiner Kallweit , 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: References: <20231205103559.9605-1-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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Dec 05, 2023 at 02:31:41PM +0300, Serge Semin wrote: > On Tue, Dec 05, 2023 at 10:49:47AM +0000, Russell King (Oracle) wrote: > > 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 there is no point in creating the > > > dummy MDIO device instance in order to get the DW XPCS handler since the > > > MDIO core subsystem will create the device during the MDIO bus > > > registration procedure. > > > > > Please reword this overly long sentence. > > Ok. > > > > > If they're left unmasked, what prevents them being created as PHY > > devices? > > Not sure I fully get what you meant. If they are left unmasked the > MDIO-device descriptor will be created by the MDIO subsystem anyway. > What the point in creating another one? Saying what Russell said, in a different way: /* * Return true if the child node is for a phy. It must either: * o Compatible string of "ethernet-phy-idX.X" * o Compatible string of "ethernet-phy-ieee802.3-c45" * o Compatible string of "ethernet-phy-ieee802.3-c22" * o In the white list above (and issue a warning) * o No compatibility string * * A device which is not a phy is expected to have a compatible string * indicating what sort of device it is. */ bool of_mdiobus_child_is_phy(struct device_node *child) So when walking the bus, if a node is found which fits these criteria, its assumed to be a PHY. Anything on the MDIO bus which is not a PHY needs to use a compatible. Andrew