[PATCH phy-next 13/22] phy: introduce phy_get_max_link_rate() helper for consumers

Vladimir Oltean vladimir.oltean at nxp.com
Thu Mar 5 03:54:05 PST 2026


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.



More information about the Linux-rockchip mailing list