Pull phy updates from Vinod Koul:
"New Support:
- Qualcomm Eliza QMP UFS PHY
- Canaan K230 USB 2.0 PHY driver
- Mediatek mt8167 dsi-phy
- Eswin EIC7700 SATA PHY driver
Updates:
- Sorted subsytem Makefile/Kconfig and some kernel-doc udpates"
* tag 'phy-for-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy:
dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Eliza QMP UFS PHY
phy: qcom: m31-eusb2: clear PLL_EN during init
phy: eswin: Create eswin directory and add EIC7700 SATA PHY driver
dt-bindings: phy: eswin: Document the EIC7700 SoC SATA PHY
phy: apple: apple: Use local variable for ioremap return value
phy: qcom: qmp-usbc: Simplify check for non-NULL pointer
phy: marvell: mmp3-hsic: Avoid re-casting __iomem
phy: apple: atc: Make atcphy_dwc3_reset_ops variable static
dt-bindings: phy: mediatek,dsi-phy: Add support for mt8167
phy: usb: Add driver for Canaan K230 USB 2.0 PHY
dt-bindings: phy: Add Canaan K230 USB PHY
phy: phy-mtk-tphy: Update names and format of kernel-doc comments
phy: Sort the subsystem Kconfig
phy: Sort the subsystem Makefile
phy: move spacemit pcie driver to its subfolder
Geert reports that enabling CONFIG_KUNIT_ALL_TESTS shouldn't enable
features that aren't enabled without it. That isn't what "*all* tests"
means, but as the prompt puts it, "All KUnit tests with satisfied
dependencies".
The impact is that enabling CONFIG_KUNIT_ALL_TESTS brings features which
cannot be disabled as built-in into the kernel.
Keep the pattern where consumer drivers have to "select PHY_COMMON_PROPS",
but if KUNIT_ALL_TESTS is enabled, also make PHY_COMMON_PROPS user
selectable, so it can be turned off.
Modify PHY_COMMON_PROPS_TEST to depend on PHY_COMMON_PROPS rather than
select it.
Fixes: e7556b59ba ("phy: add phy_get_rx_polarity() and phy_get_tx_polarity()")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Closes: https://lore.kernel.org/linux-phy/CAMuHMdUBaoYKNj52gn8DQeZFZ42Cvm6xT6fvo0-_twNv1k3Jhg@mail.gmail.com/
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20260226153315.3530378-1-vladimir.oltean@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
With CONFIG_TYPEC=m, this driver cannot be built-in:
arm-linux-gnueabi/bin/arm-linux-gnueabi-ld: drivers/phy/phy-google-usb.o: in function `google_usb_phy_remove':
phy-google-usb.c:(.text+0x24): undefined reference to `typec_switch_unregister'
Add CONFIG_TYPEC as a hard dependency here to force a clean build.
In theory, compile-testing with CONFIG_TYPEC=n would also work, but
that seems pointless.
Fixes: cbce66669c ("phy: Add Google Tensor SoC USB PHY driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patch.msgid.link/20260202095655.1289973-1-arnd@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
phy common properties
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
Introduce "rx-polarity" and "tx-polarity" device tree properties with
Kunit tests
Add helpers in the generic PHY folder which can be used using 'select
PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
enable GENERIC_PHY.
These helpers need to deal with the slight messiness of the fact that
the polarity properties are arrays per protocol, and with the fact that
there is no default value mandated by the standard properties, all
default values depend on driver and protocol (PHY_POL_NORMAL may be a
good default for SGMII, whereas PHY_POL_AUTO may be a good default for
PCIe).
Push the supported mask of polarities to these helpers, to simplify
drivers such that they don't need to validate what's in the device tree
(or other firmware description).
Add a KUnit test suite to make sure that the API produces the expected
results. The fact that we use fwnode structures means we can validate
with software nodes, and as opposed to the device_property API, we can
bypass the need to have a device structure.
Co-developed-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://patch.msgid.link/20260111093940.975359-6-vladimir.oltean@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The SpacemiT K1 SoC includes three USB ports:
- One USB2.0 OTG port
- One USB2.0 host-only port
- One USB3.0 port with an integrated USB2.0 DRD interface
Each of these ports is connected to a USB2.0 PHY responsible for USB2
transmission.
This commit adds support for the SpacemiT K1 USB2.0 PHY, which is
compliant with the USB 2.0 specification and supports both 8-bit 60MHz
and 16-bit 30MHz parallel interfaces.
Signed-off-by: Ze Huang <huang.ze@linux.dev>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Junzhong Pan <panjunzhong@linux.spacemit.com>
Link: https://patch.msgid.link/20251017-k1-usb2phy-v6-2-7cf9ea2477a1@linux.dev
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The Apple Type-C PHY (ATCPHY) is a PHY for USB 2.0, USB 3.x,
USB4/Thunderbolt, and DisplayPort connectivity found in Apple Silicon SoCs.
The PHY handles muxing between these different protocols and also provides
the reset controller for the attached dwc3 USB controller.
There is no documentation available for this PHY and the entire sequence
of MMIO pokes has been figured out by tracing all MMIO access of Apple's
driver under a thin hypervisor and correlating the register reads/writes
to their kernel's debug output to find their names. Deviations from this
sequence generally results in the port not working or, especially when
the mode is switched to USB4 or Thunderbolt, to some watchdog resetting
the entire SoC.
This initial commit already introduces support for Display Port and
USB4/Thunderbolt but the drivers for these are not ready. We cannot
control the alternate mode negotiation and are stuck with whatever Apple's
firmware decides such that any DisplayPort or USB4/Thunderbolt device will
result in a correctly setup PHY but not be usable until the other drivers
are upstreamed as well.
Co-developed-by: Janne Grunau <j@jannau.net>
Signed-off-by: Janne Grunau <j@jannau.net>
Co-developed-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> # for reset controller
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Link: https://patch.msgid.link/20251214-b4-atcphy-v3-3-ba82b20e9459@kernel.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Introduce a driver that supports three PHYs found on the SpacemiT
K1 SoC. The first PHY is a combo PHY that can be configured for
use for either USB 3 or PCIe. The other two PHYs support PCIe
only.
All three PHYs must be programmed with an 8 bit receiver termination
value, which must be determined dynamically. Only the combo PHY is
able to determine this value. The combo PHY performs a special
calibration step at probe time to discover this, and that value is
used to program each PHY that operates in PCIe mode. The combo
PHY must therefore be probed before either of the PCIe-only PHYs
will be used.
Each PHY has an internal PLL driven from an external oscillator.
This PLL started when the PHY is first initialized, and stays
on thereafter.
During normal operation, the USB or PCIe driver using the PHY must
ensure (other) clocks and resets are set up properly.
However PCIe mode clocks are enabled and resets are de-asserted
temporarily by this driver to perform the calibration step on the
combo PHY.
Tested-by: Junzhong Pan <panjunzhong@linux.spacemit.com>
Signed-off-by: Alex Elder <elder@riscstar.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/all/ba532f8d-a452-40e5-af46-b58b89f70a92@linaro.org/ [1]
Tested-by: Yixun Lan <dlan@gentoo.org>
Link: https://patch.msgid.link/20251218151235.454997-4-elder@riscstar.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Realtek DHC (digital home center) RTD SoCs support DWC3 XHCI USB
controller. Added the driver to drive the USB 2.0 PHY transceivers.
Note: New driver,remove the port status notification on legacy USB PHY.
Use the generic PHY to notify the usb device connect and disconnect.
To avoid using these PHYs would require describing the very same
PHY using both the generic "phy" property and the deprecated "usb-phy"
property.
Signed-off-by: Stanley Chang <stanley_chang@realtek.com>
Link: https://lore.kernel.org/r/20231213031203.4911-2-stanley_chang@realtek.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 134e6d25f6.
The recently added Realtek PHY drivers depend on the new port status
notification mechanism which was built on the deprecated USB PHY
implementation and devicetree binding.
Specifically, using these PHYs would require describing the very same
PHY using both the generic "phy" property and the deprecated "usb-phy"
property which is clearly wrong.
We should not be building new functionality on top of the legacy USB PHY
implementation even if it is currently stuck in some kind of
transitional limbo.
Revert the new Realtek PHY drivers for now so that the port status
notification interface can be reverted and replaced.
Fixes: 134e6d25f6 ("phy: realtek: usb: Add driver for the Realtek SoC USB 2.0 PHY")
Cc: stable@vger.kernel.org # 6.6
Cc: Stanley Chang <stanley_chang@realtek.com>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20231106110654.31090-3-johan+linaro@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds
Yulin LuandVinod Koul
Jiayu DuandVinod Koul
Vladimir OlteanandVinod Koul
Arnd BergmannandVinod Koul
Roy LuoandVinod Koul
Ze HuangandVinod Koul
Alex ElderandVinod Koul
Sven PeterandVinod Koul
Inochi AmaotoandVinod Koul
Ivaylo IvanovandVinod Koul
Dmitry BaryshkovandVinod Koul
Hui-Ping ChenandVinod Koul
Lorenzo BianconiandVinod Koul
Stanley ChangandGreg Kroah-Hartman
Johan HovoldandGreg Kroah-Hartman
Sakari AilusandVinod Koul