I'd break this patch up into more pieces - notably, I'd do the union / naming change first (ie, 'win_spec') as that's one big no-op. I'd do a separate patch that's just whitespace changes, because you did fix a bunch of those. That's also a no-op. Those can both be easily reviewed and committed asap.

Then yeah, the rest of it!

In D5633#120272, @adrian wrote:

I'd break this patch up into more pieces - notably, I'd do the union / naming change first (ie, 'win_spec') as that's one big no-op. I'd do a separate patch that's just whitespace changes, because you did fix a bunch of those. That's also a no-op. Those can both be easily reviewed and committed asap.

+1 on breaking things up.

The fixed window support here is actually just working around bhndb's intended role as a mediator between the host and WiFi chipsets running with their PCI core (and PCMCIA, etc.) in endpoint mode.

On a SoC you don't need to mediate access to bhnd resources via a bridge translation layer, and bhndb is just dead weight.

Instead, you should add a bcma_fdt or bcma_nexus subclass of the bcma driver (living along-side bcma_bhndb), in which you'd simply pass resource requests directly to the bus nexus/fdt/etc.

You can find an (untested) example of this in dev/bhnd/siba/siba_nexus.c; this is a direct port of Bruce Simpson's sentry5 siba_nexus.c to bhnd(4).

Additionally, you may want to make use of the resource API improvements I've been working on: https://github.com/freebsd/freebsd/commit/2755090e79a70ef494f40b408a238b659355a1ec

This should allow you to implement bhnd_resource* handling in your bcma_nexus.c by adding a generic BHND_BUS_ACTIVATE_RESOURCE implementation that passes through to BUS_ACTIVATE_RESOURCE.

@adrian : would it make sense to add a phabricator review for these resource changes, and then @mizhka_gmail.com can weigh in directly on any issues he has making use of them? Coordinating across my repo and upstream is going to take some figuring out and process changes on my part.

@landon_landonf.org ,
Your commit looks interesting ))) very interesting.

bridge vs. subclass: I've tried both ways and bridge looks easy.
For instance, bcma_attach calls BHND_ALLOC_RESOURCE of parent device and if parent is nexus, not bridge, this method is bhnd_generic_alloc_bhnd_resource. It calls bhnd_get_port_rid which returns -1 and causes KASSERT fail. This is just one example.
The bridged way is more tested and more stable. So I can create hierarchy nexus -> bhnd_soc -> bhndb_nexus -> bcma and just implement required methods. Main advantage of this schema is flexibility and readability.

BTW, I'll split this diff into separate patches. Please reject it (sorry, I didn't find such button).

In D5633#120413, @mizhka_gmail.com wrote:

@landon_landonf.org ,
Your commit looks interesting ))) very interesting.

bridge vs. subclass: I've tried both ways and bridge looks easy.
For instance, bcma_attach calls BHND_ALLOC_RESOURCE of parent device and if parent is nexus, not bridge, this method is bhnd_generic_alloc_bhnd_resource. It calls bhnd_get_port_rid which returns -1 and causes KASSERT fail. This is just one example.
The bridged way is more tested and more stable. So I can create hierarchy nexus -> bhnd_soc -> bhndb_nexus -> bcma and just implement required methods. Main advantage of this schema is flexibility and readability.

I can't support both WiFi bridge core use and SoC nexus use of bhndb without it becoming too unwieldy. The bridge code is built to translate host resources for use by WiFi/SoC-agnostic core drivers, and mediate/prioritize access to over-committed bridge resource mappings, all to present what we get for free on a SoC. Everything from DMA to interrupts would require special-casing just to disable bhndb's translation/mediation (as is the case with BHNDB_REGWIN_T_FIXED).

Additionally, the bhndb_hwcfg mechanism by bhndb provides just enough abstraction for handling bhnd bridge core's register windows, but the more complex device resource specifications required by Broadcom SoC-based devices is going to make FDT a necessity anyway:

http://xref.plausible.coop/source/xref/linux-master/arch/arm/boot/dts/bcm5301x.dtsi

http://xref.plausible.coop/source/xref/linux-master/Documentation/devicetree/bindings/bus/brcm%2Cbus-axi.txt