From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) (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 69B031CAA7D for ; Fri, 20 Mar 2026 09:51:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774000319; cv=none; b=WZfWhYmcrsrOrtRMcpD+L/4jjjF6djA4wEikbaq+OcgQ/gHYMP1O28rnHuscWWvI2kz60aIVi3BgH8hHxkhg1jkLderMU2r3sQLfXZi5picIo0FP4q8b+su0aKnEJAcQN+O/YPgRJIm/zmzeOz6xOopzid75njUMY0byWHkwku8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774000319; c=relaxed/simple; bh=tBusV8I1xKXUrGEu9BjwwnL+Ldksq8Sarqj0TThaMqk=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=ewlSNeIT+9LZyOTFXKohYrX8o4OSybIJCMFaoZ+1LnANxy/JOy02xeErpCcILosFa5qeJKEkP+bWlzY3q5R9KSCCFyTnoxwug9W5J05kliV8A9PUrQDUXT8eMUBzlSWpbktoE1iEG52y6sSJ3qZueuhcAq8V+4oSR8fO1UjqBfg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ux7sY9yw; arc=none smtp.client-ip=91.218.175.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ux7sY9yw" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774000306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SB0KpBn5A09Moyx+zjJpQCHUxGkKOb8xwpecR+YoJT4=; b=ux7sY9ywu+wS45NR3bq7PywwA4yYp30v4K9OZ3Eua2QuPZ2luZmhd+98gprsJzH8xMB6Nf bXJjA8h8o5i/Y29DqWrnoMESdqi7RX+zRDB2jAHBO9x1sk9Lwda/m2n2LHrDjmm2dXUlqt i6aWySuiFz498jMm/x8VCqt1OVKoXpU= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 20 Mar 2026 17:50:50 +0800 Message-Id: Cc: , , , , , , Subject: Re: [PATCH 1/1] usb: dwc3: dwc3-generic-plat: Add optional VBUS regulator support X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "Ze Huang" To: "Chukun Pan" , References: <20260320081826.1331721-1-amadeus@jmu.edu.cn> In-Reply-To: <20260320081826.1331721-1-amadeus@jmu.edu.cn> X-Migadu-Flow: FLOW_OUT Hi Chukun On Fri Mar 20, 2026 at 4:18 PM CST, Chukun Pan wrote: > Hi, > >> I don't think it's a good idea to tie this optional VBUS regulator >> implementation to the SpacemiT K1 platform. >> >> While the K1 SoC does have a DRD controller, current boards in the wild >> (like Jupiter[1], OrangePi RV2[2], and Banana Pi F3[3]) all route this >> port to an onboard hub[4][5]. IMHO, managing the downstream VBUS regulat= or >> via the onboard_usb_dev driver is the correct approach for us. > > I'm sorry, but I don't quite understand why it's necessary to use > onboard_usb_dev driver instead. > I think it's better to align the driver with the actual hardware. I'm not opposed to managing any regulators in usb host/device drivers. But if we do have an onboard hub, and regulator belongs to the downstream ports of the hub, then it's hub's job, right? > > The DRD controller is connected to the onboard USB hub, so it can > only operate in host mode. If all downstream ports of the USB hub > use the same VBUS supply, then what's the problem with using this? It does work. Many boards leave gpio controlled regulators always on, that's what we want to solve. If we have to choose the parent of these regulators, why not put them in the correct hierarchy? > >> K1 platform currently does not need this feature here. >> >> Considering the role switch, I think it would be better to hold off on >> this until there is an actual board/user that relies on it. > > There is a board without onboard USB hub, If such a board really need the regulator, IMO, your patch is the way to go= . > > such as the OrangePi R2S. > So this is possible for boards that don't have onboard USB hub? OrangePi haven't released the schematic yet. That's what I could find [1], which seems similar to RV2. &usb3hub { vbus-gpios =3D <&gpio 123 0>; /* gpio_123 for usb3 hub pwr and output = vbus */ status =3D "okay"; }; [1] https://github.com/orangepi-xunlong/linux-orangepi/blob/orange-pi-6.6-k= y/arch/riscv/boot/dts/ky/x1_orangepi-r2s.dts#L762 > > Thanks, > Chukun Thanks, Ze