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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 0D370C433EF for ; Wed, 20 Jul 2022 13:54:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=InoxLaZhtgd5QDQg10Z9DwKCDdsk6JWllrcxv4AD3ks=; b=dXteHxT4xl7b+B cVC6dZMorQljp8DtfxmhRjGuD/54POh6aRxYrty37tBiBOzFC9GS61yVjR+wOIz0uWjzIyRRxHJTH TbeIpqFO2zPs+F6k3iWbWZm8u6NfllQR+Fx+sCQphsIvQm1Na65kX0T3c16SObo2jBBXqLxAg3/Ph ixRwQQ/oeOEvVDnZtYP6xGt1smJ4lD5j/bJ2jWC1bGBE8SNWi/r8bEtU+FZHgvPUGkgJu+fhIuHtb yFyzA7GyX+ZcaPclFktljwls13+GL6wAJNyi54p5m0es2R17+Y3Tc0YAvIIIhPZ8i40WyGWDd5hWa KoFezrGqfCGvCpX+4QXA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEA8j-006KB4-4G; Wed, 20 Jul 2022 13:53:25 +0000 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oEA8h-006K39-0R for linux-arm-kernel@lists.infradead.org; Wed, 20 Jul 2022 13:53:24 +0000 Received: by mail-ed1-x533.google.com with SMTP id v12so23853340edc.10 for ; Wed, 20 Jul 2022 06:53:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=v7Ua7Pjztqwug82UBS8PZqoIQdh5WrByyVymA7qNXfY=; b=Nmbr0Ft+AJ1qLYlMHWEXMpaR4XELHNyQAwZbdBWe8fGQhHqGPd1gD6d1KCMogKEBpz Bm7n5gTDnNsGpTpIkaOZ/zXnhVIirBjmDIiHPfE54B8fs3L0ulH52s18KafGlgDihKqD PaL3yw6KG6rnj0ZvTD+0rKFVYgv6JFRs8QlaCeMNV8thMquMeGmS7cdhhzAbqDi04V1y bqXgezBmXgeiTzanu4P8w270e0fjtnEJ0Rdb5mMCD7nIRDUxtqJ86WODqq6wl3rOeexs MpaGTPLcOKjG1JGubt82XE2ZHtNLyqAR7dQDQ01s94CBo8rkf6vBBE6N47hf84cFcPIX X2rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=v7Ua7Pjztqwug82UBS8PZqoIQdh5WrByyVymA7qNXfY=; b=TSM/Ho0RJMxi+UN5+2UonlxgFWW6IA0jMnja+JW4/XfYkSdMp1TORbsiS2Z20mzwVL NSDGF3U90KwRldfqqtC/LKH2+qRhF/p6vtORc3gRELkgnegv861vPOY55IStaIIIbZZA Ejsr0CnW36u1EGdl6o0hFPl6mx3cnyn4VQZ++Z66Ez6i4CeDX9k4Z8WJb/TuDe5NFsU1 HNAxcIqTNPAnZHN/rCX9cCDcMJPerZN3Cq0sM+OeK9Z+MZPdBJhsk8PiDJJI+SudBkUk WxeYlbL6mFp83H2kBKrNlQqBm0K1j1/5InkxWLf3n4/IpyWxKuee+hzRpDkWOY55jdqN 1exQ== X-Gm-Message-State: AJIora/g9RqNeLIrLH91hSrERDZNGioczbHD1vf63A+LzfI/KF7FcTXg Bk9S2xDGLNO1Bvp/e+eq41A= X-Google-Smtp-Source: AGRyM1tM9Guy5xL3TVWbHbE/7jg1cpe+wU1P3TJ2yS6onGuYZEUFHUh9quYHkm8PmlmdDbV86wGfEA== X-Received: by 2002:aa7:d788:0:b0:43b:bcbe:64d3 with SMTP id s8-20020aa7d788000000b0043bbcbe64d3mr1108303edq.15.1658325198189; Wed, 20 Jul 2022 06:53:18 -0700 (PDT) Received: from skbuf ([188.25.231.115]) by smtp.gmail.com with ESMTPSA id h10-20020a170906718a00b00718e4e64b7bsm7934599ejk.79.2022.07.20.06.53.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Jul 2022 06:53:17 -0700 (PDT) Date: Wed, 20 Jul 2022 16:53:14 +0300 From: Vladimir Oltean To: Sean Anderson Cc: Heiner Kallweit , Russell King , netdev@vger.kernel.org, Jakub Kicinski , Madalin Bucur , "David S . Miller" , Paolo Abeni , Ioana Ciornei , linux-kernel@vger.kernel.org, Eric Dumazet , Andrew Lunn , Alexandre Belloni , Benjamin Herrenschmidt , Claudiu Manoil , Florian Fainelli , Frank Rowand , Krzysztof Kozlowski , Li Yang , Michael Ellerman , Paul Mackerras , Rob Herring , Saravana Kannan , Shawn Guo , UNGLinuxDriver@microchip.com, Vivien Didelot , Vladimir Oltean , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [RFC PATCH net-next 0/9] net: pcs: Add support for devices probed in the "usual" manner Message-ID: <20220720135314.5cjxiifrq5ig4vjb@skbuf> References: <2d028102-dd6a-c9f6-9e18-5abf84eb37a1@seco.com> <20220719181113.q5jf7mpr7ygeioqw@skbuf> <20220711160519.741990-1-sean.anderson@seco.com> <20220719152539.i43kdp7nolbp2vnp@skbuf> <20220719153811.izue2q7qff7fjyru@skbuf> <2d028102-dd6a-c9f6-9e18-5abf84eb37a1@seco.com> <20220719181113.q5jf7mpr7ygeioqw@skbuf> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220720_065323_073571_DFFA8318 X-CRM114-Status: GOOD ( 21.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Jul 19, 2022 at 03:34:45PM -0400, Sean Anderson wrote: > We could do it, but it'd be a pretty big hack. Something like the > following. Phylink would need to be modified to grab the lock before > every op and check if the PCS is dead or not. This is of course still > not optimal, since there's no way to re-attach a PCS once it goes away. You assume it's just phylink who operates on a PCS structure, but if you include your search pool to also cover include/linux/pcs/pcs-xpcs.h, you'll see a bunch of exported functions which are called directly by the client drivers (stmmac, sja1105). At this stage it gets pretty hard to validate that drivers won't attempt from any code path to do something stupid with a dead PCS. All in all it creates an environment with insanely weak guarantees; that's pretty hard to get behind IMO. > IMO a better solution is to use devlink and submit a patch to add > notifications which the MAC driver can register for. That way it can > find out when the PCS goes away and potentially do something about it > (or just let itself get removed). Not sure I understand what connection there is between devlink (device links) and PCS {de}registration notifications. We could probably add those notifications without any intervention from the device core: we would just need to make this new PCS "core" to register an blocking_notifier_call_chain to which interested drivers could add their notifier blocks. How a certain phylink user is going to determine that "hey, this PCS is definitely mine and I can use it" is an open question. In any case, my expectation is that we have a notifier chain, we can at least continue operating (avoid unbinding the struct device), but essentially move our phylink_create/phylink_destroy calls to within those notifier blocks. Again, retrofitting this model to existing drivers, phylink API (and maybe even its internal structure) is something that's hard to hop on board of; I think it's a solution waiting for a problem, and I don't have an interest to develop or even review it. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel