From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
To: Sean Anderson <sean.anderson@linux.dev>
Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
"Pandey, Radhey Shyam" <radhey.shyam.pandey@amd.com>,
"open list:DESIGNWARE USB3 DRD IP DRIVER"
<linux-usb@vger.kernel.org>, "Frager, Neal" <neal.frager@amd.com>,
"Simek, Michal" <michal.simek@amd.com>,
open list <linux-kernel@vger.kernel.org>,
"moderated list:ARM/ZYNQ ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] usb: dwc3: Always deassert xilinx resets
Date: Tue, 13 Jan 2026 23:53:51 +0000 [thread overview]
Message-ID: <20260113235334.t6cx2y2zrj436wtb@synopsys.com> (raw)
In-Reply-To: <d6788510-3ae2-4f13-85f6-c0438c89b9a6@linux.dev>
On Tue, Jan 13, 2026, Sean Anderson wrote:
> On 1/12/26 19:49, Thinh Nguyen wrote:
> > On Fri, Jan 09, 2026, Sean Anderson wrote:
> >> On 1/9/26 01:01, Pandey, Radhey Shyam wrote:
> >> > [AMD Official Use Only - AMD Internal Distribution Only]
> >> >
> >> >> -----Original Message-----
> >> >> From: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> >> >> Sent: Friday, January 9, 2026 6:19 AM
> >> >> To: Sean Anderson <sean.anderson@linux.dev>
> >> >> Cc: Thinh Nguyen <Thinh.Nguyen@synopsys.com>; open list:DESIGNWARE
> >> >> USB3 DRD IP DRIVER <linux-usb@vger.kernel.org>; Frager, Neal
> >> >> <neal.frager@amd.com>; Simek, Michal <michal.simek@amd.com>; open list
> >> >> <linux-kernel@vger.kernel.org>; moderated list:ARM/ZYNQ ARCHITECTURE
> >> >> <linux-arm-kernel@lists.infradead.org>; Philipp Zabel <p.zabel@pengutronix.de>;
> >> >> Pandey, Radhey Shyam <radhey.shyam.pandey@amd.com>; Greg Kroah-Hartman
> >> >> <gregkh@linuxfoundation.org>
> >> >> Subject: Re: [PATCH] usb: dwc3: Always deassert xilinx resets
> >> >>
> >> >> On Tue, Jan 06, 2026, Sean Anderson wrote:
> >> >> > If we don't have a usb3 phy we don't need to assert the core resets.
> >> >> > Deassert them even if we didn't assert them to support booting when
> >> >> > the bootloader never released the core from reset.
> >> > Is it a customized bootloader ? i.e it assert reset but don't deassert.
> >>
> >> No. Most peripheral resets are asserted on PoR. So if the bootloader
> >> doesn't deassert them then Linux has to.
> >>
> >> My goal is to make init_serdes() in psu_init_gpl.c optional and do all
> >> serdes initialization in the phy driver (and in the consumer drivers). I
> >> have this working for DP/PCIe. I'm working on SATA, and I don't think
> >> USB/SGMII need much special. This gives the following advantages:
> >>
> >> - On some boards (mine) the reference clocks may not be configured in
> >> SPL/FSBL. So ILL calibration will fail (and take a long time to do so)
> >> unless we defer initialization to U-Boot/Linux where the phy driver
> >> can request the clocks.
> >> - If PCIe/SATA are not used in U-Boot, ILL calibration can be deferred
> >> until Linux when it can be done it parallel with other initialization.
> >> - We will have flexibility to switch between different serdes
> >> configurations at runtime. For example, this could allow the
> >> bootloader to fixup the devicetree to support PCIe and SATA M.2
> >> drives, depending on what the user has plugged in.
> >>
> >> > I think ideally core /APB reset should be done independent on
> >> > MAC 2.0/3.0 configuration.
> >>
> >> I agree, but I think the existing code does this optimization to reduce
> >> boot time when the bootloader has already initialized USB. I have
> >> preserved that in this patch.
> >>
> >
> > I think all this info is useful. Can we include it in the change log?
>
> OK, how about:
>
> I am working on moving serdes initialization to the phy (and consumer)
> drivers to improve flexibility and boot times (depending on
> configuration). Currently, core resets are released in the bootloader by
> init_serdes() in psu_init_gpl.c. In order to remove init_serdes, we
> need to handle the case where the bootloader never released the core
> resets. If we don't have a usb3 phy we don't need to assert the core
> resets, but deassert them anyway to handle this case.
>
> We could assert all resets every boot, but I believe the existing
> procedure is an optimization to reduce boot time when the bootloader has
> already initialized USB. So this patch preserves the separate code
> paths.
Sounds good to me! Typically we write it in imperative mood, but it's
just minor nit. I care more about the motivation behind these changes.
Radhey can comment if there's doubt.
Otherwise, you can add this in v2:
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Thanks,
Thinh
next prev parent reply other threads:[~2026-01-13 23:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-06 17:10 Sean Anderson
2026-01-09 0:49 ` Thinh Nguyen
2026-01-09 6:01 ` Pandey, Radhey Shyam
2026-01-09 15:51 ` Sean Anderson
2026-01-13 0:49 ` Thinh Nguyen
2026-01-13 15:45 ` Sean Anderson
2026-01-13 23:53 ` Thinh Nguyen [this message]
2026-01-13 0:43 ` Thinh Nguyen
2026-01-09 15:52 ` Sean Anderson
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=20260113235334.t6cx2y2zrj436wtb@synopsys.com \
--to=thinh.nguyen@synopsys.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=neal.frager@amd.com \
--cc=p.zabel@pengutronix.de \
--cc=radhey.shyam.pandey@amd.com \
--cc=sean.anderson@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®