diff mbox series

[net-next] net: ethernet: ti: davinci_mdio: Fix the revision string for J721E

Message ID 20231018140009.1725-1-r-gunasekaran@ti.com (mailing list archive)
State Deferred
Delegated to: Netdev Maintainers
Headers show
Series [net-next] net: ethernet: ti: davinci_mdio: Fix the revision string for J721E | expand

Checks

Context Check Description
netdev/series_format success Single patches do not need cover letters
netdev/tree_selection success Clearly marked for net-next
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 1363 this patch: 1363
netdev/cc_maintainers warning 6 maintainers not CCed: grygorii.strashko@ti.com u.kleine-koenig@pengutronix.de michael@walle.cc wei.fang@nxp.com geert+renesas@glider.be robh@kernel.org
netdev/build_clang success Errors and warnings before: 1388 this patch: 1388
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes fail Problems with Fixes tag: 1
netdev/build_allmodconfig_warn success Errors and warnings before: 1388 this patch: 1388
netdev/checkpatch warning WARNING: Unknown commit id '07e651db2d78', maybe rebased or not pulled?
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0

Commit Message

Ravi Gunasekaran Oct. 18, 2023, 2 p.m. UTC
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@ti.com>
---
 drivers/net/ethernet/ti/davinci_mdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: 2dac75696c6da3c848daa118a729827541c89d33

Comments

Nishanth Menon Oct. 18, 2023, 3:44 p.m. UTC | #1
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@ti.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).
Jakub Kicinski Oct. 18, 2023, 5:52 p.m. UTC | #2
On Wed, 18 Oct 2023 10:44:48 -0500 Nishanth Menon wrote:
> A) netdev maintainers could provide me an rc1 based immutable tag

FWIW that shouldn't be a problem, assuming my script to do so didn't
bit rot :)

Does it really have to be rc1 or something more recent would work?
Nishanth Menon Oct. 18, 2023, 6 p.m. UTC | #3
On 10:52-20231018, Jakub Kicinski wrote:
> On Wed, 18 Oct 2023 10:44:48 -0500 Nishanth Menon wrote:
> > A) netdev maintainers could provide me an rc1 based immutable tag
> 
> FWIW that shouldn't be a problem, assuming my script to do so didn't
> bit rot :)
> 
> Does it really have to be rc1 or something more recent would work?

Thanks Jakub. SoC tree needs me to send based off rc1 for new features.
I'd rather not mess with that.

Sure if we are doing an fixes pull, we can figure something out to
sync. rc1 saves us the headache of conflict of me sending a PR merge
while netdev maintainers aren't expecting it to be merged to master
via soc tree.
Jakub Kicinski Oct. 18, 2023, 6:16 p.m. UTC | #4
On Wed, 18 Oct 2023 13:00:35 -0500 Nishanth Menon wrote:
> Thanks Jakub. SoC tree needs me to send based off rc1 for new features.
> I'd rather not mess with that.
> 
> Sure if we are doing an fixes pull, we can figure something out to
> sync. rc1 saves us the headache of conflict of me sending a PR merge
> while netdev maintainers aren't expecting it to be merged to master
> via soc tree.

Sounds good, I'll wait for Ravi to respond to you and once we have 
a green light we can plonk the patch on top of rc1.
Ravi Gunasekaran Oct. 19, 2023, 5:41 a.m. UTC | #5
Nishanth, Jakub,

On 10/18/23 9:14 PM, Nishanth Menon wrote:
> 
> 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.

I will drop the fixes tag then and maintain SR1.0, SR1.1, SR2.0 for J721E
and mention in the commit msg that this is a preparatory patch to fix the
incorrect revision string generation. And in the next cycle, I will
send out a patch removing the invalid revision IDs.

Ideally I would prefer to do this for all the SoCs, but I would need some
time to compile the list. So for now, I will send a v2 targeting only J721E.

Please let me know your thoughts on this.

> 
> Also in the future, please CC me as the reporter and for Soc-fixes
> dependency issues (I am listed in the MAINTAINERS file).
> 
Sure.
Nishanth Menon Oct. 19, 2023, 5:23 p.m. UTC | #6
On 11:11-20231019, Ravi Gunasekaran wrote:
> Nishanth, Jakub,
> 
> On 10/18/23 9:14 PM, Nishanth Menon wrote:
> > 
> > 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.
> 
> I will drop the fixes tag then and maintain SR1.0, SR1.1, SR2.0 for J721E
> and mention in the commit msg that this is a preparatory patch to fix the
> incorrect revision string generation. And in the next cycle, I will
> send out a patch removing the invalid revision IDs.
> 
> Ideally I would prefer to do this for all the SoCs, but I would need some
> time to compile the list. So for now, I will send a v2 targeting only J721E.
> 
> Please let me know your thoughts on this.

just do the full list in one shot. it is easier that way than having to
repeat this sync over and over again.
diff mbox series

Patch

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 */ },
 };