Linux-PHY Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] phy: qualcomm: usb-hs-28nm: use flex array
From: Gustavo A. R. Silva @ 2026-03-05  4:52 UTC (permalink / raw)
  To: Konrad Dybcio, Rosen Penev, linux-phy
  Cc: Vinod Koul, Neil Armstrong, Kees Cook, Gustavo A. R. Silva,
	open list:ARM/QUALCOMM MAILING LIST, open list,
	open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <8d7a25e8-3af6-4adf-bcec-394895519bea@oss.qualcomm.com>

Hi!

On 3/5/26 19:06, Konrad Dybcio wrote:
> On 3/5/26 12:06 AM, Rosen Penev wrote:
>> Allows simplifying allocation to a single kzalloc call.
>>
>> Also allows using __counted_by for extra runtime analysis.
>>
>> Signed-off-by: Rosen Penev <rosenp@gmail.com>
>> ---
> 
> I don't see how this is an improvement - __counted_by() is useful for
> cases where we don't know how many entries there are, but in this
> case it's fully deterministic (as priv->num_clks is a compile-time
> constant)

Will this always be the case in the future (entries being a compile-time
constant)?

Thanks
-Gustavo

> 
> Konrad
> 


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH net-next v2 2/7] net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()
From: Mohd Ayaan Anwar @ 2026-03-05 19:48 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
	Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
	linux-phy, linux-stm32, Neil Armstrong, netdev, Paolo Abeni,
	Vinod Koul
In-Reply-To: <E1vxS44-0000000BQXU-38lG@rmk-PC.armlinux.org.uk>

On Tue, Mar 03, 2026 at 03:53:40PM +0000, Russell King (Oracle) wrote:
> qcom-sgmii-eth now accepts the phy_set_mode*() calls to configure the
> SerDes, taking a PHY interface mode rather than a speed. This allows
> the elimination of the interface mode to speed conversion in
> ethqos_mac_finish_serdes().
> 
> Tested-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Reviewed-by: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>

	Ayaan

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v11 0/9] mmc: host: renesas_sdhi_core: support configuring an optional sdio mux
From: Ulf Hansson @ 2026-03-05 16:19 UTC (permalink / raw)
  To: Josua Mayer, Peter Rosin
  Cc: Marc Kleine-Budde, Vincent Mailhol, Vinod Koul, Neil Armstrong,
	Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
	Tony Lindgren, Janusz Krzysztofik, Vignesh R, Andi Shyti,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Yoshihiro Shimoda,
	Yazan Shhady, Jon Nettleton, Vladimir Oltean, Mikhail Anikin,
	linux-can, linux-phy, linux-kernel, linux-omap, linux-i2c,
	linux-mmc, devicetree, linux-renesas-soc
In-Reply-To: <20260226-rz-sdio-mux-v11-0-c2a350f9bbd3@solid-run.com>

On Thu, 26 Feb 2026 at 14:21, Josua Mayer <josua@solid-run.com> wrote:
>
> This series has evolved over time from adding generic mux support for
> renesas sdhi driver, to partial rewrite of the mux framework.
>
> Several drivers have started implementing driver-local managed and
> unmanaged helper functions for getting and selecting a mux-state object.
>
> mmc maintainers have requested that new code shall intreoduce and use
> generic helper functions that can be shared by all drivers, avoiding
> code duplication.
>
> This series is structured in 5 parts, each of which is self-sufficient
> depending only on the previous patches. This shall allow the first N
> patches to be applied even if the last ones need further discussion.
>
> 1. Rename driver-local helper functions to avoid name collision with
>    global version to be introduced later.
>
> 2. Implement generic device-managed helper functions in mux core.
>
> 3. Convert driver local code from similar patterns to use the newly
>    added global helpers.
>
> 4. Change mux-core Kconfig so that it can be enabled through menuconfig,
>    without an explicit "select" dependency from other drivers.
>
> 5. add dt bindings and driver support for mux in renesas sdhi driver.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Changes in v11:
> - changed approach to Kconfig making MULTIPLEXER a bool, and adding a
>   user-visible wrapper for menuconfig.
>   (Reported-by: Ulf Hansson <ulf.hansson@linaro.org>)
> - dropped the "default m if COMPILE_TEST".
>   (Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>)
> - improved kerneldoc line wrapping.
> - removed unnecessary changes to original devm_mux_control-get.
> - fix "reference preceded by free" in mux_state_get function
> - Link to v10: https://lore.kernel.org/r/20260225-rz-sdio-mux-v10-0-1ee44f2ea112@solid-run.com
>

[...]

To me, this looks ready for a new try. Unless I hear some objections,
I intend to apply this as material for v7.1 via my mmc tree on Monday.

The complete series will be available on an immutable branch, for
other subsystem maintainers to pull in if that turns out to be needed.
I let you know of more details on Monday.

Kind regards
Uffe

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH] phy: cadence: Sierra: Do not modify register when getting parent clock
From: Gregory CLEMENT @ 2026-03-05 15:57 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Aswath Govindraju, Swapnil Jakhade
  Cc: Théo Lebrun, Thomas Petazzoni, linux-phy, linux-kernel,
	Gregory CLEMENT

The get_parent() callback for the PLL_CMNLC1 clock was incorrectly
writing to the register while determining the parent clock index. This
unintended register access forces the PHY back into training mode. If
the PHY is already configured, this unexpected change prevents it from
exiting training mode.

Remove the register write operation to ensure the PHY remains stable
during the get_parent() callback.

Fixes: da08aab940092 ("phy: cadence: Sierra: Fix to get correct parent for mux clocks")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 drivers/phy/cadence/phy-cadence-sierra.c | 9 ++-------
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/phy/cadence/phy-cadence-sierra.c b/drivers/phy/cadence/phy-cadence-sierra.c
index 92ab1a31646ae..d4e8979c3abba 100644
--- a/drivers/phy/cadence/phy-cadence-sierra.c
+++ b/drivers/phy/cadence/phy-cadence-sierra.c
@@ -706,15 +706,10 @@ static u8 cdns_sierra_pll_mux_get_parent(struct clk_hw *hw)
 
 	regmap_field_read(field, &val);
 
