All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Markus Schneider-Pargmann <msp@baylibre.com>
Cc: linux-phy@lists.infradead.org, Vinod Koul <vkoul@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev,
	linux-tegra@vger.kernel.org, linux-usb@vger.kernel.org,
	netdev@vger.kernel.org, spacemit@lists.linux.dev,
	UNGLinuxDriver@microchip.com,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Andy Yan <andy.yan@rock-chips.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	Vincent Mailhol <mailhol@kernel.org>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers
Date: Thu, 5 Mar 2026 13:54:05 +0200	[thread overview]
Message-ID: <20260305115405.7f73yheba4xdqi3j@skbuf> (raw)
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.


WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Markus Schneider-Pargmann <msp@baylibre.com>
Cc: linux-phy@lists.infradead.org, Vinod Koul <vkoul@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev,
	linux-tegra@vger.kernel.org, linux-usb@vger.kernel.org,
	netdev@vger.kernel.org, spacemit@lists.linux.dev,
	UNGLinuxDriver@microchip.com,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Andy Yan <andy.yan@rock-chips.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	Vincent Mailhol <mailhol@kernel.org>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers
Date: Thu, 5 Mar 2026 13:54:05 +0200	[thread overview]
Message-ID: <20260305115405.7f73yheba4xdqi3j@skbuf> (raw)
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

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Markus Schneider-Pargmann <msp@baylibre.com>
Cc: linux-phy@lists.infradead.org, Vinod Koul <vkoul@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev,
	linux-tegra@vger.kernel.org, linux-usb@vger.kernel.org,
	netdev@vger.kernel.org, spacemit@lists.linux.dev,
	UNGLinuxDriver@microchip.com,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Andy Yan <andy.yan@rock-chips.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	Vincent Mailhol <mailhol@kernel.org>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers
Date: Thu, 5 Mar 2026 13:54:05 +0200	[thread overview]
Message-ID: <20260305115405.7f73yheba4xdqi3j@skbuf> (raw)
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-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <vladimir.oltean@nxp.com>
To: Markus Schneider-Pargmann <msp@baylibre.com>
Cc: linux-phy@lists.infradead.org, Vinod Koul <vkoul@kernel.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org, linux-can@vger.kernel.org,
	linux-gpio@vger.kernel.org, linux-ide@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-pci@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
	linux-riscv@lists.infradead.org,
	linux-rockchip@lists.infradead.org,
	linux-samsung-soc@vger.kernel.org, linux-sunxi@lists.linux.dev,
	linux-tegra@vger.kernel.org, linux-usb@vger.kernel.org,
	netdev@vger.kernel.org, spacemit@lists.linux.dev,
	UNGLinuxDriver@microchip.com,
	Andrzej Hajda <andrzej.hajda@intel.com>,
	Robert Foss <rfoss@kernel.org>,
	Laurent Pinchart <Laurent.pinchart@ideasonboard.com>,
	Jonas Karlman <jonas@kwiboo.se>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@gmail.com>, Simona Vetter <simona@ffwll.ch>,
	Andy Yan <andy.yan@rock-chips.com>,
	Marc Kleine-Budde <mkl@pengutronix.de>,
	Vincent Mailhol <mailhol@kernel.org>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Alexandre Belloni <alexandre.belloni@bootlin.com>,
	Claudiu Beznea <claudiu.beznea@tuxon.dev>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Magnus Damm <magnus.damm@gmail.com>
Subject: Re: [PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers
Date: Thu, 5 Mar 2026 13:54:05 +0200	[thread overview]
Message-ID: <20260305115405.7f73yheba4xdqi3j@skbuf> (raw)
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-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-03-05 11:54 UTC|newest]

