Re: [PATCH net-next v4 05/15] net: phy: Create a phy_port for PHY-driven SFPs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> One way to avoid that would be to extract out of phylink/phylib all the
> functions for linkmode handling that aren't tied to phylink/phylib
> directly, but are about managing the capabilities of each interface,
> linkmode, speed, duplex, etc. For phylink, that would be :
> 
> phylink_merge_link_mode
> phylink_get_capabilities
> phylink_cap_from_speed_duplex
> phylink_limit_mac_speed
> phylink_caps_to_linkmodes
> phylink_interface_max_speed
> phylink_interface_signal_rate
> phylink_is_empty_linkmode
> phylink_an_mode_str
> phylink_set_port_modes

...

> These would go into linkmode.c/h for example, and we'd have a shared set
> of helpers that we can use in phylink, phylib and phy_port.

Please be careful with the scope of these. Heiner is going through
phylib and trying to reduce the scope of some of the functions we
exporting in include/linux/phy.h to just being available in
drivers/net/phy. That will help stop MAC drivers abuse them. We should
do the same here, limit what can actually use these helpers to stop
abuse.

	Andrew




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux