From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A09A3E9598; Tue, 20 Jan 2026 14:41:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.11.138.130 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768920082; cv=none; b=s37pxWtWRWKHhMoH2XWKWfoOH+LEWOxGPc0zzhQxpQQzPcnXtVTKiYZWP8x5UAPce20+UnJjNRbhGpznz1ibMm9Bv0YxRsDqN29EYP71ubHGeLcWMkF1Ks9m9ygqaD0B1+GK8ezxUd33Y4Dw+yi8lyzsZrdePk/UYgvjfivkvns= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768920082; c=relaxed/simple; bh=0eliuaQZWNTt7WLgFve+O+VDDRcSouQfwZyXuVgVuh8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=BHyWSQYAcaR7cejvhrFBrQqAo2+XS0syyEn/EJr87nQhpPPkK2MQW9II5wu05xVSvfiStSrmVd9qAiU10HUhyI9Py7yDUewT+BtvrXoeCKDF+7ArJH7Q4zHjYeyiwipBa7fLzMHOXZ/7343ktWnzrfBf5zT3qDCmi8OqZR91fW0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de; spf=pass smtp.mailfrom=sntech.de; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b=wlp0I5GK; arc=none smtp.client-ip=185.11.138.130 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sntech.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sntech.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b="wlp0I5GK" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de; s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version: References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Reply-To; bh=Sag+H/BhPZ45KSkJ6zCyuoYRKvuE9xHt5nOXwQMVW40=; b=wlp0I5GKmkHGAajTVUbav838z3 6hqseOEREYnEOKPj/nmBZZi/VZDgF5D6MNyxqFPU0be0Ids+mGYNL/DbmmjFKW4UL4X6Tf1IlNKzw 2JzL/ufy7vBtteFvAA/uIQ5jhdJxU2d6EgQCECbgueW+iOAHk4zaAZpdf2gq4EPJEkAonK0ZmGJor q/T/DsRgoreG3A+qEK9gcRNjJr1I2sbYzd4U6W28Wat5tRGRkkLU4d7BIM9N9WbUzE1uQBE5g4FIL GgmOdXHfV96fRHsRrGuSGsgbYEwHLdEDX/quh3UR2izo/uXGz5y4QsnuixAmOxjB3EjGTaqorYDcZ cG+3jzaA==; Received: from i53875a75.versanet.de ([83.135.90.117] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1viCuo-003T50-Vr; Tue, 20 Jan 2026 15:41:07 +0100 From: Heiko =?UTF-8?B?U3TDvGJuZXI=?= To: Quentin Schulz , Alexey Charkov Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , "Martin K. Petersen" , Shawn Lin , Manivannan Sadhasivam , devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] arm64: dts: rockchip: Explicitly request UFS reset pin on RK3576 Date: Tue, 20 Jan 2026 15:41:06 +0100 Message-ID: <4830042.taCxCBeP46@diego> In-Reply-To: References: <20260120-ufs-rst-v2-1-b5735f1996f6@gmail.com> <9e51b504-e0f0-4d17-baa2-387339507c86@cherry.de> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Am Dienstag, 20. Januar 2026, 14:14:48 Mitteleurop=C3=A4ische Normalzeit sc= hrieb Alexey Charkov: > On Tue, Jan 20, 2026 at 5:00=E2=80=AFPM Quentin Schulz wrote: > > > > Hi Alexey, > > > > On 1/20/26 1:53 PM, Alexey Charkov wrote: > > > Rockchip RK3576 UFS controller uses a dedicated pin to reset the conn= ected > > > UFS device, which can operate either in a hardware controlled mode or= as a > > > GPIO pin. > > > > > > Power-on default is GPIO mode, but the boot ROM reconfigures it to a > > > hardware controlled mode if it uses UFS to load the next boot stage. > > > > > > Given that existing bindings (and rk3576.dtsi) expect a GPIO-controll= ed > > > device reset, request the required pin config explicitly. > > > > > > This doesn't appear to affect Linux, but it does affect U-boot: > > > > > > Before: > > > =3D> md.l 0x2604b398 > > > 2604b398: 00000011 00000000 00000000 00000000 ................ > > > < ... snip ... > > > > =3D> ufs init > > > ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=3D[3, 3], lane[2, 2], = pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate =3D 2 > > > =3D> md.l 0x2604b398 > > > 2604b398: 00000011 00000000 00000000 00000000 ................ > > > > > > After: > > > =3D> md.l 0x2604b398 > > > 2604b398: 00000011 00000000 00000000 00000000 ................ > > > < ... snip ...> > > > =3D> ufs init > > > ufshcd-rockchip ufshc@2a2d0000: [RX, TX]: gear=3D[3, 3], lane[2, 2], = pwr[FASTAUTO_MODE, FASTAUTO_MODE], rate =3D 2 > > > =3D> md.l 0x2604b398 > > > 2604b398: 00000010 00000000 00000000 00000000 ................ > > > > > > (0x2604b398 is the respective pin mux register, with its BIT0 driving= the > > > mode of UFS_RST: unset =3D GPIO, set =3D hardware controlled UFS_RST) > > > > > > This helps ensure that GPIO-driven device reset actually fires when t= he > > > system requests it, not when whatever black box magic inside the UFSHC > > > decides to reset the flash chip. > > > > > > > Would have liked a mention on why pull-down in the commit log. >=20 > Indeed. Heiko, if you're going to apply this to your tree, would you > mind amending the commit description with something like the > following? >=20 > The pin is requested with pull-down enabled, which is in line with the > SoC power-on default and helps ensure that the attached UFS chip stays > in reset until the driver takes over the control of the respective > GPIO line. Will do :-) Heiko > > In any case, > > > > Reviewed-by: Quentin Schulz >=20 > Thanks a lot! >=20 > Best regards, > Alexey >=20