From: Sean Anderson <sean.anderson@linux.dev>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: "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 10:45:32 -0500 [thread overview]
Message-ID: <d6788510-3ae2-4f13-85f6-c0438c89b9a6@linux.dev> (raw)
In-Reply-To: <20260113004941.4fhmvlkhf5pifwgt@synopsys.com>
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.
next prev parent reply other threads:[~2026-01-13 15:45 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 [this message]
2026-01-13 23:53 ` Thinh Nguyen
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=d6788510-3ae2-4f13-85f6-c0438c89b9a6@linux.dev \
--to=sean.anderson@linux.dev \
--cc=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 \
/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
Powered by JetHome