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