Add genet driver for Raspberry Pi 4B Ethernet

[• karels]

Summary

Add driver for Broadcom "GENET" version 5, as found in BCM-2711 on
Raspberry Pi 4B. The driver is derived in part from the bcmgenet.c
driver in NetBSD, along with bcmgenetreg.h.

Test Plan

Tested by several alpha testers

[manu]

sys/arm64/broadcom/genet/if_genet.c

313

You need to release the resource before returning here.

350

We have mii_fdt_get_contype in sys/dev/mii/mii_fdt.c for this.

sys/conf/files.arm64

182

optional SOC_BRCM_BCM2838 fdt genet

[kevans]

I see what you mean now about gen_setup_extres() having been useless for your purposes -- the problem is that our RPi stuff doesn't use the extres clk framework like it should, so these clk/hwreset may be found in the FDT but they aren't locally registered like the framework's expecting. This scared me at first, and it still kinda sucks, but that's baggage that predates your work on this.

[val_packett.cool]

would be nice to split the FDT attachment into a separate if_genet_fdt file already, since we know if_genet_acpi will eventually come (here's the acpi table)

[skibo]

sys/arm64/broadcom/genet/if_genet.c

1180–1183

Weird indentation. Is this leftover debug code?

[• karels]

@greg: I'm not quite sure how the FDT/ACPI split should be done; I think that will have to wait for another time.

sys/arm64/broadcom/genet/if_genet.c

313

Which resource?

350

Thanks, fixed in next iteration.

1180–1183

Yes, thanks Removed in next iteration.

[• karels]

Updates based on review comments, including teardown after failed attach.

[manu]

In D24436#538192, @greg_unrelenting.technology wrote:

would be nice to split the FDT attachment into a separate if_genet_fdt file already, since we know if_genet_acpi will eventually come (here's the acpi table)

Agreed, even if this could be done later it would be better to split now.

[manu]

sys/arm64/broadcom/genet/if_genet.c

333

Why not make this function a complete detach ?
This would also help for dev/test by only compiling this driver as a module.

376

It always returns 0 even if we cannot parse the phy mode, please return 1 here in case of an error.

518

This function return void but can fail, if bus_dma* calls fails we will still attach but the interface wouldn't be usable. Better return the error code and handle that in attach().

582

bus_dmamap_destroy can fails, I think that there is nothing that we can do if it fails but a warning printf would be nice.

586

Same for bus_dma_tag_destroy

1655

that doesn't seem right

[• karels]

Is there an existing example of FDT / ACPI split to use as a model?

[• karels]

About doing a full detach: then code is needed to undo the init routine, and there are far more failure modes. I'll look at it though.

[manu]

In D24436#538847, @karels wrote:

Is there an existing example of FDT / ACPI split to use as a model?

You could have a look at sys/dev/usb/controller/generic_ehci*

[maciphone2_googlemail.com]

In D24436#538847, @karels wrote:

Is there an existing example of FDT / ACPI split to use as a model?

If you want, you could take a look at the following . Thank you :

https://marc.info/?l=openbsd-tech&m=158670721506367&w=2
https://marc.info/?l=openbsd-tech&m=158653301620637&w=2
https://marc.info/?l=openbsd-tech&m=158653487221337&w=2

[• karels]

Address more review comments; fix bug with bpf and txcsum.

Notes:

I started a version with full detach; it is not working correctly yet.

I looked at the FDT/ACPI versions of the generic ehci; is there any
documentation of how inheritance works? I think moving to that framework
would take me a while, so I'm favoring lazy evaluation at the moment.

[manu]

In D24436#538986, @karels wrote:

Address more review comments; fix bug with bpf and txcsum.

Notes:

I started a version with full detach; it is not working correctly yet.

What is the problem exactly ?

I looked at the FDT/ACPI versions of the generic ehci; is there any
documentation of how inheritance works?

I'm not sure ...

I think moving to that framework would take me a while, so I'm favoring lazy evaluation at the moment.

I'm not even sure that we could boot RPI4 with ACPI right now so I guess it's ok to leave this for now.

[manu]

This looks good for me now, I've not tested the driver as I don't have the hardware but all my comments are now resolved.
Thanks for doing this port.

[• karels]

In D24436#539201, @manu wrote:

In D24436#538986, @karels wrote:

Address more review comments; fix bug with bpf and txcsum.

Notes:

I started a version with full detach; it is not working correctly yet.

What is the problem exactly ?

I started with code to "stop" on ifconfig down, then re-init on "up". The plan was to use "stop" to undo all the running state, like flushing rings, when doing detach. It was no longer crashing, but not working after re-init.

I looked at the FDT/ACPI versions of the generic ehci; is there any
documentation of how inheritance works?

I'm not sure ...

I think moving to that framework would take me a while, so I'm favoring lazy evaluation at the moment.

I'm not even sure that we could boot RPI4 with ACPI right now so I guess it's ok to leave this for now.

Thanks, that seems best to me too.

I will wait until tomorrow for any other comments, then commit if there is nothing significant/unfixed.