From: Philipp Zabel <p.zabel@pengutronix.de>
To: Yixun Lan <dlan@kernel.org>
Cc: Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Junzhong Pan <junzhong.pan@spacemit.com>,
Guodong Xu <guodong@riscstar.com>,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
spacemit@lists.linux.dev, linux-kernel@vger.kernel.org,
Inochi Amaoto <inochiama@gmail.com>
Subject: Re: [PATCH v3] reset: spacemit: k3: Decouple composite reset lines
Date: Thu, 19 Mar 2026 12:42:47 +0100 [thread overview]
Message-ID: <c0a6d0346e2b766ab4dab3340445c45843f28b60.camel@pengutronix.de> (raw)
In-Reply-To: <20260318131043-GKA488271@kernel.org>
On Mi, 2026-03-18 at 21:10 +0800, Yixun Lan wrote:
> Hi Philipp,
>
> On 13:39 Wed 18 Mar , Philipp Zabel wrote:
> > On Di, 2026-03-17 at 02:36 +0000, Yixun Lan wrote:
> > > Instead of grouping several different reset lines into one composite
> > > reset, decouple them to individual ones which make it more aligned
> > > with underlying hardware. And for DWC USB driver, it will match well
> > > with the number of the reset property in the DT bindings.
> > >
> > > The DWC3 USB host controller in K3 SoC has three reset lines - AHB, VCC,
> > > PHY. The PCIe controller also has three reset lines - DBI, Slave, Master.
> > > Also three reset lines each for UCIE and RCPU block.
> > >
> > > As an agreement with maintainer, the reset IDs has been rearranged as
> > > contiguous number and pushed as a fix for the driver, and reason is that
> > > there isn't any consumer of reset driver so far,
> >
> > Unfortunately that does not seem to be the case for all APMU resets.
> > A lore query for all changed IDs [1] yields a patch that adds ethernet
> > device nodes using RESET_APMU_EMAC[012] [2].
> >
> Yes, although the ethernet use this ID, but I don't think we should worry
> about that, since the ethernet patch is still under review, and ideally it
> will be merged after this reordering patch, unless you disagree? and insist
> the RESET_APMU_EMAC should not be changed?
Yes, please. Somebody might have picked up those patches from the list
and we can easily avoid the risk of breaking their ethernet with v7.0
by not reordering all resets. Let's do that.
regards
Philipp
prev parent reply other threads:[~2026-03-19 11:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 2:36 Yixun Lan
2026-03-18 12:39 ` Philipp Zabel
2026-03-18 13:10 ` Yixun Lan
2026-03-18 13:17 ` Yixun Lan
2026-03-19 11:42 ` Philipp Zabel [this message]
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=c0a6d0346e2b766ab4dab3340445c45843f28b60.camel@pengutronix.de \
--to=p.zabel@pengutronix.de \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlan@kernel.org \
--cc=guodong@riscstar.com \
--cc=inochiama@gmail.com \
--cc=junzhong.pan@spacemit.com \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=robh@kernel.org \
--cc=spacemit@lists.linux.dev \
/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
all inboxes | Powered by JetHome®