Thread overview: 260+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-04 17:57 [PATCH phy-next 00/22] Split Generic PHY consumer and provider API Vladimir Oltean
2026-03-04 17:57 ` Vladimir Oltean
2026-03-04 17:57 ` Vladimir Oltean
2026-03-04 17:57 ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 01/22] ata: add <linux/pm_runtime.h> where missing Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 20:14   ` Damien Le Moal
2026-03-04 20:14     ` Damien Le Moal
2026-03-04 20:14     ` Damien Le Moal
2026-03-04 20:14     ` Damien Le Moal
2026-03-04 17:57 ` [PATCH phy-next 02/22] PCI: add missing headers transitively included by <linux/phy/phy.h> Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 22:24   ` Bjorn Helgaas
2026-03-04 22:24     ` Bjorn Helgaas
2026-03-04 22:24     ` Bjorn Helgaas
2026-03-04 22:24     ` Bjorn Helgaas
2026-03-04 22:34     ` Vladimir Oltean
2026-03-04 22:34       ` Vladimir Oltean
2026-03-04 22:34       ` Vladimir Oltean
2026-03-04 22:34       ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 03/22] usb: " Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-05  2:43   ` Thinh Nguyen
2026-03-05  2:43     ` Thinh Nguyen
2026-03-05  2:43     ` Thinh Nguyen
2026-03-05  2:43     ` Thinh Nguyen
2026-03-04 17:57 ` [PATCH phy-next 04/22] drm: add <linux/pm_runtime.h> where missing Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 05/22] phy: " Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-05  7:45   ` Geert Uytterhoeven
2026-03-05  7:45     ` Geert Uytterhoeven
2026-03-05  7:45     ` Geert Uytterhoeven
2026-03-05  7:45     ` Geert Uytterhoeven
2026-03-05 10:02   ` André Draszik
2026-03-05 10:02     ` André Draszik
2026-03-05 10:02     ` André Draszik
2026-03-05 10:02     ` André Draszik
2026-03-04 17:57 ` [PATCH phy-next 06/22] phy: spacemit: include missing <linux/phy/phy.h> Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 07/22] net: lan969x: include missing <linux/of.h> Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-06  9:56   ` Daniel Machon
2026-03-06  9:56     ` Daniel Machon
2026-03-06  9:56     ` Daniel Machon
2026-03-06  9:56     ` Daniel Machon
2026-03-04 17:57 ` [PATCH phy-next 08/22] PCI: remove device links to PHY Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 22:28   ` Bjorn Helgaas
2026-03-04 22:28     ` Bjorn Helgaas
2026-03-04 22:28     ` Bjorn Helgaas
2026-03-04 22:28     ` Bjorn Helgaas
2026-03-04 17:57 ` [PATCH phy-next 09/22] ufs: exynos: stop poking into struct phy guts Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 10/22] drm/rockchip: dw_hdmi: avoid direct dereference of phy->dev.of_node Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 11/22] drm/msm/dp: remove debugging prints with internal struct phy state Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 23:53   ` Dmitry Baryshkov
2026-03-04 23:53     ` Dmitry Baryshkov
2026-03-04 23:53     ` Dmitry Baryshkov
2026-03-04 23:53     ` Dmitry Baryshkov
2026-03-04 17:57 ` [PATCH phy-next 12/22] phy: move provider API out of public <linux/phy/phy.h> Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 23:54   ` Dmitry Baryshkov
2026-03-04 23:54     ` Dmitry Baryshkov
2026-03-04 23:54     ` Dmitry Baryshkov
2026-03-04 23:54     ` Dmitry Baryshkov
2026-03-05  8:28   ` Geert Uytterhoeven
2026-03-05  8:28     ` Geert Uytterhoeven
2026-03-05  8:28     ` Geert Uytterhoeven
2026-03-05  8:28     ` Geert Uytterhoeven
2026-03-06 12:51     ` Vladimir Oltean
2026-03-06 12:51       ` Vladimir Oltean
2026-03-06 12:51       ` Vladimir Oltean
2026-03-06 12:51       ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-05  7:47   ` Geert Uytterhoeven
2026-03-05  7:47     ` Geert Uytterhoeven
2026-03-05  7:47     ` Geert Uytterhoeven
2026-03-05  7:47     ` Geert Uytterhoeven
2026-03-06 12:50     ` Vladimir Oltean
2026-03-06 12:50       ` Vladimir Oltean
2026-03-06 12:50       ` Vladimir Oltean
2026-03-06 12:50       ` Vladimir Oltean
2026-03-05  9:36   ` Markus Schneider-Pargmann
2026-03-05  9:36     ` Markus Schneider-Pargmann
2026-03-05  9:36     ` Markus Schneider-Pargmann
2026-03-05  9:36     ` Markus Schneider-Pargmann
2026-03-05 11:54     ` Vladimir Oltean [this message]
2026-03-05 11:54       ` Vladimir Oltean
2026-03-05 11:54       ` Vladimir Oltean
2026-03-05 11:54       ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 14/22] drm/rockchip: dsi: include PHY provider header Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 15/22] drm: bridge: cdns-mhdp8546: use consumer API for getting PHY bus width Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 16/22] media: sunxi: a83-mips-csi2: include PHY provider header Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 17/22] net: renesas: rswitch: " Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-05  8:29   ` Geert Uytterhoeven
2026-03-05  8:29     ` Geert Uytterhoeven
2026-03-05  8:29     ` Geert Uytterhoeven
2026-03-05  8:29     ` Geert Uytterhoeven
2026-03-04 17:57 ` [PATCH phy-next 18/22] pinctrl: tegra-xusb: " Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-05 12:43   ` Linus Walleij
2026-03-05 12:43     ` Linus Walleij
2026-03-05 12:43     ` Linus Walleij
2026-03-05 12:43     ` Linus Walleij
2026-03-05 12:44     ` Linus Walleij
2026-03-05 12:44       ` Linus Walleij
2026-03-05 12:44       ` Linus Walleij
2026-03-05 12:44       ` Linus Walleij
2026-03-05 12:47       ` Vladimir Oltean
2026-03-05 12:47         ` Vladimir Oltean
2026-03-05 12:47         ` Vladimir Oltean
2026-03-05 12:47         ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 19/22] power: supply: cpcap-charger: include missing <linux/property.h> Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-05  9:52   ` Sebastian Reichel
2026-03-05  9:52     ` Sebastian Reichel
2026-03-05  9:52     ` Sebastian Reichel
2026-03-05  9:52     ` Sebastian Reichel
2026-03-04 17:57 ` [PATCH phy-next 20/22] phy: include PHY provider header Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 23:56   ` Dmitry Baryshkov
2026-03-04 23:56     ` Dmitry Baryshkov
2026-03-04 23:56     ` Dmitry Baryshkov
2026-03-04 23:56     ` Dmitry Baryshkov
2026-03-05  3:22   ` Shawn Lin
2026-03-05  3:22     ` Shawn Lin
2026-03-05  3:22     ` Shawn Lin
2026-03-05  3:22     ` Shawn Lin
2026-03-06 13:06     ` Vladimir Oltean
2026-03-06 13:06       ` Vladimir Oltean
2026-03-06 13:06       ` Vladimir Oltean
2026-03-06 13:06       ` Vladimir Oltean
2026-03-04 17:57 ` [PATCH phy-next 21/22] phy: remove temporary provider compatibility from consumer header Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 23:56   ` Dmitry Baryshkov
2026-03-04 23:56     ` Dmitry Baryshkov
2026-03-04 23:56     ` Dmitry Baryshkov
2026-03-04 23:56     ` Dmitry Baryshkov
2026-03-04 17:57 ` [PATCH phy-next 22/22] MAINTAINERS: add regex for linux-phy Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-04 17:57   ` Vladimir Oltean
2026-03-05  8:39   ` Konrad Dybcio
2026-03-05  8:39     ` Konrad Dybcio
2026-03-05  8:39     ` Konrad Dybcio
2026-03-05  8:39     ` Konrad Dybcio
2026-03-05  8:51     ` Vladimir Oltean
2026-03-05  8:51       ` Vladimir Oltean
2026-03-05  8:51       ` Vladimir Oltean
2026-03-05  8:51       ` Vladimir Oltean
2026-03-05  9:11       ` Konrad Dybcio
2026-03-05  9:11         ` Konrad Dybcio
2026-03-05  9:11         ` Konrad Dybcio
2026-03-05  9:11         ` Konrad Dybcio
2026-03-05  9:13         ` Vladimir Oltean
2026-03-05  9:13           ` Vladimir Oltean
2026-03-05  9:13           ` Vladimir Oltean
2026-03-05  9:13           ` Vladimir Oltean
2026-03-05  9:15           ` Konrad Dybcio
2026-03-05  9:15             ` Konrad Dybcio
2026-03-05  9:15             ` Konrad Dybcio
2026-03-05  9:15             ` Konrad Dybcio
2026-03-05  9:30       ` Joe Perches
2026-03-05  9:30         ` Joe Perches
2026-03-05  9:30         ` Joe Perches
2026-03-05  9:30         ` Joe Perches
2026-03-05 11:43         ` Vladimir Oltean
2026-03-05 11:43           ` Vladimir Oltean
2026-03-05 11:43           ` Vladimir Oltean
2026-03-05 11:43           ` Vladimir Oltean
2026-03-05 12:15           ` Krzysztof Wilczyński
2026-03-05 12:15             ` Krzysztof Wilczyński
2026-03-05 12:15             ` Krzysztof Wilczyński
2026-03-05 12:15             ` Krzysztof Wilczyński
2026-03-05 12:29             ` Krzysztof Wilczyński
2026-03-05 12:29               ` Krzysztof Wilczyński
2026-03-05 12:29               ` Krzysztof Wilczyński
2026-03-05 12:29               ` Krzysztof Wilczyński
2026-03-05 12:39               ` Vladimir Oltean
2026-03-05 12:39                 ` Vladimir Oltean
2026-03-05 12:39                 ` Vladimir Oltean
2026-03-05 12:39                 ` Vladimir Oltean
2026-03-05 12:44                 ` Russell King (Oracle)
2026-03-05 12:44                   ` Russell King (Oracle)
2026-03-05 12:44                   ` Russell King (Oracle)
2026-03-05 12:44                   ` Russell King (Oracle)
2026-03-05 13:01                   ` Krzysztof Wilczyński
2026-03-05 13:01                     ` Krzysztof Wilczyński
2026-03-05 13:01                     ` Krzysztof Wilczyński
2026-03-05 13:01                     ` Krzysztof Wilczyński
2026-03-05 12:38             ` Vladimir Oltean
2026-03-05 12:38               ` Vladimir Oltean
2026-03-05 12:38               ` Vladimir Oltean
2026-03-05 12:38               ` Vladimir Oltean
2026-03-05 13:06               ` Krzysztof Wilczyński
2026-03-05 13:06                 ` Krzysztof Wilczyński
2026-03-05 13:06                 ` Krzysztof Wilczyński
2026-03-05 13:06                 ` Krzysztof Wilczyński
2026-03-05 13:11                 ` Vladimir Oltean
2026-03-05 13:11                   ` Vladimir Oltean
2026-03-05 13:11                   ` Vladimir Oltean
2026-03-05 13:11                   ` Vladimir Oltean
2026-03-05 15:35           ` Joe Perches
2026-03-05 15:35             ` Joe Perches
2026-03-05 15:35             ` Joe Perches
2026-03-05 15:35             ` Joe Perches
2026-03-05 15:39             ` Vladimir Oltean
2026-03-05 15:39               ` Vladimir Oltean
2026-03-05 15:39               ` Vladimir Oltean
2026-03-05 15:39               ` Vladimir Oltean

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260305115405.7f73yheba4xdqi3j@skbuf \
    --to=vladimir.oltean@nxp.com \
    --cc=Laurent.pinchart@ideasonboard.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=airlied@gmail.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrzej.hajda@intel.com \
    --cc=andy.yan@rock-chips.com \
    --cc=claudiu.beznea@tuxon.dev \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=geert+renesas@glider.be \
    --cc=jernej.skrabec@gmail.com \
    --cc=jonas@kwiboo.se \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-can@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=magnus.damm@gmail.com \
    --cc=mailhol@kernel.org \
    --cc=mkl@pengutronix.de \
    --cc=mripard@kernel.org \
    --cc=msp@baylibre.com \
    --cc=neil.armstrong@linaro.org \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=rfoss@kernel.org \
    --cc=simona@ffwll.ch \
    --cc=spacemit@lists.linux.dev \
    --cc=tzimmermann@suse.de \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.