arm/arm64: dts: adi: sc59x: fix I2C and CRC nodes

[jiez]

This patch does the following:

• sc594-som.dtsi and sc598-som.dtsi: remove useless code

• sc59x.dtsi: add i2c3/4/5 nodes; fix register block length in i2c controller nodes; fix register block base address, register block length, interrupt number in crc0 and crc1 nodes; add crc2 and crc3.

• sc59x-64.dtsi: fix register block length for crc0 and crc1; add crc2 and crc3; add crc2_dma and crc3_dma in crc_cluster.

PR Description

• Please replace this comment with a summary of your changes, and add any context
  necessary to understand them. List any dependencies required for this change.
• To check the checkboxes below, insert a 'x' between square brackets (without
  any space), or simply check them after publishing the PR.
• If you changes include a breaking change, please specify dependent PRs in the
  description and try to push all related PRs simultaneously.

PR Type

• Bug fix (a change that fixes an issue)
• New feature (a change that adds new functionality)
• Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

• I have conducted a self-review of my own code changes
• I have compiled my changes, including the documentation
• I have tested the changes on the relevant hardware
• I have updated the documentation outside this repo accordingly
• I have provided links for the relevant upstream lore

[pamolloy]

Can you also look for other commented blocks like this and clean them up? 🙏

[pamolloy]

Please split the CRC changes into a separate commit. How did you come across the fact that the addresses were wrong and that there are two missing nodes? Is this the same in U-Boot? And where did you get the new interrupt numbers?

[jiez]

Because 0x31001200 is the base address of i2c5. So crc0 cannot have the same base address. When looking for the correct address in the manuals, I noticed that sc59x has 4 CRC devices while sc57x and sc58x have only 2. U-Boot does not have CRC devices in sc5xx devicetree files. All information are from the latest processor hardware reference manuals.

[nunojsa]

On top of Philip's comments, we should have one patch for ARM and another for arm64.

[jiez]

On top of Philip's comments, we should have one patch for ARM and another for arm64.

Why?

[nunojsa]

Basically because in linux we want self contained commits when possible. Like per arch, subystem, file... It likely does not apply/matter here but imagine you wanted to backport, apply this commit somewhere else only on ARM. You would need to take care about the arm64 changes.

[jiez]

Basically because in linux we want self contained commits when possible. Like per arch, subystem, file... It likely does not apply/matter here but imagine you wanted to backport, apply this commit somewhere else only on ARM. You would need to take care about the arm64 changes.

I don't see the possibility of this scenario. In what situation we will want to backport this change only on ARM but not ARM64?

[nunojsa]

I don't see the possibility of this scenario. In what situation we will want to backport this change only on ARM but not ARM64?

As I said, "...It likely does not apply/matter here...". But this is about processes and best practices. Up to you and Philip anyways 🤷‍♂️