From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from gloria.sntech.de (gloria.sntech.de [185.11.138.130])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5262D31619C
	for <linux-kernel@vger.kernel.org>; Thu, 28 May 2026 05:57:55 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.11.138.130
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1779947879; cv=none; b=nFtPkiRSumClGX305aYHLe4yWucO3ijw1PvoLm9ajwoumx0ahy8jPlhKoj6Mvxhu33bYMtfntjOgdN3cVYPOGkPfhAcYL3V5e38/fagMPdKZJ8jkjXRbybOmPRUjDQTxhhqFIw5w0TiXBkOFx+vChC/HTy3ntFe0H+0M3qD98js=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1779947879; c=relaxed/simple;
	bh=feq5ROLEFqZUsskJCd/WjBg1UiksitEwcgfOY2/fn2M=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version:Content-Type; b=UKEUz6FZF7ojfEcV1QS7jUqn8KYBMa/Q9SrO7L/NQKjhZ0TFLkuRHOMlps0T1ZmojiUMV9ScX/n7RhMMD9n+VPUaW1TlybSTY/Rc0CHnVkOOEPxEdPq5FwLUcj1dGwI97hS4QT1SO7hTxoHI3/DkCfC/+Hyv4mg+i/DftXhvXbo=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=sntech.de; spf=pass smtp.mailfrom=sntech.de; dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b=QlVv0Qrk; arc=none smtp.client-ip=185.11.138.130
Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=sntech.de
Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sntech.de
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=sntech.de header.i=@sntech.de header.b="QlVv0Qrk"
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sntech.de;
	s=gloria202408; h=Content-Type:Content-Transfer-Encoding:MIME-Version:
	References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Reply-To;
	bh=Fd80mj/3IKoqWLM74yrIKUbYLZKNJTRnbWUqqZcHbKs=; b=QlVv0Qrk0PyeAuUmNgfjl8R7/Z
	NeoTZdlSlxqRCcZHYA3bn1vb/T2z1+qwkDd5Tuk/9oOQn/Ssn+BK2wkx+yWy4wCPL6GKPzoNoXN1t
	idv4b5jx5aE37qz6gYEnEYQgrnXv0qLTZZtqdffUdf51mQ4D3D2n3P3Dpy7pTE90V3CEplSN+dWDG
	/NgcjdBvzy7d+ekKG67XLwOPF7FUhyGgmhPSyhd817TSXP3RklXa5YZT2d4IPLE4ueTld9QojvTkJ
	FMbVbPwc9PncJ4ocnWF03PXJK7njzwB2Mn0Qg+x306NgieTKIfOo0StcAtoTb6uGAVD6Xm9sTzAkG
	tX3oGzrg==;
From: Heiko Stuebner <heiko@sntech.de>
To: Chukun Pan <amadeus@jmu.edu.cn>
Cc: jonas@kwiboo.se, linux-arm-kernel@lists.infradead.org,
 linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org,
 Chukun Pan <amadeus@jmu.edu.cn>
Subject:
 Re: [PATCH v2 2/5] arm64: dts: rockchip: Enable USB 2.0 ports on Radxa E20C
Date: Thu, 28 May 2026 07:57:45 +0200
Message-ID: <3879225.zToM8qfIzz@phil>
In-Reply-To: <20260525065005.1056845-1-amadeus@jmu.edu.cn>
References:
 <20260505171208.3267387-3-heiko@sntech.de>
 <20260525065005.1056845-1-amadeus@jmu.edu.cn>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Hi,

Am Montag, 25. Mai 2026, 08:50:05 Mitteleurop=C3=A4ische Sommerzeit schrieb=
 Chukun Pan:
> > +&usb_host0_xhci {
> > +	extcon =3D <&usb2phy>;
> > +	maximum-speed =3D "high-speed";
> > +	phys =3D <&usb2phy_otg>;
> > +	phy-names =3D "usb2-phy";
>=20
> I received this warning for this otg port:
> [    0.163307] dwc3 fe500000.usb: Configuration mismatch. dr_mode forced =
to host

Interesting, because if I read the schematics correctly, this is the
controller labeled "usb2.0 otg0" .
It even has a vbus-detect line.

If I understand the schematics and product page correctly, this
actually is an outward facing type-c-port, making the device a
peripheral?

usb_host0_xhci -> port1 of FE1.1s_QFN (device1 connected to the hub)
uart0 -> ch340 -> port2 of FE1.1s_QFN (device2 connected to the hub)

=46E1.1s_QFN host dm+dp going to the type-c port of the board.

So if anything, that controller should probably have dr_mode=3Dperipheral
I think?


>=20
> > +	snps,dis_u2_susphy_quirk;
>=20
> This property is missing in the sige1 patch. Since this property
> is related to phy vbus detection, can we move it to rk3528.dtsi?

yeah, that sounds sensible ... looking at the other socs using that
quirk, it really seems to be a property of the controller.


Heiko