[PATCH 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Florian Fainelli]

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 at 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/?id=69d2ea9c798983c4a7157278ec84ff969d1cd8e8

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 :).
-- 
Florian