From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id A6F883EDAB5 for ; Thu, 23 Apr 2026 12:45:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776948354; cv=none; b=rVWrgw8GNZbBI9c+Z6Pm2dpGDDGtEDxLsiVWY8w4E9QCWkFoAwugx/sipri8ifFubgLEa9W3V8DGkaj9l8sJl4/mZP8FnppNBe35qRpIzZKacaGbr30R8//XKZAj6jT9n4f/FNd2mwocOOlBrUKmfJY1r+SNCGkzp2ssFBNGaU0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776948354; c=relaxed/simple; bh=1hnK+dHO7NwK59eFBNOIB9XPiLwJlzfXVNvT1CU00Qs=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VrlyG0XuScc6Q9dgVcBkgKLWz7HvCATOiHsJ1HTeXNPOOp10iwji4tUDW1vCLTG5FD0z8Cy7F5NADFlVdG7+b44YNu6ndQMf6uePJdqZYGOXVpcCNxHSCJ66jJGpswUp1Lh8P4OiuKTsaENqTZjsxxgfwsKGF4oe+uIMlKQ16Yw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=XMw4tqRA; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="XMw4tqRA" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 634E01C25; Thu, 23 Apr 2026 05:45:46 -0700 (PDT) Received: from [10.1.25.24] (e122027.cambridge.arm.com [10.1.25.24]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DFB543F7B4; Thu, 23 Apr 2026 05:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776948351; bh=1hnK+dHO7NwK59eFBNOIB9XPiLwJlzfXVNvT1CU00Qs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=XMw4tqRAbByxim3L352hb+YPq0+x+rFyqMEbF+Ud3DlrMHyfnUkACe7Msq3RIzFDa /otMb2ZVUa+zSaBR1Xyz61oLk7HVDy8ZHzRlNN0HRlTrbDNxmtNh1Vh7rt4s6HeQ4r iv+extJAW33uiyU/AuU6ysNc1jc3spJMCNThX7hw= Message-ID: Date: Thu, 23 Apr 2026 13:45:48 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] reset: use a shared SRCU domain for reset controls To: Philipp Zabel , Heiko Stuebner Cc: linux-kernel@vger.kernel.org, Bartosz Golaszewski References: <20260417154809.1984386-1-steven.price@arm.com> From: Steven Price Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit +Heiko for the Rockchip questions. On 23/04/2026 11:27, Philipp Zabel wrote: > Hi Steven, > > On Fr, 2026-04-17 at 16:48 +0100, Steven Price wrote: >> Commit 78ebbff6d1a0 ("reset: handle removing supplier before consumers") >> added a dynamically initialized srcu_struct to every reset_control and >> cleaned it up again when the handle was dropped. >> >> That breaks early boot users which acquire and release reset handles >> before workqueues are online. On rk3288 this shows up during >> rockchip_smp_prepare_cpus(), where pmu_set_power_domain() gets a reset >> control for a CPU core and then drops it again before SMP bring-up has >> finished. > > Can the reset_control_put() call be dropped from pmu_set_power_domain() > to fix the problem? I'm not that familiar with the code, so I'm not sure. Just dropping that call causes a WARN_ON() bringing the secondary CPUs on (because the call to rockchip_get_core_reset() expects to have exclusive access to the reset). Switching to a shared reset then his a WARN_ON() in reset_control_assert because deassert_count == 0. I could keep digging blindly but I'm not really sure how this code is meant to work. Hopefully Heiko might be able to shed some more light on this? > Putting the reset control should mean that the driver doesn't care > about the state of the reset line anymore, but the platsmp code very > much expects the reset line to stay deasserted after enabling a CPU. > Acquiring reset controls in rockchip_smp_prepare_cpus() once and never > giving them up via reset_control_put() seems like a correct fix, > regardless of whether this patch is applied or not. > > It looks like the meson platsmp suffers from the same issue. This is why I did the fix in the reset code - how many other platforms might have similar issues? But obviously if these platforms are buggy then they should be fixed. My interest is keeping the devboard working so I can keep testing Panfrost on it. Thanks, Steve >> cleanup_srcu_struct() then tries to flush delayed SRCU work >> and hits the WARN_ON(!wq_online) path, which can leave the machine >> hanging before the serial console appears. >> >> Keep the supplier-removal protection, but move it to a single shared >> static SRCU domain for the reset core. That preserves the rcdev lifetime >> protection needed for supplier unregister without requiring per-handle >> init_srcu_struct()/cleanup_srcu_struct() on normal get/put paths. > > I'd prefer to document the workqueue requirement and keep the SRCU > domain per reset_control, if possible. > > regards > Philipp