From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f50.google.com (mail-pj1-f50.google.com [209.85.216.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DE3D52D6E58 for ; Thu, 2 Jul 2026 01:49:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782956997; cv=none; b=toAhXsw4/P+YDQKyGX/7NhmYGagTEHaIx5KZw1o06CdgkyJFWFG9A6az+jvzpFoNWDzlUzNZc3OVc1IKeQx8xJYzclM/X61u9qX2DgKJ4W5opvmYv8WIe97Olt30Fkv2oga6fPFcTd8+wLn6oMWLta8dMkkVS+ut1VH+DG4WWrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782956997; c=relaxed/simple; bh=zp4TrgKrdo8LRxGqn42HDahOSlIYt9m0YOUdzj58Ubc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=dYD9uY4VkrlQjtVJhrfZmCbaPKeLUXIAWlESI47csPudTEvpzvysK3tX5c96pyQSe3A++WT6lznQ6ow3eOh6GFnEc2lLRLNMhMS1rGQS7ILQ3VWu3J6E75oby3Arx/hgs0QiNE60JHMQAH6Sf42rZipb7yp7et2yO2pVFVscnlA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=RD22Af2U; arc=none smtp.client-ip=209.85.216.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="RD22Af2U" Received: by mail-pj1-f50.google.com with SMTP id 98e67ed59e1d1-37ff798fe89so890461a91.1 for ; Wed, 01 Jul 2026 18:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1782956994; x=1783561794; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=J3jSeMZN0e9RiTr23Xi2KHpV4fFpgmT05xW1Ks8KJnA=; b=RD22Af2UfzAevGySeY16VS+w6lPAgrKeyraqy0sdUdBg6pQPyPLL5fscvt7mS6nFcE mfNuqSATD7N6kHWAyKKDh7YDAij7BAERVsxgaJykqjVYBSpjhxbrsxUGMwoSNmHeQGrr BlIMAEzHuynFs+dEka0tdxLvLzet3r1xiYdQREWoMAcGWEk9TdSrk8hKxJNsyFxKw+Aa /hc77cpSLZEC1MoaIQoAYZxVaCsOVc8DYdi4Mr1dddFd1w2yyXGHBDx+zAgf+RImk3RO OGqEHJfBnC55yUvAA3HdDJ4FMu9gaaYDgbtr53Sf6Q43KYBFfS+oXJ8ELgUhrf3WiHcv caNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782956994; x=1783561794; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=J3jSeMZN0e9RiTr23Xi2KHpV4fFpgmT05xW1Ks8KJnA=; b=iK5y1nY/KWdQJ0ap2IcxWlrEtXm6RIRp59G9/+f2JXsJ+8U3nOSyjU+aRQiwaA0XN3 jJibo4CABA4GI+HSZ2AuRXOwG3jtw51w6SKw1Yhk30cWYpamWVmi1bn5NwLW4iB+kIBj rdmuQRqqCEhHUM+vTKsMT20LU7LZX2k5Ww0Rnk9KtnEOZswenifq5tdm1m4ox2KiliUz FNODMYLoZWTGjl+XmD6HrkCz7wct17E7m9PbLh3TlBgpS9KA/6L3VSg6wZLjMujppyZk C9i95uLKWTB7PoiGXaHtBpyJW3CqICnE5DGGCMgtOClvUONG0/7pMQn7rvOmKhv5TzWL 5s/g== X-Forwarded-Encrypted: i=1; AHgh+RpAG5DIEqGMDICwqkNmnSAPXdRaOYrtFlEeCauc0MZMNwzuFxhzaARk5rYeglPWjjq759JcgrJwFbwUCuM=@vger.kernel.org X-Gm-Message-State: AOJu0YzpJDEbj4KuRcV70sU+lYwjjDcNwjuPKP/6CMc713s6PCn7wtBN OHTNO0/e1XWpeuhhY3xIQ2QhRcJDCYX2UmVkSGdP7UtddxVXIWVzSthY X-Gm-Gg: AfdE7clET/5KY2xdxq3nhH3ChF9zVmkY2LyNpJlH7wXlX6W8WWvqaaFRAd5Tmjgqtvc 3Lfw7g4kJ35p/Ez7wHgDWVP3/FpylCBma+zBpxVXiUbT+ieYVWra568+RX2iV4HTe3+YKakLzuq URUzvYZKDmj2/Gvrb94IPXkTq4QrfAK/KUxpOenCehqYf0jJe3T8GIQk/J8cLnholpWJ+elYcxV XpKV6JCyd16T5F857wWJqHK4JhxOZFzaOYabhdpPtfz7WBjFRYZsolE4fOtbvVASrWGrxYbpTzS TcL2qzsF2Bn30M+Wm+gwFXqQgPxeialsqsTQGvsUZ1q9QCz5B12htmylkZjTvp7l9w2hHXel50l YF5LRDysr9XoEoGTfv/642vCTAol7YCTbM9mCvMzvrXw7JUXJRNl9uNpfRn3iPdVELuLp6v9HEv 4ZumHxL7WzMVTeOoUEhYYJdMC3AritURh1TIHvchVQfM7nm9HeWkOFB324PIqRvsoQAg== X-Received: by 2002:a17:90b:3b52:b0:37f:9ce3:ca93 with SMTP id 98e67ed59e1d1-380aa1d7714mr4632989a91.28.1782956993855; Wed, 01 Jul 2026 18:49:53 -0700 (PDT) Received: from [192.168.0.100] (60-250-196-139.hinet-ip.hinet.net. [60.250.196.139]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-380e1631aadsm130307a91.4.2026.07.01.18.49.50 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 01 Jul 2026 18:49:53 -0700 (PDT) Message-ID: Date: Thu, 2 Jul 2026 09:49:46 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support To: Krzysztof Kozlowski Cc: Vinod Koul , Neil Armstrong , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Arnd Bergmann , Catalin Marinas , Jacky Huang , Shan-Chun Hung , Hui-Ping Chen , Joey Lu , linux-phy@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <20260625023958.569299-1-a0987203069@gmail.com> <20260625023958.569299-3-a0987203069@gmail.com> <20260625-sexy-black-tarantula-4031a6@quoll> <24de6a00-ba4e-455b-baa7-479d1cc2edf3@gmail.com> <0f5a408b-5c55-4cd2-831a-49316c9912c9@kernel.org> Content-Language: en-US From: Joey Lu In-Reply-To: <0f5a408b-5c55-4cd2-831a-49316c9912c9@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/30/2026 2:16 PM, Krzysztof Kozlowski wrote: > On 29/06/2026 12:40, Joey Lu wrote: >> On 6/25/2026 3:58 PM, Krzysztof Kozlowski wrote: >>> On Thu, Jun 25, 2026 at 10:39:56AM +0800, Joey Lu wrote: >>>> properties: >>>> compatible: >>>> enum: >>>> - nuvoton,ma35d1-usb2-phy >>>> >>>> + reg: >>>> + maxItems: 1 >>>> + >>>> "#phy-cells": >>>> - const: 0 >>>> + const: 1 >>>> + description: >>>> + The single cell selects the PHY port. 0 selects the OTG port (USB0, >>>> + shared with DWC2 gadget controller) and 1 selects the host-only port >>>> + (USB1). >>>> >>>> - clocks: >>>> - maxItems: 1 >>> This is odd, considering that parent does not have clocks. So explain me >>> this: >>> 1. USB PHY needed clocks. >>> 2. You extend USB PHY to cover second part. >>> 3. That extension for second part means that clocks are not needed. >>> Really, how? How is it possible in hardware? >> The hardware has two independent clock domains: >> >>   - The PHY analog block takes the 24 MHz HXT as its reference, wired >>     directly to the PHY's internal PLL, which derives the required >> operating >>     frequencies internally. This reference path is entirely outside the SoC >>     software clock tree; no software-gatable clock gate needs to be enabled >>     for the PHY to power up and lock its PLL. The only software control the >>     PHY driver exercises is toggling each PHY's Power-On Reset (POR) bit, >>     which resides in the SYS register block. The driver accesses this via >>     the parent regmap >> >>   - `HUSBH0_GATE` / `HUSBH1_GATE` / `USBD_GATE` are AHB/APB bus interface >>     clocks for the host and gadget (EHCI, OHCI, DWC2). They gate >>     the register-access path between the CPU and each controller, not >> the PHY >>     analog circuitry itself. >> >> The original single-port driver enabled `HUSBH0_GATE` as if it belonged >> to the >> PHY, but that gate is actually owned by EHCI0/OHCI0 and is already >> managed by >> those controller drivers through their own `clocks` DTS bindings. The PHY >> driver was redundantly enabling the same gate. >> >> When extending the driver to cover PHY1, the same pattern held: EHCI1/OHCI1 >> manage `HUSBH1_GATE` themselves. There is no clock that belongs >> exclusively to >> the PHY, so `clocks` will be dropped from the PHY binding entirely. > What driver has to do with it? > > You did not answer the question. How adding missing OTG to existing > device causes that hardware to lose a clock? How is it possible? > To answer the hardware question directly: adding OTG support does not cause the hardware to lose a clock. The hardware clock topology is identical in both the single-port and dual-port cases. The PHY analog block derives its reference from the 24 MHz HXT crystal through an always-on path via the PHY's internal PLL. No software-gated clock in the kernel clock tree sits in this path. The PHY's power-on and reset state is managed through USBPMISCR in the SYS register block, which the driver accesses via the nuvoton,sys regmap outside the clock tree. `HUSBH0_GATE` gates the AHB bus interface to the EHCI0/OHCI0 host controllers that share PHY0. This relationship is the same in both the single-port and dual-port configurations. >>>> + nuvoton,rcalcode: >>>> + $ref: /schemas/types.yaml#/definitions/uint32-array >>>> + minItems: 1 >>>> + maxItems: 2 >>> You should require two values. I understand that any PHY is optional, >>> thus you skip the entry, so how would you provide value for PHY1 only? >> `nuvoton,rcalcode` will be changed to require exactly two values >> (`minItems: 2, maxItems: 2`), one for PHY0 and one for PHY1 respectively. >> The property will remain optional overall; when absent, each port >> retains its >> power-on default value loaded at hardware initialisation. When present, both >> entries must be supplied. > So are you going to implement it or not? > Yes, I will implement this change in the next version of the patchset. >>>> + items: >>>> + minimum: 0 >>>> + maximum: 15 >>>> + description: >>>> + Resistor calibration trim codes for PHY0 and PHY1 respectively. >>>> + Each 4-bit value is written to the RCALCODE field in USBPMISCR and >>>> + adjusts the PHY's internal termination resistance. Both entries are >>>> + optional; when absent the hardware reset default is used. >>>> >>>> - nuvoton,sys: >>>> - $ref: /schemas/types.yaml#/definitions/phandle >>>> + nuvoton,oc-active-high: >>>> + type: boolean >>>> description: >>>> - phandle to syscon for checking the PHY clock status. >>>> + When present, the over-current detect input from the VBUS power switch >>>> + is treated as active-high. The default (property absent) is active-low. >>>> + This setting is shared by both USB host ports. >>>> >>>> required: >>>> - compatible >>>> + - reg >>> That's ABI break which was not explained in the commit msg - neither >>> specifying impact nor actually providing reasons why you break ABI. >>> >>> And honestly, you have no resources here except the address, so now it >>> is clear that this should be folded into parent. See DTS101 talk slides. >> The commit message will be updated to explicitly acknowledge the ABI break: >> existing DTS files that contain a standalone `usb-phy` node without a `reg` >> property will fail dt-schema validation after this change. The impact is >> limited to the MA35D1 SoC; no upstream DTS for this SoC existed before this >> patch series, so no in-tree board files are broken. The break is intentional > But all of out of tree users are broken. On reflection, the approach is being revised to eliminate the ABI break entirely. The next revision will keep the existing `nuvoton,ma35d1-usb2-phy` binding intact with all its current required properties (`compatible`, `clocks`, `nuvoton,sys`, `#phy-cells`). New OTG and dual-port capability will be expressed as strictly optional backward-compatible additions: - `#phy-cells` updated from `const: 0` to `enum: [0, 1]`. Existing DTS   with `#phy-cells = <0>` continues to validate and behave as before.   New DTS opting into dual-port uses `#phy-cells = <1>`. - `nuvoton,rcalcode`: optional, exactly two values when present. - `nuvoton,oc-active-high`: optional boolean. > > Best regards, > Krzysztof