Re: [PATCH net-next 18/20] net: ethernet: qualcomm: Add PPE MAC support for phylink

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

 



On Wed, Jan 10, 2024 at 07:40:30PM +0800, Luo Jie wrote:
> +static void ppe_phylink_mac_link_up(struct ppe_device *ppe_dev, int port,
> +				    struct phy_device *phy,
> +				    unsigned int mode, phy_interface_t interface,
> +				    int speed, int duplex, bool tx_pause, bool rx_pause)
> +{
> +	struct phylink_pcs *pcs = ppe_phylink_mac_select_pcs(ppe_dev, port, interface);
> +	struct ppe_uniphy *uniphy = pcs_to_ppe_uniphy(pcs);
> +	struct ppe_port *ppe_port = ppe_port_get(ppe_dev, port);
> +
> +	/* Wait uniphy auto-negotiation completion */
> +	ppe_uniphy_autoneg_complete_check(uniphy, port);

Way too late...

> @@ -352,6 +1230,12 @@ static int ppe_port_maxframe_set(struct ppe_device *ppe_dev,
>  }
>  
>  static struct ppe_device_ops qcom_ppe_ops = {
> +	.phylink_setup = ppe_phylink_setup,
> +	.phylink_destroy = ppe_phylink_destroy,
> +	.phylink_mac_config = ppe_phylink_mac_config,
> +	.phylink_mac_link_up = ppe_phylink_mac_link_up,
> +	.phylink_mac_link_down = ppe_phylink_mac_link_down,
> +	.phylink_mac_select_pcs = ppe_phylink_mac_select_pcs,
>  	.set_maxframe = ppe_port_maxframe_set,
>  };

Why this extra layer of abstraction? If you need separate phylink
operations, why not implement separate phylink_mac_ops structures?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!




[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux