* Re: [PATCH] phy: qcom: qmp-combo: Add polarity inversion support for SAR2130P
From: Vinod Koul @ 2026-01-14 14:01 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Dmitry Baryshkov, Neil Armstrong,
Konrad Dybcio, Krzysztof Kozlowski, Krishna Kurapati
Cc: linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <20251017203438.744197-1-krishna.kurapati@oss.qualcomm.com>
On Sat, 18 Oct 2025 02:04:38 +0530, Krishna Kurapati wrote:
> On SAR2130P QXR Platform, the CC Lines are inverted and the lane
> programming is to be done reverse compared to other targets.
>
> As per the HW specifics, Bit-2 of TYPEC_CTRL register indicates
> port select polarity. This bit is to be set for SAR2130P.
>
>
> [...]
Applied, thanks!
[1/1] phy: qcom: qmp-combo: Add polarity inversion support for SAR2130P
commit: 24991bfbbd84d68d5710e1563752047914db941a
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: (subset) [PATCH v2 0/6] Enable UFS support on Milos
From: Vinod Koul @ 2026-01-14 14:01 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Alim Akhtar, Avri Altman,
Bart Van Assche, Neil Armstrong, Konrad Dybcio, Luca Weiss
Cc: ~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, linux-scsi, linux-phy,
Krzysztof Kozlowski, Abel Vesa, Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260112-milos-ufs-v2-0-d3ce4f61f030@fairphone.com>
On Mon, 12 Jan 2026 14:53:13 +0100, Luca Weiss wrote:
> Add inline-crypto-engine and UFS bindings & driver parts, then add them
> to milos dtsi and enable the UFS storage on Fairphone (Gen. 6).
>
>
Applied, thanks!
[3/6] dt-bindings: phy: qcom,sc8280xp-qmp-ufs-phy: document the Milos QMP UFS PHY
commit: ed0a26aa453b6ec7faec32ddb4fb3d4360e1676c
[4/6] phy: qcom-qmp-ufs: Add Milos support
commit: 3554ded4f02aa8e95af66911aa666b2cd192022d
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: qcom: edp: Fix NULL pointer dereference for phy v6 (x1e80100)
From: Vinod Koul @ 2026-01-14 14:01 UTC (permalink / raw)
To: Neil Armstrong, Abel Vesa, Dmitry Baryshkov, Val Packett
Cc: Abel Vesa, linux-arm-msm, linux-phy, linux-kernel
In-Reply-To: <20260111083317.604754-1-val@packett.cool>
On Sun, 11 Jan 2026 05:25:59 -0300, Val Packett wrote:
> For Glymur SoC support, the com_clk_fwd_cfg callback was added, and a
> stub implementation was added for the v4 of the hardware. However it
> was omitted for the v6, causing a NULL pointer dereference oops on
> Hamoa/Purwa (X1E/X1P) SoC devices. Fix by adding the appropriate stub.
>
>
Applied, thanks!
[1/1] phy: qcom: edp: Fix NULL pointer dereference for phy v6 (x1e80100)
commit: 70812056fbfb9348788e35b7641ff959b711840e
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH] phy: sun4i-usb: replace use of system_wq with system_percpu_wq
From: Vinod Koul @ 2026-01-14 14:01 UTC (permalink / raw)
To: linux-kernel, linux-phy, linux-arm-kernel, linux-sunxi,
Marco Crivellari
Cc: Tejun Heo, Lai Jiangshan, Frederic Weisbecker,
Sebastian Andrzej Siewior, Michal Hocko, Kishon Vijay Abraham I,
Jernej Skrabec, Samuel Holland, Chen-Yu Tsai
In-Reply-To: <20251105152023.259813-1-marco.crivellari@suse.com>
On Wed, 05 Nov 2025 16:20:23 +0100, Marco Crivellari wrote:
> Currently if a user enqueues a work item using schedule_delayed_work() the
> used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
> WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
> schedule_work() that is using system_wq and queue_work(), that makes use
> again of WORK_CPU_UNBOUND.
>
> This lack of consistency cannot be addressed without refactoring the API.
>
> [...]
Applied, thanks!
[1/1] phy: sun4i-usb: replace use of system_wq with system_percpu_wq
commit: 877686f9f42b58b04e4e25d07034bc95cadc20f3
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v2] phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()
From: Vinod Koul @ 2026-01-14 14:01 UTC (permalink / raw)
To: kishon, heiko, Wentao Liang
Cc: linux-phy, linux-rockchip, linux-kernel, linux-arm-kernel, stable
In-Reply-To: <20260109154626.2452034-1-vulab@iscas.ac.cn>
On Fri, 09 Jan 2026 15:46:26 +0000, Wentao Liang wrote:
> The for_each_available_child_of_node() calls of_node_put() to
> release child_np in each success loop. After breaking from the
> loop with the child_np has been released, the code will jump to
> the put_child label and will call the of_node_put() again if the
> devm_request_threaded_irq() fails. These cause a double free bug.
>
> Fix by returning directly to avoid the duplicate of_node_put().
>
> [...]
Applied, thanks!
[1/1] phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()
commit: e07dea3de508cd6950c937cec42de7603190e1ca
Best regards,
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 3/5] phy: rockchip-snps-pcie3: Increase sram init timeout
From: Vinod Koul @ 2026-01-14 13:29 UTC (permalink / raw)
To: Shawn Lin
Cc: Manivannan Sadhasivam, Bjorn Helgaas, linux-pci, linux-rockchip,
linux-phy, Heiko Stuebner, Neil Armstrong, Sebastian Reichel
In-Reply-To: <1766560210-100883-4-git-send-email-shawn.lin@rock-chips.com>
On 24-12-25, 15:10, Shawn Lin wrote:
> Per massive test, 500us is not enough for all chips, increase it
> to 20000us for worse case recommended.
>
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
>
> drivers/phy/rockchip/phy-rockchip-snps-pcie3.c | 10 +++++++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> index 9933cda..f5a5d0af 100644
> --- a/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> +++ b/drivers/phy/rockchip/phy-rockchip-snps-pcie3.c
> @@ -19,6 +19,9 @@
> #include <linux/regmap.h>
> #include <linux/reset.h>
>
> +/* Common definition */
> +#define RK_SRAM_INIT_TIMEOUT_US 20000
> +
> /* Register for RK3568 */
> #define GRF_PCIE30PHY_CON1 0x4
> #define GRF_PCIE30PHY_CON6 0x18
> @@ -28,6 +31,7 @@
> #define GRF_PCIE30PHY_WR_EN (0xf << 16)
> #define SRAM_INIT_DONE(reg) (reg & BIT(14))
>
> +
why this empty line here?
> #define RK3568_BIFURCATION_LANE_0_1 BIT(0)
>
> /* Register for RK3588 */
> @@ -134,7 +138,7 @@ static int rockchip_p3phy_rk3568_calibrate(struct rockchip_p3phy_priv *priv)
> ret = regmap_read_poll_timeout(priv->phy_grf,
> GRF_PCIE30PHY_STATUS0,
> reg, SRAM_INIT_DONE(reg),
> - 0, 500);
> + 0, RK_SRAM_INIT_TIMEOUT_US);
> if (ret)
> dev_err(&priv->phy->dev, "lock failed 0x%x, check input refclk and power supply\n",
> reg);
> @@ -203,11 +207,11 @@ static int rockchip_p3phy_rk3588_calibrate(struct rockchip_p3phy_priv *priv)
> ret = regmap_read_poll_timeout(priv->phy_grf,
> RK3588_PCIE3PHY_GRF_PHY0_STATUS1,
> reg, RK3588_SRAM_INIT_DONE(reg),
> - 0, 500);
> + 0, RK_SRAM_INIT_TIMEOUT_US);
> ret |= regmap_read_poll_timeout(priv->phy_grf,
> RK3588_PCIE3PHY_GRF_PHY1_STATUS1,
> reg, RK3588_SRAM_INIT_DONE(reg),
> - 0, 500);
> + 0, RK_SRAM_INIT_TIMEOUT_US);
> if (ret)
> dev_err(&priv->phy->dev, "lock failed 0x%x, check input refclk and power supply\n",
> reg);
> --
> 2.7.4
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 net-next 00/10] PHY polarity inversion via generic device tree properties
From: Vinod Koul @ 2026-01-14 13:18 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev, devicetree, linux-phy, linux-kernel, linux-arm-kernel,
linux-mediatek, Daniel Golle, Horatiu Vultur, Bjørn Mork,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra,
Marek Behún, Lee Jones, Patrice Chotard
In-Reply-To: <20260111093940.975359-1-vladimir.oltean@nxp.com>
On 11-01-26, 11:39, Vladimir Oltean wrote:
> Introduce "rx-polarity" and "tx-polarity" device tree properties.
> Convert two existing networking use cases - the EN8811H Ethernet PHY and
> the Mediatek LynxI PCS.
>
> Requested merge strategy:
> Patches 1-5 through linux-phy
The following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:
Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/phy/linux-phy.git tags/phy_common_properties
for you to fetch changes up to e7556b59ba65179612bce3fa56bb53d1b4fb20db:
phy: add phy_get_rx_polarity() and phy_get_tx_polarity() (2026-01-14 18:16:05 +0530)
----------------------------------------------------------------
phy common properties
Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
Introduce "rx-polarity" and "tx-polarity" device tree properties with
Kunit tests
----------------------------------------------------------------
Vladimir Oltean (5):
dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yaml
dt-bindings: phy-common-props: create a reusable "protocol-names" definition
dt-bindings: phy-common-props: ensure protocol-names are unique
dt-bindings: phy-common-props: RX and TX lane polarity inversion
phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
.../devicetree/bindings/phy/phy-common-props.yaml | 157 ++++++++
.../bindings/phy/transmit-amplitude.yaml | 103 -----
MAINTAINERS | 10 +
drivers/phy/Kconfig | 22 ++
drivers/phy/Makefile | 2 +
drivers/phy/phy-common-props-test.c | 422 +++++++++++++++++++++
drivers/phy/phy-common-props.c | 209 ++++++++++
include/dt-bindings/phy/phy.h | 4 +
include/linux/phy/phy-common-props.h | 32 ++
9 files changed, 858 insertions(+), 103 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/phy-common-props.yaml
delete mode 100644 Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
create mode 100644 drivers/phy/phy-common-props-test.c
create mode 100644 drivers/phy/phy-common-props.c
create mode 100644 include/linux/phy/phy-common-props.h
> linux-phy provides stable branch or tag to netdev
> patches 6-10 through netdev
>
> v2 at:
> https://lore.kernel.org/netdev/20260103210403.438687-1-vladimir.oltean@nxp.com/
> Changes since v2:
> - fix bug with existing fwnode which is missing polarity properties.
> This is supposed to return the default value, not an error. (thanks to
> Bjørn Mork).
> - fix inconsistency between PHY_COMMON_PROPS and GENERIC_PHY_COMMON_PROPS
> Kconfig options by using PHY_COMMON_PROPS everywhere (thanks to Bjørn
> Mork).
>
> v1 at:
> https://lore.kernel.org/netdev/20251122193341.332324-1-vladimir.oltean@nxp.com/
> Changes since v1:
> - API changes: split error code from returned value; introduce two new
> helpers for simple driver cases
> - Add KUnit tests
> - Bug fixes in core code and in drivers
> - Defer XPCS patches for later (*)
> - Convert Mediatek LynxI PCS
> - Logical change: rx-polarity and tx-polarity refer to the currently
> described block, and not necessarily to device pins
> - Apply Rob's feedback
> - Drop the "joint maintainership" idea.
>
> (*) To simplify the generic XPCS driver, I've decided to make
> "tx-polarity" default to <PHY_POL_NORMAL>, rather than <PHY_POL_NORMAL>
> OR <PHY_POL_INVERT> for SJA1105. But in order to avoid breakage, it
> creates a hard dependency on this patch set being merged *first*:
> https://lore.kernel.org/netdev/20251118190530.580267-1-vladimir.oltean@nxp.com/
> so that the SJA1105 driver can provide an XPCS fwnode with the right
> polarity specified. All patches in context can be seen at:
> https://github.com/vladimiroltean/linux/tree/phy-polarity-inversion
>
> Original cover letter:
>
> Polarity inversion (described in patch 4/10) is a feature with at least
> 4 potential new users waiting for a generic description:
> - Horatiu Vultur with the lan966x SerDes
> - Daniel Golle with the MaxLinear GSW1xx switches
> - Bjørn Mork with the AN8811HB Ethernet PHY
> - Me with a custom SJA1105 board, switch which uses the DesignWare XPCS
>
> I became interested in exploring the problem space because I was averse
> to the idea of adding vendor-specific device tree properties to describe
> a common need.
>
> This set contains an implementation of a generic feature that should
> cater to all known needs that were identified during my documentation
> phase.
>
> Apart from what is converted here, we also have the following, which I
> did not touch:
> - "st,px_rx_pol_inv" - its binding is a .txt file and I don't have time
> for such a large detour to convert it to dtschema.
> - "st,pcie-tx-pol-inv" and "st,sata-tx-pol-inv" - these are defined in a
> .txt schema but are not implemented in any driver. My verdict would be
> "delete the properties" but again, I would prefer not introducing such
> dependency to this series.
>
> Vladimir Oltean (10):
> dt-bindings: phy: rename transmit-amplitude.yaml to
> phy-common-props.yaml
> dt-bindings: phy-common-props: create a reusable "protocol-names"
> definition
> dt-bindings: phy-common-props: ensure protocol-names are unique
> dt-bindings: phy-common-props: RX and TX lane polarity inversion
> phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
> dt-bindings: net: airoha,en8811h: deprecate "airoha,pnswap-rx" and
> "airoha,pnswap-tx"
> net: phy: air_en8811h: deprecate "airoha,pnswap-rx" and
> "airoha,pnswap-tx"
> dt-bindings: net: pcs: mediatek,sgmiisys: deprecate "mediatek,pnswap"
> net: pcs: pcs-mtk-lynxi: pass SGMIISYS OF node to PCS
> net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"
>
> .../bindings/net/airoha,en8811h.yaml | 11 +-
> .../bindings/net/pcs/mediatek,sgmiisys.yaml | 7 +-
> .../bindings/phy/phy-common-props.yaml | 157 +++++++
> .../bindings/phy/transmit-amplitude.yaml | 103 -----
> MAINTAINERS | 10 +
> drivers/net/dsa/mt7530-mdio.c | 4 +-
> drivers/net/ethernet/mediatek/mtk_eth_soc.c | 19 +-
> drivers/net/pcs/Kconfig | 1 +
> drivers/net/pcs/pcs-mtk-lynxi.c | 63 ++-
> drivers/net/phy/Kconfig | 1 +
> drivers/net/phy/air_en8811h.c | 53 ++-
> drivers/phy/Kconfig | 22 +
> drivers/phy/Makefile | 2 +
> drivers/phy/phy-common-props-test.c | 422 ++++++++++++++++++
> drivers/phy/phy-common-props.c | 209 +++++++++
> include/dt-bindings/phy/phy.h | 4 +
> include/linux/pcs/pcs-mtk-lynxi.h | 5 +-
> include/linux/phy/phy-common-props.h | 32 ++
> 18 files changed, 979 insertions(+), 146 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/phy/phy-common-props.yaml
> delete mode 100644 Documentation/devicetree/bindings/phy/transmit-amplitude.yaml
> create mode 100644 drivers/phy/phy-common-props-test.c
> create mode 100644 drivers/phy/phy-common-props.c
> create mode 100644 include/linux/phy/phy-common-props.h
>
> --
> 2.43.0
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3 net-next 05/10] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()
From: Vinod Koul @ 2026-01-14 13:10 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Bjørn Mork, netdev, devicetree, linux-phy, linux-kernel,
linux-arm-kernel, linux-mediatek, Daniel Golle, Horatiu Vultur,
Andrew Lunn, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra,
Marek Behún, Lee Jones, Patrice Chotard
In-Reply-To: <20260111141549.xtl5bpjtru6rv6ys@skbuf>
On 11-01-26, 16:15, Vladimir Oltean wrote:
> On Sun, Jan 11, 2026 at 12:53:15PM +0100, Bjørn Mork wrote:
> > Vladimir Oltean <vladimir.oltean@nxp.com> writes:
> >
> > > Add helpers in the generic PHY folder which can be used using 'select
> > > GENERIC_PHY_COMMON_PROPS' from Kconfig
> >
> > The code looks good to me now.
> >
> > But renaming stuff is hard. Leftover old config symbol in the commit
> > description here. Could be fixed up on merge, maybe?
> >
> >
> > Bjørn
>
> This is unfortunate. I'll let Vinot comment on the preferred approach,
> although I also wouldn't prefer resending to fix a minor commit message
> mistake. Thanks for spotting and for the review in general.
Yes fixed that while applying
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 2/2] phy: eswin: Create eswin directory and add EIC7700 SATA PHY driver
From: Vinod Koul @ 2026-01-14 12:11 UTC (permalink / raw)
To: Yulin Lu
Cc: neil.armstrong, robh, krzk+dt, conor+dt, p.zabel, linux-phy,
devicetree, linux-kernel, ningyu, zhengyu, linmin, huangyifeng,
fenglin, lianghujun
In-Reply-To: <20260106063309.241-1-luyulin@eswincomputing.com>
On 06-01-26, 14:33, Yulin Lu wrote:
> Created the eswin phy driver directory and added support for
> the SATA phy driver on the EIC7700 SoC platform.
>
> Signed-off-by: Yulin Lu <luyulin@eswincomputing.com>
> ---
> drivers/phy/Kconfig | 1 +
> drivers/phy/Makefile | 1 +
> drivers/phy/eswin/Kconfig | 14 ++
> drivers/phy/eswin/Makefile | 2 +
> drivers/phy/eswin/phy-eic7700-sata.c | 221 +++++++++++++++++++++++++++
> 5 files changed, 239 insertions(+)
> create mode 100644 drivers/phy/eswin/Kconfig
> create mode 100644 drivers/phy/eswin/Makefile
> create mode 100644 drivers/phy/eswin/phy-eic7700-sata.c
>
> diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
> index 678dd0452f0a..6d50704917f0 100644
> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -105,6 +105,7 @@ source "drivers/phy/allwinner/Kconfig"
> source "drivers/phy/amlogic/Kconfig"
> source "drivers/phy/broadcom/Kconfig"
> source "drivers/phy/cadence/Kconfig"
> +source "drivers/phy/eswin/Kconfig"
> source "drivers/phy/freescale/Kconfig"
> source "drivers/phy/hisilicon/Kconfig"
> source "drivers/phy/ingenic/Kconfig"
> diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
> index bfb27fb5a494..482a143d3417 100644
> --- a/drivers/phy/Makefile
> +++ b/drivers/phy/Makefile
> @@ -17,6 +17,7 @@ obj-y += allwinner/ \
> amlogic/ \
> broadcom/ \
> cadence/ \
> + eswin/ \
> freescale/ \
> hisilicon/ \
> ingenic/ \
> diff --git a/drivers/phy/eswin/Kconfig b/drivers/phy/eswin/Kconfig
> new file mode 100644
> index 000000000000..37447cc3af63
> --- /dev/null
> +++ b/drivers/phy/eswin/Kconfig
> @@ -0,0 +1,14 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# Phy drivers for ESWIN platforms
> +#
> +config PHY_EIC7700_SATA
> + tristate "eic7700 Sata SerDes/PHY driver"
> + depends on ARCH_ESWIN || COMPILE_TEST
> + depends on HAS_IOMEM
> + select GENERIC_PHY
> + help
> + Enable this to support SerDes/Phy found on ESWIN's
> + EIC7700 SoC.This Phy supports SATA 1.5 Gb/s,
> + SATA 3.0 Gb/s, SATA 6.0 Gb/s speeds.
> + It supports one SATA host port to accept one SATA device.
> diff --git a/drivers/phy/eswin/Makefile b/drivers/phy/eswin/Makefile
> new file mode 100644
> index 000000000000..db08c66be812
> --- /dev/null
> +++ b/drivers/phy/eswin/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-$(CONFIG_PHY_EIC7700_SATA) += phy-eic7700-sata.o
> diff --git a/drivers/phy/eswin/phy-eic7700-sata.c b/drivers/phy/eswin/phy-eic7700-sata.c
> new file mode 100644
> index 000000000000..96ae62a1b637
> --- /dev/null
> +++ b/drivers/phy/eswin/phy-eic7700-sata.c
> @@ -0,0 +1,221 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * ESWIN SATA PHY driver
> + *
> + * Copyright 2026, Beijing ESWIN Computing Technology Co., Ltd..
> + * All rights reserved.
> + *
> + * Authors: Yulin Lu <luyulin@eswincomputing.com>
> + */
> +
> +#include <linux/bitfield.h>
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/phy/phy.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/reset.h>
> +
> +#define SATA_AXI_LP_CTRL 0x08
> +#define SATA_MPLL_CTRL 0x20
> +#define SATA_P0_PHY_STAT 0x24
> +#define SATA_PHY_CTRL0 0x28
> +#define SATA_PHY_CTRL1 0x2c
> +#define SATA_REF_CTRL 0x34
> +#define SATA_REF_CTRL1 0x38
> +#define SATA_LOS_IDEN 0x3c
> +
> +#define SATA_CLK_RST_SOURCE_PHY BIT(0)
> +#define SATA_P0_PHY_TX_AMPLITUDE_GEN1_MASK GENMASK(6, 0)
> +#define SATA_P0_PHY_TX_AMPLITUDE_GEN2_MASK GENMASK(14, 8)
> +#define SATA_P0_PHY_TX_AMPLITUDE_GEN3_MASK GENMASK(22, 16)
> +#define SATA_P0_PHY_TX_PREEMPH_GEN1_MASK GENMASK(5, 0)
> +#define SATA_P0_PHY_TX_PREEMPH_GEN2_MASK GENMASK(13, 8)
> +#define SATA_P0_PHY_TX_PREEMPH_GEN3_MASK GENMASK(21, 16)
> +#define SATA_LOS_LEVEL_MASK GENMASK(4, 0)
> +#define SATA_LOS_BIAS_MASK GENMASK(18, 16)
> +#define SATA_M_CSYSREQ BIT(0)
> +#define SATA_S_CSYSREQ BIT(16)
> +#define SATA_REF_REPEATCLK_EN BIT(0)
> +#define SATA_REF_USE_PAD BIT(20)
> +#define SATA_MPLL_MULTIPLIER_MASK GENMASK(22, 16)
> +#define SATA_P0_PHY_READY BIT(0)
> +
> +#define PLL_LOCK_SLEEP_US 10
> +#define PLL_LOCK_TIMEOUT_US 1000
> +
> +struct eic7700_sata_phy {
> + struct reset_control *rst;
> + struct regmap *regmap;
> + struct clk *clk;
> + struct phy *phy;
> +};
> +
> +static const struct regmap_config eic7700_sata_phy_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> + .max_register = SATA_LOS_IDEN,
> +};
> +
> +static int wait_for_phy_ready(struct regmap *regmap, u32 reg, u32 checkbit,
> + u32 status)
> +{
> + u32 val;
> + int ret;
> +
> + ret = regmap_read_poll_timeout(regmap, reg, val,
> + (val & checkbit) == status,
> + PLL_LOCK_SLEEP_US, PLL_LOCK_TIMEOUT_US);
> +
> + return ret;
> +}
> +
> +static int eic7700_sata_phy_init(struct phy *phy)
> +{
> + struct eic7700_sata_phy *sata_phy = phy_get_drvdata(phy);
> + u32 val;
> + int ret;
> +
> + ret = clk_prepare_enable(sata_phy->clk);
> + if (ret)
> + return ret;
> +
> + regmap_write(sata_phy->regmap, SATA_REF_CTRL1, SATA_CLK_RST_SOURCE_PHY);
> +
> + val = FIELD_PREP(SATA_P0_PHY_TX_AMPLITUDE_GEN1_MASK, 0x42) |
> + FIELD_PREP(SATA_P0_PHY_TX_AMPLITUDE_GEN2_MASK, 0x46) |
> + FIELD_PREP(SATA_P0_PHY_TX_AMPLITUDE_GEN3_MASK, 0x73);
> + regmap_write(sata_phy->regmap, SATA_PHY_CTRL0, val);
> +
> + val = FIELD_PREP(SATA_P0_PHY_TX_PREEMPH_GEN1_MASK, 0x5) |
> + FIELD_PREP(SATA_P0_PHY_TX_PREEMPH_GEN2_MASK, 0x5) |
> + FIELD_PREP(SATA_P0_PHY_TX_PREEMPH_GEN3_MASK, 0x8);
Where are the magic values you are writing coming from..?
> + regmap_write(sata_phy->regmap, SATA_PHY_CTRL1, val);
> +
> + val = FIELD_PREP(SATA_LOS_LEVEL_MASK, 0x9) |
> + FIELD_PREP(SATA_LOS_BIAS_MASK, 0x2);
> + regmap_write(sata_phy->regmap, SATA_LOS_IDEN, val);
> +
> + val = SATA_M_CSYSREQ | SATA_S_CSYSREQ;
> + regmap_write(sata_phy->regmap, SATA_AXI_LP_CTRL, val);
> +
> + val = SATA_REF_REPEATCLK_EN | SATA_REF_USE_PAD;
> + regmap_write(sata_phy->regmap, SATA_REF_CTRL, val);
> +
> + val = FIELD_PREP(SATA_MPLL_MULTIPLIER_MASK, 0x3c);
> + regmap_write(sata_phy->regmap, SATA_MPLL_CTRL, val);
> +
> + usleep_range(15, 20);
> +
> + ret = reset_control_deassert(sata_phy->rst);
> + if (ret)
> + goto disable_clk;
> +
> + ret = wait_for_phy_ready(sata_phy->regmap, SATA_P0_PHY_STAT,
> + SATA_P0_PHY_READY, 1);
> + if (ret < 0) {
> + dev_err(&sata_phy->phy->dev, "PHY READY check failed\n");
> + goto disable_clk;
> + }
> +
> + return 0;
> +
> +disable_clk:
> + clk_disable_unprepare(sata_phy->clk);
> + return ret;
> +}
> +
> +static int eic7700_sata_phy_exit(struct phy *phy)
> +{
> + struct eic7700_sata_phy *sata_phy = phy_get_drvdata(phy);
> + int ret;
> +
> + ret = reset_control_assert(sata_phy->rst);
> + if (ret)
> + return ret;
> +
> + clk_disable_unprepare(sata_phy->clk);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops eic7700_sata_phy_ops = {
> + .init = eic7700_sata_phy_init,
> + .exit = eic7700_sata_phy_exit,
> + .owner = THIS_MODULE,
> +};
> +
> +static int eic7700_sata_phy_probe(struct platform_device *pdev)
> +{
> + struct eic7700_sata_phy *sata_phy;
> + struct phy_provider *phy_provider;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + void __iomem *regs;
> +
> + sata_phy = devm_kzalloc(dev, sizeof(*sata_phy), GFP_KERNEL);
> + if (!sata_phy)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENOENT;
> +
> + regs = devm_ioremap(dev, res->start, resource_size(res));
> + if (IS_ERR(regs))
> + return PTR_ERR(regs);
devm_platform_get_and_ioremap_resource() please
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 5/7] i2c: omap: switch to new generic helper for getting selected mux-state
From: Wolfram Sang @ 2026-01-14 11:52 UTC (permalink / raw)
To: Josua Mayer
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Kishon Vijay Abraham I, Peter Rosin,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Vignesh R, Janusz Krzysztofik, Andi Shyti,
Neil Armstrong, Mikhail Anikin, Yazan Shhady, Jon Nettleton,
linux-mmc, devicetree, linux-kernel, linux-renesas-soc, linux-can,
linux-phy, linux-omap, linux-i2c
In-Reply-To: <20251229-rz-sdio-mux-v4-5-a023e55758fe@solid-run.com>
On Mon, Dec 29, 2025 at 03:27:29PM +0100, Josua Mayer wrote:
> Multiplexer subsystem has added generic helper functions for getting an
> already selected mux-state object.
>
> Replace existing logic in probe with the equivalent helper function.
>
> This change is only compile-tested.
>
> Reviewed-by: Andreas Kemnade <andreas@kemnade.info>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
Despite the pending discussion about the function name, it is clear that
the final patch will not go via i2c but some other tree. So, already:
Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v4 7/7] mmc: host: renesas_sdhi_core: support selecting an optional mux
From: Wolfram Sang @ 2026-01-14 11:49 UTC (permalink / raw)
To: Josua Mayer
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Marc Kleine-Budde,
Vincent Mailhol, Vinod Koul, Kishon Vijay Abraham I, Peter Rosin,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, Vignesh R, Janusz Krzysztofik, Andi Shyti,
Neil Armstrong, Mikhail Anikin, Yazan Shhady, Jon Nettleton,
linux-mmc, devicetree, linux-kernel, linux-renesas-soc, linux-can,
linux-phy, linux-omap, linux-i2c
In-Reply-To: <20251229-rz-sdio-mux-v4-7-a023e55758fe@solid-run.com>
Hi Josua,
thanks for your work and kudos for striving for a generic solution. It
seems worthwhile to me to add the helpers. I have questions, though:
> + priv->mux_state = devm_mux_state_get_optional_selected(&pdev->dev, NULL);
The minor nit (which may be bike-shedding): Maybe the function name
could be '*_select' instead of '*_selected'. To make more explicit that
this function is actively changing the selection and not passively
retrieving the current state?
The bigger thing is that with devm_* I had the expectation that
deselection is also handled automatically...
> +edselmux:
> + if (priv->mux_state)
> + mux_state_deselect(priv->mux_state);
... so I was a bit surprised to see this manual cleanup. Has it been
discussed if that deselection can also be in the helpers?
Happy hacking,
Wolfram
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 01/11] dt-bindings: phy: renesas: usb3-phy: add r8a77990 support
From: Geert Uytterhoeven @ 2026-01-14 10:22 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski, Magnus Damm,
Neil Armstrong, Rob Herring, Vinod Koul, Yoshihiro Shimoda,
devicetree, linux-phy, linux-renesas-soc
In-Reply-To: <20260101203938.159161-2-marek.vasut+renesas@mailbox.org>
Hi Marek,
On Thu, 1 Jan 2026 at 21:39, Marek Vasut
<marek.vasut+renesas@mailbox.org> wrote:
> This patch adds support for r8a77990 (R-Car E3).
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Thanks for your patch!
> --- a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml
> @@ -20,6 +20,7 @@ properties:
> - renesas,r8a7796-usb3-phy # R-Car M3-W
> - renesas,r8a77961-usb3-phy # R-Car M3-W+
> - renesas,r8a77965-usb3-phy # R-Car M3-N
> + - renesas,r8a77990-usb3-phy # R-Car E3
> - const: renesas,rcar-gen3-usb3-phy
>
> reg:
According to Section 76.1.3.5 ("PHY Register Configuration"), the
USB3.0 PHY register block is only present on R-Car H3, M3-W, M3-W+,
and M3-N, but not on R-Car E3?
Likewise, Figure 76.1 ("Clock Distribution [R-Car H3, H3-N, M3-W,
M3-W+, M3-N]") does not cover R-Car E3. Unfortunately there is no
separate picture for R-Car E3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 05/10] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
From: Andy Shevchenko @ 2026-01-14 10:09 UTC (permalink / raw)
To: Konrad Dybcio
Cc: AngeloGioacchino Del Regno, jic23, dlechner, nuno.sa, andy, arnd,
gregkh, srini, vkoul, neil.armstrong, sre, sboyd, krzk,
dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
ivo.ivanov.ivanov1, abelvesa, luca.weiss, mitltlatltl,
krishna.kurapati, linux-arm-msm, linux-iio, linux-kernel,
linux-phy, linux-pm, kernel
In-Reply-To: <dd877ea8-b634-4cc9-8280-08663f82776d@oss.qualcomm.com>
On Wed, Jan 14, 2026 at 11:04:30AM +0100, Konrad Dybcio wrote:
> On 1/14/26 10:55 AM, Andy Shevchenko wrote:
> > On Wed, Jan 14, 2026 at 10:47:20AM +0100, Konrad Dybcio wrote:
> >> On 1/14/26 10:42 AM, Andy Shevchenko wrote:
> >>> On Wed, Jan 14, 2026 at 10:09:45AM +0100, AngeloGioacchino Del Regno wrote:
> >>>> Il 14/01/26 10:07, Andy Shevchenko ha scritto:
> >>>>> On Wed, Jan 14, 2026 at 10:03:57AM +0100, AngeloGioacchino Del Regno wrote:
> >>>>>> Il 14/01/26 10:00, Andy Shevchenko ha scritto:
> >>>>>>> On Wed, Jan 14, 2026 at 09:59:40AM +0100, AngeloGioacchino Del Regno wrote:
> >>>>>>>> Il 14/01/26 09:56, Andy Shevchenko ha scritto:
> >>>>>>>>> On Wed, Jan 14, 2026 at 09:39:52AM +0100, AngeloGioacchino Del Regno wrote:
...
> >>>>>>>>>> + struct regmap_config sdam_regmap_config = {
> >>>>>>>>>> + .reg_bits = 16,
> >>>>>>>>>> + .val_bits = 8,
> >>>>>>>>>
> >>>>>>>>>> + .max_register = 0x100,
> >>>>>>>>>
> >>>>>>>>> Are you sure? This might be a bad naming, but here max == the last accessible.
> >>>>>>>>> I bet it has to be 0xff (but since the address is 16-bit it might be actually
> >>>>>>>>> 257 registers, but sounds very weird).
> >>>>>>>>
> >>>>>>>> Yes, I'm sure.
> >>>>>>>
> >>>>>>> So, what is resided on address 0x100 ?
> >>>>>>
> >>>>>> I don't remember, this is research from around 5 months ago, when I've sent
> >>>>>> the v1 of this.
> >>>>>>
> >>>>>> If you really want though, I can incorrectly set max_register to 0xff.
> >>>>>
> >>>>> Why incorrectly? Can you dig into the datasheet and check, please? We don't
> >>>>> know what is the 0x100 address means.
> >>>>
> >>>> I don't have any datasheets for Qualcomm IPs.
> >>>
> >>> Hmm... Can we have somebody from QC to check on this?
> >>> Perhaps Dmitry?
> >>
> >> 0xe6 is the last usable register today
> >
> > Thanks for checking!
> >
> >> But I wouldn't mind either 0xff or 0x100 because I don't want
> >> anyone to pull their hair out if a regmap access is dropped some day..
> >
> > There is actually about the exact window size where registers are belong to the
> > same entity (subdevice). As in the HW world most of the things are stuck with
> > power-of-two numbers, and taking into account the naming of the field, I do not
> > believe one provides a 257 (256 + 1 = 2⁸ + 1) register _windows_ ("s" is also
> > important here, as it points out to the pattern) for the subdevices. I bet the
> > 0xff, i.e. 256, is the *correct* window from the HW perspective.
>
> Right, [0x100n, 0x100n + 0xff] inclusive is the reserved register window
> for all Qualcomm PMIC peripherals, so I guess 0xff is the correct choice
> here
Thanks for the clarification, v8 addresses that, so seems to me good to go.
> If a peripheral is more complex, it's split into a couple of these
> same-sized blocks
Right.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 05/10] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
From: Konrad Dybcio @ 2026-01-14 10:04 UTC (permalink / raw)
To: Andy Shevchenko
Cc: AngeloGioacchino Del Regno, jic23, dlechner, nuno.sa, andy, arnd,
gregkh, srini, vkoul, neil.armstrong, sre, sboyd, krzk,
dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
ivo.ivanov.ivanov1, abelvesa, luca.weiss, mitltlatltl,
krishna.kurapati, linux-arm-msm, linux-iio, linux-kernel,
linux-phy, linux-pm, kernel
In-Reply-To: <aWdn_j7SOKq97vpY@smile.fi.intel.com>
On 1/14/26 10:55 AM, Andy Shevchenko wrote:
> On Wed, Jan 14, 2026 at 10:47:20AM +0100, Konrad Dybcio wrote:
>> On 1/14/26 10:42 AM, Andy Shevchenko wrote:
>>> On Wed, Jan 14, 2026 at 10:09:45AM +0100, AngeloGioacchino Del Regno wrote:
>>>> Il 14/01/26 10:07, Andy Shevchenko ha scritto:
>>>>> On Wed, Jan 14, 2026 at 10:03:57AM +0100, AngeloGioacchino Del Regno wrote:
>>>>>> Il 14/01/26 10:00, Andy Shevchenko ha scritto:
>>>>>>> On Wed, Jan 14, 2026 at 09:59:40AM +0100, AngeloGioacchino Del Regno wrote:
>>>>>>>> Il 14/01/26 09:56, Andy Shevchenko ha scritto:
>>>>>>>>> On Wed, Jan 14, 2026 at 09:39:52AM +0100, AngeloGioacchino Del Regno wrote:
>
> ...
>
>>>>>>>>>> + struct regmap_config sdam_regmap_config = {
>>>>>>>>>> + .reg_bits = 16,
>>>>>>>>>> + .val_bits = 8,
>>>>>>>>>
>>>>>>>>>> + .max_register = 0x100,
>>>>>>>>>
>>>>>>>>> Are you sure? This might be a bad naming, but here max == the last accessible.
>>>>>>>>> I bet it has to be 0xff (but since the address is 16-bit it might be actually
>>>>>>>>> 257 registers, but sounds very weird).
>>>>>>>>
>>>>>>>> Yes, I'm sure.
>>>>>>>
>>>>>>> So, what is resided on address 0x100 ?
>>>>>>
>>>>>> I don't remember, this is research from around 5 months ago, when I've sent
>>>>>> the v1 of this.
>>>>>>
>>>>>> If you really want though, I can incorrectly set max_register to 0xff.
>>>>>
>>>>> Why incorrectly? Can you dig into the datasheet and check, please? We don't
>>>>> know what is the 0x100 address means.
>>>>
>>>> I don't have any datasheets for Qualcomm IPs.
>>>
>>> Hmm... Can we have somebody from QC to check on this?
>>> Perhaps Dmitry?
>>
>> 0xe6 is the last usable register today
>
> Thanks for checking!
>
>> But I wouldn't mind either 0xff or 0x100 because I don't want
>> anyone to pull their hair out if a regmap access is dropped some day..
>
> There is actually about the exact window size where registers are belong to the
> same entity (subdevice). As in the HW world most of the things are stuck with
> power-of-two numbers, and taking into account the naming of the field, I do not
> believe one provides a 257 (256 + 1 = 2⁸ + 1) register _windows_ ("s" is also
> important here, as it points out to the pattern) for the subdevices. I bet the
> 0xff, i.e. 256, is the *correct* window from the HW perspective.
Right, [0x100n, 0x100n + 0xff] inclusive is the reserved register window
for all Qualcomm PMIC peripherals, so I guess 0xff is the correct choice
here
If a peripheral is more complex, it's split into a couple of these
same-sized blocks
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 05/10] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
From: Andy Shevchenko @ 2026-01-14 9:58 UTC (permalink / raw)
To: Konrad Dybcio
Cc: AngeloGioacchino Del Regno, jic23, dlechner, nuno.sa, andy, arnd,
gregkh, srini, vkoul, neil.armstrong, sre, sboyd, krzk,
dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
ivo.ivanov.ivanov1, abelvesa, luca.weiss, mitltlatltl,
krishna.kurapati, linux-arm-msm, linux-iio, linux-kernel,
linux-phy, linux-pm, kernel
In-Reply-To: <aWdn_j7SOKq97vpY@smile.fi.intel.com>
On Wed, Jan 14, 2026 at 11:55:18AM +0200, Andy Shevchenko wrote:
> On Wed, Jan 14, 2026 at 10:47:20AM +0100, Konrad Dybcio wrote:
> > On 1/14/26 10:42 AM, Andy Shevchenko wrote:
> > > On Wed, Jan 14, 2026 at 10:09:45AM +0100, AngeloGioacchino Del Regno wrote:
> > >> Il 14/01/26 10:07, Andy Shevchenko ha scritto:
> > >>> On Wed, Jan 14, 2026 at 10:03:57AM +0100, AngeloGioacchino Del Regno wrote:
> > >>>> Il 14/01/26 10:00, Andy Shevchenko ha scritto:
> > >>>>> On Wed, Jan 14, 2026 at 09:59:40AM +0100, AngeloGioacchino Del Regno wrote:
> > >>>>>> Il 14/01/26 09:56, Andy Shevchenko ha scritto:
> > >>>>>>> On Wed, Jan 14, 2026 at 09:39:52AM +0100, AngeloGioacchino Del Regno wrote:
...
> > >>>>>>>> + struct regmap_config sdam_regmap_config = {
> > >>>>>>>> + .reg_bits = 16,
> > >>>>>>>> + .val_bits = 8,
> > >>>>>>>
> > >>>>>>>> + .max_register = 0x100,
> > >>>>>>>
> > >>>>>>> Are you sure? This might be a bad naming, but here max == the last accessible.
> > >>>>>>> I bet it has to be 0xff (but since the address is 16-bit it might be actually
> > >>>>>>> 257 registers, but sounds very weird).
> > >>>>>>
> > >>>>>> Yes, I'm sure.
> > >>>>>
> > >>>>> So, what is resided on address 0x100 ?
> > >>>>
> > >>>> I don't remember, this is research from around 5 months ago, when I've sent
> > >>>> the v1 of this.
> > >>>>
> > >>>> If you really want though, I can incorrectly set max_register to 0xff.
> > >>>
> > >>> Why incorrectly? Can you dig into the datasheet and check, please? We don't
> > >>> know what is the 0x100 address means.
> > >>
> > >> I don't have any datasheets for Qualcomm IPs.
> > >
> > > Hmm... Can we have somebody from QC to check on this?
> > > Perhaps Dmitry?
> >
> > 0xe6 is the last usable register today
>
> Thanks for checking!
>
> > But I wouldn't mind either 0xff or 0x100 because I don't want
> > anyone to pull their hair out if a regmap access is dropped some day..
>
> There is actually about the exact window size where registers are belong to the
> same entity (subdevice). As in the HW world most of the things are stuck with
> power-of-two numbers, and taking into account the naming of the field, I do not
> believe one provides a 257 (256 + 1 = 2⁸ + 1) register _windows_ ("s" is also
> important here, as it points out to the pattern) for the subdevices. I bet the
> 0xff, i.e. 256, is the *correct* window from the HW perspective.
Even more, since these devices are described in DT, the presence of any two
sequential windows will support my version for 100% correctness, as otherwise
it will mean overlapping in the addresses for two devices, i.e. 0x100 in one
is actually 0x00 in the other.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 05/10] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
From: Andy Shevchenko @ 2026-01-14 9:55 UTC (permalink / raw)
To: Konrad Dybcio
Cc: AngeloGioacchino Del Regno, jic23, dlechner, nuno.sa, andy, arnd,
gregkh, srini, vkoul, neil.armstrong, sre, sboyd, krzk,
dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
ivo.ivanov.ivanov1, abelvesa, luca.weiss, mitltlatltl,
krishna.kurapati, linux-arm-msm, linux-iio, linux-kernel,
linux-phy, linux-pm, kernel
In-Reply-To: <ae46b504-58d3-4042-be05-f31e9e01091b@oss.qualcomm.com>
On Wed, Jan 14, 2026 at 10:47:20AM +0100, Konrad Dybcio wrote:
> On 1/14/26 10:42 AM, Andy Shevchenko wrote:
> > On Wed, Jan 14, 2026 at 10:09:45AM +0100, AngeloGioacchino Del Regno wrote:
> >> Il 14/01/26 10:07, Andy Shevchenko ha scritto:
> >>> On Wed, Jan 14, 2026 at 10:03:57AM +0100, AngeloGioacchino Del Regno wrote:
> >>>> Il 14/01/26 10:00, Andy Shevchenko ha scritto:
> >>>>> On Wed, Jan 14, 2026 at 09:59:40AM +0100, AngeloGioacchino Del Regno wrote:
> >>>>>> Il 14/01/26 09:56, Andy Shevchenko ha scritto:
> >>>>>>> On Wed, Jan 14, 2026 at 09:39:52AM +0100, AngeloGioacchino Del Regno wrote:
...
> >>>>>>>> + struct regmap_config sdam_regmap_config = {
> >>>>>>>> + .reg_bits = 16,
> >>>>>>>> + .val_bits = 8,
> >>>>>>>
> >>>>>>>> + .max_register = 0x100,
> >>>>>>>
> >>>>>>> Are you sure? This might be a bad naming, but here max == the last accessible.
> >>>>>>> I bet it has to be 0xff (but since the address is 16-bit it might be actually
> >>>>>>> 257 registers, but sounds very weird).
> >>>>>>
> >>>>>> Yes, I'm sure.
> >>>>>
> >>>>> So, what is resided on address 0x100 ?
> >>>>
> >>>> I don't remember, this is research from around 5 months ago, when I've sent
> >>>> the v1 of this.
> >>>>
> >>>> If you really want though, I can incorrectly set max_register to 0xff.
> >>>
> >>> Why incorrectly? Can you dig into the datasheet and check, please? We don't
> >>> know what is the 0x100 address means.
> >>
> >> I don't have any datasheets for Qualcomm IPs.
> >
> > Hmm... Can we have somebody from QC to check on this?
> > Perhaps Dmitry?
>
> 0xe6 is the last usable register today
Thanks for checking!
> But I wouldn't mind either 0xff or 0x100 because I don't want
> anyone to pull their hair out if a regmap access is dropped some day..
There is actually about the exact window size where registers are belong to the
same entity (subdevice). As in the HW world most of the things are stuck with
power-of-two numbers, and taking into account the naming of the field, I do not
believe one provides a 257 (256 + 1 = 2⁸ + 1) register _windows_ ("s" is also
important here, as it points out to the pattern) for the subdevices. I bet the
0xff, i.e. 256, is the *correct* window from the HW perspective.
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 05/10] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
From: Konrad Dybcio @ 2026-01-14 9:47 UTC (permalink / raw)
To: Andy Shevchenko, AngeloGioacchino Del Regno
Cc: jic23, dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, sboyd, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, mitltlatltl, krishna.kurapati, linux-arm-msm,
linux-iio, linux-kernel, linux-phy, linux-pm, kernel
In-Reply-To: <aWdk-RP-59cJeCBo@smile.fi.intel.com>
On 1/14/26 10:42 AM, Andy Shevchenko wrote:
> On Wed, Jan 14, 2026 at 10:09:45AM +0100, AngeloGioacchino Del Regno wrote:
>> Il 14/01/26 10:07, Andy Shevchenko ha scritto:
>>> On Wed, Jan 14, 2026 at 10:03:57AM +0100, AngeloGioacchino Del Regno wrote:
>>>> Il 14/01/26 10:00, Andy Shevchenko ha scritto:
>>>>> On Wed, Jan 14, 2026 at 09:59:40AM +0100, AngeloGioacchino Del Regno wrote:
>>>>>> Il 14/01/26 09:56, Andy Shevchenko ha scritto:
>>>>>>> On Wed, Jan 14, 2026 at 09:39:52AM +0100, AngeloGioacchino Del Regno wrote:
>
> ...
>
>>>>>>>> + struct regmap_config sdam_regmap_config = {
>>>>>>>> + .reg_bits = 16,
>>>>>>>> + .val_bits = 8,
>>>>>>>
>>>>>>>> + .max_register = 0x100,
>>>>>>>
>>>>>>> Are you sure? This might be a bad naming, but here max == the last accessible.
>>>>>>> I bet it has to be 0xff (but since the address is 16-bit it might be actually
>>>>>>> 257 registers, but sounds very weird).
>>>>>>
>>>>>> Yes, I'm sure.
>>>>>
>>>>> So, what is resided on address 0x100 ?
>>>>
>>>> I don't remember, this is research from around 5 months ago, when I've sent
>>>> the v1 of this.
>>>>
>>>> If you really want though, I can incorrectly set max_register to 0xff.
>>>
>>> Why incorrectly? Can you dig into the datasheet and check, please? We don't
>>> know what is the 0x100 address means.
>>
>> I don't have any datasheets for Qualcomm IPs.
>
> Hmm... Can we have somebody from QC to check on this?
> Perhaps Dmitry?
0xe6 is the last usable register today
But I wouldn't mind either 0xff or 0x100 because I don't want
anyone to pull their hair out if a regmap access is dropped some day..
Konrad
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 00/10] SPMI: Implement sub-devices and migrate drivers
From: Andy Shevchenko @ 2026-01-14 9:46 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: jic23, dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, sboyd, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, konrad.dybcio, mitltlatltl, krishna.kurapati,
linux-arm-msm, linux-iio, linux-kernel, linux-phy, linux-pm,
kernel
In-Reply-To: <aWdlSlI85ro7SbJv@smile.fi.intel.com>
On Wed, Jan 14, 2026 at 11:43:38AM +0200, Andy Shevchenko wrote:
> On Wed, Jan 14, 2026 at 10:27:32AM +0100, AngeloGioacchino Del Regno wrote:
> > Changes in v8:
> > - Renamed *res to *sub_sdev in devm_spmi_subdevice_remove() (Andy)
> > - Changed kerneldoc wording to "error pointer" for function
> > spmi_subdevice_alloc_and_add() (Andy)
> > - Shuffled around some assignments in spmi_subdevice_alloc_and_add() (Andy)
> > - Used device_property_read_u32() instead of of_property_read_u32()
> > in all of the migrated drivers (Andy)
> > - Changed .max_register field in all of the migrated drivers from
> > 0x100 to 0xff (Andy)
> > - Kept `sta1` declaration in reversed xmas tree order in function
> > iadc_poll_wait_eoc() of qcom-spmi-iadc.c (Andy)
>
> Thanks, in principle I'm okay with this version, but it would be nice to have
> clarification on the max_register for sure (it doesn't prevent the series from
> being applied).
And FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v8 00/10] SPMI: Implement sub-devices and migrate drivers
From: Andy Shevchenko @ 2026-01-14 9:43 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: jic23, dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, sboyd, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, konrad.dybcio, mitltlatltl, krishna.kurapati,
linux-arm-msm, linux-iio, linux-kernel, linux-phy, linux-pm,
kernel
In-Reply-To: <20260114092742.13231-1-angelogioacchino.delregno@collabora.com>
On Wed, Jan 14, 2026 at 10:27:32AM +0100, AngeloGioacchino Del Regno wrote:
> Changes in v8:
> - Renamed *res to *sub_sdev in devm_spmi_subdevice_remove() (Andy)
> - Changed kerneldoc wording to "error pointer" for function
> spmi_subdevice_alloc_and_add() (Andy)
> - Shuffled around some assignments in spmi_subdevice_alloc_and_add() (Andy)
> - Used device_property_read_u32() instead of of_property_read_u32()
> in all of the migrated drivers (Andy)
> - Changed .max_register field in all of the migrated drivers from
> 0x100 to 0xff (Andy)
> - Kept `sta1` declaration in reversed xmas tree order in function
> iadc_poll_wait_eoc() of qcom-spmi-iadc.c (Andy)
Thanks, in principle I'm okay with this version, but it would be nice to have
clarification on the max_register for sure (it doesn't prevent the series from
being applied).
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 05/10] nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
From: Andy Shevchenko @ 2026-01-14 9:42 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: jic23, dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, sboyd, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, konrad.dybcio, mitltlatltl, krishna.kurapati,
linux-arm-msm, linux-iio, linux-kernel, linux-phy, linux-pm,
kernel
In-Reply-To: <647b4acc-3310-4329-ac7a-77e86bab74a3@collabora.com>
On Wed, Jan 14, 2026 at 10:09:45AM +0100, AngeloGioacchino Del Regno wrote:
> Il 14/01/26 10:07, Andy Shevchenko ha scritto:
> > On Wed, Jan 14, 2026 at 10:03:57AM +0100, AngeloGioacchino Del Regno wrote:
> > > Il 14/01/26 10:00, Andy Shevchenko ha scritto:
> > > > On Wed, Jan 14, 2026 at 09:59:40AM +0100, AngeloGioacchino Del Regno wrote:
> > > > > Il 14/01/26 09:56, Andy Shevchenko ha scritto:
> > > > > > On Wed, Jan 14, 2026 at 09:39:52AM +0100, AngeloGioacchino Del Regno wrote:
...
> > > > > > > + struct regmap_config sdam_regmap_config = {
> > > > > > > + .reg_bits = 16,
> > > > > > > + .val_bits = 8,
> > > > > >
> > > > > > > + .max_register = 0x100,
> > > > > >
> > > > > > Are you sure? This might be a bad naming, but here max == the last accessible.
> > > > > > I bet it has to be 0xff (but since the address is 16-bit it might be actually
> > > > > > 257 registers, but sounds very weird).
> > > > >
> > > > > Yes, I'm sure.
> > > >
> > > > So, what is resided on address 0x100 ?
> > >
> > > I don't remember, this is research from around 5 months ago, when I've sent
> > > the v1 of this.
> > >
> > > If you really want though, I can incorrectly set max_register to 0xff.
> >
> > Why incorrectly? Can you dig into the datasheet and check, please? We don't
> > know what is the 0x100 address means.
>
> I don't have any datasheets for Qualcomm IPs.
Hmm... Can we have somebody from QC to check on this?
Perhaps Dmitry?
> > > > > > > + .fast_io = true,
> > > > > > > + };
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v7 07/10] phy: qualcomm: eusb2-repeater: Migrate to devm_spmi_subdevice_alloc_and_add()
From: Andy Shevchenko @ 2026-01-14 9:40 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: jic23, dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, sboyd, krzk, dmitry.baryshkov, quic_wcheng,
melody.olvera, quic_nsekar, ivo.ivanov.ivanov1, abelvesa,
luca.weiss, konrad.dybcio, mitltlatltl, krishna.kurapati,
linux-arm-msm, linux-iio, linux-kernel, linux-phy, linux-pm,
kernel, Abel Vesa
In-Reply-To: <8f5c79e0-5f7e-4fe4-b9d7-60375e779892@collabora.com>
On Wed, Jan 14, 2026 at 10:26:42AM +0100, AngeloGioacchino Del Regno wrote:
> Il 14/01/26 09:59, Andy Shevchenko ha scritto:
> > On Wed, Jan 14, 2026 at 09:39:54AM +0100, AngeloGioacchino Del Regno wrote:
...
> > > + struct regmap_config eusb2_regmap_config = {
> > > + .reg_bits = 16,
> > > + .val_bits = 8,
> > > + .max_register = 0x100,
> > > + .fast_io = true,
> > > + };
> >
> > This is third time of the same. Make it part of SPMI core and export to
> > the users. Or are they semantically different like different slices?
> > In that case you can export it under generic name like
> >
> > spmi_default_slice_regmap_config
>
> There are more complicated devices around that I didn't port to the new
> spmi subdevices, and I really don't want to make a default for now.
>
> At least some of those need different params (including some MediaTek ones
> that are not upstream yet).
>
> Can we please let this in and *then* see how much can be commonized after
> the majority of more complicated drivers are migrated in the future?
Sure, but it looks like a pattern currently...
--
With Best Regards,
Andy Shevchenko
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH v3] phy: fsl-imx8mq-usb: add debugfs to access control register
From: Vinod Koul @ 2026-01-14 9:39 UTC (permalink / raw)
To: Andrew Lunn
Cc: Xu Yang, neil.armstrong, shawnguo, kernel, festevam, jun.li,
Frank.Li, linux-phy, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <c1425564-9dca-45dc-ac5e-093150a3ff01@lunn.ch>
On 08-01-26, 19:24, Andrew Lunn wrote:
> On Thu, Jan 08, 2026 at 04:36:41PM +0800, Xu Yang wrote:
> > The CR port is a simple 16-bit data/address parallel port that is
> > provided for on-chip access to the control registers inside the
> > USB 3.0 femtoPHY[1]. While access to these registers is not required
> > for normal PHY operation, this interface enables you to access
> > some of the PHY’s diagnostic features during normal operation or
> > to override some basic PHY control signals.
> >
> > 3 debugfs files are created to read and write control registers,
> > all use hexadecimal format:
> > ctrl_reg_base: the register offset to write, or the start offset
> > to read.
> > ctrl_reg_count: how many continuous registers to be read.
> > ctrl_reg_value: read to show the continuous registers value from
> > the offset in ctrl_reg_base, to ctrl_reg_base
> > + ctrl_reg_count - 1, one line for one register.
> > when write, override the register at ctrl_reg_base,
> > one time can only change one 16bits register.
> >
> > Link[1]: https://www.synopsys.com/dw/doc.php/phy/usb3.0/femto/phy/x652_usb3_ss14lpp_18_ns/4.07a/dwc_usb3.0_femtophy_ss14lpp_08V18V_x1_databook.pdf
>
> Please don't ignore my comments to V2. Think about the code split
> between the generic IP licensed from Synopsys and the vendor specific
> code used for integration into the SoC. You want to avoid making a
> mess you later need to cleanup because somebody else licensed the same
> IP core from Synopsys, and need to put their own vendor specific
> integration code around the generic code.
Agree with Andrew here, please do mix, splitting would be better
>
> Andrew
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* Re: [PATCH 1/5] phy: qcom: qmp-pcie: Skip PHY reset if already up
From: Vinod Koul @ 2026-01-14 9:36 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Krishna Chaitanya Chundru, Philipp Zabel,
Jingoo Han, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas,
linux-arm-msm, linux-phy, linux-kernel, linux-pci
In-Reply-To: <cvxvq7f2ku6aq5gbbqav42ckqk2raesbxq2bx46mxvapcza5v4@5zuyjdtn5us2>
On 09-01-26, 16:03, Dmitry Baryshkov wrote:
> On Fri, Jan 09, 2026 at 02:10:49PM +0100, Neil Armstrong wrote:
> > On 1/9/26 14:08, Dmitry Baryshkov wrote:
> > > On Fri, Jan 09, 2026 at 12:51:06PM +0530, Krishna Chaitanya Chundru wrote:
> > > > If the bootloader has already powered up the PCIe PHY, doing a full
> > > > reset and waiting for it to come up again slows down boot time.
> > >
> > > How big is the delay caused by it?
> > >
> > > >
> > > > Add a check for PHY status and skip the reset steps when the PHY is
> > > > already active. In this case, only enable the required resources during
> > > > power-on. This works alongside the existing logic that skips the init
> > > > sequence.
> > >
> > > Can we end up in a state where the bootloader has mis-setup the link? Or
> > > the link going bad because of any glitch during the bootup?
> >
> > Good question, can we add a module parameter to force a full reset of the PHY in case
> > the bootloader is buggy ?
>
> I'd suggest a simpler thing: if the reset was skipped, reset the PHY in
> case of an error and retry. That's also one of the reasons why I asked
> for skip_reset not to be the persistent value.
That is a better suggestion. Helps skips if it is configured and way to
recover if buggy
--
~Vinod
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply
* [PATCH v8 10/10] iio: adc: qcom-spmi-iadc: Remove regmap R/W wrapper functions
From: AngeloGioacchino Del Regno @ 2026-01-14 9:27 UTC (permalink / raw)
To: jic23
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, sboyd, angelogioacchino.delregno, krzk,
dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
ivo.ivanov.ivanov1, abelvesa, luca.weiss, konrad.dybcio,
mitltlatltl, krishna.kurapati, linux-arm-msm, linux-iio,
linux-kernel, linux-phy, linux-pm, kernel, Jonathan Cameron
In-Reply-To: <20260114092742.13231-1-angelogioacchino.delregno@collabora.com>
This driver doesn't need to add any register base address to any
regmap call anymore since it was migrated to register as a SPMI
subdevice with its own regmap reg_base, which makes the regmap
API to automatically add such base address internally.
Since the iadc_{read,write,read_result}() functions now only do
call regmap_{read,write,bulk_read}() and nothing else, simplify
the driver by removing them and by calling regmap APIs directly.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/iio/adc/qcom-spmi-iadc.c | 83 ++++++++++++--------------------
1 file changed, 30 insertions(+), 53 deletions(-)
diff --git a/drivers/iio/adc/qcom-spmi-iadc.c b/drivers/iio/adc/qcom-spmi-iadc.c
index 55a09c0e2d5c..503f90b2a5ba 100644
--- a/drivers/iio/adc/qcom-spmi-iadc.c
+++ b/drivers/iio/adc/qcom-spmi-iadc.c
@@ -113,77 +113,59 @@ struct iadc_chip {
struct completion complete;
};
-static int iadc_read(struct iadc_chip *iadc, u16 offset, u8 *data)
-{
- unsigned int val;
- int ret;
-
- ret = regmap_read(iadc->regmap, offset, &val);
- if (ret < 0)
- return ret;
-
- *data = val;
- return 0;
-}
-
-static int iadc_write(struct iadc_chip *iadc, u16 offset, u8 data)
-{
- return regmap_write(iadc->regmap, offset, data);
-}
-
static int iadc_reset(struct iadc_chip *iadc)
{
- u8 data;
+ u32 data;
int ret;
- ret = iadc_write(iadc, IADC_SEC_ACCESS, IADC_SEC_ACCESS_DATA);
+ ret = regmap_write(iadc->regmap, IADC_SEC_ACCESS, IADC_SEC_ACCESS_DATA);
if (ret < 0)
return ret;
- ret = iadc_read(iadc, IADC_PERH_RESET_CTL3, &data);
+ ret = regmap_read(iadc->regmap, IADC_PERH_RESET_CTL3, &data);
if (ret < 0)
return ret;
- ret = iadc_write(iadc, IADC_SEC_ACCESS, IADC_SEC_ACCESS_DATA);
+ ret = regmap_write(iadc->regmap, IADC_SEC_ACCESS, IADC_SEC_ACCESS_DATA);
if (ret < 0)
return ret;
data |= IADC_FOLLOW_WARM_RB;
- return iadc_write(iadc, IADC_PERH_RESET_CTL3, data);
+ return regmap_write(iadc->regmap, IADC_PERH_RESET_CTL3, data);
}
static int iadc_set_state(struct iadc_chip *iadc, bool state)
{
- return iadc_write(iadc, IADC_EN_CTL1, state ? IADC_EN_CTL1_SET : 0);
+ return regmap_write(iadc->regmap, IADC_EN_CTL1, state ? IADC_EN_CTL1_SET : 0);
}
static void iadc_status_show(struct iadc_chip *iadc)
{
- u8 mode, sta1, chan, dig, en, req;
+ u32 mode, sta1, chan, dig, en, req;
int ret;
- ret = iadc_read(iadc, IADC_MODE_CTL, &mode);
+ ret = regmap_read(iadc->regmap, IADC_MODE_CTL, &mode);
if (ret < 0)
return;
- ret = iadc_read(iadc, IADC_DIG_PARAM, &dig);
+ ret = regmap_read(iadc->regmap, IADC_DIG_PARAM, &dig);
if (ret < 0)
return;
- ret = iadc_read(iadc, IADC_CH_SEL_CTL, &chan);
+ ret = regmap_read(iadc->regmap, IADC_CH_SEL_CTL, &chan);
if (ret < 0)
return;
- ret = iadc_read(iadc, IADC_CONV_REQ, &req);
+ ret = regmap_read(iadc->regmap, IADC_CONV_REQ, &req);
if (ret < 0)
return;
- ret = iadc_read(iadc, IADC_STATUS1, &sta1);
+ ret = regmap_read(iadc->regmap, IADC_STATUS1, &sta1);
if (ret < 0)
return;
- ret = iadc_read(iadc, IADC_EN_CTL1, &en);
+ ret = regmap_read(iadc->regmap, IADC_EN_CTL1, &en);
if (ret < 0)
return;
@@ -199,34 +181,34 @@ static int iadc_configure(struct iadc_chip *iadc, int channel)
/* Mode selection */
mode = (IADC_OP_MODE_NORMAL << IADC_OP_MODE_SHIFT) | IADC_TRIM_EN;
- ret = iadc_write(iadc, IADC_MODE_CTL, mode);
+ ret = regmap_write(iadc->regmap, IADC_MODE_CTL, mode);
if (ret < 0)
return ret;
/* Channel selection */
- ret = iadc_write(iadc, IADC_CH_SEL_CTL, channel);
+ ret = regmap_write(iadc->regmap, IADC_CH_SEL_CTL, channel);
if (ret < 0)
return ret;
/* Digital parameter setup */
decim = IADC_DEF_DECIMATION << IADC_DIG_DEC_RATIO_SEL_SHIFT;
- ret = iadc_write(iadc, IADC_DIG_PARAM, decim);
+ ret = regmap_write(iadc->regmap, IADC_DIG_PARAM, decim);
if (ret < 0)
return ret;
/* HW settle time delay */
- ret = iadc_write(iadc, IADC_HW_SETTLE_DELAY, IADC_DEF_HW_SETTLE_TIME);
+ ret = regmap_write(iadc->regmap, IADC_HW_SETTLE_DELAY, IADC_DEF_HW_SETTLE_TIME);
if (ret < 0)
return ret;
- ret = iadc_write(iadc, IADC_FAST_AVG_CTL, IADC_DEF_AVG_SAMPLES);
+ ret = regmap_write(iadc->regmap, IADC_FAST_AVG_CTL, IADC_DEF_AVG_SAMPLES);
if (ret < 0)
return ret;
if (IADC_DEF_AVG_SAMPLES)
- ret = iadc_write(iadc, IADC_FAST_AVG_EN, IADC_FAST_AVG_EN_SET);
+ ret = regmap_write(iadc->regmap, IADC_FAST_AVG_EN, IADC_FAST_AVG_EN_SET);
else
- ret = iadc_write(iadc, IADC_FAST_AVG_EN, 0);
+ ret = regmap_write(iadc->regmap, IADC_FAST_AVG_EN, 0);
if (ret < 0)
return ret;
@@ -239,19 +221,19 @@ static int iadc_configure(struct iadc_chip *iadc, int channel)
return ret;
/* Request conversion */
- return iadc_write(iadc, IADC_CONV_REQ, IADC_CONV_REQ_SET);
+ return regmap_write(iadc->regmap, IADC_CONV_REQ, IADC_CONV_REQ_SET);
}
static int iadc_poll_wait_eoc(struct iadc_chip *iadc, unsigned int interval_us)
{
unsigned int count, retry;
+ u32 sta1;
int ret;
- u8 sta1;
retry = interval_us / IADC_CONV_TIME_MIN_US;
for (count = 0; count < retry; count++) {
- ret = iadc_read(iadc, IADC_STATUS1, &sta1);
+ ret = regmap_read(iadc->regmap, IADC_STATUS1, &sta1);
if (ret < 0)
return ret;
@@ -267,11 +249,6 @@ static int iadc_poll_wait_eoc(struct iadc_chip *iadc, unsigned int interval_us)
return -ETIMEDOUT;
}
-static int iadc_read_result(struct iadc_chip *iadc, u16 *data)
-{
- return regmap_bulk_read(iadc->regmap, IADC_DATA, data, 2);
-}
-
static int iadc_do_conversion(struct iadc_chip *iadc, int chan, u16 *data)
{
unsigned int wait;
@@ -296,7 +273,7 @@ static int iadc_do_conversion(struct iadc_chip *iadc, int chan, u16 *data)
}
if (!ret)
- ret = iadc_read_result(iadc, data);
+ ret = regmap_bulk_read(iadc->regmap, IADC_DATA, data, sizeof(*data));
exit:
iadc_set_state(iadc, false);
if (ret < 0)
@@ -392,10 +369,10 @@ static int iadc_update_offset(struct iadc_chip *iadc)
static int iadc_version_check(struct iadc_chip *iadc)
{
- u8 val;
+ u32 val;
int ret;
- ret = iadc_read(iadc, IADC_PERPH_TYPE, &val);
+ ret = regmap_read(iadc->regmap, IADC_PERPH_TYPE, &val);
if (ret < 0)
return ret;
@@ -404,7 +381,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
return -EINVAL;
}
- ret = iadc_read(iadc, IADC_PERPH_SUBTYPE, &val);
+ ret = regmap_read(iadc->regmap, IADC_PERPH_SUBTYPE, &val);
if (ret < 0)
return ret;
@@ -413,7 +390,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
return -EINVAL;
}
- ret = iadc_read(iadc, IADC_REVISION2, &val);
+ ret = regmap_read(iadc->regmap, IADC_REVISION2, &val);
if (ret < 0)
return ret;
@@ -428,7 +405,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
static int iadc_rsense_read(struct iadc_chip *iadc, struct device_node *node)
{
int ret, sign, int_sense;
- u8 deviation;
+ u32 deviation;
ret = of_property_read_u32(node, "qcom,external-resistor-micro-ohms",
&iadc->rsense[IADC_EXT_RSENSE]);
@@ -440,7 +417,7 @@ static int iadc_rsense_read(struct iadc_chip *iadc, struct device_node *node)
return -EINVAL;
}
- ret = iadc_read(iadc, IADC_NOMINAL_RSENSE, &deviation);
+ ret = regmap_read(iadc->regmap, IADC_NOMINAL_RSENSE, &deviation);
if (ret < 0)
return ret;
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
* [PATCH v8 09/10] iio: adc: qcom-spmi-iadc: Migrate to devm_spmi_subdevice_alloc_and_add()
From: AngeloGioacchino Del Regno @ 2026-01-14 9:27 UTC (permalink / raw)
To: jic23
Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
neil.armstrong, sre, sboyd, angelogioacchino.delregno, krzk,
dmitry.baryshkov, quic_wcheng, melody.olvera, quic_nsekar,
ivo.ivanov.ivanov1, abelvesa, luca.weiss, konrad.dybcio,
mitltlatltl, krishna.kurapati, linux-arm-msm, linux-iio,
linux-kernel, linux-phy, linux-pm, kernel, Jonathan Cameron
In-Reply-To: <20260114092742.13231-1-angelogioacchino.delregno@collabora.com>
Some Qualcomm PMICs integrate an Current ADC device, reachable
in a specific address range over SPMI.
Instead of using the parent SPMI device (the main PMIC) as a kind
of syscon in this driver, register a new SPMI sub-device and
initialize its own regmap with this sub-device's specific base
address, retrieved from the devicetree.
This allows to stop manually adding the register base address to
every R/W call in this driver, as this can be, and is now, handled
by the regmap API instead.
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/iio/adc/qcom-spmi-iadc.c | 32 +++++++++++++++++++++-----------
1 file changed, 21 insertions(+), 11 deletions(-)
diff --git a/drivers/iio/adc/qcom-spmi-iadc.c b/drivers/iio/adc/qcom-spmi-iadc.c
index b64a8a407168..55a09c0e2d5c 100644
--- a/drivers/iio/adc/qcom-spmi-iadc.c
+++ b/drivers/iio/adc/qcom-spmi-iadc.c
@@ -16,6 +16,7 @@
#include <linux/platform_device.h>
#include <linux/regmap.h>
#include <linux/slab.h>
+#include <linux/spmi.h>
/* IADC register and bit definition */
#define IADC_REVISION2 0x1
@@ -94,7 +95,6 @@
* struct iadc_chip - IADC Current ADC device structure.
* @regmap: regmap for register read/write.
* @dev: This device pointer.
- * @base: base offset for the ADC peripheral.
* @rsense: Values of the internal and external sense resister in micro Ohms.
* @poll_eoc: Poll for end of conversion instead of waiting for IRQ.
* @offset: Raw offset values for the internal and external channels.
@@ -105,7 +105,6 @@
struct iadc_chip {
struct regmap *regmap;
struct device *dev;
- u16 base;
bool poll_eoc;
u32 rsense[2];
u16 offset[2];
@@ -119,7 +118,7 @@ static int iadc_read(struct iadc_chip *iadc, u16 offset, u8 *data)
unsigned int val;
int ret;
- ret = regmap_read(iadc->regmap, iadc->base + offset, &val);
+ ret = regmap_read(iadc->regmap, offset, &val);
if (ret < 0)
return ret;
@@ -129,7 +128,7 @@ static int iadc_read(struct iadc_chip *iadc, u16 offset, u8 *data)
static int iadc_write(struct iadc_chip *iadc, u16 offset, u8 data)
{
- return regmap_write(iadc->regmap, iadc->base + offset, data);
+ return regmap_write(iadc->regmap, offset, data);
}
static int iadc_reset(struct iadc_chip *iadc)
@@ -270,7 +269,7 @@ static int iadc_poll_wait_eoc(struct iadc_chip *iadc, unsigned int interval_us)
static int iadc_read_result(struct iadc_chip *iadc, u16 *data)
{
- return regmap_bulk_read(iadc->regmap, iadc->base + IADC_DATA, data, 2);
+ return regmap_bulk_read(iadc->regmap, IADC_DATA, data, 2);
}
static int iadc_do_conversion(struct iadc_chip *iadc, int chan, u16 *data)
@@ -483,12 +482,19 @@ static const struct iio_chan_spec iadc_channels[] = {
static int iadc_probe(struct platform_device *pdev)
{
+ struct regmap_config iadc_regmap_config = {
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = 0xff,
+ .fast_io = true,
+ };
struct device_node *node = pdev->dev.of_node;
struct device *dev = &pdev->dev;
+ struct spmi_subdevice *sub_sdev;
+ struct spmi_device *sparent;
struct iio_dev *indio_dev;
struct iadc_chip *iadc;
int ret, irq_eoc;
- u32 res;
indio_dev = devm_iio_device_alloc(dev, sizeof(*iadc));
if (!indio_dev)
@@ -497,18 +503,21 @@ static int iadc_probe(struct platform_device *pdev)
iadc = iio_priv(indio_dev);
iadc->dev = dev;
- iadc->regmap = dev_get_regmap(dev->parent, NULL);
- if (!iadc->regmap)
- return -ENODEV;
+ sparent = to_spmi_device(dev->parent);
+ sub_sdev = devm_spmi_subdevice_alloc_and_add(dev, sparent);
+ if (IS_ERR(sub_sdev))
+ return PTR_ERR(sub_sdev);
init_completion(&iadc->complete);
mutex_init(&iadc->lock);
- ret = of_property_read_u32(node, "reg", &res);
+ ret = device_property_read_u32(dev, "reg", &iadc_regmap_config.reg_base);
if (ret < 0)
return -ENODEV;
- iadc->base = res;
+ iadc->regmap = devm_regmap_init_spmi_ext(&sub_sdev->sdev, &iadc_regmap_config);
+ if (IS_ERR(iadc->regmap))
+ return PTR_ERR(iadc->regmap);
ret = iadc_version_check(iadc);
if (ret < 0)
@@ -584,3 +593,4 @@ MODULE_ALIAS("platform:qcom-spmi-iadc");
MODULE_DESCRIPTION("Qualcomm SPMI PMIC current ADC driver");
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Ivan T. Ivanov <iivanov@mm-sol.com>");
+MODULE_IMPORT_NS("SPMI");
--
2.52.0
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox