Already integrated; I believe this can be abandoned?

Minor issue related to the module build when testing against BCM4331.

Looks good, just inlined two minor comments.

Other than some minor style(9) issues to be fixed, looks good to me. Thanks for fixing these!

Looks good, just some minor comments inlined.

• Rebased against HEAD
• Fix typo in BCM4706 quirk hwrev.
• Re-enable the PCIe-G2 quirk table.

Based on feedback, lift a number of chipc subroutines out into chipc_subr.c

Re-integration of chipc_cap handling

Fix a typo helpfully caught by gcc/tinderbox.

When vending siba(4) region addresses, ensure that the port address range matches the resource defaults.

Drop extraneous changes to bhndb that break the i386 build.

Implement port-based management/proxying of bhnd_chipc SYS_RES_MEMORY resource mappings.

Based on IRC conversation, the plan here is:

Added BCM43602 note.

Inline replies. I'll submit a new diff fixing that typo in a bit.

Manually generated patch with git rename tracking disabled, applies cleanly against SVN.

Rebased against HEAD.

• Fix spelling in comment.

Thanks; fixed and rebased against HEAD.

• Merge branch 'master' into arcpatch-D6312
• Drop sh accidentally added in master to the dependency lines in sys/conf/files.
• Adopt AWK:- default value syntax recommended by emaste.

Inlined a number of bus-related comments; apologies, I still haven't had time to look at the chipcbus resource handling in enough detail.

Should this live in sys/mips/broadcom?

In D6248#134154, @mizhka_gmail.com wrote:

In D6248#134084, @landon_landonf.org wrote:

It should be possible to unify these as a single bcma_nexus driver that attaches to the mips nexus, and rely on the default/inherited implementation for most of these methods.

In the case of BHND_BUS_IS_HW_DISABLED, the default null implementation will be a problem (it panic()s); you could modify it to return false instead.

I should be able to run this locally on a MIPS device in the next couple days, at which point I can also help take a look at any issues in bhnd.

Default BHND resource activation is also good topic for discussion. Now it's call propagation to parent and fail if no parent. To avoid bhnd_soc, it also requires change.

Looks good to me.

It should be possible to unify these as a single bcma_nexus driver that attaches to the mips nexus, and rely on the default/inherited implementation for most of these methods.

If @adrian is OK with the BHND_LOGLEVEL addition to sys/conf, the rest looks good to me.

Looks good to me. Tested against a BCM4331 bridged device.

Can you verify against HEAD and abandon/update as necessary?

• Add support for generating a set of #defines for all bhnd(4) NVRAM variable keys.
• Allow ChipCommon to attach when OTP or NFLASH SPROM sources are identified.
• Rename the bhnd_nvram_* variable functions (modeled on the OF_prop* API).
• When generating nvram map headers, truncate any existing output file.
• Add an explicit fallback cases for unmatched enums.
• Re-integrate module dependency that went missing in a merge.

Drop duplicate prototype introduced in merge.

Remote extra deltas pulled in by arc in last update.

• Rebase against master
• Integrate missing bus read/write method references (merge issue caught by tinderbox).

I like the broken out caps structure.

Sweet. I just had some minor comments, in addition to the style(9) stuff.

mizkha: when you get a chance, can you eyeball this for any issues on the SoC side?

Can you do a style(9) rework of this one?

Other than minor style(9) whitespace and prefixing the macro names, looks good.

Other than minor style(9) issue, looks good to me.

If you rebase against HEAD, adrian fixed all of these upstream yesterday.

Optimize NVRAM table lookup, rebase against master.

Minor spelling fix.

Fix merge issue in device match table.

Minor spelling fix

rebased against HEAD

Fix matching of the ChipCommon device (corrected diff).

Fix matching of the ChipCommon device.

In D5633#120413, @mizhka_gmail.com wrote:

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

Requested changes inline as source comments; sorry for the delay, I accidentally left my comments unsubmitted (I'm new to phabricator too).

Based on our IRC discussions about implementing a bhnd_(nexus|fdt|etc) directly, I'm assuming this can be closed.

Minor issues aside, LGTM.

I'm ambivalent about adding line history to drop trailing whitespace, so I'll let @adrian decide.

Other than the minor /**, looks good to me.

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.

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.

Install the mdio(4) man page.

Enable mdio(4) module.