-	if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1])) {
+	if (strstr(clk_hw_get_name(hw), clk_names[CDNS_SIERRA_PLL_CMNLC1]))
 		index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC1], 0, val);
-		if (index == 1) {
-			regmap_field_write(plllc1en_field, 1);
-			regmap_field_write(termen_field, 1);
-		}
-	} else {
+	else
 		index = clk_mux_val_to_index(hw, cdns_sierra_pll_mux_table[CMN_PLLLC], 0, val);
-	}
 
 	return index;
 }

---
base-commit: 11439c4635edd669ae435eec308f4ab8a0804808
change-id: 20260305-fix_sierra_get_parent-9c8435cc65e7

Best regards,
-- 
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 15:39 UTC (permalink / raw)
  To: Joe Perches
  Cc: Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong, dri-devel,
	freedreno, linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio,
	linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <21e84301a7c37f9d5ce6f0ddcaed7846174d2a4d.camel@perches.com>

On Thu, Mar 05, 2026 at 07:35:54AM -0800, Joe Perches wrote:
> On Thu, 2026-03-05 at 13:43 +0200, Vladimir Oltean wrote:
> 
> > K:	(?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
> 
> You have (?:...)?phy(?:...)?\b
> 
> I rather doubt you want anything that ends in phy
> 
> That matches words like cryptography and way too many dts/yaml files

Yeah, the struct was meant to be non-optional, thanks for pointing it out.

K:	\bstruct\s+phy(?:_ops|_attrs|_lookup|_provider)?\b

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Joe Perches @ 2026-03-05 15:35 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong, dri-devel,
	freedreno, linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio,
	linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <20260305114352.2f7btqixg4tu5bzl@skbuf>

On Thu, 2026-03-05 at 13:43 +0200, Vladimir Oltean wrote:

> K:	(?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b

You have (?:...)?phy(?:...)?\b

I rather doubt you want anything that ends in phy

That matches words like cryptography and way too many dts/yaml files

-- 
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: AngeloGioacchino Del Regno @ 2026-03-05 14:32 UTC (permalink / raw)
  To: jic23, sboyd
  Cc: dlechner, nuno.sa, andy, arnd, gregkh, srini, vkoul,
	neil.armstrong, sre, 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: <de08d697-4202-499c-9784-2bb8d3d614b6@collabora.com>

Il 21/01/26 12:00, AngeloGioacchino Del Regno ha scritto:
> Il 14/01/26 10:27, AngeloGioacchino Del Regno ha scritto:
>> Changes in v8:
> 
> With this series being finally fully reviewed and having lots of acks, and
> since I think that the main part of this is in SPMI subsystem rather than
> others....
> 
> ....Stephen or Jonathan, can you please pick at least the SPMI code so that
> it goes in for this merge window and doesn't get forgotten again?
> 
> That also makes it easier for the other maintainers who didn't give an ack (and
> that don't want their subsystem patches to go through SPMI) to apply the patches
> in the next merge window, IMO.
> 

This series was ready and fully reviewed since the last merge window.

This is a gentle ping to remind you to *please* finally pick it.

Cheers,
Angelo

> Thanks,
> Angelo
> 
> 
>>   - 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)
>>
>> Changes in v7:
>>   - Added commit to cleanup redundant dev_name() in the pre-existing
>>     spmi_device_add() function
>>   - Added commit removing unneeded goto and improving spmi_device_add()
>>     readability by returning error in error path, and explicitly zero
>>     for success at the end.
>>
>> Changes in v6:
>>   - Added commit to convert spmi.c to %pe error format and used
>>     %pe error format in spmi_subdevice code as wanted by Uwe Kleine-Konig
>>
>> Changes in v5:
>>   - Changed dev_err to dev_err_probe in qcom-spmi-sdam (and done
>>     that even though I disagree - because I wanted this series to
>>     *exclusively* introduce the minimum required changes to
>>     migrate to the new API, but okay, whatever....!);
>>   - Added missing REGMAP dependency in Kconfig for qcom-spmi-sdam,
>>     phy-qcom-eusb2-repeater and qcom-coincell to resolve build
>>     issues when the already allowed COMPILE_TEST is enabled
>>     as pointed out by the test robot's randconfig builds.
>>
>> Changes in v4:
>>   - Added selection of REGMAP_SPMI in Kconfig for qcom-coincell and
>>     for phy-qcom-eusb2-repeater to resolve undefined references when
>>     compiled with some randconfig
>>
>> Changes in v3:
>>   - Fixed importing "SPMI" namespace in spmi-devres.c
>>   - Removed all instances of defensive programming, as pointed out by
>>     jic23 and Sebastian
>>   - Removed explicit casting as pointed out by jic23
>>   - Moved ida_free call to spmi_subdev_release() and simplified error
>>     handling in spmi_subdevice_alloc_and_add() as pointed out by jic23
>>
>> Changes in v2:
>>   - Fixed missing `sparent` initialization in phy-qcom-eusb2-repeater
>>   - Changed val_bits to 8 in all Qualcomm drivers to ensure
>>     compatibility as suggested by Casey
>>   - Added struct device pointer in all conversion commits as suggested
>>     by Andy
>>   - Exported newly introduced functions with a new "SPMI" namespace
>>     and imported the same in all converted drivers as suggested by Andy
>>   - Added missing error checking for dev_set_name() call in spmi.c
>>     as suggested by Andy
>>   - Added comma to last entry of regmap_config as suggested by Andy
>>
>> While adding support for newer MediaTek platforms, featuring complex
>> SPMI PMICs, I've seen that those SPMI-connected chips are internally
>> divided in various IP blocks, reachable in specific contiguous address
>> ranges... more or less like a MMIO, but over a slow SPMI bus instead.
>>
>> I recalled that Qualcomm had something similar... and upon checking a
>> couple of devicetrees, yeah - indeed it's the same over there.
>>
>> What I've seen then is a common pattern of reading the "reg" property
>> from devicetree in a struct member and then either
>>   A. Wrapping regmap_{read/write/etc}() calls in a function that adds
>>      the register base with "base + ..register", like it's done with
>>      writel()/readl() calls; or
>>   B. Doing the same as A. but without wrapper functions.
>>
>> Even though that works just fine, in my opinion it's wrong.
>>
>> The regmap API is way more complex than MMIO-only readl()/writel()
>> functions for multiple reasons (including supporting multiple busses
>> like SPMI, of course) - but everyone seemed to forget that regmap
>> can manage register base offsets transparently and automatically in
>> its API functions by simply adding a `reg_base` to the regmap_config
>> structure, which is used for initializing a `struct regmap`.
>>
>> So, here we go: this series implements the software concept of an SPMI
>> Sub-Device (which, well, also reflects how Qualcomm and MediaTek's
>> actual hardware is laid out anyway).
>>
>>                 SPMI Controller
>>                       |                ______
>>                       |               /       Sub-Device 1
>>                       V              /
>>                SPMI Device (PMIC) ----------- Sub-Device 2
>>                                      \
>>                                       \______ Sub-Device 3
>>
>> As per this implementation, an SPMI Sub-Device can be allocated/created
>> and added in any driver that implements a... well.. subdevice (!) with
>> an SPMI "main" device as its parent: this allows to create and finally
>> to correctly configure a regmap that is specific to the sub-device,
>> operating on its specific address range and reading, and writing, to
>> its registers with the regmap API taking care of adding the base address
>> of a sub-device's registers as per regmap API design.
>>
>> All of the SPMI Sub-Devices are therefore added as children of the SPMI
>> Device (usually a PMIC), as communication depends on the PMIC's SPMI bus
>> to be available (and the PMIC to be up and running, of course).
>>
>> Summarizing the dependency chain (which is obvious to whoever knows what
>> is going on with Qualcomm and/or MediaTek SPMI PMICs):
>>      "SPMI Sub-Device x...N" are children "SPMI Device"
>>      "SPMI Device" is a child of "SPMI Controller"
>>
>> (that was just another way to say the same thing as the graph above anyway).
>>
>> Along with the new SPMI Sub-Device registration functions, I have also
>> performed a conversion of some Qualcomm SPMI drivers and only where the
>> actual conversion was trivial.
>>
>> I haven't included any conversion of more complex Qualcomm SPMI drivers
>> because I don't have the required bandwidth to do so (and besides, I think,
>> but haven't exactly verified, that some of those require SoCs that I don't
>> have for testing anyway).
>>
>> AngeloGioacchino Del Regno (10):
>>    spmi: Remove redundant dev_name() print in spmi_device_add()
>>    spmi: Print error status with %pe format
>>    spmi: Remove unneeded goto in spmi_device_add() error path
>>    spmi: Implement spmi_subdevice_alloc_and_add() and devm variant
>>    nvmem: qcom-spmi-sdam: Migrate to devm_spmi_subdevice_alloc_and_add()
>>    power: reset: qcom-pon: Migrate to devm_spmi_subdevice_alloc_and_add()
>>    phy: qualcomm: eusb2-repeater: Migrate to
>>      devm_spmi_subdevice_alloc_and_add()
>>    misc: qcom-coincell: Migrate to devm_spmi_subdevice_alloc_and_add()
>>    iio: adc: qcom-spmi-iadc: Migrate to
>>      devm_spmi_subdevice_alloc_and_add()
>>    iio: adc: qcom-spmi-iadc: Remove regmap R/W wrapper functions
>>
>>   drivers/iio/adc/qcom-spmi-iadc.c              | 109 ++++++++----------
>>   drivers/misc/Kconfig                          |   2 +
>>   drivers/misc/qcom-coincell.c                  |  38 ++++--
>>   drivers/nvmem/Kconfig                         |   1 +
>>   drivers/nvmem/qcom-spmi-sdam.c                |  38 ++++--
>>   drivers/phy/qualcomm/Kconfig                  |   2 +
>>   .../phy/qualcomm/phy-qcom-eusb2-repeater.c    |  55 +++++----
>>   drivers/power/reset/qcom-pon.c                |  33 ++++--
>>   drivers/spmi/spmi-devres.c                    |  24 ++++
>>   drivers/spmi/spmi.c                           |  95 +++++++++++++--
>>   include/linux/spmi.h                          |  16 +++
>>   11 files changed, 290 insertions(+), 123 deletions(-)
>>
> 



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 13:11 UTC (permalink / raw)
  To: Krzysztof Wilczyński
  Cc: Joe Perches, Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong,
	dri-devel, freedreno, linux-arm-kernel, linux-arm-msm, linux-can,
	linux-gpio, linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <20260305130609.GB1659133@rocinante>

