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 <[email protected]>
---
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
--
2.17.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 <[email protected]>
> ---
> 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/[email protected]/
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
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.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
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.
--
Regards,
Ravi
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.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D