[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5899239a-50c4-46ca-9cd7-43e95d61fe54@lunn.ch>
Date: Fri, 15 Nov 2024 14:22:28 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Sagar Cheluvegowda <quic_scheluve@...cinc.com>
Cc: Vinod Koul <vkoul@...nel.org>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Jose Abreu <joabreu@...opsys.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
linux-arm-msm@...r.kernel.org, netdev@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
kernel@...cinc.com
Subject: Re: [PATCH] net: stmmac: dwmac-qcom-ethqos: Enable support for XGMAC
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
Powered by blists - more mailing lists