On Thu, Mar 05, 2026 at 10:06:09PM +0900, Krzysztof Wilczyński wrote:
> > > What about
> > > 
> > >   F:    drivers/*/*phy*
> > > 
> > > or something along these lines.
> > > 
> > >         Krzysztof
> > 
> > I don't understand your suggestion. Is it meant as a replacement for the
> > keyword regexes? Your file pattern matches on:
> 
> I was thinking more along the lines of using wildcards, the F: was just an
> example.
> 
> [...]
> 
> > There are a lot of false positives, and a lot of false negatives.
> 
> Yeah, the "catch-all", for lack of better word, will not work here.

But assume it did, for a second. The intention of the patch, stated in
the commit message, is to match on PHY consumers, to review their API
use.

$ grep -l -r '\bphy_power_on\b' drivers/ | sort | uniq
drivers/ata/ahci_ceva.c
drivers/ata/ahci_imx.c
drivers/ata/libahci_platform.c
drivers/ata/sata_dwc_460ex.c
drivers/ata/sata_mv.c
drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
drivers/gpu/drm/bridge/cadence/cdns-dsi-core.c
drivers/gpu/drm/bridge/imx/imx8qm-ldb.c
drivers/gpu/drm/bridge/imx/imx8qxp-ldb.c
drivers/gpu/drm/bridge/nwl-dsi.c
drivers/gpu/drm/bridge/samsung-dsim.c
drivers/gpu/drm/bridge/synopsys/dw-dp.c
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi2.c
drivers/gpu/drm/mediatek/mtk_dsi.c
drivers/gpu/drm/mediatek/mtk_hdmi.c
drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
drivers/gpu/drm/msm/dp/dp_ctrl.c
drivers/gpu/drm/rockchip/cdn-dp-core.c
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c
drivers/gpu/drm/rockchip/dw-mipi-dsi2-rockchip.c
drivers/gpu/drm/rockchip/dw-mipi-dsi-rockchip.c
drivers/gpu/drm/rockchip/rockchip_lvds.c
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c
drivers/gpu/drm/xlnx/zynqmp_dp.c
drivers/media/platform/cadence/cdns-csi2rx.c
drivers/media/platform/rockchip/rkisp1/rkisp1-csi.c
drivers/media/platform/samsung/exynos4-is/mipi-csis.c
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/sun8i_a83t_mipi_csi2.c
drivers/media/platform/synopsys/dw-mipi-csi2rx.c
drivers/mmc/host/sdhci-of-arasan.c
drivers/net/can/at91_can.c
drivers/net/can/flexcan/flexcan-core.c
drivers/net/can/m_can/m_can.c
drivers/net/can/rcar/rcar_canfd.c
drivers/net/can/xilinx_can.c
drivers/net/ethernet/cadence/macb_main.c
drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
...

How can it find the above? I think you've severely oversimplified what I
am trying to do.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Krzysztof Wilczyński @ 2026-03-05 13:06 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Joe Perches, Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong,
	dri-devel, freedreno, linux-arm-kernel, linux-arm-msm, linux-can,
	linux-gpio, linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <20260305123843.i47asdrjychwlgdt@skbuf>

Hello,

> > > K:    \b(?:__)?(?:devm_)?(?:of_)?phy_(?:create|destroy|provider_(?:un)?register)\b
> > > K:    \bphy_(?:create|remove)_lookup\b
> > > K:    \bphy_(?:get|set)?_drvdata\b
> > > K:    \b(?:devm_)?(?:of_)?phy_(?:optional_)?(?:get|put)(?:_by_index)?\b
> > > K:    \bphy_pm_runtime_(?:get|put)(?:_sync)?\b
> > > K:    \bphy_(?:init|exit|power_(?:on|off))\b
> > > K:    \bphy_|(?:get|set)_(?:mode(?:_ext)?|media|speed|bus_width|max_link_rate)\b
> > > K:    \bphy_(?:reset|configure|validate|calibrate)\b
> > > K:    \bphy_notify_(?:connect|disconnect|state)\b
> > > K:    (?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
> > > K:    (?:linux/phy/phy\.h|phy-props\.h|phy-provider\.h)
> > 
> > What about
> > 
> >   F:    drivers/*/*phy*
> > 
> > or something along these lines.
> > 
> >         Krzysztof
> 
> I don't understand your suggestion. Is it meant as a replacement for the
> keyword regexes? Your file pattern matches on:

