public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Quentin Schulz <quentin.schulz@cherry.de>
To: Jonas Karlman <jonas@kwiboo.se>
Cc: Kever Yang <kever.yang@rock-chips.com>,
	Simon Glass <sjg@chromium.org>,
	Philipp Tomsich <philipp.tomsich@vrull.eu>,
	Eugen Hristev <eugen.hristev@linaro.org>,
	Tom Rini <trini@konsulko.com>,
	Sebastian Reichel <sebastian.reichel@collabora.com>,
	u-boot@lists.denx.de
Subject: Re: [PATCH] rockchip: rk3588-rock-5b: Remove USB-C controller from u-boot.dtsi
Date: Mon, 16 Feb 2026 10:21:26 +0100	[thread overview]
Message-ID: <34da365d-38aa-4325-912e-cc2980ea1710@cherry.de> (raw)
In-Reply-To: <0670f2d7-89ad-47f0-90fc-de8ebe8dd81a@kwiboo.se>

Hi Jonas,

On 2/13/26 6:42 PM, Jonas Karlman wrote:
> Hi Quentin,
> 
> On 2/13/2026 6:17 PM, Quentin Schulz wrote:
>> Hi Jonas,
>>
>> On 1/26/26 10:55 PM, Jonas Karlman wrote:
>>
>> [...]
>>
>>> -&usb_host0_xhci {
>>> -	dr_mode = "peripheral";
>>> -	maximum-speed = "high-speed";
>>
>> This is not set anymore after this patch is applied (dr_mode = otg and
>> no maximum-speed). Please keep this part as is and if actually fine to
>> remove, have a separate commit motivating the removal.
> 
> I disagree, these props may differ but the function they result in for
> U-Boot is the same, i.e. ums and rockusb commands can be used before and
> after this patch.
> 
> The board u-boot.dtsi included something minimal required to have ums
> and rockusb working, this can fully be replaced with upstream DT and
> U-Boot functionality stay the same. Something I think current commit
> message is already covering.
> 

I read the commit log as "code is already in upstream DTS so remove 
duplicated code", which isn't true as two properties aren't 
making/haven't made it.

At the very least, highlight those two changes and justify why it's fine 
not to have them anymore.

Can we enter SPL_DFU mode with dr_mode = otg? (I assume we could in the 
past?) You are the one who added those two properties in 2024 and it 
also wasn't really motivated back then, so why maximum-speed as well? 
And why is it fine to remove now?

Cheers,
Quentin

  reply	other threads:[~2026-02-16  9:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-26 21:55 [PATCH] rockchip: rk3588-rock-5b: Remove USB-C controller from u-boot.dtsi Jonas Karlman
2026-01-26 22:09 ` Sebastian Reichel
2026-02-13 17:17 ` Quentin Schulz
2026-02-13 17:42   ` Jonas Karlman
2026-02-16  9:21     ` Quentin Schulz [this message]
2026-03-09  3:02 ` Kever Yang

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=34da365d-38aa-4325-912e-cc2980ea1710@cherry.de \
    --to=quentin.schulz@cherry.de \
    --cc=eugen.hristev@linaro.org \
    --cc=jonas@kwiboo.se \
    --cc=kever.yang@rock-chips.com \
    --cc=philipp.tomsich@vrull.eu \
    --cc=sebastian.reichel@collabora.com \
    --cc=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /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