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

[Andre Przywara <andre.przywara@arm.com>]

On Thu, 19 Dec 2019 13:58:24 +0100
Daniel Schwierzeck <daniel.schwierzeck@gmail.com> wrote:

Hi Daniel,

> 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 ;)

Well, actually I am not sure about it, I just saw *previous* generations (up to v3) used in MIPS .dts files in the kernel. Might as well be that v5 was never used with a MIPS core.
 
> > 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.

Yeah, and especially the fdt vs. ofnode comments were very justified.

One thing I was wondering about: on ARM the bus is always little-endian, regardless of the current CPU state. That's why we routinely use _le32 function for hardware accesses. A comment in the Linux driver[1] suggests that this is not the case for MIPS, do you know anything about it?
I used the native endian version as you suggested, as I am not aware that anyone is running U-Boot in BE on ARM.

So I addressed your comments already, you can have a look here [2] (top three commits).
I will try if I can fix some of the known shortcomings (PHY timeout etc) before posting a v2.

Cheers,
Andre.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/broadcom/genet/bcmgenet.c#n72
[2] https://github.com/apritzel/u-boot/commits/rpi4-eth