summaryrefslogtreecommitdiff
path: root/drivers/phy
AgeCommit message (Collapse)AuthorFilesLines
9 daysphy: rockchip-pcie: Enable all four lanes if requiredValmantas Paliksa1-6/+6
[ Upstream commit c3fe7071e196e25789ecf90dbc9e8491a98884d7 ] Current code enables only Lane 0 because pwr_cnt will be incremented on first call to the function. Let's reorder the enablement code to enable all 4 lanes through GRF. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Valmantas Paliksa <walmis@gmail.com> Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/16b610aab34e069fd31d9f57260c10df2a968f80.1751322015.git.geraldogabriel@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysphy: rockchip-pcie: Properly disable TEST_WRITE strobe signalGeraldo Nascimento1-2/+1
[ Upstream commit 25facbabc3fc33c794ad09d73f73268c0f8cbc7d ] pcie_conf is used to touch TEST_WRITE strobe signal. This signal should be enabled, a little time waited, and then disabled. Current code clearly was copy-pasted and never disables the strobe signal. Adjust the define. While at it, remove PHY_CFG_RD_MASK which has been unused since 64cdc0360811 ("phy: rockchip-pcie: remove unused phy_rd_cfg function"). Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Geraldo Nascimento <geraldogabriel@gmail.com> Link: https://lore.kernel.org/r/d514d5d5627680caafa8b7548cbdfee4307f5440.1751322015.git.geraldogabriel@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
14 daysphy: qualcomm: phy-qcom-eusb2-repeater: Don't zero-out registersLuca Weiss1-55/+32
[ Upstream commit 31bc94de76026c527f82c238f414539a14f0f3e6 ] Zeroing out registers does not happen in the downstream kernel, and will "tune" the repeater in surely unexpected ways since most registers don't have a reset value of 0x0. Stop doing that and instead just set the registers that are in the init sequence (though long term I don't think there's actually PMIC-specific init sequences, there's board specific tuning, but that's a story for another day). Fixes: 99a517a582fc ("phy: qualcomm: phy-qcom-eusb2-repeater: Zero out untouched tuning regs") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20250617-eusb2-repeater-tuning-v2-2-ed6c484f18ee@fairphone.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-24phy: use per-PHY lockdep keysDmitry Baryshkov1-1/+4
[ Upstream commit cf0233491b3a15933234a26efd9ecbc1c0764674 ] If the PHY driver uses another PHY internally (e.g. in case of eUSB2, repeaters are represented as PHYs), then it would trigger the following lockdep splat because all PHYs use a single static lockdep key and thus lockdep can not identify whether there is a dependency or not and reports a false positive. Make PHY subsystem use dynamic lockdep keys, assigning each driver a separate key. This way lockdep can correctly identify dependency graph between mutexes. ============================================ WARNING: possible recursive locking detected 6.15.0-rc7-next-20250522-12896-g3932f283970c #3455 Not tainted -------------------------------------------- kworker/u51:0/78 is trying to acquire lock: ffff0008116554f0 (&phy->mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c but task is already holding lock: ffff000813c10cf0 (&phy->mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&phy->mutex); lock(&phy->mutex); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by kworker/u51:0/78: #0: ffff000800010948 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work+0x18c/0x5ec #1: ffff80008036bdb0 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work+0x1b4/0x5ec #2: ffff0008094ac8f8 (&dev->mutex){....}-{4:4}, at: __device_attach+0x38/0x188 #3: ffff000813c10cf0 (&phy->mutex){+.+.}-{4:4}, at: phy_init+0x4c/0x12c stack backtrace: CPU: 0 UID: 0 PID: 78 Comm: kworker/u51:0 Not tainted 6.15.0-rc7-next-20250522-12896-g3932f283970c #3455 PREEMPT Hardware name: Qualcomm CRD, BIOS 6.0.240904.BOOT.MXF.2.4-00528.1-HAMOA-1 09/ 4/2024 Workqueue: events_unbound deferred_probe_work_func Call trace: show_stack+0x18/0x24 (C) dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x24 print_deadlock_bug+0x258/0x348 __lock_acquire+0x10fc/0x1f84 lock_acquire+0x1c8/0x338 __mutex_lock+0xb8/0x59c mutex_lock_nested+0x24/0x30 phy_init+0x4c/0x12c snps_eusb2_hsphy_init+0x54/0x1a0 phy_init+0xe0/0x12c dwc3_core_init+0x450/0x10b4 dwc3_core_probe+0xce4/0x15fc dwc3_probe+0x64/0xb0 platform_probe+0x68/0xc4 really_probe+0xbc/0x298 __driver_probe_device+0x78/0x12c driver_probe_device+0x3c/0x160 __device_attach_driver+0xb8/0x138 bus_for_each_drv+0x84/0xe0 __device_attach+0x9c/0x188 device_initial_probe+0x14/0x20 bus_probe_device+0xac/0xb0 deferred_probe_work_func+0x8c/0xc8 process_one_work+0x208/0x5ec worker_thread+0x1c0/0x368 kthread+0x14c/0x20c ret_from_fork+0x10/0x20 Fixes: 3584f6392f09 ("phy: qcom: phy-qcom-snps-eusb2: Add support for eUSB2 repeater") Fixes: e2463559ff1d ("phy: amlogic: Add Amlogic AXG PCIE PHY Driver") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reported-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/lkml/ZnpoAVGJMG4Zu-Jw@hovoldconsulting.com/ Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250605-phy-subinit-v3-1-1e1e849e10cd@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-07-24phy: tegra: xusb: Disable periodic tracking on Tegra234Haotien Hsu1-1/+1
commit 7be54870e9bf5ed0b4fe2a23b41a630527882de5 upstream. Periodic calibration updates (~10µs) may overlap with transfers when PCIe NVMe SSD, LPDDR, and USB2 devices operate simultaneously, causing crosstalk on Tegra234 devices. Hence disable periodic calibration updates and make this a one-time calibration. Fixes: d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support") Cc: stable@vger.kernel.org Signed-off-by: Haotien Hsu <haotienh@nvidia.com> Signed-off-by: Wayne Chang <waynec@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20250519090929.3132456-3-waynec@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-24phy: tegra: xusb: Decouple CYA_TRK_CODE_UPDATE_ON_IDLE from trk_hw_modeWayne Chang2-6/+9
commit 24c63c590adca310e0df95c77cf7aa5552bc3fc5 upstream. The logic that drives the pad calibration values resides in the controller reset domain and so the calibration values are only being captured when the controller is out of reset. However, by clearing the CYA_TRK_CODE_UPDATE_ON_IDLE bit, the calibration values can be set while the controller is in reset. The CYA_TRK_CODE_UPDATE_ON_IDLE bit was previously cleared based on the trk_hw_mode flag, but this dependency is not necessary. Instead, introduce a new flag, trk_update_on_idle, to independently control this bit. Fixes: d8163a32ca95 ("phy: tegra: xusb: Add Tegra234 support") Cc: stable@vger.kernel.org Signed-off-by: Wayne Chang <waynec@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20250519090929.3132456-2-waynec@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-07-24phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY modeWayne Chang1-22/+37
commit cefc1caee9dd06c69e2d807edc5949b329f52b22 upstream. When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code assumed that the regulator should be disabled. However, if the regulator is marked as always-on, regulator_is_enabled() continues to return true, leading to an incorrect attempt to disable a regulator which is not enabled. This can result in warnings such as: [ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004 _regulator_disable+0xe4/0x1a0 [ 250.155652] unbalanced disables for VIN_SYS_5V0 To fix this, we move the regulator control logic into tegra186_xusb_padctl_id_override() function since it's directly related to the ID override state. The regulator is now only disabled when the role transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID register. This ensures that regulator enable/disable operations are properly balanced and only occur when actually transitioning to/from host mode. Fixes: 49d46e3c7e59 ("phy: tegra: xusb: Add set_mode support for UTMI phy on Tegra186") Cc: stable@vger.kernel.org Signed-off-by: Wayne Chang <waynec@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20250502092606.2275682-1-waynec@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-27phy: fsl-imx8mq-usb: fix phy_tx_vboost_level_from_property()Xu Yang1-5/+5
commit b15ee09ddb987a122e74fb0fdf1bd6e864959fd3 upstream. The description of TX_VBOOST_LVL is wrong in register PHY_CTRL3 bit[31:29]. The updated description as below: 011: Corresponds to a launch amplitude of 0.844 V. 100: Corresponds to a launch amplitude of 1.008 V. 101: Corresponds to a launch amplitude of 1.156 V. This will fix the parsing function phy_tx_vboost_level_from_property() to return correct value. Fixes: 63c85ad0cd81 ("phy: fsl-imx8mp-usb: add support for phy tuning") Cc: stable@vger.kernel.org Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Xu Yang <xu.yang_2@nxp.com> Link: https://lore.kernel.org/r/20250430094502.2723983-3-xu.yang_2@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19phy: qcom-qusb2: reuse the IPQ6018 settings for IPQ5424Kathiravan Thirumoorthy1-0/+3
[ Upstream commit 25c36b54eafc98b3ef004e2037cea1328d9b8bc5 ] With the settings used in the commit 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424"), compliance test cases especially eye-diagram (Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018 settings for IPQ5424 as mentioned in the Hardware Design Document which helps to meet all the complaince requirement test cases. Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424") Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-2-3a8f86211b59@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19Revert "phy: qcom-qusb2: add QUSB2 support for IPQ5424"Kathiravan Thirumoorthy1-28/+0
[ Upstream commit 8a040e13afd94a1f91acaf8e0505769d4f7f5af4 ] With the current settings, compliance tests especially eye diagram (Host High-speed Signal Quality) tests are failing. Reuse the IPQ6018 settings to overcome this issue, as mentioned in the Hardware Design Document. So revert the change which introduced the new settings and reuse the IPQ6018 settings in the subsequent patch. Fixes: 9c56a1de296e ("phy: qcom-qusb2: add QUSB2 support for IPQ5424") Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250415-revert_hs_phy_settings-v3-1-3a8f86211b59@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19phy: qcom-qmp-usb: Fix an NULL vs IS_ERR() bugChenyuan Yang1-1/+5
[ Upstream commit d14402a38c2d868cacb1facaf9be908ca6558e59 ] The qmp_usb_iomap() helper function currently returns the raw result of devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return a NULL pointer and the caller only checks error pointers with IS_ERR(), NULL could bypass the check and lead to an invalid dereference. Fix the issue by checking if devm_ioremap() returns NULL. When it does, qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM), ensuring safe and consistent error handling. Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com> Fixes: a5d6b1ac56cb ("phy: qcom-qmp-usb: fix memleak on probe deferral") CC: Johan Hovold <johan@kernel.org> CC: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250414125050.2118619-1-chenyuan0y@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19phy: rockchip: samsung-hdptx: Do no set rk_hdptx_phy->rate in case of errorsCristian Ciocaltea1-4/+6
[ Upstream commit 1f4d382769e3b38dfc498c806811dae856e40f31 ] Ensure rk_hdptx_ropll_tmds_cmn_config() updates hdptx->rate only after all the other operations have been successful. Fixes: c4b09c562086 ("phy: phy-rockchip-samsung-hdptx: Add clock provider support") Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-4-8cb1678e7663@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19phy: rockchip: samsung-hdptx: Fix clock ratio setupCristian Ciocaltea1-1/+2
[ Upstream commit 0422253ac1919fea8292381c85f11a9decff1bb1 ] The switch from 1/10 to 1/40 clock ratio must happen when exceeding the 340 MHz rate limit of HDMI 1.4, i.e. when entering the HDMI 2.0 domain, and not before. Therefore, use the correct comparison operator '>' instead of '>=' when checking the max rate. While at it, introduce a define for this rate limit constant. Fixes: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Link: https://lore.kernel.org/r/20250318-phy-sam-hdptx-bpc-v6-3-8cb1678e7663@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-14phy: Fix error handling in tegra_xusb_port_initMa Ke1-4/+4
If device_add() fails, do not use device_unregister() for error handling. device_unregister() consists two functions: device_del() and put_device(). device_unregister() should only be called after device_add() succeeded because device_del() undoes what device_add() does if successful. Change device_unregister() to put_device() call before returning from the function. As comment of device_add() says, 'if device_add() succeeds, you should call device_del() when you want to get rid of it. If device_add() has not succeeded, use only put_device() to drop the reference count'. Found by code review. Cc: stable@vger.kernel.org Fixes: 53d2a715c240 ("phy: Add Tegra XUSB pad controller support") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20250303072739.3874987-1-make24@iscas.ac.cn Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: renesas: rcar-gen3-usb2: Set timing registers only onceClaudiu Beznea1-2/+5
phy-rcar-gen3-usb2 driver exports 4 PHYs. The timing registers are common to all PHYs. There is no need to set them every time a PHY is initialized. Set timing register only when the 1st PHY is initialized. Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250507125032.565017-6-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: renesas: rcar-gen3-usb2: Assert PLL reset on PHY power offClaudiu Beznea1-1/+9
Assert PLL reset on PHY power off. This saves power. Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250507125032.565017-5-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: renesas: rcar-gen3-usb2: Lock around hardware registers and driver dataClaudiu Beznea1-23/+26
The phy-rcar-gen3-usb2 driver exposes four individual PHYs that are requested and configured by PHY users. The struct phy_ops APIs access the same set of registers to configure all PHYs. Additionally, PHY settings can be modified through sysfs or an IRQ handler. While some struct phy_ops APIs are protected by a driver-wide mutex, others rely on individual PHY-specific mutexes. This approach can lead to various issues, including: 1/ the IRQ handler may interrupt PHY settings in progress, racing with hardware configuration protected by a mutex lock 2/ due to msleep(20) in rcar_gen3_init_otg(), while a configuration thread suspends to wait for the delay, another thread may try to configure another PHY (with phy_init() + phy_power_on()); re-running the phy_init() goes to the exact same configuration code, re-running the same hardware configuration on the same set of registers (and bits) which might impact the result of the msleep for the 1st configuring thread 3/ sysfs can configure the hardware (though role_store()) and it can still race with the phy_init()/phy_power_on() APIs calling into the drivers struct phy_ops To address these issues, add a spinlock to protect hardware register access and driver private data structures (e.g., calls to rcar_gen3_is_any_rphy_initialized()). Checking driver-specific data remains necessary as all PHY instances share common settings. With this change, the existing mutex protection is removed and the cleanup.h helpers are used. While at it, to keep the code simpler, do not skip regulator_enable()/regulator_disable() APIs in rcar_gen3_phy_usb2_power_on()/rcar_gen3_phy_usb2_power_off() as the regulators enable/disable operations are reference counted anyway. Fixes: f3b5a8d9b50d ("phy: rcar-gen3-usb2: Add R-Car Gen3 USB2 PHY driver") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250507125032.565017-4-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: renesas: rcar-gen3-usb2: Move IRQ request in probeClaudiu Beznea1-20/+26
Commit 08b0ad375ca6 ("phy: renesas: rcar-gen3-usb2: move IRQ registration to init") moved the IRQ request operation from probe to struct phy_ops::phy_init API to avoid triggering interrupts (which lead to register accesses) while the PHY clocks (enabled through runtime PM APIs) are not active. If this happens, it results in a synchronous abort. One way to reproduce this issue is by enabling CONFIG_DEBUG_SHIRQ, which calls free_irq() on driver removal. Move the IRQ request and free operations back to probe, and take the runtime PM state into account in IRQ handler. This commit is preparatory for the subsequent fixes in this series. Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250507125032.565017-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: renesas: rcar-gen3-usb2: Fix role detection on unbind/bindClaudiu Beznea1-19/+14
It has been observed on the Renesas RZ/G3S SoC that unbinding and binding the PHY driver leads to role autodetection failures. This issue occurs when PHY 3 is the first initialized PHY. PHY 3 does not have an interrupt associated with the USB2_INT_ENABLE register (as rcar_gen3_int_enable[3] = 0). As a result, rcar_gen3_init_otg() is called to initialize OTG without enabling PHY interrupts. To resolve this, add rcar_gen3_is_any_otg_rphy_initialized() and call it in role_store(), role_show(), and rcar_gen3_init_otg(). At the same time, rcar_gen3_init_otg() is only called when initialization for a PHY with interrupt bits is in progress. As a result, the struct rcar_gen3_phy::otg_initialized is no longer needed. Fixes: 549b6b55b005 ("phy: renesas: rcar-gen3-usb2: enable/disable independent irqs") Cc: stable@vger.kernel.org Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://lore.kernel.org/r/20250507125032.565017-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: tegra: xusb: remove a stray unlockDan Carpenter1-2/+0
We used to take a lock in tegra186_utmi_bias_pad_power_on() but now we have moved the lock into the caller. Unfortunately, when we moved the lock this unlock was left behind and it results in a double unlock. Delete it now. Fixes: b47158fb4295 ("phy: tegra: xusb: Use a bitmask for UTMI pad power state tracking") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/aAjmR6To4EnvRl4G@stanley.mountain Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: phy-rockchip-samsung-hdptx: Fix PHY PLL output 50.25MHz errorAlgea Cao1-0/+2
When using HDMI PLL frequency division coefficient at 50.25MHz that is calculated by rk_hdptx_phy_clk_pll_calc(), it fails to get PHY LANE lock. Although the calculated values are within the allowable range of PHY PLL configuration. In order to fix the PHY LANE lock error and provide the expected 50.25MHz output, manually compute the required PHY PLL frequency division coefficient and add it to ropll_tmds_cfg configuration table. Signed-off-by: Algea Cao <algea.cao@rock-chips.com> Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Acked-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250427095124.3354439-1-algea.cao@rock-chips.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-05-14phy: starfive: jh7110-usb: Fix USB 2.0 host occasional detection failureHal Feng1-0/+7
JH7110 USB 2.0 host fails to detect USB 2.0 devices occasionally. With a long time of debugging and testing, we found that setting Rx clock gating control signal to normal power consumption mode can solve this problem. Signed-off-by: Hal Feng <hal.feng@starfivetech.com> Link: https://lore.kernel.org/r/20250422101244.51686-1-hal.feng@starfivetech.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-04-11phy: rockchip-samsung-dcphy: Add missing assignmentDan Carpenter1-1/+1
The "ret = " was accidentally dropped so the error handling doesn't work. Fixes: b2a1a2ae7818 ("phy: rockchip: Add Samsung MIPI D-/C-PHY driver") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/e64265a4-9543-4728-a49f-ea910fccef7c@stanley.mountain Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-04-11phy: can-transceiver: Re-instate "mux-states" property presence checkGeert Uytterhoeven1-7/+15
On the Renesas Gray Hawk Single development board: can-transceiver-phy can-phy0: /can-phy0: failed to get mux-state (0) "mux-states" is an optional property for CAN transceivers. However, mux_get() always prints an error message in case of an error, including when the property is not present, confusing the user. Fix this by re-instating the property presence check (this time using the proper API) in a wrapper around devm_mux_state_get(). When the multiplexer subsystem gains support for optional muxes, the wrapper can just be removed. In addition, propagate all real errors upstream, instead of ignoring them. Fixes: d02dfd4ceb2e9f34 ("phy: can-transceiver: Drop unnecessary "mux-states" property presence check") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/r/3d7e0d723908284e8cf06ad1f7950c03173178f3.1742483710.git.geert+renesas@glider.be Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-04-11phy: qcom-qmp-ufs: check for mode type for phy settingNitin Rawat1-1/+2
Generally all target supports Rate B but for very few like SM8550, two sets of UFS PHY settings are provided, one set is to support HS-G5 Rate A and another set is to support HS-G4 and lower gears with Rate B. Commit b02cc9a17679("phy: qcom-qmp-ufs: Add PHY Configuration support for sm8750") apply Rate B setting for SM8550 gear 5 without checking for mode value (Rate A or Rate B) from Controller driver which caused issue as SM8550 support rate A for Gear 5. Fix this by adding mode check before applying Rat B phy setting. Fixes: b02cc9a17679 ("phy: qcom-qmp-ufs: Add PHY Configuration support for sm8750") Reported-by: Neil Armstrong <neil.armstrong@linaro.org> Closes: https://lore.kernel.org/all/430ed11c-0490-45be-897b-27cad9682371@quicinc.com/ Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com> Link: https://lore.kernel.org/r/20250407121008.22230-1-quic_nitirawa@quicinc.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-04-11phy: tegra: xusb: Use a bitmask for UTMI pad power state trackingWayne Chang1-17/+27
The current implementation uses bias_pad_enable as a reference count to manage the shared bias pad for all UTMI PHYs. However, during system suspension with connected USB devices, multiple power-down requests for the UTMI pad result in a mismatch in the reference count, which in turn produces warnings such as: [ 237.762967] WARNING: CPU: 10 PID: 1618 at tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763103] Call trace: [ 237.763104] tegra186_utmi_pad_power_down+0x160/0x170 [ 237.763107] tegra186_utmi_phy_power_off+0x10/0x30 [ 237.763110] phy_power_off+0x48/0x100 [ 237.763113] tegra_xusb_enter_elpg+0x204/0x500 [ 237.763119] tegra_xusb_suspend+0x48/0x140 [ 237.763122] platform_pm_suspend+0x2c/0xb0 [ 237.763125] dpm_run_callback.isra.0+0x20/0xa0 [ 237.763127] __device_suspend+0x118/0x330 [ 237.763129] dpm_suspend+0x10c/0x1f0 [ 237.763130] dpm_suspend_start+0x88/0xb0 [ 237.763132] suspend_devices_and_enter+0x120/0x500 [ 237.763135] pm_suspend+0x1ec/0x270 The root cause was traced back to the dynamic power-down changes introduced in commit a30951d31b25 ("xhci: tegra: USB2 pad power controls"), where the UTMI pad was being powered down without verifying its current state. This unbalanced behavior led to discrepancies in the reference count. To rectify this issue, this patch replaces the single reference counter with a bitmask, renamed to utmi_pad_enabled. Each bit in the mask corresponds to one of the four USB2 PHYs, allowing us to track each pad's enablement status individually. With this change: - The bias pad is powered on only when the mask is clear. - Each UTMI pad is powered on or down based on its corresponding bit in the mask, preventing redundant operations. - The overall power state of the shared bias pad is maintained correctly during suspend/resume cycles. The mutex used to prevent race conditions during UTMI pad enable/disable operations has been moved from the tegra186_utmi_bias_pad_power_on/off functions to the parent functions tegra186_utmi_pad_power_on/down. This change ensures that there are no race conditions when updating the bitmask. Cc: stable@vger.kernel.org Fixes: a30951d31b25 ("xhci: tegra: USB2 pad power controls") Signed-off-by: Wayne Chang <waynec@nvidia.com> Reviewed-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20250408030905.990474-1-waynec@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-04-01Merge tag 'phy-for-6.15' of ↵Linus Torvalds30-230/+4190
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy Pull phy updates from Vinod Koul: "A fairly moderate sized request for the generic phy subsystem with some new device and driver support along with driver updates with Samsung and Qualcomm ones being major ones. New HW Support: - Qualcomm X1P42100 PCIe Gen4x4, QCS615 qmp usbc, PCIe UNIPHY 28LP driver, SM8750 QMP UFS PHY - Rockchip rk3576 hdptx, rk3562 naneng-combo support - Samsung MIPI D-/C-PHY driver, ExynosAutov920 ufs phy driver Updates: - Samsung USB3 Type-C lane orientation detection and configuration for Google gs101 - Qualcomm support for dual lane PHY support for QCS8300 SoC" * tag 'phy-for-6.15' of git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy: (47 commits) phy: rockchip-naneng-combo: Support rk3562 dt-bindings: phy: rockchip: Add rk3562 naneng-combophy compatible phy: rockchip: Add Samsung MIPI D-/C-PHY driver dt-bindings: phy: Add Rockchip MIPI C-/D-PHY schema phy: qcom: uniphy-28lp: add COMMON_CLK dependency phy: rockchip: usbdp: Remove unnecessary bool conversion phy: rockchip: usbdp: Avoid call hpd_event_trigger in dp_phy_init phy: rockchip: usbdp: Only verify link rates/lanes/voltage when the corresponding set flags are set phy: qcom-qmp-pcie: add dual lane PHY support for QCS8300 dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the QCS8300 QMP PCIe PHY Gen4 x2 phy: qcom-qmp-ufs: Add PHY Configuration support for sm8750 dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the SM8750 QMP UFS PHY phy: qcom: Introduce PCIe UNIPHY 28LP driver dt-bindings: phy: qcom,uniphy-pcie: Document PCIe uniphy phy: qcom: qmp-usbc: Add qmp configuration for QCS615 phy: freescale: imx8m-pcie: assert phy reset and perst in power off phy: freescale: imx8m-pcie: cleanup reset logic phy: core: Remove unused phy_pm_runtime_(allow|forbid) dt-bindings: phy: document Allwinner A523 USB-2.0 PHY phy: phy-rockchip-samsung-hdptx: Add support for RK3576 ...
2025-03-16phy: rockchip-naneng-combo: Support rk3562Jon Lin1-0/+152
rk3562 has 1 naneng comboPHY used for PCIe and USB3. Signed-off-by: Jon Lin <jon.lin@rock-chips.com> Signed-off-by: Kever Yang <kever.yang@rock-chips.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250227110836.2343158-2-kever.yang@rock-chips.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-16phy: rockchip: Add Samsung MIPI D-/C-PHY driverHeiko Stuebner3-0/+1732
Add driver for the MIPI D-/C-PHY block based around a Samsung IP-block that is for example needed to drive a MIPI DSI output on rk3588. Right now only the D-PHY portion is implemented, with the C-PHY part needing separate work. Tested-by: Daniel Semkowicz <dse@thaumatec.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Heiko Stuebner <heiko.stuebner@cherry.de> Link: https://lore.kernel.org/r/20250313134035.278133-3-heiko@sntech.de Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-16phy: qcom: uniphy-28lp: add COMMON_CLK dependencyArnd Bergmann1-0/+1
In configurations without CONFIG_COMMON_CLK, the driver fails to build: aarch64-linux-ld: drivers/phy/qualcomm/phy-qcom-uniphy-pcie-28lp.o: in function `qcom_uniphy_pcie_probe': phy-qcom-uniphy-pcie-28lp.c:(.text+0x200): undefined reference to `__clk_hw_register_fixed_rate' aarch64-linux-ld: phy-qcom-uniphy-pcie-28lp.c:(.text+0x238): undefined reference to `of_clk_hw_simple_get' phy-qcom-uniphy-pcie-28lp.c:(.text+0x238): dangerous relocation: unsupported relocation aarch64-linux-ld: phy-qcom-uniphy-pcie-28lp.c:(.text+0x240): undefined reference to `of_clk_hw_simple_get' aarch64-linux-ld: phy-qcom-uniphy-pcie-28lp.c:(.text+0x248): undefined reference to `devm_of_clk_add_hw_provider' Add that as a Kconfig dependencies. Fixes: 74badb8b0b14 ("phy: qcom: Introduce PCIe UNIPHY 28LP driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250314154915.4074980-1-arnd@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-12phy: rockchip: usbdp: Remove unnecessary bool conversionThorsten Blum1-1/+1
Remove the unnecessary bool conversion and simplify the code. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250224220339.199180-2-thorsten.blum@linux.dev Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-12phy: rockchip: usbdp: Avoid call hpd_event_trigger in dp_phy_initAndy Yan1-1/+0
Function rk_udphy_dp_hpd_event_trigger will set vogrf let it trigger HPD interrupt to DP by Type-C. This configuration is only required when the DP work in Alternate Mode, and called by typec_mux_set. In standard DP mode, such settings will prevent the DP from receiving HPD interrupts. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Link: https://lore.kernel.org/r/20250302115257.188774-1-andyshrk@163.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-12phy: rockchip: usbdp: Only verify link rates/lanes/voltage when the ↵Andy Yan1-34/+53
corresponding set flags are set According documentation of phy_configure_opts_dp, at the configure stage, link rates should only be verify/configure when set_rate flag is set, the same applies to lanes and voltage. So do it as the documentation says. Because voltage setting depends on the lanes, link rates set previously, so record the link rates and lanes at it's verify stage. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Link: https://lore.kernel.org/r/20250312080041.524546-1-andyshrk@163.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-11phy: qcom-qmp-pcie: add dual lane PHY support for QCS8300Ziyue Zhang1-0/+89
The PCIe Gen4x2 PHY for qcs8300 has a lot of difference with sa8775p. So the qcs8300_qmp_gen4x2_pcie_rx_alt_tbl for qcs8300 is added. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Ziyue Zhang <quic_ziyuzhan@quicinc.com> Link: https://lore.kernel.org/r/20250310063103.3924525-3-quic_ziyuzhan@quicinc.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-11phy: qcom-qmp-ufs: Add PHY Configuration support for sm8750Nitin Rawat3-8/+246
Add SM8750 specific register layout and table configs. The serdes TX RX register offset has changed for SM8750 and hence keep UFS specific serdes offsets in a dedicated header file. Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Co-developed-by: Manish Pandey <quic_mapa@quicinc.com> Signed-off-by: Manish Pandey <quic_mapa@quicinc.com> Signed-off-by: Nitin Rawat <quic_nitirawa@quicinc.com> Link: https://lore.kernel.org/r/20250310-sm8750_ufs_master-v2-2-0dfdd6823161@quicinc.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-11phy: qcom: Introduce PCIe UNIPHY 28LP driverNitheesh Sekar3-0/+299
Add Qualcomm PCIe UNIPHY 28LP driver support present in Qualcomm IPQ5332 SoC and the phy init sequence. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Nitheesh Sekar <quic_nsekar@quicinc.com> Signed-off-by: Varadarajan Narayanan <quic_varada@quicinc.com> Link: https://lore.kernel.org/r/20250220094251.230936-3-quic_varada@quicinc.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-11phy: qcom: qmp-usbc: Add qmp configuration for QCS615Krishna Kurapati1-0/+3
Provide PHY configuration for the USB QMP PHY for QCS615 Platform. Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Unreviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20250310110359.210990-1-krishna.kurapati@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-11phy: freescale: imx8m-pcie: assert phy reset and perst in power offStefan Eichenberger1-0/+11
Ensure the PHY reset and perst is asserted during power-off to guarantee it is in a reset state upon repeated power-on calls. This resolves an issue where the PHY may not properly initialize during subsequent power-on cycles. Power-on will deassert the reset at the appropriate time after tuning the PHY parameters. During suspend/resume cycles, we observed that the PHY PLL failed to lock during resume when the CPU temperature increased from 65C to 75C. The observed errors were: phy phy-32f00000.pcie-phy.3: phy poweron failed --> -110 imx6q-pcie 33800000.pcie: waiting for PHY ready timeout! imx6q-pcie 33800000.pcie: PM: dpm_run_callback(): genpd_resume_noirq+0x0/0x80 returns -110 imx6q-pcie 33800000.pcie: PM: failed to resume noirq: error -110 This resulted in a complete CPU freeze, which is resolved by ensuring the PHY is in reset during power-on, thus preventing PHY PLL failures. Cc: stable@vger.kernel.org Fixes: 1aa97b002258 ("phy: freescale: pcie: Initialize the imx8 pcie standalone phy driver") Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250305144355.20364-3-eichest@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-11phy: freescale: imx8m-pcie: cleanup reset logicStefan Eichenberger1-9/+3
Remove the switch statement and base perst release on whether it is found in the device tree. The probe function fails without the reset property, making it mandatory. Therefore, always release reset independent of the variant. This does not change the behavior of the driver but reduces driver complexity and allows for easier future modifications. Signed-off-by: Stefan Eichenberger <stefan.eichenberger@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://lore.kernel.org/r/20250305144355.20364-2-eichest@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-10phy: core: Remove unused phy_pm_runtime_(allow|forbid)Dr. David Alan Gilbert1-24/+0
phy_pm_runtime_allow() and phy_pm_runtime_forbid() were added in 2013 as part of commit ff764963479a ("drivers: phy: add generic PHY framework") but have remained unused. Remove them. Fix up the (English) docs - I've left the Chinese translation. Signed-off-by: Dr. David Alan Gilbert <linux@treblig.org> Link: https://lore.kernel.org/r/20250306015408.277729-1-linux@treblig.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-10phy: phy-rockchip-samsung-hdptx: Add support for RK3576Nicolas Frattaroli1-0/+11
Despite the compatible already being listed in the bindings, the PHY driver never gained explicit support for it. This is especially a problem because the explicitly listed PHY addresses need to be specified for each SoC. To solve this, add the compatible, and a PHY config, with the address gleaned from rk3576.dtsi. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250306-rk3576-hdptx-phy-v1-1-288cc4b0611a@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-03-03Merge tag 'v6.14-rc5' of ↵Bartosz Golaszewski7-35/+73
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into gpio/for-next Linux 6.14-rc5
2025-02-27phy: exynos5-usbdrd: Do not depend on Type-CKrzysztof Kozlowski1-1/+1
Older Exynos designs, like Exynos5422, do not have USB Type-C and the USB DRD PHY does not really need CONFIG_TYPEC for these devices at all. Incorrectly added optional dependency on CONFIG_TYPEC caused this driver to be missing for exynos_defconfig and as result Exynos5422-based boards like Hardkernel Odroid HC1 failed to probe USB. Reported-by: Krzysztof Kozlowski <krzk@kernel.org> Closes: https://krzk.eu/#/builders/21/builds/6139 Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/3c0b77e6-357d-453e-8b63-4757c3231bde@samsung.com/ Fixes: 09dc674295a3 ("phy: exynos5-usbdrd: subscribe to orientation notifier if required") Reviewed-by: André Draszik <andre.draszik@linaro.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250227070518.5468-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-02-17phy: mapphone-mdm6600: use gpiod_multi_set_value_cansleepDavid Lechner1-3/+1
Reduce verbosity by using gpiod_multi_set_value_cansleep() instead of gpiod_set_array_value_cansleep(). ddata->cmd_gpios->ndescs is validated to be equal to PHY_MDM6600_NR_CMD_LINES during driver probe, so it will have the same value as the previously hard-coded argument. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David Lechner <dlechner@baylibre.com> Acked-by: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20250210-gpio-set-array-helper-v3-14-d6a673674da8@baylibre.com Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
2025-02-14phy: PHY_LAN966X_SERDES should depend on SOC_LAN966 || MCHP_LAN966X_PCIGeert Uytterhoeven1-0/+1
The Microchip LAN966X SerDes PHY is only present on Microchip LAN966x SoCs. However, when used as a PCI endpoint, all peripherals of the LAN966x SoC can be accessed by the PCI host. Hence add dependencies on SOC_LAN966 and MCHP_LAN966X_PCI, to prevent asking the user about this driver when configuring a kernel without Microchip LAN966x SoC and PCIe support. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Herve Codina <herve.codina@bootlin.com> Link: https://lore.kernel.org/r/369233