The errata i2329 affects certain K3 SoC versions. The k3-socinfo.c
driver generates the revision string for different variants of the
same SoC in an incremental fashion. This is not true for all SoCs.
An example case being J721E, for which the actual silicon revision
names are 1.0, 1.1 for its variants, while the k3-socinfo.c driver
interprets these variants as revisions 1.0, 2.0 respectively,
which is incorrect.
While the work to fixup the silicon revision string is posted
to the soc tree, this patch serves as a fail-safe step by maintaining
a list of correct and incorrect revision strings, so that the fixup
work does not break the errata workaround for such corrected SoCs.
The silicon revisions affected by the errata i2329 can be found under
the MDIO module in the "Advisories by Modules" section of each
SoC errata document listed below
AM62x: https://www.ti.com/lit/er/sprz487c/sprz487c.pdf
AM64X: https://www.ti.com/lit/er/sprz457g/sprz457g.pdf
AM65X: https://www.ti.com/lit/er/sprz452i/sprz452i.pdf
J7200: https://www.ti.com/lit/er/sprz491d/sprz491d.pdf
J721E: https://www.ti.com/lit/er/sprz455d/sprz455d.pdf
J721S2: https://www.ti.com/lit/er/sprz530b/sprz530b.pdf
Signed-off-by: Ravi Gunasekaran <[email protected]>
---
Changes since v1:
* For J721E, retained the incorrect SR ID and added the correct one
* Add AM65x SR2.1 to the workaround list
v1: https://lore.kernel.org/all/[email protected]/
drivers/net/ethernet/ti/davinci_mdio.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
index 628c87dc1d28..25aaef502edc 100644
--- a/drivers/net/ethernet/ti/davinci_mdio.c
+++ b/drivers/net/ethernet/ti/davinci_mdio.c
@@ -516,9 +516,11 @@ static const struct soc_device_attribute k3_mdio_socinfo[] = {
{ .family = "AM64X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
{ .family = "AM65X", .revision = "SR1.0", .data = &am65_mdio_soc_data },
{ .family = "AM65X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
+ { .family = "AM65X", .revision = "SR2.1", .data = &am65_mdio_soc_data },
{ .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 = "SR1.1", .data = &am65_mdio_soc_data },
{ .family = "J721E", .revision = "SR2.0", .data = &am65_mdio_soc_data },
{ .family = "J721S2", .revision = "SR1.0", .data = &am65_mdio_soc_data},
{ /* sentinel */ },
base-commit: 2030579113a1b1b5bfd7ff24c0852847836d8fd1
--
2.17.1
On 16:47-20231020, Ravi Gunasekaran wrote:
> The errata i2329 affects certain K3 SoC versions. The k3-socinfo.c
> driver generates the revision string for different variants of the
> same SoC in an incremental fashion. This is not true for all SoCs.
> An example case being J721E, for which the actual silicon revision
> names are 1.0, 1.1 for its variants, while the k3-socinfo.c driver
> interprets these variants as revisions 1.0, 2.0 respectively,
> which is incorrect.
>
> While the work to fixup the silicon revision string is posted
> to the soc tree, this patch serves as a fail-safe step by maintaining
> a list of correct and incorrect revision strings, so that the fixup
> work does not break the errata workaround for such corrected SoCs.
>
> The silicon revisions affected by the errata i2329 can be found under
> the MDIO module in the "Advisories by Modules" section of each
> SoC errata document listed below
>
> AM62x: https://www.ti.com/lit/er/sprz487c/sprz487c.pdf
> AM64X: https://www.ti.com/lit/er/sprz457g/sprz457g.pdf
> AM65X: https://www.ti.com/lit/er/sprz452i/sprz452i.pdf
> J7200: https://www.ti.com/lit/er/sprz491d/sprz491d.pdf
> J721E: https://www.ti.com/lit/er/sprz455d/sprz455d.pdf
> J721S2: https://www.ti.com/lit/er/sprz530b/sprz530b.pdf
>
> Signed-off-by: Ravi Gunasekaran <[email protected]>
> ---
>
> Changes since v1:
> * For J721E, retained the incorrect SR ID and added the correct one
> * Add AM65x SR2.1 to the workaround list
>
> v1: https://lore.kernel.org/all/[email protected]/
>
> drivers/net/ethernet/ti/davinci_mdio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> index 628c87dc1d28..25aaef502edc 100644
> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> @@ -516,9 +516,11 @@ static const struct soc_device_attribute k3_mdio_socinfo[] = {
> { .family = "AM64X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> { .family = "AM65X", .revision = "SR1.0", .data = &am65_mdio_soc_data },
> { .family = "AM65X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> + { .family = "AM65X", .revision = "SR2.1", .data = &am65_mdio_soc_data },
> { .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 = "SR1.1", .data = &am65_mdio_soc_data },
> { .family = "J721E", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> { .family = "J721S2", .revision = "SR1.0", .data = &am65_mdio_soc_data},
> { /* sentinel */ },
>
Looks like every device is impacted -> so, why not just flip the
logic to indicate devices that are NOT impacted? is'nt that a smaller
list?
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
On 10/20/2023 5:53 PM, Nishanth Menon wrote:
> On 16:47-20231020, Ravi Gunasekaran wrote:
>> The errata i2329 affects certain K3 SoC versions. The k3-socinfo.c
>> driver generates the revision string for different variants of the
>> same SoC in an incremental fashion. This is not true for all SoCs.
>> An example case being J721E, for which the actual silicon revision
>> names are 1.0, 1.1 for its variants, while the k3-socinfo.c driver
>> interprets these variants as revisions 1.0, 2.0 respectively,
>> which is incorrect.
>>
>> While the work to fixup the silicon revision string is posted
>> to the soc tree, this patch serves as a fail-safe step by maintaining
>> a list of correct and incorrect revision strings, so that the fixup
>> work does not break the errata workaround for such corrected SoCs.
>>
>> The silicon revisions affected by the errata i2329 can be found under
>> the MDIO module in the "Advisories by Modules" section of each
>> SoC errata document listed below
>>
>> AM62x: https://www.ti.com/lit/er/sprz487c/sprz487c.pdf
>> AM64X: https://www.ti.com/lit/er/sprz457g/sprz457g.pdf
>> AM65X: https://www.ti.com/lit/er/sprz452i/sprz452i.pdf
>> J7200: https://www.ti.com/lit/er/sprz491d/sprz491d.pdf
>> J721E: https://www.ti.com/lit/er/sprz455d/sprz455d.pdf
>> J721S2: https://www.ti.com/lit/er/sprz530b/sprz530b.pdf
>>
>> Signed-off-by: Ravi Gunasekaran <[email protected]>
>> ---
>>
>> Changes since v1:
>> * For J721E, retained the incorrect SR ID and added the correct one
>> * Add AM65x SR2.1 to the workaround list
>>
>> v1: https://lore.kernel.org/all/[email protected]/
>>
>> drivers/net/ethernet/ti/davinci_mdio.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
>> index 628c87dc1d28..25aaef502edc 100644
>> --- a/drivers/net/ethernet/ti/davinci_mdio.c
>> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
>> @@ -516,9 +516,11 @@ static const struct soc_device_attribute k3_mdio_socinfo[] = {
>> { .family = "AM64X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
>> { .family = "AM65X", .revision = "SR1.0", .data = &am65_mdio_soc_data },
>> { .family = "AM65X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
>> + { .family = "AM65X", .revision = "SR2.1", .data = &am65_mdio_soc_data },
>> { .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 = "SR1.1", .data = &am65_mdio_soc_data },
>> { .family = "J721E", .revision = "SR2.0", .data = &am65_mdio_soc_data },
>> { .family = "J721S2", .revision = "SR1.0", .data = &am65_mdio_soc_data},
>> { /* sentinel */ },
>>
> Looks like every device is impacted -> so, why not just flip the
> logic to indicate devices that are NOT impacted? is'nt that a smaller
> list?
>
At the moment, the list of unaffected devices is small. But as and when we
introduce more devices,
this list will need update. Also I feel that few years down the line, when
someone looks at the code,
a list of affected devices provides a better context as it is easier to trace it
back to the errata document.
Regards,
Ravi
On 23:35-20231020, Ravi Gunasekaran wrote:
>
>
> On 10/20/2023 5:53 PM, Nishanth Menon wrote:
> > On 16:47-20231020, Ravi Gunasekaran wrote:
> >> The errata i2329 affects certain K3 SoC versions. The k3-socinfo.c
> >> driver generates the revision string for different variants of the
> >> same SoC in an incremental fashion. This is not true for all SoCs.
> >> An example case being J721E, for which the actual silicon revision
> >> names are 1.0, 1.1 for its variants, while the k3-socinfo.c driver
> >> interprets these variants as revisions 1.0, 2.0 respectively,
> >> which is incorrect.
> >>
> >> While the work to fixup the silicon revision string is posted
> >> to the soc tree, this patch serves as a fail-safe step by maintaining
> >> a list of correct and incorrect revision strings, so that the fixup
> >> work does not break the errata workaround for such corrected SoCs.
> >>
> >> The silicon revisions affected by the errata i2329 can be found under
> >> the MDIO module in the "Advisories by Modules" section of each
> >> SoC errata document listed below
> >>
> >> AM62x: https://www.ti.com/lit/er/sprz487c/sprz487c.pdf
> >> AM64X: https://www.ti.com/lit/er/sprz457g/sprz457g.pdf
> >> AM65X: https://www.ti.com/lit/er/sprz452i/sprz452i.pdf
> >> J7200: https://www.ti.com/lit/er/sprz491d/sprz491d.pdf
> >> J721E: https://www.ti.com/lit/er/sprz455d/sprz455d.pdf
> >> J721S2: https://www.ti.com/lit/er/sprz530b/sprz530b.pdf
> >>
> >> Signed-off-by: Ravi Gunasekaran <[email protected]>
> >> ---
> >>
> >> Changes since v1:
> >> * For J721E, retained the incorrect SR ID and added the correct one
> >> * Add AM65x SR2.1 to the workaround list
> >>
> >> v1: https://lore.kernel.org/all/[email protected]/
> >>
> >> drivers/net/ethernet/ti/davinci_mdio.c | 2 ++
> >> 1 file changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/net/ethernet/ti/davinci_mdio.c b/drivers/net/ethernet/ti/davinci_mdio.c
> >> index 628c87dc1d28..25aaef502edc 100644
> >> --- a/drivers/net/ethernet/ti/davinci_mdio.c
> >> +++ b/drivers/net/ethernet/ti/davinci_mdio.c
> >> @@ -516,9 +516,11 @@ static const struct soc_device_attribute k3_mdio_socinfo[] = {
> >> { .family = "AM64X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> >> { .family = "AM65X", .revision = "SR1.0", .data = &am65_mdio_soc_data },
> >> { .family = "AM65X", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> >> + { .family = "AM65X", .revision = "SR2.1", .data = &am65_mdio_soc_data },
> >> { .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 = "SR1.1", .data = &am65_mdio_soc_data },
> >> { .family = "J721E", .revision = "SR2.0", .data = &am65_mdio_soc_data },
> >> { .family = "J721S2", .revision = "SR1.0", .data = &am65_mdio_soc_data},
> >> { /* sentinel */ },
> >>
> > Looks like every device is impacted -> so, why not just flip the
> > logic to indicate devices that are NOT impacted? is'nt that a smaller
> > list?
> >
>
> At the moment, the list of unaffected devices is small. But as and when we
> introduce more devices,
> this list will need update. Also I feel that few years down the line, when
> someone looks at the code,
> a list of affected devices provides a better context as it is easier to trace it
> back to the errata document.
Just handle it with a different compatible if needed. There is no loss
of readability as the check is still readable based on soc_data. but
this removes this entire mess of interdependency of merges completely
out. There are still ROM only spins that are happening and as far as I
see this mess just keeps growing. Alternatively, reading some IP level
version register helps detect the fixed versions, uses that (infact
you should probably insist to the design team to update the revision
for the fix for this very purpose) - that way, the ones that may have
been missed could be limited by soc_data management.
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D