Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp4423749pxb; Tue, 5 Oct 2021 02:49:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwRPhFEtAY8ZxY+nGYv7OqlLl7GwStkNuUaviwM2gfkd2O7wBVviyGnrAuG3bRrO5tc0qc8 X-Received: by 2002:a05:6a00:1141:b0:440:3c27:807c with SMTP id b1-20020a056a00114100b004403c27807cmr29311646pfm.71.1633427367098; Tue, 05 Oct 2021 02:49:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633427367; cv=none; d=google.com; s=arc-20160816; b=jWeuDP/hPMpt0dOVmc0YWHWVgL7n1exnKPV4f11GvbDzMgIutn6Bf2TC/YPyfTyei6 IyjQISDfHJRoG4hJbyGjUBg5NTw2eZ/fl/vHycsv2M+4NpEtkiy34KZdYCuutKiXmtCC 3o1PWUME9XUhSnFXrYW+i+4WGc0E240IEl5I20KyOYzecl4LAFzLW5zfzgxt5Q/O30eN 9Ybo9zBV78LrNEWqAKFkyzWAq4sMnucb0pEurmW5goq6xciyFlhkQswpuNU+Azc5kFSR JN2hYMk+ZU6HdLItZNU5J7IB2mwqkUM2+tDrdJQi+3+ABQH9X7+u+paRvsMgEosFR8hq 176g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=HIo2aCXY4RPVQU/Hm5Gq2nvMpxEwV3G/HpRH5pcWZsw=; b=spjXEhNy3R8FovbY4dwM9iP53A7I+1w1c7S7KSyyR0F3rRRJetXRvJghIR6sFLQsWZ LcXCo0v8udvTDQC6xb8lfsjecBqrRtGDNpKSgeRJ08tkuxk1pZuh7AmtpbzcCeuVNnzd G2E84GXu5+QJG5461hY8p0Tbf3fz60v3asLN/2n06mVfnNA4j6Ps3F2tId0jlqTpe6SJ 8RWUuCV0mr66xLem40X8/+U52n0fxOHdUwVkRirTLaQYTRyAzohYPAtjYFlZihQ5tkfU xBKSrIektAr4x8Ce3dNSfbFDv5lNmmaDSYRsJHTwKUXWToobgE8sSmAXTKuL0+MHVciK eYTw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=DpEcNNx2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v7si1386023pjk.36.2021.10.05.02.49.11; Tue, 05 Oct 2021 02:49:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b=DpEcNNx2; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233597AbhJEJuF (ORCPT + 99 others); Tue, 5 Oct 2021 05:50:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233077AbhJEJuF (ORCPT ); Tue, 5 Oct 2021 05:50:05 -0400 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75FB6C06161C; Tue, 5 Oct 2021 02:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HIo2aCXY4RPVQU/Hm5Gq2nvMpxEwV3G/HpRH5pcWZsw=; b=DpEcNNx2E0xJDw7NvmJ/OWgyPG /uRe1Cg741kuptggFNyO55EaIohJO7+3l+pwqDeyLtWSQ4kCeemFe4dlhwSGErenebiovozoEVN3k XqQW0OLG/fZIN8kqmnO8l6QOEZNJOgJcjGzOECSQBJbtx2ZzUTQoZ71mS3hGdNRGzr67cplpTbBgq qKU9nSDelAYUm62EgYFytltMIJBOfwcfGp84/flNol3aucUa2189ComRBHikmW+RxOLW2eeOinCN5 LXI2IM/wV+5jxjfqbZjWGEbCNW+jQ1WFqZSh38s/sJXMsR3one4KMbVcU9KnqYWBBLWstlLr5FX+i GdFjwZVQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:54946) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mXh3U-00005s-3G; Tue, 05 Oct 2021 10:48:12 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1mXh3T-0008Mw-12; Tue, 05 Oct 2021 10:48:11 +0100 Date: Tue, 5 Oct 2021 10:48:10 +0100 From: "Russell King (Oracle)" To: Sean Anderson Cc: netdev@vger.kernel.org, "David S . Miller" , Jakub Kicinski , linux-kernel@vger.kernel.org, Andrew Lunn , Heiner Kallweit , Saravana Kannan Subject: Re: [RFC net-next PATCH 05/16] net: phylink: Automatically attach PCS devices Message-ID: References: <20211004191527.1610759-1-sean.anderson@seco.com> <20211004191527.1610759-6-sean.anderson@seco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211004191527.1610759-6-sean.anderson@seco.com> Sender: Russell King (Oracle) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 04, 2021 at 03:15:16PM -0400, Sean Anderson wrote: > This adds support for automatically attaching PCS devices when creating > a phylink. To do this, drivers must first register with > phylink_register_pcs. After that, new phylinks will attach the PCS > device specified by the "pcs" property. > > At the moment there is no support for specifying the interface used to > talk to the PCS. The MAC driver is expected to know how to talk to the > PCS. This is not a change, but it is perhaps an area for improvement. > > I believe this is mostly correct with regard to registering/ > unregistering. However I am not too familiar with the guts of Linux's > device subsystem. It is possible (likely, even) that the current system > is insufficient to prevent removing PCS devices which are still in-use. > I would really appreciate any feedback, or suggestions of subsystems to > use as reference. In particular: do I need to manually create device > links? Should I instead add an entry to of_supplier_bindings? Do I need > a call to try_module_get? I think this is an area that needs to be thought about carefully. Things are not trivial here. The first mistake I see below is the use of device links. pl->dev is the "struct device" embedded within "struct net_device". This doesn't have a driver associated with it, and so using device links is likely ineffectual. Even with the right device, I think careful thought is needed - we have network drivers where one "struct device" contains multiple network interfaces. Should the removal of a PCS from one network interface take out all of them? Alternatively, could we instead use phylink to "unplug" the PCS and mark the link down - would that be a better approach than trying to use device links? -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!