I was thinking more along the lines of using wildcards, the F: was just an
example.

[...]

> There are a lot of false positives, and a lot of false negatives.

Yeah, the "catch-all", for lack of better word, will not work here.

	Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Krzysztof Wilczyński @ 2026-03-05 13:01 UTC (permalink / raw)
  To: Russell King (Oracle)
  Cc: Vladimir Oltean, Joe Perches, Konrad Dybcio, linux-phy,
	Vinod Koul, Neil Armstrong, dri-devel, freedreno,
	linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
	linux-kernel, linux-media, linux-pci, linux-renesas-soc,
	linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
	linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <aal6kWDx_3XRGB4K@shell.armlinux.org.uk>

Hello,

> > > For content match, it could also be:
> > > 
> > >   K:    phy
> > > 
> > > I believe this would match everything of interest?
> > 
> > Yeah, and way more. Think USB PHY, network PHY, etc. Don't want to drown
> > the linux-phy mailing list in unrelated patches, either.
> 
> Also phylink, any memory management / DMA stuff that happens to mention
> "physical", and probably numerous other examples.

Makes sense!  Sorry for the commotion here, then. :)

	Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 18/22] pinctrl: tegra-xusb: include PHY provider header
From: Vladimir Oltean @ 2026-03-05 12:47 UTC (permalink / raw)
  To: Linus Walleij
  Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
	linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
	linux-kernel, linux-media, linux-pci, linux-renesas-soc,
	linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
	linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
	Thierry Reding, Jonathan Hunter, Krzysztof Kozlowski
In-Reply-To: <CAD++jL=m+cEcqy1i2H0tdeBa3Sy76myGAR9HdBqrT4u-x5v50A@mail.gmail.com>

On Thu, Mar 05, 2026 at 01:44:42PM +0100, Linus Walleij wrote:
> On Thu, Mar 5, 2026 at 1:43 PM Linus Walleij <linusw@kernel.org> wrote:
> > On Wed, Mar 4, 2026 at 7:00 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
> >
> > > The tegra-xusb pinctrl driver is also a PHY provider (calls
> > > devm_phy_create() for PCIe and SATA). However, according to Vinod Koul,
> > > having PHY provider drivers outside of drivers/phy/ is discouraged,
> > > although it would be difficult for me to address a proper movement here.
> > >
> > > Include the private provider API header from drivers/phy/, but leave a
> > > FIXME in place. It will have to be moved, eventually.
> > >
> > > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> >
> > Fair enough, is this a regression so I should merge it for fixes
> > or just a nonurgent fix that I can apply for next?
> 
> Sorry I realized it needs to go in with the series.
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> 
> You can take it from here.

Yeah, the plan is explained in the cover letter. No regression intended
if it's taken through the same tree as the header split itself.

Thanks for the review.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 18/22] pinctrl: tegra-xusb: include PHY provider header
From: Linus Walleij @ 2026-03-05 12:44 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
	linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
	linux-kernel, linux-media, linux-pci, linux-renesas-soc,
	linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
	linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
	Thierry Reding, Jonathan Hunter, Krzysztof Kozlowski
In-Reply-To: <CAD++jLnCtu20rXcg7sMVLBi24EohscJoz0kN46XJaKPJt00O2w@mail.gmail.com>

