On 12/19/2019 4:58 AM, Daniel Schwierzeck wrote:
Hi Andre,
Am 19.12.19 um 12:42 schrieb Andre Przywara:
On Thu, 19 Dec 2019 12:32:06 +0100 Daniel Schwierzeck daniel.schwierzeck@gmail.com wrote:
Hi Daniel,
many thanks for your valuable comments! Do you have access to a MIPS board using a GENETv5 MAC? I would be very curious to see if the driver works there, and am happy to make adjustments.
No, I have not. I was only triggered by your commit message that this MAC is also used on some MIPS based Broadcom SoC's ;)
GENET v1, v2 and v3 are used exclusively used on MIPS-based Broadcom STB chips. GENET v4 is used exclusively used on ARM (32-bit) Broadcom STB chips and finally GENET v5 is used exclusively used on ARM 64-bit based chips, including 2711. Unlike other peripherals (SPI, NAND, I2C, Ethernet switches and PHYs) this Ethernet MAC is only used on STB chips and no other business unit within Broadcom has used it AFAICT so the chances of finding GENET in a non STB chips are close to zero at this point.
The GENET data path goes through a proprietary bus called SCB which for MIPS and ARM 32-bit was configurable to be little, big or automatically follow the CPU's endian which is the default. With the latest 64-bit ARM chips it was decided to drop the endian configuration and hard code the bus to be little endian. The register interface goes through a proprietary bus called GISB which always follows the CPU's endian and is not configurable AFAICT (there are other properties, like no re-ordering, no posting, which is why "raw" accessors are correct, too). Therefore using native endian accessors is the right thing to do here to guarantee maximum portability between all SoCs where this controller can be used.
Only MIPS-based STB chips support a boot strap to select the CPU's endian and when that happens the SCB and GISB buses remain native endian as indicated earlier. We did some work to ensure that an ARM BE kernel would work:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...
but that was just for making sure there were no obvious problem and is not a configuration we support or want to support and only the kernel and userland were made BE for testing, it was booted from the LE boot loader.
Does your board use a PHY connected via RGMII? Because this is something we are relying on at the moment. But without any ways of testing this I'd rather not support other transports at this time.
I think your points below are all valid, so thanks for bringing this up. Will test this later on and post a v2 in due time then.
We had a similar scenario a few months ago, where a newly supported ARM based Broadcom SoC could simply reuse various drivers initially added for MIPS based Broadcom SoC's. So if someone wants to use your driver with a MIPS based Broadcom SoC in the future, likely some tweaking of the driver is required. But at least the basic cross-arch compatibility should be given.
Agreed. I am not sure if such a situation will ever arise in the future because those MIPS-based chips are reasonably old now, and few if any people have shown interest in using something different than CFE (Broadcom's own boot loader) or their own third stage, but hey, someone might see the light at some point :).