[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231018154448.vlunpwbw67xeh4rj@unfasten>
Date: Wed, 18 Oct 2023 10:44:48 -0500
From: Nishanth Menon <nm@...com>
To: Ravi Gunasekaran <r-gunasekaran@...com>,
Neha Malcom Francis <n-francis@...com>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
<pabeni@...hat.com>, <rogerq@...com>, <andrew@...n.ch>,
<f.fainelli@...il.com>, <horms@...nel.org>,
<linux-omap@...r.kernel.org>, <netdev@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <srk@...com>,
Thejasvi Konduru <t-konduru@...com>,
<linux-arm-kernel@...ts.infradead.org>, <u-kumar1@...com>
Subject: Re: [PATCH net-next] net: ethernet: ti: davinci_mdio: Fix the
revision string for J721E
On 19:30-20231018, Ravi Gunasekaran wrote:
> Prior to the commit 07e651db2d78 ("soc: ti: k3-socinfo: Revamp driver
> to accommodate different rev structs"), K3 SoC's revision was
> interpreted as an incremental value or one-to-one mapping of the
> JTAG_ID's variant field. Now that the revision mapping is fixed,
> update the correct revision string for J721E in k3_mdio_socinfo,
> so that MDIO errata i2329 is applied for J721E SR1.1.
>
> Fixes: 07e651db2d78 ("soc: ti: k3-socinfo: Revamp driver to accommodate different rev structs")
> Signed-off-by: Ravi Gunasekaran <r-gunasekaran@...com>
> ---
> drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index 628c87dc1d28..998fe2717cf9 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -519,7 +519,7 @@ static const struct soc_device_attribute k3_mdio_socinfo[] = {
> { .family = "J7200", .revision = "SR1.0", .data = &am65_mdio_soc_data },
> { .family = "J7200", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> { .family = "J721E", .revision = "SR1.0", .data = &am65_mdio_soc_data },
> - { .family = "J721E", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> + { .family = "J721E", .revision = "SR1.1", .data = &am65_mdio_soc_data },
> { .family = "J721S2", .revision = "SR1.0", .data = &am65_mdio_soc_data},
> { /* sentinel */ },
> };
>
> base-commit: 2dac75696c6da3c848daa118a729827541c89d33
Uggh.. This is a bit of chicken or hen problem here that creates
bisectability issues (thanks for linux-next for exposing this).
Neha's patch I picked up is a valid fix, though this side effect was
unfortunate.
My suggestion is:
a) I will drop
https://lore.kernel.org/all/20231016101608.993921-4-n-francis@ti.com/
from my queue for this window.
b) please identify other places where we could have this situation.
https://www.ti.com/lit/pdf/spruiu1 seems to indicate just SR1.0 for
J7200.
We then have the following steps potentially
Drop the fixes and Maintain both SR2.0 and SR1.0 (add SR1.1) so that
we can merge the socinfo fixes without breaking bisectability.
To merge, the following options exist:
A) netdev maintainers could provide me an rc1 based immutable tag
B) if netdev maintainers can give me a ack to carry this patch(or patch
series for relevant SoCs) on my tree, I can apply the fixes before
picking up the socinfo fixups.
C) I can wait a kernel window to the nearest rc1 *after* netdev fixes
are merged in to pick up socinfo fix.
Once A/B/C is done (I would like netdev maintainers to suggest which way
to go), we can drop the "invalid" SoC SR ID.
I don't see a cleaner way to get this inter-dependency integrated.
Also in the future, please CC me as the reporter and for Soc-fixes
dependency issues (I am listed in the MAINTAINERS file).
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
Powered by blists - more mailing lists