On Thu, Mar 5, 2026 at 1:43 PM Linus Walleij <linusw@kernel.org> wrote:
> On Wed, Mar 4, 2026 at 7:00 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:
>
> > The tegra-xusb pinctrl driver is also a PHY provider (calls
> > devm_phy_create() for PCIe and SATA). However, according to Vinod Koul,
> > having PHY provider drivers outside of drivers/phy/ is discouraged,
> > although it would be difficult for me to address a proper movement here.
> >
> > Include the private provider API header from drivers/phy/, but leave a
> > FIXME in place. It will have to be moved, eventually.
> >
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
>
> Fair enough, is this a regression so I should merge it for fixes
> or just a nonurgent fix that I can apply for next?

Sorry I realized it needs to go in with the series.
Reviewed-by: Linus Walleij <linusw@kernel.org>

You can take it from here.

Yours,
Linus Walleij

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Russell King (Oracle) @ 2026-03-05 12:44 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Krzysztof Wilczyński, Joe Perches, Konrad Dybcio, linux-phy,
	Vinod Koul, Neil Armstrong, dri-devel, freedreno,
	linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
	linux-kernel, linux-media, linux-pci, linux-renesas-soc,
	linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
	linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver
In-Reply-To: <20260305123956.ojkt4k3ly64xz7fu@skbuf>

On Thu, Mar 05, 2026 at 02:39:56PM +0200, Vladimir Oltean wrote:
> On Thu, Mar 05, 2026 at 09:29:57PM +0900, Krzysztof Wilczyński wrote:
> > For content match, it could also be:
> > 
> >   K:    phy
> > 
> > I believe this would match everything of interest?
> 
> Yeah, and way more. Think USB PHY, network PHY, etc. Don't want to drown
> the linux-phy mailing list in unrelated patches, either.

Also phylink, any memory management / DMA stuff that happens to mention
"physical", and probably numerous other examples.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 18/22] pinctrl: tegra-xusb: include PHY provider header
From: Linus Walleij @ 2026-03-05 12:43 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
	linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
	linux-kernel, linux-media, linux-pci, linux-renesas-soc,
	linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
	linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
	Thierry Reding, Jonathan Hunter, Krzysztof Kozlowski
In-Reply-To: <20260304175735.2660419-19-vladimir.oltean@nxp.com>

On Wed, Mar 4, 2026 at 7:00 PM Vladimir Oltean <vladimir.oltean@nxp.com> wrote:

> The tegra-xusb pinctrl driver is also a PHY provider (calls
> devm_phy_create() for PCIe and SATA). However, according to Vinod Koul,
> having PHY provider drivers outside of drivers/phy/ is discouraged,
> although it would be difficult for me to address a proper movement here.
>
> Include the private provider API header from drivers/phy/, but leave a
> FIXME in place. It will have to be moved, eventually.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

Fair enough, is this a regression so I should merge it for fixes
or just a nonurgent fix that I can apply for next?

Long term a custom device can be created from the pin
control driver so that the Linux device model can be
used to move the driver over to phy.

Yours,
Linus Walleij

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 12:39 UTC (permalink / raw)
  To: Krzysztof Wilczyński
  Cc: Joe Perches, Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong,
	dri-devel, freedreno, linux-arm-kernel, linux-arm-msm, linux-can,
	linux-gpio, linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <20260305122957.GA1652563@rocinante>

On Thu, Mar 05, 2026 at 09:29:57PM +0900, Krzysztof Wilczyński wrote:
> For content match, it could also be:
> 
>   K:    phy
> 
> I believe this would match everything of interest?

Yeah, and way more. Think USB PHY, network PHY, etc. Don't want to drown
the linux-phy mailing list in unrelated patches, either.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 12:38 UTC (permalink / raw)
  To: Krzysztof Wilczyński
  Cc: Joe Perches, Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong,
	dri-devel, freedreno, linux-arm-kernel, linux-arm-msm, linux-can,
	linux-gpio, linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <20260305121532.GA1649635@rocinante>

On Thu, Mar 05, 2026 at 09:15:32PM +0900, Krzysztof Wilczyński wrote:
> Hello,
> 
> > K:    \b(?:__)?(?:devm_)?(?:of_)?phy_(?:create|destroy|provider_(?:un)?register)\b
> > K:    \bphy_(?:create|remove)_lookup\b
> > K:    \bphy_(?:get|set)?_drvdata\b
> > K:    \b(?:devm_)?(?:of_)?phy_(?:optional_)?(?:get|put)(?:_by_index)?\b
> > K:    \bphy_pm_runtime_(?:get|put)(?:_sync)?\b
> > K:    \bphy_(?:init|exit|power_(?:on|off))\b
> > K:    \bphy_|(?:get|set)_(?:mode(?:_ext)?|media|speed|bus_width|max_link_rate)\b
> > K:    \bphy_(?:reset|configure|validate|calibrate)\b
> > K:    \bphy_notify_(?:connect|disconnect|state)\b
> > K:    (?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
> > K:    (?:linux/phy/phy\.h|phy-props\.h|phy-provider\.h)
> 
> What about
> 
>   F:    drivers/*/*phy*
> 
> or something along these lines.
> 
>         Krzysztof

I don't understand your suggestion. Is it meant as a replacement for the
keyword regexes? Your file pattern matches on:

$ ls drivers/*/*phy*
drivers/base/physical_location.c           drivers/phy/phy-airoha-pcie.c        drivers/phy/phy-core-mipi-dphy.c   drivers/phy/phy-snps-eusb2.c
drivers/base/physical_location.h           drivers/phy/phy-airoha-pcie-regs.h   drivers/phy/phy-google-usb.c       drivers/phy/phy-spacemit-k1-pcie.c
drivers/firewire/phy-packet-definitions.h  drivers/phy/phy-can-transceiver.c    drivers/phy/phy-lgm-usb.c          drivers/phy/phy-xgene.c
drivers/net/sungem_phy.c                   drivers/phy/phy-common-props.c       drivers/phy/phy-lpc18xx-usb-otg.c  drivers/reset/reset-rzg2l-usbphy-ctrl.c
drivers/nfc/mei_phy.c                      drivers/phy/phy-common-props-test.c  drivers/phy/phy-nxp-ptn3222.c      drivers/reset/reset-rzv2h-usb2phy.c
drivers/nfc/mei_phy.h                      drivers/phy/phy-core.c               drivers/phy/phy-pistachio-usb.c

drivers/net/phy:
adin1100.c        bcm87xx.c      dp83848.c     lxt.c                 mediatek             mxl-gpy.c                 phy_caps.c           qsemi.c     teranetics.c
adin.c            bcm-cygnus.c   dp83867.c     Makefile              meson-gxl.c          national.c                phy-caps.h           qt2025.rs   uPD60620.c
air_en8811h.c     bcm-phy-lib.c  dp83869.c     marvell10g.c          micrel.c             ncn26000.c                phy-core.c           realtek     vitesse.c
amd.c             bcm-phy-lib.h  dp83tc811.c   marvell-88q2xxx.c     microchip.c          nxp-c45-tja11xx.c         phy_device.c         rockchip.c  xilinx_gmii2rgmii.c
aquantia          bcm-phy-ptp.c  dp83td510.c   marvell-88x2222.c     microchip_rds_ptp.c  nxp-c45-tja11xx.h         phy_led_triggers.c   sfp-bus.c
as21xxx.c         broadcom.c     dp83tg720.c   marvell.c             microchip_rds_ptp.h  nxp-c45-tja11xx-macsec.c  phylib.h             sfp.c
ax88796b.c        cicada.c       et1011c.c     mdio_bus.c            microchip_t1.c       nxp-cbtx.c                phylib-internal.h    sfp.h
ax88796b_rust.rs  cortina.c      fixed_phy.c   mdio_bus_provider.c   microchip_t1s.c      nxp-tja11xx.c             phylink.c            smsc.c
bcm54140.c        davicom.c      icplus.c      mdio_device.c         mii_timestamper.c    open_alliance_helpers.c   phy_link_topology.c  ste10Xp.c
bcm63xx.c         dp83640.c      intel-xway.c  mdio_devres.c         motorcomm.c          open_alliance_helpers.h   phy_package.c        stubs.c
bcm7xxx.c         dp83640_reg.h  Kconfig       mdio-open-alliance.h  mscc                 phy.c                     phy_port.c           swphy.c
bcm84881.c        dp83822.c      linkmode.c    mdio-private.h        mxl-86110.c          phy-c45.c                 qcom                 swphy.h

drivers/usb/phy:
Kconfig   phy-ab8500-usb.c      phy-am335x-control.h  phy-fsl-usb.h  phy-gpio-vbus-usb.c  phy-mv-usb.h    phy-tahvo.c        phy-ulpi.c
Makefile  phy-am335x.c          phy.c                 phy-generic.c  phy-isp1301.c        phy-mxs-usb.c   phy-tegra-usb.c    phy-ulpi-viewport.c
of.c      phy-am335x-control.c  phy-fsl-usb.c         phy-generic.h  phy-keystone.c       phy-omap-otg.c  phy-twl6030-usb.c

There are a lot of false positives, and a lot of false negatives.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Krzysztof Wilczyński @ 2026-03-05 12:29 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Joe Perches, Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong,
	dri-devel, freedreno, linux-arm-kernel, linux-arm-msm, linux-can,
	linux-gpio, linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <20260305121532.GA1649635@rocinante>

On 26-03-05 21:15:32, Krzysztof Wilczyński wrote:
> Hello,
> 
> > K:	\b(?:__)?(?:devm_)?(?:of_)?phy_(?:create|destroy|provider_(?:un)?register)\b
> > K:	\bphy_(?:create|remove)_lookup\b
> > K:	\bphy_(?:get|set)?_drvdata\b
> > K:	\b(?:devm_)?(?:of_)?phy_(?:optional_)?(?:get|put)(?:_by_index)?\b
> > K:	\bphy_pm_runtime_(?:get|put)(?:_sync)?\b
> > K:	\bphy_(?:init|exit|power_(?:on|off))\b
> > K:	\bphy_|(?:get|set)_(?:mode(?:_ext)?|media|speed|bus_width|max_link_rate)\b
> > K:	\bphy_(?:reset|configure|validate|calibrate)\b
> > K:	\bphy_notify_(?:connect|disconnect|state)\b
> > K:	(?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
> > K:	(?:linux/phy/phy\.h|phy-props\.h|phy-provider\.h)
> 
> What about
> 
>   F:	drivers/*/*phy*
> 
> or something along these lines.

For content match, it could also be:

  K:	phy

I believe this would match everything of interest?  Perhaps there is no
need to have any of these complex regular expressions, would be my way of
thinking here.  Makes it easier to maintain, too.

Just thinking out loud, really...

	Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Krzysztof Wilczyński @ 2026-03-05 12:15 UTC (permalink / raw)
  To: Vladimir Oltean
  Cc: Joe Perches, Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong,
	dri-devel, freedreno, linux-arm-kernel, linux-arm-msm, linux-can,
	linux-gpio, linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <20260305114352.2f7btqixg4tu5bzl@skbuf>

Hello,

> K:	\b(?:__)?(?:devm_)?(?:of_)?phy_(?:create|destroy|provider_(?:un)?register)\b
> K:	\bphy_(?:create|remove)_lookup\b
> K:	\bphy_(?:get|set)?_drvdata\b
> K:	\b(?:devm_)?(?:of_)?phy_(?:optional_)?(?:get|put)(?:_by_index)?\b
> K:	\bphy_pm_runtime_(?:get|put)(?:_sync)?\b
> K:	\bphy_(?:init|exit|power_(?:on|off))\b
> K:	\bphy_|(?:get|set)_(?:mode(?:_ext)?|media|speed|bus_width|max_link_rate)\b
> K:	\bphy_(?:reset|configure|validate|calibrate)\b
> K:	\bphy_notify_(?:connect|disconnect|state)\b
> K:	(?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
> K:	(?:linux/phy/phy\.h|phy-props\.h|phy-provider\.h)

What about

  F:	drivers/*/*phy*

or something along these lines.

	Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers
From: Vladimir Oltean @ 2026-03-05 11:54 UTC (permalink / raw)
  To: Markus Schneider-Pargmann
  Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
	linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
	linux-kernel, linux-media, linux-pci, linux-renesas-soc,
	linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
	linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
	Andrzej Hajda, Robert Foss, Laurent Pinchart, Jonas Karlman,
	Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, David Airlie, Simona Vetter, Andy Yan,
	Marc Kleine-Budde, Vincent Mailhol, Nicolas Ferre,
	Alexandre Belloni, Claudiu Beznea, Geert Uytterhoeven,
	Magnus Damm
In-Reply-To: <DGUQWFYCPRQZ.17SO07GXW2DYA@baylibre.com>

On Thu, Mar 05, 2026 at 10:36:14AM +0100, Markus Schneider-Pargmann wrote:
> All of the can drivers that would use this function are checking phy
> before assigning the max_link_rate:
> 
>   if (transceiver)
>           priv->can.bitrate_max = transceiver->attrs.max_link_rate;
> 
> Would it be reasonable to have
> 
>   if (!phy)
>           return 0;
> 
> in this function to be able to drop these individual checks of the
> drivers? This would be similar to clk_get_rate() which does the same
> check and return 0 for convenience.
> 
> Best
> Markus

Thanks, that's a good point. The transceiver is acquired through
devm_phy_optional_get() and NULL is given by the API as a non-error case,
so I guess it means it should also tolerate NULL coming back to it.

This just leaves an inconsistency with phy_(get|set)_bus_width() which
are not NULL-tolerant but should also be. I'll leave those as is for
now, since I don't want to make the series any larger than it is, but
I'll update the new API with your suggestion.

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy
From: Vladimir Oltean @ 2026-03-05 11:43 UTC (permalink / raw)
  To: Joe Perches
  Cc: Konrad Dybcio, linux-phy, Vinod Koul, Neil Armstrong, dri-devel,
	freedreno, linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio,
	linux-ide, linux-kernel, linux-media, linux-pci,
	linux-renesas-soc, linux-riscv, linux-rockchip, linux-samsung-soc,
	linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
	UNGLinuxDriver
In-Reply-To: <f3a5aa3df78553ffc0fd0024f5fd36a4e2158c88.camel@perches.com>

On Thu, Mar 05, 2026 at 01:30:40AM -0800, Joe Perches wrote:
> On Thu, 2026-03-05 at 10:51 +0200, Vladimir Oltean wrote:
> > On Thu, Mar 05, 2026 at 09:39:35AM +0100, Konrad Dybcio wrote:
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 55af015174a5..bdfa47d9c774 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -10713,6 +10713,7 @@ F:    Documentation/devicetree/bindings/phy/
> > > >  F:   drivers/phy/
> > > >  F:   include/dt-bindings/phy/
> > > >  F:   include/linux/phy/
> > > > +K:   \b(devm_)?(of_)?phy_(create|destroy|init|exit|reset|power_(on|off)|configure|validate|calibrate|(get|set)_(mode|media|speed|bus_width|drvdata)|get_max_link_rate|pm_runtime_(get|put)|notify_(connect|disconnect|state)|get|put|optional_get|provider_(un)?register|simple_xlate|(create|remove)_lookup)\b|(struct\s+)?phy(_ops|_attrs|_lookup|_provider)?\b|linux/phy/phy\.h|phy-props\.h|phy-provider\.h
> 
> You could use multiple K: entries instead of this monster.
> 
> And please use (?:<foo>) to avoid capture groups too.

Thanks, I wasn't aware of either of those.

I am now working with this:

K:	\b(?:__)?(?:devm_)?(?:of_)?phy_(?:create|destroy|provider_(?:un)?register)\b
K:	\bphy_(?:create|remove)_lookup\b
K:	\bphy_(?:get|set)?_drvdata\b
K:	\b(?:devm_)?(?:of_)?phy_(?:optional_)?(?:get|put)(?:_by_index)?\b
K:	\bphy_pm_runtime_(?:get|put)(?:_sync)?\b
K:	\bphy_(?:init|exit|power_(?:on|off))\b
K:	\bphy_|(?:get|set)_(?:mode(?:_ext)?|media|speed|bus_width|max_link_rate)\b
K:	\bphy_(?:reset|configure|validate|calibrate)\b
K:	\bphy_notify_(?:connect|disconnect|state)\b
K:	(?:struct\s+)?phy(?:_ops|_attrs|_lookup|_provider)?\b
K:	(?:linux/phy/phy\.h|phy-props\.h|phy-provider\.h)

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v3 2/2] phy: qcom: edp: Add per-version LDO configuration callback
From: Konrad Dybcio @ 2026-03-05 11:26 UTC (permalink / raw)
  To: Yongxing Mou, Vinod Koul, Neil Armstrong, Stephen Boyd,
	Bjorn Andersson
  Cc: linux-arm-msm, linux-phy, linux-kernel, stable
In-Reply-To: <20260302-edp_phy-v3-2-ca8888d793b0@oss.qualcomm.com>

On 3/2/26 9:28 AM, Yongxing Mou wrote:
> For eDP low Vdiff, the LDO setting depends on the PHY version, instead of
> being a simple 0x0 or 0x01. Introduce the com_ldo_config callback to
> correct LDO setting accroding to the HPG.
> 
> Since SC7280 uses different LDO settings than SA8775P/SC8280XP, introduce
> qcom_edp_phy_ops_v3 to keep the LDO setting correct.
> 
> Cc: stable@vger.kernel.org
> Fixes: f199223cb490 ("phy: qcom: Introduce new eDP PHY driver")
> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
> ---

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # SC8280XP X13s

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* [PATCH] phy: renesas: rzg3e-usb3: Convert to FIELD_MODIFY()
From: Geert Uytterhoeven @ 2026-03-05 10:15 UTC (permalink / raw)
  To: Vinod Koul, Neil Armstrong, Biju Das
  Cc: linux-phy, linux-renesas-soc, Geert Uytterhoeven

Use the FIELD_MODIFY() helper instead of open-coding the same operation.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
No changes in generated code.
---
 drivers/phy/renesas/phy-rzg3e-usb3.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/renesas/phy-rzg3e-usb3.c b/drivers/phy/renesas/phy-rzg3e-usb3.c
index 6b3453ea0004cf59..7f809ef1bb5135ec 100644
--- a/drivers/phy/renesas/phy-rzg3e-usb3.c
+++ b/drivers/phy/renesas/phy-rzg3e-usb3.c
@@ -78,13 +78,11 @@ static void rzg3e_phy_usb2test_phy_init(void __iomem *base)
 	writel(val, base + USB3_TEST_UTMICTRL2);
 
 	val = readl(base + USB3_TEST_PRMCTRL5_R);
-	val &= ~USB3_TEST_PRMCTRL5_R_TXPREEMPAMPTUNE0_MASK;
-	val |= FIELD_PREP(USB3_TEST_PRMCTRL5_R_TXPREEMPAMPTUNE0_MASK, 2);
+	FIELD_MODIFY(USB3_TEST_PRMCTRL5_R_TXPREEMPAMPTUNE0_MASK, &val, 2);
 	writel(val, base + USB3_TEST_PRMCTRL5_R);
 
 	val = readl(base + USB3_TEST_PRMCTRL6_R);
-	val &= ~USB3_TEST_PRMCTRL6_R_OTGTUNE0_MASK;
-	val |= FIELD_PREP(USB3_TEST_PRMCTRL6_R_OTGTUNE0_MASK, 7);
+	FIELD_MODIFY(USB3_TEST_PRMCTRL6_R_OTGTUNE0_MASK, &val, 7);
 	writel(val, base + USB3_TEST_PRMCTRL6_R);
 
 	val = readl(base + USB3_TEST_RESET);
-- 
2.43.0


-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply related

* Re: [PATCH] phy: qualcomm: usb-hs-28nm: use flex array
From: Konrad Dybcio @ 2026-03-05 10:06 UTC (permalink / raw)
  To: Rosen Penev, linux-phy
  Cc: Vinod Koul, Neil Armstrong, Kees Cook, Gustavo A. R. Silva,
	open list:ARM/QUALCOMM MAILING LIST, open list,
	open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260304230636.27808-1-rosenp@gmail.com>

On 3/5/26 12:06 AM, Rosen Penev wrote:
> Allows simplifying allocation to a single kzalloc call.
> 
> Also allows using __counted_by for extra runtime analysis.
> 
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---

I don't see how this is an improvement - __counted_by() is useful for
cases where we don't know how many entries there are, but in this
case it's fully deterministic (as priv->num_clks is a compile-time
constant)

