diff mbox series

net: stmmac: dwmac-qcom-ethqos: Enable support for XGMAC

Message ID 20241112-fix_qcom_ethqos_to_support_xgmac-v1-1-f0c93b27f9b2@quicinc.com (mailing list archive)
State New
Headers show
Series net: stmmac: dwmac-qcom-ethqos: Enable support for XGMAC | expand

Commit Message

Sagar Cheluvegowda Nov. 13, 2024, 2:08 a.m. UTC 
All Qualcomm platforms have only supported EMAC version 4 until
now whereas in future we will also be supporting XGMAC version
which has higher capabilities than its peer. As both has_gmac4
and has_xgmac fields cannot co-exist, make sure to disable the
former flag when has_xgmac  is enabled.

We want to keep the default capabilities as EMAC4 and enable
XGMAC support from the dtsi based on the platform needs.

Signed-off-by: Sagar Cheluvegowda <quic_scheluve@quicinc.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 2 ++
 1 file changed, 2 insertions(+)


---
base-commit: 28955f4fa2823e39f1ecfb3a37a364563527afbc
change-id: 20241112-fix_qcom_ethqos_to_support_xgmac-d1a81ea9cbfc

Best regards,

Comments

Andrew Lunn Nov. 14, 2024, 2:51 a.m. UTC | #1 
On Tue, Nov 12, 2024 at 06:08:10PM -0800, Sagar Cheluvegowda wrote:
> All Qualcomm platforms have only supported EMAC version 4 until
> now whereas in future we will also be supporting XGMAC version
> which has higher capabilities than its peer. As both has_gmac4
> and has_xgmac fields cannot co-exist, make sure to disable the
> former flag when has_xgmac  is enabled.

If you say they are mutually exclusive, how can it happen that both
are enabled?

To me, this feels like you are papering over a bug somewhere else.

	Andrew
Sagar Cheluvegowda Nov. 15, 2024, 1:08 a.m. UTC | #2 
On 11/13/2024 6:51 PM, Andrew Lunn wrote:
> On Tue, Nov 12, 2024 at 06:08:10PM -0800, Sagar Cheluvegowda wrote:
>> All Qualcomm platforms have only supported EMAC version 4 until
>> now whereas in future we will also be supporting XGMAC version
>> which has higher capabilities than its peer. As both has_gmac4
>> and has_xgmac fields cannot co-exist, make sure to disable the
>> former flag when has_xgmac  is enabled.
> 
> If you say they are mutually exclusive, how can it happen that both
> are enabled?
> 
> To me, this feels like you are papering over a bug somewhere else.
> 
> 	Andrew


We can set either has_gmac4 or has_xgmac flags by using below
dtsi properties as well. But since Qualcomm only supported
GMAC4 version in all of its chipsets until now, we had enabled
has_gmac4 flag by default within dwmac_qcom_ethqos.c instead
of adding any of the below entries in the dtsi. But this will
create problem for us as we start supporting Xgmac version
in the future, so we are trying to add this change so that
our driver can support Xgmac version when "snps,dwxgmac" is 
defined in the dtsi and we are keeping the default supported
configuration as gmac4.


	if (of_device_is_compatible(np, "snps,dwmac-4.00") ||
	    of_device_is_compatible(np, "snps,dwmac-4.10a") ||
	    of_device_is_compatible(np, "snps,dwmac-4.20a") ||
	    of_device_is_compatible(np, "snps,dwmac-5.10a") ||
	    of_device_is_compatible(np, "snps,dwmac-5.20")) {
		plat->has_gmac4 = 1;
		plat->has_gmac = 0;
		plat->pmt = 1;
		if (of_property_read_bool(np, "snps,tso"))
			plat->flags |= STMMAC_FLAG_TSO_EN;
	}


	if (of_device_is_compatible(np, "snps,dwxgmac")) {
		plat->has_xgmac = 1;
		plat->pmt = 1;
		if (of_property_read_bool(np, "snps,tso"))
			plat->flags |= STMMAC_FLAG_TSO_EN;
	}
