Re: [PATCH v3 net-next 05/10] phy: add phy_get_rx_polarity() and phy_get_tx_polarity()

0 views
Skip to first unread message

Geert Uytterhoeven

unread,
Feb 26, 2026, 8:28:12 AM (yesterday) Feb 26
to Vladimir Oltean, net...@vger.kernel.org, devic...@vger.kernel.org, linu...@lists.infradead.org, linux-...@vger.kernel.org, linux-ar...@lists.infradead.org, linux-m...@lists.infradead.org, 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, Vinod Koul, Neil Armstrong, Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún, Lee Jones, Patrice Chotard, open list:KERNEL SELFTEST FRAMEWORK, KUnit Development
Hi Vladimir,

CC kunit

On Sun, 11 Jan 2026 at 10:44, Vladimir Oltean <vladimi...@nxp.com> wrote:
> Add helpers in the generic PHY folder which can be used using 'select
> GENERIC_PHY_COMMON_PROPS' from Kconfig, without otherwise needing to
> enable GENERIC_PHY.
>
> These helpers need to deal with the slight messiness of the fact that
> the polarity properties are arrays per protocol, and with the fact that
> there is no default value mandated by the standard properties, all
> default values depend on driver and protocol (PHY_POL_NORMAL may be a
> good default for SGMII, whereas PHY_POL_AUTO may be a good default for
> PCIe).
>
> Push the supported mask of polarities to these helpers, to simplify
> drivers such that they don't need to validate what's in the device tree
> (or other firmware description).
>
> Add a KUnit test suite to make sure that the API produces the expected
> results. The fact that we use fwnode structures means we can validate
> with software nodes, and as opposed to the device_property API, we can
> bypass the need to have a device structure.
>
> Co-developed-by: Bjørn Mork <bj...@mork.no>
> Signed-off-by: Bjørn Mork <bj...@mork.no>
> Signed-off-by: Vladimir Oltean <vladimi...@nxp.com>

Thanks for your patch, which is now commit e7556b59ba651796
("phy: add phy_get_rx_polarity() and phy_get_tx_polarity()") in
v7.0-rc1.

> --- a/drivers/phy/Kconfig
> +++ b/drivers/phy/Kconfig
> @@ -5,6 +5,28 @@
>
> menu "PHY Subsystem"
>
> +config PHY_COMMON_PROPS
> + bool
> + help
> + This parses properties common between generic PHYs and Ethernet PHYs.
> +
> + Select this from consumer drivers to gain access to helpers for
> + parsing properties from the
> + Documentation/devicetree/bindings/phy/phy-common-props.yaml schema.
> +
> +config PHY_COMMON_PROPS_TEST
> + tristate "KUnit tests for PHY common props" if !KUNIT_ALL_TESTS
> + select PHY_COMMON_PROPS

This select means that enabling KUNIT_ALL_TESTS also enables extra
functionality, which may not be desirable in a production system.
As PHY_COMMON_PROPS is bool, this extra functionality is even part of
the base kernel if KUNIT_ALL_TESTS=m. Unfortunately PHY_COMMON_PROPS is
invisible, so this cannot just be changed from "select" to "depends on".
But perhaps PHY_COMMON_PROPS can be made visible if KUNIT_ALL_TESTS,
so the select can be turned into a dependency?

> + depends on KUNIT
> + default KUNIT_ALL_TESTS
> + help
> + This builds KUnit tests for the PHY common property API.
> +
> + For more information on KUnit and unit tests in general,
> + please refer to the KUnit documentation in Documentation/dev-tools/kunit/.
> +
> + When in doubt, say N.
> +
> config GENERIC_PHY
> bool "PHY Core"
> help

Gr{oetje,eeting}s,

Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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

Vladimir Oltean

unread,
Feb 26, 2026, 10:10:44 AM (yesterday) Feb 26
to Geert Uytterhoeven, net...@vger.kernel.org, devic...@vger.kernel.org, linu...@lists.infradead.org, linux-...@vger.kernel.org, linux-ar...@lists.infradead.org, linux-m...@lists.infradead.org, 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, Vinod Koul, Neil Armstrong, Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún, Lee Jones, Patrice Chotard, open list:KERNEL SELFTEST FRAMEWORK, KUnit Development
Hi Geert,

On Thu, Feb 26, 2026 at 02:22:29PM +0100, Geert Uytterhoeven wrote:
> > +config PHY_COMMON_PROPS
> > + bool
> > + help
> > + This parses properties common between generic PHYs and Ethernet PHYs.
> > +
> > + Select this from consumer drivers to gain access to helpers for
> > + parsing properties from the
> > + Documentation/devicetree/bindings/phy/phy-common-props.yaml schema.
> > +
> > +config PHY_COMMON_PROPS_TEST
> > + tristate "KUnit tests for PHY common props" if !KUNIT_ALL_TESTS
> > + select PHY_COMMON_PROPS
>
> This select means that enabling KUNIT_ALL_TESTS also enables extra
> functionality, which may not be desirable in a production system.
> As PHY_COMMON_PROPS is bool, this extra functionality is even part of
> the base kernel if KUNIT_ALL_TESTS=m. Unfortunately PHY_COMMON_PROPS is
> invisible, so this cannot just be changed from "select" to "depends on".
> But perhaps PHY_COMMON_PROPS can be made visible if KUNIT_ALL_TESTS,
> so the select can be turned into a dependency?

Is this what you're asking for?

-- >8 --
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 02467dfd4fb0..1875d5b784f6 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -6,7 +6,7 @@
menu "PHY Subsystem"

config PHY_COMMON_PROPS
- bool
+ bool "PHY common properties" if KUNIT_ALL_TESTS
help
This parses properties common between generic PHYs and Ethernet PHYs.

@@ -16,8 +16,7 @@ config PHY_COMMON_PROPS

config PHY_COMMON_PROPS_TEST
tristate "KUnit tests for PHY common props" if !KUNIT_ALL_TESTS
- select PHY_COMMON_PROPS
- depends on KUNIT
+ depends on KUNIT && PHY_COMMON_PROPS
default KUNIT_ALL_TESTS
help
This builds KUnit tests for the PHY common property API.
-- >8 --

Geert Uytterhoeven

unread,
Feb 26, 2026, 10:14:16 AM (yesterday) Feb 26
to Vladimir Oltean, net...@vger.kernel.org, devic...@vger.kernel.org, linu...@lists.infradead.org, linux-...@vger.kernel.org, linux-ar...@lists.infradead.org, linux-m...@lists.infradead.org, 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, Vinod Koul, Neil Armstrong, Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún, Lee Jones, Patrice Chotard, open list:KERNEL SELFTEST FRAMEWORK, KUnit Development
Hi Vladimir,
Yes, that would work. Do you think it is acceptable?
Thanks!

Vladimir Oltean

unread,
Feb 26, 2026, 10:21:24 AM (yesterday) Feb 26
to Geert Uytterhoeven, net...@vger.kernel.org, devic...@vger.kernel.org, linu...@lists.infradead.org, linux-...@vger.kernel.org, linux-ar...@lists.infradead.org, linux-m...@lists.infradead.org, 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, Vinod Koul, Neil Armstrong, Matthias Brugger, AngeloGioacchino Del Regno, Eric Woudstra, Marek Behún, Lee Jones, Patrice Chotard, open list:KERNEL SELFTEST FRAMEWORK, KUnit Development
Yes, I think it's fine. I misinterpreted what kunit_"all"_tests means,
then read its prompt which says "All KUnit tests with satisfied dependencies".

I'll send a patch.
Reply all
Reply to author
Forward
0 new messages