Konrad

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH phy-next 05/22] phy: add <linux/pm_runtime.h> where missing
From: André Draszik @ 2026-03-05 10:02 UTC (permalink / raw)
  To: Vladimir Oltean, linux-phy
  Cc: Vinod Koul, Neil Armstrong, dri-devel, freedreno,
	linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
	linux-kernel, linux-media, linux-pci, linux-renesas-soc,
	linux-riscv, linux-rockchip, linux-samsung-soc, linux-sunxi,
	linux-tegra, linux-usb, netdev, spacemit, UNGLinuxDriver,
	Peter Griffin, Tudor Ambarus, Geert Uytterhoeven, Magnus Damm,
	Heiko Stuebner
In-Reply-To: <20260304175735.2660419-6-vladimir.oltean@nxp.com>

On Wed, 2026-03-04 at 19:57 +0200, Vladimir Oltean wrote:
> It appears that the phy-mapphone-mdm6600, phy-qcom-snps-femto-v2,
> phy-rcar-gen3-pcie, r8a779f0-ether-serdes and phy-rockchip-typec drivers
> call runtime PM operations without including the proper header.
> 
> This was provided by <linux/phy/phy.h> but no function exported by this
> header directly needs it. So we need to drop it from there, and fix up
> drivers that used to depend on that.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>