Andrew Lunn Nov. 15, 2024, 1:22 p.m. UTC | #3 
On Thu, Nov 14, 2024 at 05:08:13PM -0800, Sagar Cheluvegowda wrote:
> 
> 
> On 11/13/2024 6:51 PM, Andrew Lunn wrote:
> > On Tue, Nov 12, 2024 at 06:08:10PM -0800, Sagar Cheluvegowda wrote:
> >> All Qualcomm platforms have only supported EMAC version 4 until
> >> now whereas in future we will also be supporting XGMAC version
> >> which has higher capabilities than its peer. As both has_gmac4
> >> and has_xgmac fields cannot co-exist, make sure to disable the
> >> former flag when has_xgmac  is enabled.
> > 
> > If you say they are mutually exclusive, how can it happen that both
> > are enabled?
> > 
> > To me, this feels like you are papering over a bug somewhere else.
> > 
> > 	Andrew
> 
> 
> We can set either has_gmac4 or has_xgmac flags by using below
> dtsi properties as well. But since Qualcomm only supported
> GMAC4 version in all of its chipsets until now, we had enabled
> has_gmac4 flag by default within dwmac_qcom_ethqos.c instead
> of adding any of the below entries in the dtsi. But this will
> create problem for us as we start supporting Xgmac version
> in the future, so we are trying to add this change so that
> our driver can support Xgmac version when "snps,dwxgmac" is 
> defined in the dtsi and we are keeping the default supported
> configuration as gmac4.

So i think you are saying that stmmac_probe_config_dt() does not
reliably set

	plat->has_gmac4 = 1;

or

	plat->has_xgmac = 1;

because you have not listed the secondary compatibles:

"snps,dwmac-4.00"
"snps,dwmac-4.10a"
"snps,dwmac-4.20a"
"snps,dwmac-5.10a"
"snps,dwmac-5.20"
"snps,dwxgmac"

in your .dtsi files.

It is too late to add these, because of backwards compatibility to old
DT blobs.

However, you are thinking of doing it correctly for new SoCs, and
include "snps,dwxgmac", so stmmac_probe_config_dt() will set
plat->has_xgmac = 1. The hard coded plat_dat->has_gmac4 = 1 then gives
you problems.

Correct?

An explanation like this needs to be added to the commit message
however you solve it in the end, because your current commit message
does not explain the problem you are trying to solve.

You already have:

struct ethqos_emac_driver_data {
        const struct ethqos_emac_por *por;
        unsigned int num_por;
        bool rgmii_config_loopback_en;
        bool has_emac_ge_3;
        const char *link_clk_name;
        bool has_integrated_pcs;
        u32 dma_addr_width;
        struct dwmac4_addrs dwmac4_addrs;
        bool needs_sgmii_loopback;
};

static const struct of_device_id qcom_ethqos_match[] = {
        { .compatible = "qcom,qcs404-ethqos", .data = &emac_v2_3_0_data},
        { .compatible = "qcom,sa8775p-ethqos", .data = &emac_v4_0_0_data},
        { .compatible = "qcom,sc8280xp-ethqos", .data = &emac_v3_0_0_data},
        { .compatible = "qcom,sm8150-ethqos", .data = &emac_v2_1_0_data},
        { }
};

This has has_emac_ge_3. I think it is much cleaner to add has_gmac4
and has_xgmac to ethqos_emac_driver_data, so you have a clear link to
the compatible.

	Andrew
diff mbox series

Patch

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index 901a3c1959fa..2f813f7ab196 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -872,6 +872,8 @@  static int qcom_ethqos_probe(struct platform_device *pdev)
 	plat_dat->dump_debug_regs = rgmii_dump;
 	plat_dat->ptp_clk_freq_config = ethqos_ptp_clk_freq_config;
 	plat_dat->has_gmac4 = 1;
+	if (plat_dat->has_xgmac)
+		plat_dat->has_gmac4 = 0;
 	if (ethqos->has_emac_ge_3)
 		plat_dat->dwmac4_addrs = &data->dwmac4_addrs;
 	plat_dat->pmt = 1;