Some pragmatic shortcuts are being taken by PHY consumer driver authors,
which put a burden on the framework. A lot of these can be caught during
review.

Make sure the linux-phy list is copied on as many keywords that a regex
can reasonably catch.

For simplicity sake this is not perfect (devm_ and of_ are not valid
prefixes for all function names), but I tried to pay attention on
avoiding false matches on things like:
- drivers/net/vendor/device/phy.h
- include/linux/phy.h - network PHY, not generic PHY

So I used \b to try to match on actual word boundaries and be explicit
about what is matched on.

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

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
 
 GENERIC PINCTRL I2C DEMULTIPLEXER DRIVER
 M:	Wolfram Sang <wsa+renesas@sang-engineering.com>
-- 
2.43.0

On 3/4/26 6:57 PM, Vladimir Oltean wrote:
> Some pragmatic shortcuts are being taken by PHY consumer driver authors,
> which put a burden on the framework. A lot of these can be caught during
> review.
> 
> Make sure the linux-phy list is copied on as many keywords that a regex
> can reasonably catch.
> 
> For simplicity sake this is not perfect (devm_ and of_ are not valid
> prefixes for all function names), but I tried to pay attention on
> avoiding false matches on things like:
> - drivers/net/vendor/device/phy.h
> - include/linux/phy.h - network PHY, not generic PHY
> 
> So I used \b to try to match on actual word boundaries and be explicit
> about what is matched on.
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> 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

Would looking for the devm/of_phy_ prefix followed by an open parentheses
not suffice for the 'has function call' case, instead of listing all
currently present exported functions?

My worry is that this approach is overbuilt and absolutely no one will
remember to update it

Konrad

Hello Konrad,

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
> 
> Would looking for the devm/of_phy_ prefix followed by an open parentheses
> not suffice for the 'has function call' case, instead of listing all
> currently present exported functions?

This would maybe work when you run ./scripts/get_maintainer.pl on a file.
But I would like it to have good coverage on individual patches too. And
since the devm/of_phy prefix only matches when you "get" the PHY, not
"use" it, my fear is we would still be missing out on the most important
part of the patches.

> 
> My worry is that this approach is overbuilt and absolutely no one will
> remember to update it

I think I can add a test in the patch build automation that correlates
function and struct names from <linux/phy/phy.h> with their presence in
MAINTAINERS.

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.

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)

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

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

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

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.

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

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.

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

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.

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!

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

On 3/5/26 9:51 AM, Vladimir Oltean wrote:
> Hello Konrad,
> 
> 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
>>
>> Would looking for the devm/of_phy_ prefix followed by an open parentheses
>> not suffice for the 'has function call' case, instead of listing all
>> currently present exported functions?
> 
> This would maybe work when you run ./scripts/get_maintainer.pl on a file.
> But I would like it to have good coverage on individual patches too. And
> since the devm/of_phy prefix only matches when you "get" the PHY, not
> "use" it, my fear is we would still be missing out on the most important
> part of the patches.

But that's just '(devm_)?(of_)?phy_[a-z]+\(|includes.h'?

Konrad

On Thu, Mar 05, 2026 at 10:11:32AM +0100, Konrad Dybcio wrote:
> On 3/5/26 9:51 AM, Vladimir Oltean wrote:
> > Hello Konrad,
> >
> > 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
> >>
> >> Would looking for the devm/of_phy_ prefix followed by an open parentheses
> >> not suffice for the 'has function call' case, instead of listing all
> >> currently present exported functions?
> >
> > This would maybe work when you run ./scripts/get_maintainer.pl on a file.
> > But I would like it to have good coverage on individual patches too. And
> > since the devm/of_phy prefix only matches when you "get" the PHY, not
> > "use" it, my fear is we would still be missing out on the most important
> > part of the patches.
> 
> But that's just '(devm_)?(of_)?phy_[a-z]+\(|includes.h'?

Yeah, but what about the networking PHY API, phy_start(), phy_connect(),
phy_inband_caps() etc?

On 3/5/26 10:13 AM, Vladimir Oltean wrote:
> On Thu, Mar 05, 2026 at 10:11:32AM +0100, Konrad Dybcio wrote:
>> On 3/5/26 9:51 AM, Vladimir Oltean wrote:
>>> Hello Konrad,
>>>
>>> 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
>>>>
>>>> Would looking for the devm/of_phy_ prefix followed by an open parentheses
>>>> not suffice for the 'has function call' case, instead of listing all
>>>> currently present exported functions?
>>>
>>> This would maybe work when you run ./scripts/get_maintainer.pl on a file.
>>> But I would like it to have good coverage on individual patches too. And
>>> since the devm/of_phy prefix only matches when you "get" the PHY, not
>>> "use" it, my fear is we would still be missing out on the most important
>>> part of the patches.
>>
>> But that's just '(devm_)?(of_)?phy_[a-z]+\(|includes.h'?
> 
> Yeah, but what about the networking PHY API, phy_start(), phy_connect(),
> phy_inband_caps() etc?

OK I wasn't aware of that poor namespacing..

Konrad