Received: by 2002:a05:7412:3210:b0:e2:908c:2ebd with SMTP id eu16csp907739rdb; Fri, 1 Sep 2023 07:33:02 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGN6FQTjJ5hg5ScdpY+OfBFCbBKtnMQtUKDKGy+zhZtqfZOeR6Iz71d9YGyXS6wkjhghR84 X-Received: by 2002:a05:6a00:b48:b0:68a:570f:e36a with SMTP id p8-20020a056a000b4800b0068a570fe36amr2999362pfo.4.1693578781684; Fri, 01 Sep 2023 07:33:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1693578781; cv=none; d=google.com; s=arc-20160816; b=k0ChkcCrhFWJ9I8F8j6l4kjRahx60n6+ntIVJ9P9EgXNmFwu5HCVSzNbq2J3DVhUHQ RKjsJRycsQvwURmVzj/swfnfQ9Nx7IqhQq9c1lvzbsQ5xoP8LWFu6M/rnbSKHlFk7JH5 G89vm7zGiUKZ/vY5Sdv6ytMM/Bpbt6zOITF0VNfnwiUJidRmx7ZxFhdBjAZb9h5TZsTY cfBJPya8WBYJztY642Ue/vAvhav4fMK7VHUJEwunYqalT4sOrUnCL8yU5GNTENpfcNse d83fWNK+t/hMvpBJdcOdrBbe6kxWvIAV6NiavgkkIPO/3hQvnVOOMoZ0Lea1C1K9GLlQ 0eYw== 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=hBuX7nam5gAwvmnrcnEmb9akPHOPpfY13LdGw+HDNN4=; fh=X0amR1yIzxOZ95nRnYYZkSjaUrKfirCkt+fz0SBXQtg=; b=phEHKRADt6ZZEWCCMtJUGzMBP8qlu3kriXvHcBYG1674X96ZNLmaUQPbzXDgJBWSMC xLSq4z92iiFWuAWwRe4zaD3M2mCBT4anUbleA1OLgoOR7IlFvnN0pLFPa7tlcYInA0Pq RcbOEB7jd5io3AVr48zPhfk8uvMO1xxrK6ha4Ah2wC8sc/LuYO34Zdbelo9XR1LwD1kE sUS9daifkOZKo2b2ui+0dzYj3zY/i35SL0g1gqFBCEFe65G2oYbgE+3kD5PS0S1UNQiD nYd8+njKIlNNsKV5US4PYp70nmLnlCFfDD9iTBKHJE68NMPor17eEJR9+VRc7Ft20brn JGrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b="VS9CV/bn"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cd10-20020a056a00420a00b006688c47e5b4si2894204pfb.399.2023.09.01.07.32.42; Fri, 01 Sep 2023 07:33:01 -0700 (PDT) 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=fail (test mode) header.i=@armlinux.org.uk header.s=pandora-2019 header.b="VS9CV/bn"; 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=fail (p=NONE sp=NONE dis=NONE) header.from=armlinux.org.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233555AbjIAMrn (ORCPT + 99 others); Fri, 1 Sep 2023 08:47:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47924 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229666AbjIAMrl (ORCPT ); Fri, 1 Sep 2023 08:47:41 -0400 Received: from pandora.armlinux.org.uk (unknown [IPv6:2001:4d48:ad52:32c8:5054:ff:fe00:142]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC9361712; Fri, 1 Sep 2023 05:47:01 -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=hBuX7nam5gAwvmnrcnEmb9akPHOPpfY13LdGw+HDNN4=; b=VS9CV/bnPTECa4kVBOglmidFnz DZoU2xOv9m6v9xwyr03s63CnbrEebOlw0HhCxVIkktpuz1VoecbABL07nFYO/XgMbjcDFMOpmoWT/ WM0K/JQ85uw34SMTY56jBM58KJ1EERr5V2vOhxFSnEXAmSKv/wyhKHnWg0Sm3I8EQCYPCL/alRn1H IE3xv/kreq3kgA6iMpZ4Cc5cd6GBUSgSgVXmT81zdF5OeK0BlPOzjN6PfWv/oXZFGGZlRG0AAmrfG gf/Rn0oMnsR5kWFPpKOHSO9Qzo3igTW23eZlaiPolOld6zK58nMfFs1+j2g5fec7+Syn2aFWM9MUC m7HzmWTg==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:35794) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1qc3X1-00049k-0L; Fri, 01 Sep 2023 13:45:47 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.94.2) (envelope-from ) id 1qc3Wy-0007qD-LR; Fri, 01 Sep 2023 13:45:44 +0100 Date: Fri, 1 Sep 2023 13:45:44 +0100 From: "Russell King (Oracle)" To: "Radu Pirea (OSS)" Cc: Radu Pirea , "atenart@kernel.org" , "sd@queasysnail.net" , "andrew@lunn.ch" , "hkallweit1@gmail.com" , "davem@davemloft.net" , Sebastian Tobuschat , "linux-kernel@vger.kernel.org" , "pabeni@redhat.com" , "richardcochran@gmail.com" , "edumazet@google.com" , "kuba@kernel.org" , "netdev@vger.kernel.org" Subject: Re: [RFC net-next v2 5/5] net: phy: nxp-c45-tja11xx: implement mdo_insert_tx_tag Message-ID: References: <20230824091615.191379-1-radu-nicolae.pirea@oss.nxp.com> <20230824091615.191379-6-radu-nicolae.pirea@oss.nxp.com> <5d42d6c9-2f0c-8913-49ec-50a25860c49f@oss.nxp.com> <518c11e9000f895fddb5b3dc4d5b2bf445cf320f.camel@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Russell King (Oracle) X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED,RDNS_NONE, SPF_HELO_NONE,SPF_NONE autolearn=no 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: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 01, 2023 at 02:31:32PM +0300, Radu Pirea (OSS) wrote: > On 01.09.2023 12:27, Russell King (Oracle) wrote: > > On Fri, Sep 01, 2023 at 09:09:06AM +0000, Radu Pirea wrote: > > > On Wed, 2023-08-30 at 13:35 +0200, Sabrina Dubroca wrote: > > > ... > > > > > > > And it's not restored when the link goes back up? That's inconvenient > > > > :/ > > > > Do we end up with inconsistent state? ie driver and core believe > > > > everything is still offloaded, but HW lost all state? do we leak > > > > some resources allocated by the driver? > > > > > > Yes. We end up with inconsistent state. The HW will lost all state when > > > the phy is reseted. No resource is leaked, everything is there, but the > > > configuration needs to be reapplied. > > > > If it's happening because the PHY is being re-attached from the network > > driver, then wouldn't it be a good idea to synchronise the hardware > state with the software configuration in the ->config_init function? > > .config_init might be an option, but keeping the keys in the driver might > not be a good idea. > > > > > Presumably the hardware state is also lost when resuming from suspend > > as well? If so, that'll also fix that issue as well. > soft_reset is called when resuming from suspend, so, in this case, the > MACsec configuration will be lost. Depending on what loses power at suspend time, it could be that the PHY is powered down, and thus would lose all configuration. This is something that the MACSEC core _has_ to expect may happen, and there has to be some way to restore the configuration, including the keys! One can't "write configuration to hardware and then forget" when the hardware may lose state, no matter what the configuration is. Take for example hibernation... where the system may be effectively powered off - maybe even if it's a piece of mains powered equipment, it may be unplugged from the mains. When the system resumes, shouldn't the configuration be completely restored, keys and all, so that it continues to function as it was before hibernation? The only possible alternative would be to have some kind of way for the driver to tell the core that state was lost, so the core can invalidate that state and inform userspace of that event, so userspace gets the opportunity itself to restore the lost state. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!