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;
Date:   Thu, 13 Apr 2023 20:41:29 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Florian Fainelli <f.fainelli@gmail.com>
Cc:     Jacob Keller <jacob.e.keller@intel.com>,
        Yan Wang <rk.code@outlook.com>, davem@davemloft.net,
        edumazet@google.com, pabeni@redhat.com, kuba@kernel.org,
        mcoquelin.stm32@gmail.com,
        Giuseppe Cavallaro <peppe.cavallaro@st.com>,
        Alexandre Torgue <alexandre.torgue@foss.st.com>,
        Jose Abreu <joabreu@synopsys.com>,
        "open list:STMMAC ETHERNET DRIVER" <netdev@vger.kernel.org>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
        <linux-stm32@st-md-mailman.stormreply.com>,
        "moderated list:ARM/STM32 ARCHITECTURE" 
        <linux-arm-kernel@lists.infradead.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next v4] net: stmmac:fix system hang when setting up
 tag_8021q VLAN for DSA ports
Message-ID: <20230413174129.dafmlq57a3pc2ppn@skbuf>
References: <KL1PR01MB5448C7BF5A7AAC1CBCD5C36AE6989@KL1PR01MB5448.apcprd01.prod.exchangelabs.com>
 <01ef9d4f-d2dc-d584-4733-798cffda49a1@intel.com>
 <298c045a-5438-6761-46d8-c46c57989812@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <298c045a-5438-6761-46d8-c46c57989812@gmail.com>
Precedence: bulk

On Thu, Apr 13, 2023 at 10:15:55AM -0700, Florian Fainelli wrote:
> On 4/13/23 10:07, Jacob Keller wrote:
> > On 4/13/2023 8:06 AM, Yan Wang wrote:
> > > The system hang because of dsa_tag_8021q_port_setup()->
> > > 				stmmac_vlan_rx_add_vid().
> > > 
> > > I found in stmmac_drv_probe() that cailing pm_runtime_put()
> > > disabled the clock.
> > > 
> > > First, when the kernel is compiled with CONFIG_PM=y,The stmmac's
> > > resume/suspend is active.
> > > 
> > > Secondly,stmmac as DSA master,the dsa_tag_8021q_port_setup() function
> > > will callback stmmac_vlan_rx_add_vid when DSA dirver starts. However,
> > > The system is hanged for the stmmac_vlan_rx_add_vid() accesses its
> > > registers after stmmac's clock is closed.
> > > 
> > > I would suggest adding the pm_runtime_resume_and_get() to the
> > > stmmac_vlan_rx_add_vid().This guarantees that resuming clock output
> > > while in use.
> > > 
> > > Signed-off-by: Yan Wang <rk.code@outlook.com>
> > 
> > This looks identical to the net fix you posted at [1]. I don't think we
> > need both?
> > 
> > [1]:
> > https://lore.kernel.org/netdev/KL1PR01MB5448020DE191340AE64530B0E6989@KL1PR01MB5448.apcprd01.prod.exchangelabs.com/
> 
> Unfortunately both still lack a proper Fixes: tag, and this is bug fix.
> -- 
> Florian
> 

I guess that would be:

Fixes: 5ec55823438e ("net: stmmac: add clocks management for gmac driver")

although in this case, that would be only part of the story. That commit
split the runtime PM handling between stmmac_vlan_rx_add_vid() and
stmmac_vlan_rx_kill_vid() in a strange way, where an added VLAN RX
filter takes a refcount on the device, and a deleted filter one drops
the refcount.

That is... strange?! but it worked in a way, I guess.

Then commit b3dcb3127786 ("net: stmmac: correct clocks enabled in
stmmac_vlan_rx_kill_vid()") came a few months later and blamed that
oddity on a bad merge conflict resolution... ?! Basically, from what I
can tell, it's this later commit the one that broke things, for using
runtime PM only for stmmac_vlan_rx_kill_vid() but not for stmmac_vlan_rx_add_vid().