Devicetree
 help / color / mirror / Atom feed
From: "Stefan Dösinger" <stefandoesinger@gmail.com>
To: Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Brian Masney <bmasney@redhat.com>,
	Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver
Date: Wed, 24 Jun 2026 23:00:04 +0300	[thread overview]
Message-ID: <7_XKp5ZWTJeJfxJieymOJA@gmail.com> (raw)
In-Reply-To: <90c4f50eb23dec06497d46f9c0f522a6b90a918b.camel@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

Hi Philipp,

Am Donnerstag, 18. Juni 2026, 12:24:26 Ostafrikanische Zeit schrieb Philipp 
Zabel:

> > +	[ZX297520V3_UART0_RESET]     = { .reg = 0x78,  .mask = BIT(6)  | 
BIT(7) 
> > },
> Is this a single reset line controlled by two bits (do you know what
> they are)? Or might these actually be two different reset controls that
> are just always set together?

I suppose I could expose both bits as separate reset controls in the binding. 
The lower bit is usually the one that actually resets the device, while the 
higher one works similarly to PCLK - it disconnects the device from the bus, 
if asserted. Depending on the device it may or may not leave any residual 
effect behind after deassert.

The stumbling block is the dwc2 USB driver. It only takes one reset, so I'd 
have to add another one (or abuse the dwc2-ecc reset) and presumably add a PHY 
driver for the 3rd reset or add a dwc2-phy reset.

The AMBA bus already takes an array of resets, so the pl011 UARTs are fine 
either way. For stmmac I need a glue driver for other reasons anyway. the 
dwc,mmc2 controller on this board seems to have only one reset, so no need to 
extend the driver here.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

  parent reply	other threads:[~2026-06-24 20:00 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-16 20:26 [PATCH RFC v4 00/12] ZTE zx297520v3 clock bindings and driver Stefan Dösinger
2026-06-16 20:26 ` [PATCH RFC v4 01/12] dt-bindings: clk: zte: Add zx297520v3 top clock and reset bindings Stefan Dösinger
2026-06-16 20:32   ` sashiko-bot
2026-06-17 16:08   ` Conor Dooley
2026-06-17 17:47     ` Stefan Dösinger
2026-06-17 21:23       ` Conor Dooley
2026-06-17 21:41         ` Conor Dooley
2026-06-18 18:59         ` Stefan Dösinger
2026-06-18 19:54           ` Conor Dooley
2026-06-20 17:28             ` Stefan Dösinger
2026-06-21 18:58               ` Conor Dooley
2026-06-16 20:26 ` [PATCH RFC v4 02/12] dt-bindings: clk: zte: Add zx297520v3 matrix " Stefan Dösinger
2026-06-17 16:11   ` Conor Dooley
2026-06-16 20:26 ` [PATCH RFC v4 03/12] dt-bindings: clk: zte: Add zx297520v3 LSP " Stefan Dösinger
2026-06-16 20:34   ` sashiko-bot
2026-06-17 16:12   ` Conor Dooley
2026-06-16 20:26 ` [PATCH RFC v4 04/12] clk: zte: Add Clock registration infrastructure Stefan Dösinger
2026-06-16 20:38   ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 05/12] clk: zte: Add zx PLL support infrastructure Stefan Dösinger
2026-06-16 20:43   ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 06/12] clk: zte: Add regmap based clocks Stefan Dösinger
2026-06-16 20:39   ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 07/12] clk: zte: Introduce a driver for zx297520v3 top clocks Stefan Dösinger
2026-06-16 20:43   ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 08/12] clk: zte: Introduce a driver for zx297520v3 matrix clocks Stefan Dösinger
2026-06-16 20:37   ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 09/12] clk: zte: Introduce a driver for zx297520v3 LSP clocks Stefan Dösinger
2026-06-16 20:38   ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 10/12] reset: zte: Add a zx297520v3 reset driver Stefan Dösinger
2026-06-18  9:24   ` Philipp Zabel
2026-06-18 19:28     ` Stefan Dösinger
2026-06-24 20:00     ` Stefan Dösinger [this message]
2026-06-16 20:26 ` [PATCH RFC v4 11/12] ARM: dts: zte: Declare zx297520v3 clock device nodes Stefan Dösinger
2026-06-16 20:38   ` sashiko-bot
2026-06-16 20:26 ` [PATCH RFC v4 12/12] ARM: dts: zte: Add a syscon-reboot for zx297520v3 boards Stefan Dösinger
2026-06-16 20:42   ` sashiko-bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7_XKp5ZWTJeJfxJieymOJA@gmail.com \
    --to=stefandoesinger@gmail.com \
    --cc=bmasney@redhat.com \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=p.zabel@pengutronix.de \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox