NICE!!! :)

Generally speaking, I'm happy with patch. The only thing I worry is CD9660 image (inspired by ZRouter) vs. UFS1 zipped image (inspired by freebsd-wifi-build). This patch is based on CD9660 and it can be committed, but in future it will be nice to support both image types.

@sgalabov , could you please have a look? Thanks!

Of course I like it. More broadcom features. I hope to see ARM BHND support in future :) I'll cross fingers before start rebase

In D8749#182206, @yamori813_yahoo.co.jp wrote:

Why delete my added gpio_delay() in gpiospi.c ? My KSZ8995MA code don't work no gpio_delay() on my target. I think current code clock is wrong.

Thanks for your contribution!

Thank you, Hiroki-san!

@yamori813_yahoo.co.jp , could you please test this commit? It's slightly different from your version, I've checked compilation and i want to be sure that nothing from functional part is broken. Thanks in advance

Rebased to -HEAD

Closed

Abandon this revision. need to find more flexible way

In D8344#177280, @adrian wrote:

I'm happy with his going into the tree as-is. We can always unify these drivers more later.

Would someone mind please committing this to -head?

@yamori813_yahoo.co.jp , do you have plan to merge it with e6000sw or add VLAN support?

(?) I wonder what is tested KERNCONF :)
(?) any documentation source?
(+) Patch is fine against -HEAD

(*) Small improvements are welcome (@ray, @adrian comments)
(+) Patch is fine against current -HEAD
(+) Build has been compiled via freebsd-wifi-build/tl-wr1043nd

1. I see some "magic" constants. May be worth to add macros.
2. DPRINTF usage: it prints function name on each call, is it useful/enough useful?
3. "style(9)": ADM6996FC_READREG/WRITEREG - to be tab instead of space
4. No checks on malloc results, may be NULL.
5. Probe: can you add array of IDs to match. In future it will be easy to add IDs into array to bring support of another models.

Hi @adrian, @loos. Is there any way to make automatic check diff against style(9)?

Please ship it!

Thank you! Already on github: https://github.com/freebsd/freebsd/commit/2a1c75d8f2f60bf398ad401e6cde49562f938564. Time to rebase ;)

I would call bcm_mips4k instead of bcm_mips.

Also please land sketches for items mentioned by you in parallel review request

In D7775#161359, @landonf wrote:

This patch is written in parallel with D7769, but it doesn't interfere with it. IMHO, some work should be done to marry them :)

Once the INTRNG regression got ironed out, my thinking around D7769 was:

• Move (bhnd|siba|bcma|)_nexus into sys/mips/broadcom so that we can depend directly on MIPS-specific behavior. There's very little code there, and making it arch-specific simplifies things.

Quick check on Broadcom 4716.

Looks fine. Let's land it :)

• style(9) change
• no functional change

new style of bhnd_set_default_core_desc is nice. Abandoning this rev...

In D6988#146662, @landonf wrote:

The command "reboot" hangs on Asus RT-N53. It worked before, so fix is simple: watchdog must be triggered always on shutdown.

This will break on non-PMU-equippped devices (e.g. WGT634U), and more recent Broadcom devices that map the PMU register block via a dedicated core instead of ChipCommon; if we can't use CFE, we have to look at the ChipCommon core revision + capability flags + device table.

Do you mean "throw exception" under "break"?

TC: run "reboot"
AR: hang

If you break to debugger (sysctl debug.kdb.panic=1) and issue a 'reset' command, the same code path succeeds; any idea why CFE is failing here?

Because CFE is unreliable thing :) CFE is generic word, too many builds, versions, hacks and so on. The less used CFE features, the less pain :)

• fixed typo in macro name
• timeout variable

• fixed according to review remark: usage of cast instead of #define case

• usage of macros from bcma_dmp.h instead of new ones
• added status checks

In D6920#145338, @landonf wrote:

In addition to inline comments, if you happen to feel like implementing the nearly identical bcma_suspend_core(), I wouldn't say no :-)

In D6880#145236, @landonf wrote:

In D6880#144503, @mizhka_gmail.com wrote:

In D6880#144475, @landonf wrote:

I believe the the switch type can be determined via the NVRAM boardflags:

• BFL_ENETADM (ADMtek switch)
• BFL_ENETSPI (SPI roboswitch)
• BFL_ENETVLAN (VLAN support for either)

I'd like the bhnd-attached drivers to identify the child device configuration locally, and then provide that in a generic form to their children, so that we can limit the CHIPID switch statements and NVRAM variable dependencies to a few central places that use the declarative device tables, and avoid hard dependencies on bhnd(4) API in (potentially non-bhnd-specific) devices attached to the device tree well below the bhnd(4) cores.

Yes, it allow to identify bus of etherswitch, but not model.

From what I remember of the ISC-licensed Broadcom code, there may some quirks to reading the etherswitch device ID, but it /should/ be readable.

We need to know Chip ID because different chips has different register layout. For instance, BCM5325 and BCM5358 are very-very close, but has crucial difference in one bit -"VLAN Valid" flag: for BCM5325 it's bit(6), for BCM5358 it's bit(7). (BCM5325 can be external/integrated, BCM5358 is integrated). As result, BCM5325 code fails on BCM5358 and vice versa.

To be honest, there are many families of BroadCom ethernet switches, B53xx is subclass, mostly used in home routers.
As possible solution, we can put ChipId in independent place (i.e. not-BHND-specific), for instance, kernel environment variable.

Rather than a global variable (i.e. kenv), my recommendation would to be pass down what you need from the ethernet driver itself; that way the interface between ethernet and switch driver can be independent of the bhnd bus, and we're not creating dependencies on global state populated by bhnd.

I also want to solve CFI issue on RT-N16, hope Alex will look on it.
My laziness forced me to code following test for MIPS boards:

• CFE load kernel
• login as root
• call devinfo, uname, hostname, ifconfig

Superb!

I've scan changes briefly:

• what is test strategy? is it just kernel loading or passing over rc to multiuser mode?
• changes are more than announced ;) for instance, flashmap is removed. What is new alternative to flashmap?

Super-nice change. I had a lot of thoughts about it.
I'm asking for few changes in inline comments, but please feel free to ask any question, argue, reject :)

In D6880#144475, @landonf wrote:

I believe the the switch type can be determined via the NVRAM boardflags:

• BFL_ENETADM (ADMtek switch)
• BFL_ENETSPI (SPI roboswitch)
• BFL_ENETVLAN (VLAN support for either)

I'd like the bhnd-attached drivers to identify the child device configuration locally, and then provide that in a generic form to their children, so that we can limit the CHIPID switch statements and NVRAM variable dependencies to a few central places that use the declarative device tables, and avoid hard dependencies on bhnd(4) API in (potentially non-bhnd-specific) devices attached to the device tree well below the bhnd(4) cores.

• move def implementation for BHND_CHIPC_GET_CAPS into bhnd_chipc_if.m

• new sc_buswidth parameter to softc
• scan of configuration for new sc_buswidth parameter