>  drivers/phy/phy-google-usb.c                   | 1 +

For Google:
Reviewed-by: André Draszik <andre.draszik@linaro.org>

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply

* Re: [PATCH v8 11/23] scsi: ufs: mediatek: Remove undocumented downstream reset cruft
From: Nicolas Frattaroli @ 2026-03-05  9:57 UTC (permalink / raw)
  To: chu.stanley@gmail.com, robh@kernel.org,
	Chunfeng Yun (云春峰), kishon@kernel.org,
	James.Bottomley@HansenPartnership.com, bvanassche@acm.org,
	AngeloGioacchino Del Regno, neil.armstrong@linaro.org,
	conor+dt@kernel.org, Chaotian Jing (井朝天),
	lgirdwood@gmail.com, vkoul@kernel.org, krzk+dt@kernel.org,
	p.zabel@pengutronix.de, alim.akhtar@samsung.com,
	matthias.bgg@gmail.com, avri.altman@wdc.com,
	martin.petersen@oracle.com, broonie@kernel.org,
	Peter Wang (王信友)
  Cc: linux-scsi@vger.kernel.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-phy@lists.infradead.org, linux-mediatek@lists.infradead.org,
	Louis-Alexis Eyraud, kernel@collabora.com
In-Reply-To: <3aeee75e78fed2be92038c776463a231b94462f3.camel@mediatek.com>

On Thursday, 5 March 2026 10:14:47 Central European Standard Time Peter Wang (王信友) wrote:
> On Wed, 2026-03-04 at 15:53 +0100, Nicolas Frattaroli wrote:
> > @@ -2383,38 +2383,12 @@ MODULE_DEVICE_TABLE(of, ufs_mtk_of_match);
> >  static int ufs_mtk_probe(struct platform_device *pdev)
> >  {
> >  	int err;
> > -	struct device *dev = &pdev->dev, *phy_dev = NULL;
> > 
> 
> Will there be a build error if phy_dev is removed?
> Please make sure that each patch can build successfully, one by one.
> 
> Thanks
> Peter
> 
> 
> 
> 

Yes, these are the kinds of mistakes that happen when you ask someone
to pick apart patches for your downstream convenience.

I'll hand dealing with any further fixups and variable naming concerns
you have over to Angelo, as I can't be bothered to deal with you
anymore.



-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox